ffsb job does not exit on xfs 4.14-rc1+

[Xiong Zhou]

Hi,

ffsb test won't exit like this on Linus tree 4.14-rc1+.
Latest commit cd4175b11685

This does not happen on v4.13

Thanks,

1  1505  Ss   0   0:00 /usr/sbin/sshd -D
 1505  1752  Ss   0   0:00  \_ sshd: root [priv]
 1752  1762  S0   0:00  |   \_ sshd: root@pts/0
 1762  1763  Ss   0   0:00  |   \_ -bash
 1763  8706  S+   0   0:00  |   \_ /bin/bash -x ./run.sh --daxoff ffsb
 8706 10044  S+   0   0:00  |   \_ /bin/bash -x ./ffsb.sh xfs 
/dev/pmem0 /daxmnt 8099
10044 10053  S+   0   0:00  |   \_ make run
10053 10056  S+   0   0:00  |   \_ /bin/bash -x ./runtest.sh
10056 10167  Sl+  0 21171969:20  |   \_ ffsb 
large_file_creates_threads_192.ffsb
10056 10168  S+   0   0:00  |   \_ tee 
large_file_creates_threads_192.ffsb.out
 

sh-4.4# xfs_info /daxmnt/
meta-data=/dev/pmem0 isize=512agcount=4, agsize=524288 blks
 =   sectsz=4096  attr=2, projid32bit=1
 =   crc=1finobt=1 spinodes=0 rmapbt=0
 =   reflink=0
data =   bsize=4096   blocks=2097152, imaxpct=25
 =   sunit=0  swidth=0 blks
naming   =version 2  bsize=4096   ascii-ci=0 ftype=1
log  =internal   bsize=4096   blocks=2560, version=2
 =   sectsz=4096  sunit=1 blks, lazy-count=1
realtime =none   extsz=4096   blocks=0, rtextents=0

sh-4.4# uname -r
4.14.0-rc1-master-cd4175b11685+

sh-4.4# xfs_io -V
xfs_io version 4.10.0

sh-4.4# ffsb -V
FFSB version 6.0-RC2 started
-V: No such file or directory


# cat large_file_creates_threads_192.ffsb

# Large file creates
# Creating 1 GB files.

time=300
alignio=1
directio=0

[filesystem0]
location=__SCRATCH_MNT__

# All created files will be 1 GB.
min_filesize=1GB
max_filesize=1GB
[end0]

[threadgroup0]
num_threads=192

create_weight=1

write_blocksize=4KB

[stats]
enable_stats=1
enable_range=1

msec_range0.00  0.01
msec_range0.01  0.02
msec_range0.02  0.05
msec_range0.05  0.10
msec_range0.10  0.20
msec_range0.20  0.50
msec_range0.50  1.00
msec_range1.00  2.00
msec_range2.00  5.00
msec_range5.00 10.00
msec_range   10.00 20.00
msec_range   20.00 50.00
msec_range   50.00100.00
msec_range  100.00200.00
msec_range  200.00500.00
msec_range  500.00   1000.00
msec_range 1000.00   2000.00
msec_range 2000.00   5000.00
msec_range 5000.00  1.00
[end]
[end0]

Re: fanotify_mark FAN_MARK_FLUSH | _MOUNT stress blocks write to directory

[Xiong Zhou]

On Thu, Aug 31, 2017 at 07:52:41AM +0300, Amir Goldstein wrote:
> On Thu, Aug 31, 2017 at 6:51 AM, Xiong Zhou  wrote:
> > hi,
> >
> > This happens on 4.13.0-rc7+ to commit 42ff72c
> 
> Don't understand. Is this a regression? from which commit?

No. I'm just saying the exact kernel version: Linus tree, commit 42ff72c

The same on 4.11. Did not test on kernels older than that.

> 
> >
> > After firing up the stress, touch a file in monitoring directory could
> > hang like forever.
> >
> > Pretty easy to hit.
> 
> So are running 3 processes that constantly ask to be notified
> blocking on file system events and then they never read those
> events. Even tough the marks are also destroyed, odd are that
> at least one mark will be alive at any given time.
> 
> Why is it surprising that touching a file in monitored directory
> hangs forever?

It should complete with an error or success in a reasonable time ?

If we keep it hanging, oom killer is online and system hangs.

> 
> I am very happy to see someone is writing stress tests for
> fanotify, I am just not sure this test is tuned correctly.
> Have you been trying to reproduce a reported bug?

No. Just try stress tests.

Xiong

> 
> Amir.
> 
> >
> > Thanks,
> > Xiong
> >
> > [  492.060879] INFO: task touch:2259 blocked for more than 120 seconds.
> > [  492.093497]   Not tainted 4.13.0-rc7-master-42ff72c+ #9
> > [  492.121049] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables 
> > this message.
> > [  492.156289] touch   D0  2259   2233 0x0080
> > [  492.180880] Call Trace:
> > [  492.191813]  __schedule+0x28d/0x890
> > [  492.207440]  schedule+0x36/0x80
> > [  492.221529]  fanotify_handle_event+0x2a1/0x2f0
> > [  492.241542]  ? remove_wait_queue+0x60/0x60
> > [  492.260150]  fsnotify+0x2d3/0x4f0
> > [  492.275055]  ? security_inode_init_security+0xd2/0x190
> > [  492.298097]  security_file_open+0x89/0x90
> > [  492.316038]  do_dentry_open+0x139/0x330
> > [  492.333216]  vfs_open+0x4f/0x70
> > [  492.347225]  ? may_open+0x5a/0x100
> > [  492.362481]  path_openat+0x548/0x13b0
> > [  492.378958]  do_filp_open+0x91/0x100
> > [  492.394969]  ? __alloc_fd+0x46/0x170
> > [  492.410930]  do_sys_open+0x124/0x210
> > [  492.426927]  SyS_open+0x1e/0x20
> > [  492.440963]  do_syscall_64+0x67/0x150
> > [  492.457367]  entry_SYSCALL64_slow_path+0x25/0x25
> > [  492.478251] RIP: 0033:0x7fe877f8e5a0
> > [  492.495755] RSP: 002b:7ffe57120318 EFLAGS: 0246 ORIG_RAX: 
> > 0002
> > [  492.529911] RAX: ffda RBX: 7ffe57120578 RCX: 
> > 7fe877f8e5a0
> > [  492.561508] RDX: 01b6 RSI: 0941 RDI: 
> > 7ffe5712268c
> > [  492.595577] RBP:  R08:  R09: 
> > 
> > [  492.631144] R10: 7ffe57120030 R11: 0246 R12: 
> > 7ffe5712268c
> > [  492.664970] R13: 7fe8782612a0 R14: 0001 R15: 
> > 
> >
> >
> > 
> > $ cat test.sh
> >
> > #!/bin/bash -x
> >
> > fallocate -l 2G test.img
> > mkfs.xfs -fq test.img
> > mkdir -p testdir
> > mount -o loop test.img testdir || exit
> >
> > SCRATCH_MNT=$(readlink -f testdir)
> >
> > function clean ()
> > {
> > while ps -eo comm | grep -q -e fanotify ; do
> > killall fanotify_flush_stress
> > done
> >
> > umount -d $SCRATCH_MNT
> > rm -rf test.img scrc $SCRATCH_MNT fanotify_flush_stress
> > }
> >
> > trap "clean; exit;" 2
> >
> > cc fanotify_flush_stress.c -o fanotify_flush_stress
> >
> > ./fanotify_flush_stress $SCRATCH_MNT &
> > ./fanotify_flush_stress $SCRATCH_MNT &
> > ./fanotify_flush_stress $SCRATCH_MNT &
> >
> > ps jf | grep fanotify
> >
> > touch $SCRATCH_MNT/1  # hang
> >
> > clean
> >
> > 
> > $ cat fanotify_flush_stress.c
> >
> > #define _GNU_SOURCE /* Needed to get O_LARGEFILE definition */
> > #include 
> > #include 
> > #include 
> > #include 
> > #include 
> > #include 
> > #include 
> > #include 
> > #include 
> >
> > int main(int argc, char *argv[])
> > {
> > char buf;
> > int fd;
> >
> > /* Check mount point is supplied */
> > if (argc != 2) {
> > fpri

fanotify_mark FAN_MARK_FLUSH | _MOUNT stress blocks write to directory

[Xiong Zhou]

hi,

This happens on 4.13.0-rc7+ to commit 42ff72c

After firing up the stress, touch a file in monitoring directory could
hang like forever.

Pretty easy to hit.

Thanks,
Xiong

[  492.060879] INFO: task touch:2259 blocked for more than 120 seconds.
[  492.093497]   Not tainted 4.13.0-rc7-master-42ff72c+ #9
[  492.121049] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this 
message.
[  492.156289] touch   D0  2259   2233 0x0080
[  492.180880] Call Trace:
[  492.191813]  __schedule+0x28d/0x890
[  492.207440]  schedule+0x36/0x80
[  492.221529]  fanotify_handle_event+0x2a1/0x2f0
[  492.241542]  ? remove_wait_queue+0x60/0x60
[  492.260150]  fsnotify+0x2d3/0x4f0
[  492.275055]  ? security_inode_init_security+0xd2/0x190
[  492.298097]  security_file_open+0x89/0x90
[  492.316038]  do_dentry_open+0x139/0x330
[  492.333216]  vfs_open+0x4f/0x70
[  492.347225]  ? may_open+0x5a/0x100
[  492.362481]  path_openat+0x548/0x13b0
[  492.378958]  do_filp_open+0x91/0x100
[  492.394969]  ? __alloc_fd+0x46/0x170
[  492.410930]  do_sys_open+0x124/0x210
[  492.426927]  SyS_open+0x1e/0x20
[  492.440963]  do_syscall_64+0x67/0x150
[  492.457367]  entry_SYSCALL64_slow_path+0x25/0x25
[  492.478251] RIP: 0033:0x7fe877f8e5a0
[  492.495755] RSP: 002b:7ffe57120318 EFLAGS: 0246 ORIG_RAX: 
0002
[  492.529911] RAX: ffda RBX: 7ffe57120578 RCX: 7fe877f8e5a0
[  492.561508] RDX: 01b6 RSI: 0941 RDI: 7ffe5712268c
[  492.595577] RBP:  R08:  R09: 
[  492.631144] R10: 7ffe57120030 R11: 0246 R12: 7ffe5712268c
[  492.664970] R13: 7fe8782612a0 R14: 0001 R15: 



$ cat test.sh

#!/bin/bash -x

fallocate -l 2G test.img
mkfs.xfs -fq test.img
mkdir -p testdir
mount -o loop test.img testdir || exit

SCRATCH_MNT=$(readlink -f testdir)

function clean ()
{
while ps -eo comm | grep -q -e fanotify ; do
killall fanotify_flush_stress
done

umount -d $SCRATCH_MNT
rm -rf test.img scrc $SCRATCH_MNT fanotify_flush_stress
}

trap "clean; exit;" 2

cc fanotify_flush_stress.c -o fanotify_flush_stress

./fanotify_flush_stress $SCRATCH_MNT &
./fanotify_flush_stress $SCRATCH_MNT &
./fanotify_flush_stress $SCRATCH_MNT &

ps jf | grep fanotify

touch $SCRATCH_MNT/1  # hang

clean


$ cat fanotify_flush_stress.c

#define _GNU_SOURCE /* Needed to get O_LARGEFILE definition */
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

int main(int argc, char *argv[])
{
char buf;
int fd;

/* Check mount point is supplied */
if (argc != 2) {
fprintf(stderr, "Usage: %s MOUNT\n", argv[0]);
exit(EXIT_FAILURE);
}

printf("%s on %s\n", argv[0], argv[1]);
/* Create the file descriptor for accessing the fanotify API */
fd = fanotify_init(FAN_CLOEXEC | FAN_CLASS_CONTENT | FAN_NONBLOCK,
   O_RDWR | O_LARGEFILE);
if (fd == -1) {
perror("fanotify_init");
exit(EXIT_FAILURE);
}

/* Loop marking all kinds of events and flush */
while (1) {

#if 1
if (fanotify_mark(fd, FAN_MARK_ADD | FAN_MARK_MOUNT,
  FAN_ACCESS | FAN_MODIFY | FAN_OPEN_PERM | FAN_CLOSE |
  FAN_OPEN | FAN_ACCESS_PERM | FAN_ONDIR |
  FAN_EVENT_ON_CHILD, -1, argv[1]) == -1)

perror("fanotify_mark add");

if (fanotify_mark(fd, FAN_MARK_FLUSH | FAN_MARK_MOUNT,
0, -1, argv[1]) == -1)
perror("fanotify_mark flush mount");
#else
if (fanotify_mark(fd, FAN_MARK_ADD | FAN_MARK_MOUNT,
  FAN_ACCESS | FAN_MODIFY | FAN_OPEN_PERM | FAN_CLOSE |
  FAN_OPEN | FAN_ACCESS_PERM | FAN_ONDIR |
  FAN_EVENT_ON_CHILD, -1, argv[1]) == -1)

perror("fanotify_mark add");

if (fanotify_mark(fd, FAN_MARK_FLUSH, 0, -1, argv[1]) == -1)
perror("fanotify_mark flush");
#endif
}

close(fd);
exit(EXIT_SUCCESS);
}

0324 tree BUG at kernel/auditsc.c:1513!

[Xiong Zhou]

[11230.930568] [ cut here ]
[11230.953828] kernel BUG at kernel/auditsc.c:1513!
[11230.976157] invalid opcode:  [#1] SMP
[11230.995917] Modules linked in: btrfs xor raid6_pq ext2 dm_thin_pool 
dm_persistent_data dm_bio_prison dm_bufio loop ext4 jbd2 mbcache xt_CHECKSUM 
iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 
nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack ipt_REJECT 
nf_reject_ipv4 tun bridge stp llc ebtable_filter ebtables ip6table_filter 
ip6_tables iptable_filter dm_mirror dm_region_hash dm_log dm_mod intel_rapl 
sb_edac edac_core x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm 
irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcbc ipmi_ssif 
aesni_intel crypto_simd ipmi_si glue_helper iTCO_wdt ipmi_devintf 
iTCO_vendor_support cryptd dax_pmem sg hpilo ipmi_msghandler hpwdt lpc_ich 
pcc_cpufreq pcspkr dax ioatdma i2c_i801 wmi acpi_power_meter acpi_cpufreq
[11231.318010]  dca shpchp nfsd auth_rpcgss nfs_acl lockd grace sunrpc 
binfmt_misc ip_tables xfs libcrc32c sd_mod mgag200 i2c_algo_bit drm_kms_helper 
syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm tg3 ptp hpsa crc32c_intel 
nd_pmem serio_raw i2c_core pps_core scsi_transport_sas [last unloaded: 
scsi_debug]
[11231.440342] CPU: 24 PID: 15334 Comm: dio_truncate Not tainted 
4.11.0-rc3-linux-next-65b2dc3-next-20170324 #336
[11231.488861] Hardware name: HP ProLiant DL360 Gen9, BIOS P89 05/06/2015
[11231.521003] task: 9eb578bc5a00 task.stack: c277665d8000
[11231.547477] RIP: 0010:__audit_syscall_entry+0xf0/0x100
[11231.570495] RSP: 0018:c277665dbe90 EFLAGS: 00010206
[11231.594551] RAX:  RBX: 9ebf2896a800 RCX: 
[11231.626815] RDX: 4000 RSI: 7ffe7a853c60 RDI: 0002
[11231.658965] RBP: c277665dbea0 R08: 7ffe7a853940 R09: 9eb578bc5a00
[11231.691211] R10: 7ffe7a853940 R11: 770b5a00 R12: 
[11231.723119] R13: 0002 R14:  R15: 
[11231.755258] FS:  7fdbdb18b740() GS:9ebf3fc0() 
knlGS:
[11231.791482] CS:  0010 DS:  ES:  CR0: 80050033
[11231.817433] CR2: 7fff02451000 CR3: 00076082 CR4: 001406e0
[11231.849728] Call Trace:
[11231.860748]  syscall_trace_enter+0x1d0/0x2b0
[11231.880034]  ? __audit_syscall_exit+0x209/0x290
[11231.900057]  do_syscall_64+0x155/0x180
[11231.916776]  entry_SYSCALL64_slow_path+0x25/0x25
[11231.937440] RIP: 0033:0x7fdbdad70c20
[11231.953513] RSP: 002b:7ffe7a853c28 EFLAGS: 0246 ORIG_RAX: 
0002
[11231.989037] RAX: ffda RBX: 7fdbdb18b6c0 RCX: 7fdbdad70c20
[11232.023770] RDX:  RSI: 4000 RDI: 7ffe7a853c60
[11232.059308] RBP: 7ffe7a853c60 R08:  R09: 01a68010
[11232.091419] R10: 7ffe7a853940 R11: 0246 R12: 
[11232.123493] R13: 7ffe7a854d50 R14:  R15: 
[11232.155457] Code: 02 00 00 00 00 00 00 5b 41 5c 5d c3 48 c7 43 50 00 00 00 
00 48 c7 c2 a0 f8 6f a6 48 89 de 4c 89 cf e8 05 f5 ff ff 41 89 c4 eb a9 <0f> 0b 
0f 1f 40 00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00
[11232.240315] RIP: __audit_syscall_entry+0xf0/0x100 RSP: c277665dbe90
[11232.272441] BUG: unable to handle kernel paging request at 9ebf29362000
[11232.272451] ---[ end trace 7e25ab22dc4e0f7a ]---
[11232.273486] Kernel panic - not syncing: Fatal exception
[11232.347746] IP: __memmove+0x24/0x1a0
[11232.363684] PGD 7362e1067
[11232.363684] P4D 7362e1067
[11232.375799] PUD 107243f063
[11232.387851] PMD 1069361063
[11232.400372] BAD
[11232.422587] Oops: 0002 [#2] SMP
[11232.436808] Modules linked in: btrfs xor raid6_pq ext2 dm_thin_pool 
dm_persistent_data dm_bio_prison dm_bufio loop ext4 jbd2 mbcache xt_CHECKSUM 
iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 
nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack ipt_REJECT 
nf_reject_ipv4 tun bridge stp llc ebtable_filter ebtables ip6table_filter 
ip6_tables iptable_filter dm_mirror dm_region_hash dm_log dm_mod intel_rapl 
sb_edac edac_core x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm 
irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcbc ipmi_ssif 
aesni_intel crypto_simd ipmi_si glue_helper iTCO_wdt ipmi_devintf 
iTCO_vendor_support cryptd dax_pmem sg hpilo ipmi_msghandler hpwdt lpc_ich 
pcc_cpufreq pcspkr dax ioatdma i2c_i801 wmi acpi_power_meter acpi_cpufreq
[11232.793787]  dca shpchp nfsd auth_rpcgss nfs_acl lockd grace sunrpc 
binfmt_misc ip_tables xfs libcrc32c sd_mod mgag200 i2c_algo_bit drm_kms_helper 
syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm tg3 ptp hpsa crc32c_intel 
nd_pmem serio_raw i2c_core pps_core scsi_transport_sas [last unloaded: 
scsi_debug]
[11232.920032] CPU: 19 PID: 15333 Comm: dio_truncate Tainted: G  D 
4.11.0-rc3-

fsx tests on DAX started to fail with msync failure on 0307 -next tree

[Xiong Zhou]

Hi,

xfstests cases:
generic/075 generic/112 generic/127 generic/231 generic/263

fail with DAX, pass without it. Both xfs and ext4.

It was okay on 0306 -next tree.

+ ./check generic/075
FSTYP -- xfs (non-debug)
PLATFORM  -- Linux/x86_64 hp-dl360g9-12 
4.11.0-rc1-linux-next-5be4921-next-20170310
MKFS_OPTIONS  -- -f -bsize=4096 /dev/pmem0p2
MOUNT_OPTIONS -- -o dax -o context=system_u:object_r:nfs_t:s0 /dev/pmem0p2 
/daxsch

generic/075 4s ... [failed, exit status 1] - output mismatch (see 
/root/xfstests/results//generic/075.out.bad)
--- tests/generic/075.out   2016-12-13 14:38:25.984557426 +0800
+++ /root/xfstests/results//generic/075.out.bad 2017-03-14 
10:40:23.083052839 +0800
@@ -4,15 +4,4 @@
 ---
 fsx.0 : -d -N numops -S 0
 ---
-

-fsx.1 : -d -N numops -S 0 -x

...
(Run 'diff -u tests/generic/075.out 
/root/xfstests/results//generic/075.out.bad'  to see the entire diff)
..

$ diff -u xfstests/tests/generic/075.out 
/root/xfstests/results//generic/075.out.bad
--- xfstests/tests/generic/075.out  2016-12-13 14:38:25.984557426 +0800
+++ /root/xfstests/results//generic/075.out.bad 2017-03-14 10:40:23.083052839 
+0800
@@ -4,15 +4,4 @@
 ---
 fsx.0 : -d -N numops -S 0
 ---
-

-fsx.1 : -d -N numops -S 0 -x

-

-fsx.2 : -d -N numops -l filelen -S 0

-

-fsx.3 : -d -N numops -l filelen -S 0 -x

+fsx (-d -N 1000 -S 0) failed, 0 - compare 
/root/xfstests/results//generic/075.0.{good,bad,fsxlog}

$ diff -u /root/xfstests/results//generic/075.0.{good,fsxlog} | tail -20
-03cb30 f903 da03 1103 7503 5403 8903 9f03 6b03
-03cb40 bb03 fb03 5603 7e03 c503 ca03 0103 9603
-03cb50 7f03 7c03 0c03 5103 ed03 dc03 a403 5c03
-03cb60 5403 b903 4403 3c03 4b03 a903 2303 1a03
-03cb70 2b03 5f03 fd03 ee03 1303 9703 2903 d303
-03cb80 4e03 9903 f903 8003 b803 2503 2203 c903
-03cb90 6803 7a03 0f03 6303 de03 ba03 6e03 6503
-03cba0 db03
-03cba2
+skipping zero size read
+skipping insert range behind EOF
+3 mapwrite 0x2e836 thru0x3cba1 (0xe36c bytes)
+domapwrite: msync: Invalid argument
+LOG DUMP (3 total operations):
+1(  1 mod 256): SKIPPED (no operation)
+2(  2 mod 256): SKIPPED (no operation)
+3(  3 mod 256): MAPWRITE 0x2e836 thru 0x3cba1  (0xe36c bytes)
+Log of operations saved to "075.0.fsxops"; replay with --replay-ops
+Correct content saved for comparison
+(maybe hexdump "075.0" vs "075.0.fsxgood")

https://git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git/tree/tests/generic/075
https://git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git/tree/ltp/fsx.c

Re: [PATCH 0/2] fix for direct-I/O to DAX mappings

[Xiong Zhou]

On Sat, Feb 25, 2017 at 09:08:28AM -0800, Dan Williams wrote:
> Hi Andrew,
> 
> While Ross was doing a review of a new mmap+DAX direct-I/O test case for
> xfstests, from Xiong, he noticed occasions where it failed to trigger a
> page dirty event.  Dave then spotted the problem fixed by patch1. The
> pte_devmap() check is precluding pte_allows_gup(), i.e. bypassing
> permission checks and dirty tracking.

This mmap-dax-dio case still fails with this patchset, while it makes
sense. It's the test case that need to be fixed.

BTW, this patchset fixes another xfsrestore issue, which i hit now
and then, xfs/301 w/ or wo/ DAX only on nvdimms. xfsrestore never
return but killable.

Thanks,
> 
> Patch2 is a cleanup and clarifies that pte_unmap() only needs to be done
> once per page-worth of ptes. It unifies the exit paths similar to the
> generic gup_pte_range() in the __HAVE_ARCH_PTE_SPECIAL case.
> 
> I'm sending this through the -mm tree for a double-check from memory
> management folks. It has a build success notification from the kbuild
> robot.
> 
> ---
> 
> Dan Williams (2):
>   x86, mm: fix gup_pte_range() vs DAX mappings
>   x86, mm: unify exit paths in gup_pte_range()
> 
> 
>  arch/x86/mm/gup.c |   37 +
>  1 file changed, 21 insertions(+), 16 deletions(-)

Re: boot failure, module: overflow in relocation

[Xiong Zhou]

Nevermind, it got fixed now i think.

On Thu, Mar 02, 2017 at 05:51:27PM +0800, Xiong Zhou wrote:
> Hi,
> 
> One host failed to boot while merge going on,
> 
> [   13.076303] module: overflow in relocation type 10 val a0060e58
> [   13.076338] module: overflow in relocation type 10 val a01ac96b
> [   13.076340] module: `scsi_transport_sas' likely not compiled with 
> -mcmodel=kernel
> [   13.181517] module: `pps_core' likely not compiled with -mcmodel=kernel
> [   13.212405] module: overflow in relocation type 10 val a004c278
> [   13.244297] module: `fjes' likely not compiled with -mcmodel=kernel
> [   13.294340] module: overflow in relocation type 10 val a003be58
> [   13.294348] module: overflow in relocation type 10 val a0082797
> [   13.294350] module: `nd_pmem' likely not compiled with -mcmodel=kernel
> [   13.388080] module: `pps_core' likely not compiled with -mcmodel=kernel
> [   13.433976] module: overflow in relocation type 10 val a0095c8e
> [   13.466011] module: `drm' likely not compiled with -mcmodel=kernel
> 
> then wait to mount rootfs or other tasks like forever.
> 
> Bisect pointing to:
> commit d1091c7fa3d52ebce4dd3f15d04155b3469b2f90
> Author: Josh Poimboeuf 
> Date:   Tue Feb 21 15:35:32 2017 -0600
> 
> objtool: Improve detection of BUG() and other dead ends
> 
> After reverting these 3 commits, login prompt shows.
> 4e4636c objtool: Enclose contents of unreachable() macro in a block
> 3d1e236 objtool: Prevent GCC from merging annotate_unreachable()
> d1091c7 objtool: Improve detection of BUG() and other dead ends 
> 
> Thanks,
> 
>  bisect log --
> git bisect start
> # good: [86292b33d4b79ee03e2f43ea0381ef85f077c760] Merge branch 'akpm' 
> (patches from Andrew)
> git bisect good 86292b33d4b79ee03e2f43ea0381ef85f077c760
> # bad: [8313064c2e75542201e557e2b496668811c2484a] Merge tag 'nfsd-4.11' of 
> git://linux-nfs.org/~bfields/linux
> git bisect bad 8313064c2e75542201e557e2b496668811c2484a
> # bad: [d4f4cf77b37eaea58ef863a4cbc95dad3880b524] Merge branch 'for-linus' of 
> git://git.armlinux.org.uk/~rmk/linux-arm
> git bisect bad d4f4cf77b37eaea58ef863a4cbc95dad3880b524
> # bad: [74efe07bc38c538ba7ac40a895910f4f3bee3152] Merge branch 
> 'locking-urgent-for-linus' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
> git bisect bad 74efe07bc38c538ba7ac40a895910f4f3bee3152
> # good: [c4d2603dac3a555e4bb324daf5cb5cdb5694eedd] rhashtable: Fix RCU 
> dereference annotation in rht_bucket_nested
> git bisect good c4d2603dac3a555e4bb324daf5cb5cdb5694eedd
> # good: [2f44f75257d57f0d5668dba3a6ada0f4872132c9] Merge branch 'qed-fixes'
> git bisect good 2f44f75257d57f0d5668dba3a6ada0f4872132c9
> # good: [74e3f63ce60eb81fbd39aa6c0353059b7e2cb5f7] Merge 
> git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide
> git bisect good 74e3f63ce60eb81fbd39aa6c0353059b7e2cb5f7
> # bad: [4e4636cf981b5b629fbfb78aa9f232e015f7d521] objtool: Enclose contents 
> of unreachable() macro in a block
> git bisect bad 4e4636cf981b5b629fbfb78aa9f232e015f7d521
> # bad: [d1091c7fa3d52ebce4dd3f15d04155b3469b2f90] objtool: Improve detection 
> of BUG() and other dead ends
> git bisect bad d1091c7fa3d52ebce4dd3f15d04155b3469b2f90
> # good: [9f0c18aec620bc9d82268b3cb937568dd07b43ff] objtool: Fix 
> CONFIG_STACK_VALIDATION=y warning for out-of-tree modules
> git bisect good 9f0c18aec620bc9d82268b3cb937568dd07b43ff
> # first bad commit: [d1091c7fa3d52ebce4dd3f15d04155b3469b2f90] objtool: 
> Improve detection of BUG() and other dead ends

boot failure, module: overflow in relocation

[Xiong Zhou]

Hi,

One host failed to boot while merge going on,

[   13.076303] module: overflow in relocation type 10 val a0060e58
[   13.076338] module: overflow in relocation type 10 val a01ac96b
[   13.076340] module: `scsi_transport_sas' likely not compiled with 
-mcmodel=kernel
[   13.181517] module: `pps_core' likely not compiled with -mcmodel=kernel
[   13.212405] module: overflow in relocation type 10 val a004c278
[   13.244297] module: `fjes' likely not compiled with -mcmodel=kernel
[   13.294340] module: overflow in relocation type 10 val a003be58
[   13.294348] module: overflow in relocation type 10 val a0082797
[   13.294350] module: `nd_pmem' likely not compiled with -mcmodel=kernel
[   13.388080] module: `pps_core' likely not compiled with -mcmodel=kernel
[   13.433976] module: overflow in relocation type 10 val a0095c8e
[   13.466011] module: `drm' likely not compiled with -mcmodel=kernel

then wait to mount rootfs or other tasks like forever.

Bisect pointing to:
commit d1091c7fa3d52ebce4dd3f15d04155b3469b2f90
Author: Josh Poimboeuf 
Date:   Tue Feb 21 15:35:32 2017 -0600

objtool: Improve detection of BUG() and other dead ends

After reverting these 3 commits, login prompt shows.
4e4636c objtool: Enclose contents of unreachable() macro in a block
3d1e236 objtool: Prevent GCC from merging annotate_unreachable()
d1091c7 objtool: Improve detection of BUG() and other dead ends 

Thanks,

 bisect log --
git bisect start
# good: [86292b33d4b79ee03e2f43ea0381ef85f077c760] Merge branch 'akpm' (patches 
from Andrew)
git bisect good 86292b33d4b79ee03e2f43ea0381ef85f077c760
# bad: [8313064c2e75542201e557e2b496668811c2484a] Merge tag 'nfsd-4.11' of 
git://linux-nfs.org/~bfields/linux
git bisect bad 8313064c2e75542201e557e2b496668811c2484a
# bad: [d4f4cf77b37eaea58ef863a4cbc95dad3880b524] Merge branch 'for-linus' of 
git://git.armlinux.org.uk/~rmk/linux-arm
git bisect bad d4f4cf77b37eaea58ef863a4cbc95dad3880b524
# bad: [74efe07bc38c538ba7ac40a895910f4f3bee3152] Merge branch 
'locking-urgent-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect bad 74efe07bc38c538ba7ac40a895910f4f3bee3152
# good: [c4d2603dac3a555e4bb324daf5cb5cdb5694eedd] rhashtable: Fix RCU 
dereference annotation in rht_bucket_nested
git bisect good c4d2603dac3a555e4bb324daf5cb5cdb5694eedd
# good: [2f44f75257d57f0d5668dba3a6ada0f4872132c9] Merge branch 'qed-fixes'
git bisect good 2f44f75257d57f0d5668dba3a6ada0f4872132c9
# good: [74e3f63ce60eb81fbd39aa6c0353059b7e2cb5f7] Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide
git bisect good 74e3f63ce60eb81fbd39aa6c0353059b7e2cb5f7
# bad: [4e4636cf981b5b629fbfb78aa9f232e015f7d521] objtool: Enclose contents of 
unreachable() macro in a block
git bisect bad 4e4636cf981b5b629fbfb78aa9f232e015f7d521
# bad: [d1091c7fa3d52ebce4dd3f15d04155b3469b2f90] objtool: Improve detection of 
BUG() and other dead ends
git bisect bad d1091c7fa3d52ebce4dd3f15d04155b3469b2f90
# good: [9f0c18aec620bc9d82268b3cb937568dd07b43ff] objtool: Fix 
CONFIG_STACK_VALIDATION=y warning for out-of-tree modules
git bisect good 9f0c18aec620bc9d82268b3cb937568dd07b43ff
# first bad commit: [d1091c7fa3d52ebce4dd3f15d04155b3469b2f90] objtool: Improve 
detection of BUG() and other dead ends

Re: mm allocation failure and hang when running xfstests generic/269 on xfs

[Xiong Zhou]

On Thu, Mar 02, 2017 at 09:42:23AM +0100, Michal Hocko wrote:
> On Thu 02-03-17 12:17:47, Anshuman Khandual wrote:
> > On 03/02/2017 10:49 AM, Xiong Zhou wrote:
> > > On Wed, Mar 01, 2017 at 04:37:31PM -0800, Christoph Hellwig wrote:
> > >> On Wed, Mar 01, 2017 at 12:46:34PM +0800, Xiong Zhou wrote:
> > >>> Hi,
> > >>>
> > >>> It's reproduciable, not everytime though. Ext4 works fine.
> > >> On ext4 fsstress won't run bulkstat because it doesn't exist.  Either
> > >> way this smells like a MM issue to me as there were not XFS changes
> > >> in that area recently.
> > > Yap.
> > > 
> > > First bad commit:
> > > 
> > > commit 5d17a73a2ebeb8d1c6924b91e53ab2650fe86ffb
> > > Author: Michal Hocko 
> > > Date:   Fri Feb 24 14:58:53 2017 -0800
> > > 
> > > vmalloc: back off when the current task is killed
> > > 
> > > Reverting this commit on top of
> > >   e5d56ef Merge tag 'watchdog-for-linus-v4.11'
> > > survives the tests.
> > 
> > Does fsstress test or the system hang ? I am not familiar with this
> > code but If it's the test which is getting hung and its hitting this
> > new check introduced by the above commit that means the requester is
> > currently being killed by OOM killer for some other memory allocation
> > request.
> 
> Well, not exactly. It is sufficient for it to be _killed_ by SIGKILL.
> And for that it just needs to do a group_exit when one thread was still
> in the kernel (see zap_process). While I can change this check to
> actually do the oom specific check I believe a more generic
> fatal_signal_pending is the right thing to do here. I am still not sure
> what is the actual problem here, though. Could you be more specific
> please?

It's blocking the test and system-shutdown. fsstress wont exit.

For anyone interested, a simple ugly reproducer:

cat > fst.sh < local.config < -- 
> Michal Hocko
> SUSE Labs

Re: mm allocation failure and hang when running xfstests generic/269 on xfs

[Xiong Zhou]

On Wed, Mar 01, 2017 at 04:37:31PM -0800, Christoph Hellwig wrote:
> On Wed, Mar 01, 2017 at 12:46:34PM +0800, Xiong Zhou wrote:
> > Hi,
> > 
> > It's reproduciable, not everytime though. Ext4 works fine.
> 
> On ext4 fsstress won't run bulkstat because it doesn't exist.  Either
> way this smells like a MM issue to me as there were not XFS changes
> in that area recently.

Yap.

First bad commit:

commit 5d17a73a2ebeb8d1c6924b91e53ab2650fe86ffb
Author: Michal Hocko 
Date:   Fri Feb 24 14:58:53 2017 -0800

vmalloc: back off when the current task is killed

Reverting this commit on top of
  e5d56ef Merge tag 'watchdog-for-linus-v4.11'
survives the tests.

mm allocation failure and hang when running xfstests generic/269 on xfs

[Xiong Zhou]

Hi,

It's reproduciable, not everytime though. Ext4 works fine.

Based on test logs, it's bad on Linus tree commit:
  e5d56ef Merge tag 'watchdog-for-linus-v4.11'

It's good on commit:
  f8e6859 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc

Trying to narrow down a little bit.

Thanks,
Xiong

---

fsstress: vmalloc: allocation failure, allocated 12288 of 20480 bytes, 
mode:0x14080c2(GFP_KERNEL|__GFP_HIGHMEM|__GFP_ZERO), nodemask=(null)
fsstress cpuset=/ mems_allowed=0-1
CPU: 1 PID: 23460 Comm: fsstress Not tainted 4.10.0-master-45554b2+ #21
Hardware name: HP ProLiant DL380 Gen9/ProLiant DL380 Gen9, BIOS P89 10/05/2016
Call Trace:
 dump_stack+0x63/0x87
 warn_alloc+0x114/0x1c0
 ? alloc_pages_current+0x88/0x120
 __vmalloc_node_range+0x250/0x2a0
 ? kmem_zalloc_greedy+0x2b/0x40 [xfs]
 ? free_hot_cold_page+0x21f/0x280
 vzalloc+0x54/0x60
 ? kmem_zalloc_greedy+0x2b/0x40 [xfs]
 kmem_zalloc_greedy+0x2b/0x40 [xfs]
 xfs_bulkstat+0x11b/0x730 [xfs]
 ? xfs_bulkstat_one_int+0x340/0x340 [xfs]
 ? selinux_capable+0x20/0x30
 ? security_capable+0x48/0x60
 xfs_ioc_bulkstat+0xe4/0x190 [xfs]
 xfs_file_ioctl+0x9dd/0xad0 [xfs]
 ? do_filp_open+0xa5/0x100
 do_vfs_ioctl+0xa7/0x5e0
 SyS_ioctl+0x79/0x90
 do_syscall_64+0x67/0x180
 entry_SYSCALL64_slow_path+0x25/0x25
RIP: 0033:0x7f825023f577
RSP: 002b:7ea76e58 EFLAGS: 0246 ORIG_RAX: 0010
RAX: ffda RBX: 3f7e RCX: 7f825023f577
RDX: 7ea76e70 RSI: c0205865 RDI: 0003
RBP: 0003 R08: 0008 R09: 0036
R10: 0069 R11: 0246 R12: 0036
R13: 7f824c002d00 R14: 1209 R15: 
Mem-Info:
active_anon:23126 inactive_anon:1719 isolated_anon:0
 active_file:153709 inactive_file:356889 isolated_file:0
 unevictable:0 dirty:0 writeback:0 unstable:0
 slab_reclaimable:43829 slab_unreclaimable:45414
 mapped:14638 shmem:2470 pagetables:1599 bounce:0
 free:7463113 free_pcp:23729 free_cma:0
Node 0 active_anon:36372kB inactive_anon:140kB active_file:449540kB 
inactive_file:355288kB unevictable:0kB isolated(anon):0kB isolated(file):0kB 
mapped:21792kB dirty:0kB writeback:0kB shmem:0kB shmem_thp: 0kB 
shmem_pmdmapped: 10240kB anon_thp: 796kB writeback_tmp:0kB unstable:0kB 
pages_scanned:0 all_unreclaimable? no
Node 1 active_anon:56132kB inactive_anon:6736kB active_file:165296kB 
inactive_file:1072268kB unevictable:0kB isolated(anon):0kB isolated(file):0kB 
mapped:36760kB dirty:0kB writeback:0kB shmem:0kB shmem_thp: 0kB 
shmem_pmdmapped: 12288kB anon_thp: 9084kB writeback_tmp:0kB unstable:0kB 
pages_scanned:0 all_unreclaimable? no
Node 0 DMA free:15884kB min:40kB low:52kB high:64kB active_anon:0kB 
inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB 
writepending:0kB present:15992kB managed:15904kB mlocked:0kB 
slab_reclaimable:0kB slab_unreclaimable:20kB kernel_stack:0kB pagetables:0kB 
bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB
lowmem_reserve[]: 0 1821 15896 15896 15896
Node 0 DMA32 free:1860532kB min:4968kB low:6772kB high:8576kB active_anon:0kB 
inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB 
writepending:0kB present:1948156kB managed:1865328kB mlocked:0kB 
slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:0kB 
bounce:0kB free_pcp:2132kB local_pcp:0kB free_cma:0kB
lowmem_reserve[]: 0 0 14074 14074 14074
Node 0 Normal free:13111616kB min:39660kB low:54072kB high:68484kB 
active_anon:36372kB inactive_anon:140kB active_file:449540kB 
inactive_file:355296kB unevictable:0kB writepending:0kB present:14680064kB 
managed:14412260kB mlocked:0kB slab_reclaimable:77256kB 
slab_unreclaimable:86096kB kernel_stack:8184kB pagetables:3132kB bounce:0kB 
free_pcp:45712kB local_pcp:212kB free_cma:0kB
lowmem_reserve[]: 0 0 0 0 0
Node 1 Normal free:14864424kB min:45432kB low:61940kB high:78448kB 
active_anon:56132kB inactive_anon:6736kB active_file:165296kB 
inactive_file:1072264kB unevictable:0kB writepending:0kB present:16777216kB 
managed:16508964kB mlocked:0kB slab_reclaimable:98060kB 
slab_unreclaimable:95540kB kernel_stack:7880kB pagetables:3264kB bounce:0kB 
free_pcp:46848kB local_pcp:640kB free_cma:0kB
lowmem_reserve[]: 0 0 0 0 0
Node 0 DMA: 1*4kB (U) 1*8kB (U) 0*16kB 0*32kB 2*64kB (U) 1*128kB (U) 1*256kB 
(U) 0*512kB 1*1024kB (U) 1*2048kB (M) 3*4096kB (M) = 15884kB
Node 0 DMA32: 13*4kB (UM) 10*8kB (UM) 13*16kB (UM) 11*32kB (M) 18*64kB (UM) 
9*128kB (UM) 16*256kB (UM) 12*512kB (UM) 12*1024kB (UM) 10*2048kB (UM) 
443*4096kB (M) = 1860532kB
Node 0 Normal: 2765*4kB (UME) 737*8kB (UME) 145*16kB (UME) 251*32kB (UME) 
626*64kB (UM) 255*128kB (UME) 46*256kB (UME) 23*512kB (UE) 15*1024kB (U) 
8*2048kB (U) 3163*4096kB (M) = 13110956kB
Node 1 Normal: 3422*4kB (UME) 1039*8kB (UME) 158*16kB (UME) 852*32kB (UME) 
1125*64kB (UME) 617*128kB (UE) 329*256kB (UME) 117*512kB (UME) 18*1024kB (UM) 
6*2048kB (U) 3537*4096kB (M) = 14865168kB
Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp

Ext4 new shutdown ioctl fails generic/04{4,5,6}

[Xiong Zhou]

Hi,

On latest Linus tree, xfstests generic/04{4,5,6} fails.

FSTYP -- ext4
PLATFORM  -- Linux/x86_64 rhel73 4.10.0-master-45554b2+
MKFS_OPTIONS  -- /dev/sdc
MOUNT_OPTIONS -- -o acl,user_xattr -o context=system_u:object_r:nfs_t:s0 
/dev/sdc /test2

generic/045  - output mismatch (see 
/root/xfstests-dev/results//generic/045.out.bad)
--- tests/generic/045.out   2017-02-21 21:49:05.04500 -0500
+++ /root/xfstests-dev/results//generic/045.out.bad 2017-02-27 
22:24:52.44400 -0500
@@ -1 +1,1000 @@
 QA output created by 045
+corrupt file /test2/1 - non-zero size but no extents
+corrupt file /test2/2 - non-zero size but no extents
+corrupt file /test2/3 - non-zero size but no extents
+corrupt file /test2/4 - non-zero size but no extents
+corrupt file /test2/5 - non-zero size but no extents
+corrupt file /test2/6 - non-zero size but no extents

LTP write03 writev07 xfs failures

[Xiong Zhou]

Hi,

These 2 tests PASS on Linus tree commit:
  37c8596 Merge tag 'tty-4.11-rc1' of git://git.kernel.org/pub/scm/linux...
FAIL on commit:
  60e8d3e Merge tag 'pci-v4.11-changes' of git://git.kernel.org/pub/scm/...

LTP latest commit: c60d3ca move_pages12: include lapi/mmap.h

Steps:

sh-4.2# pwd
/root/ltp
sh-4.2# git log --oneline -1
c60d3ca move_pages12: include lapi/mmap.h
sh-4.2# uname -r
4.10.0-master-60e8d3e+
sh-4.2# mount | grep test1
/dev/sda3 on /test1 type xfs 
(rw,relatime,seclabel,attr2,inode64,logbsize=256k,sunit=512,swidth=512,noquota)
sh-4.2# xfs_info /test1
meta-data=/dev/sda3  isize=512agcount=16, agsize=245696 blks
 =   sectsz=512   attr=2, projid32bit=1
 =   crc=1finobt=1 spinodes=0
data =   bsize=4096   blocks=3931136, imaxpct=25
 =   sunit=64 swidth=64 blks
naming   =version 2  bsize=4096   ascii-ci=0 ftype=1
log  =internal   bsize=4096   blocks=2560, version=2
 =   sectsz=512   sunit=64 blks, lazy-count=1
realtime =none   extsz=4096   blocks=0, rtextents=0
sh-4.2# 
sh-4.2# TMPDIR=/test1 ./testcases/kernel/syscalls/write/write03
write03 0  TINFO  :  Enter Block 1: test to check if write corrupts the 
file when write fails
write03 1  TFAIL  :  write03.c:125: failure of write(2) corrupted the file
write03 0  TINFO  :  Exit block 1
sh-4.2# 
sh-4.2# TMPDIR=/test1 ./testcases/kernel/syscalls/writev/writev07
tst_test.c:760: INFO: Timeout per run is 0h 05m 00s
writev07.c:60: INFO: starting test with initial file offset: 0 
writev07.c:82: INFO: got EFAULT
writev07.c:87: FAIL: file was written to
writev07.c:93: PASS: offset stayed unchanged
writev07.c:60: INFO: starting test with initial file offset: 65 
writev07.c:82: INFO: got EFAULT
writev07.c:89: PASS: file stayed untouched
writev07.c:93: PASS: offset stayed unchanged
writev07.c:60: INFO: starting test with initial file offset: 4096 
writev07.c:82: INFO: got EFAULT
writev07.c:89: PASS: file stayed untouched
writev07.c:93: PASS: offset stayed unchanged
writev07.c:60: INFO: starting test with initial file offset: 4097 
writev07.c:82: INFO: got EFAULT
writev07.c:89: PASS: file stayed untouched
writev07.c:93: PASS: offset stayed unchanged

Summary:
passed   7
failed   1
skipped  0
warnings 0
sh-4.2# 
sh-4.2# mkfs.xfs -V
mkfs.xfs version 4.7.0
sh-4.2# cd ../xfsprogs/
sh-4.2# git log --oneline -1
d7e1f5f xfsprogs: Release v4.7
sh-4.2# 

Thanks,
Xiong

LTP write03 writev07 xfs failures

[Xiong Zhou]

Hi,

These 2 tests PASS on Linus tree commit:
  37c8596 Merge tag 'tty-4.11-rc1' of git://git.kernel.org/pub/scm/linux...
FAIL on commit:
  60e8d3e Merge tag 'pci-v4.11-changes' of git://git.kernel.org/pub/scm/...

LTP latest commit: c60d3ca move_pages12: include lapi/mmap.h

Steps:

sh-4.2# pwd
/root/ltp
sh-4.2# git log --oneline -1
c60d3ca move_pages12: include lapi/mmap.h
sh-4.2# uname -r
4.10.0-master-60e8d3e+
sh-4.2# mount | grep test1
/dev/sda3 on /test1 type xfs
(rw,relatime,seclabel,attr2,inode64,logbsize=256k,sunit=512,swidth=512,noquota)
sh-4.2# xfs_info /test1
meta-data=/dev/sda3  isize=512agcount=16, agsize=245696 blks
 =   sectsz=512   attr=2, projid32bit=1
 =   crc=1finobt=1 spinodes=0
data =   bsize=4096   blocks=3931136, imaxpct=25
 =   sunit=64 swidth=64 blks
naming   =version 2  bsize=4096   ascii-ci=0 ftype=1
log  =internal   bsize=4096   blocks=2560, version=2
 =   sectsz=512   sunit=64 blks, lazy-count=1
realtime =none   extsz=4096   blocks=0, rtextents=0
sh-4.2#
sh-4.2# TMPDIR=/test1 ./testcases/kernel/syscalls/write/write03
write03 0  TINFO  :  Enter Block 1: test to check if write
corrupts the file when write fails
write03 1  TFAIL  :  write03.c:125: failure of write(2) corrupted the file
write03 0  TINFO  :  Exit block 1
sh-4.2#
sh-4.2# TMPDIR=/test1 ./testcases/kernel/syscalls/writev/writev07
tst_test.c:760: INFO: Timeout per run is 0h 05m 00s
writev07.c:60: INFO: starting test with initial file offset: 0
writev07.c:82: INFO: got EFAULT
writev07.c:87: FAIL: file was written to
writev07.c:93: PASS: offset stayed unchanged
writev07.c:60: INFO: starting test with initial file offset: 65
writev07.c:82: INFO: got EFAULT
writev07.c:89: PASS: file stayed untouched
writev07.c:93: PASS: offset stayed unchanged
writev07.c:60: INFO: starting test with initial file offset: 4096
writev07.c:82: INFO: got EFAULT
writev07.c:89: PASS: file stayed untouched
writev07.c:93: PASS: offset stayed unchanged
writev07.c:60: INFO: starting test with initial file offset: 4097
writev07.c:82: INFO: got EFAULT
writev07.c:89: PASS: file stayed untouched
writev07.c:93: PASS: offset stayed unchanged

Summary:
passed   7
failed   1
skipped  0
warnings 0
sh-4.2#
sh-4.2# mkfs.xfs -V
mkfs.xfs version 4.7.0
sh-4.2# cd ../xfsprogs/
sh-4.2# git log --oneline -1
d7e1f5f xfsprogs: Release v4.7
sh-4.2#

Thanks,
Xiong

Re: Starting kvm/qemu guest crash kernel linux-next 0221 tree

[Xiong Zhou]

On Wed, Feb 22, 2017 at 09:28:21AM +0100, Paolo Bonzini wrote:
> 
> 
> On 22/02/2017 02:52, Xiong Zhou wrote:
> > Hi,
> > 
> > Starting a guest begin to crash kernel on 0221 -next tree.
> > 
> > It's fine on 0220 tree.

I reproduced only once. Now it's hard to reproduce.
> 
> Can you try commits a26d553400b30b6e0389f5c723c0fc6f7ea473da (0221) and

With above commit reverted by git revert -m 1, no panic so far.
But it's hard to reproduce.


> b95234c840045b7c72380fd14c59416af28fcb02 (0220)?
> 
> What is the guest and the QEMU command line?

It's a RHEL-7.3 guest on a RHEL-7.3+ host

cmdline:
/usr/libexec/qemu-kvm -name 73h -S -machine 
pc-i440fx-rhel7.0.0,accel=kvm,usb=off,dump-guest-core=off -cpu 
Haswell,-hle,-rtm -m 8000 -realtime mlock=off -smp 
8,sockets=8,cores=1,threads=1 -uuid aab09e0f-d48a-4223-9b81-35d4718d59fc 
-no-user-config -nodefaults -chardev 
socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-2-73h/monitor.sock,server,nowait
 -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew 
-global kvm-pit.lost_tick_policy=delay -no-hpet -no-shutdown -global 
PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot strict=on -device 
ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x6.0x7 -device 
ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x6 
-device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x6.0x1 
-device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x6.0x2 
-device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 -drive 
file=/var/lib/libvirt/images/rhel73.qcow2,format=qcow2,if=none,id=drive-ide0-0-0
 -device ide-hd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1 
-drive 
file=/var/lib/libvirt/images/73h.qcow2,format=qcow2,if=none,id=drive-ide0-0-1 
-device ide-hd,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1 -drive 
file=/root/RHEL-7.2-20151030.0-Server-x86_64-dvd1.iso,format=raw,if=none,id=drive-ide0-1-0,readonly=on
 -device ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0,bootindex=2 
-netdev tap,fd=25,id=hostnet0 -device 
rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:83:12:7b,bus=pci.0,addr=0x3 
-chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 
-chardev spicevmc,id=charchannel0,name=vdagent -device 
virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0
 -spice 
port=5900,addr=127.0.0.1,disable-ticketing,image-compression=off,seamless-migration=on
 -vga qxl -global qxl-vga.ram_size=67108864 -global qxl-vga.vram_size=67108864 
-global qxl-vga.vgamem_mb=16 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 
-device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -chardev 
spicevmc,id=charredir0,name=usbredir -device 
usb-redir,chardev=charredir0,id=redir0,bus=usb.0,port=1 -chardev 
spicevmc,id=charredir1,name=usbredir -device 
usb-redir,chardev=charredir1,id=redir1,bus=usb.0,port=2 -device 
virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7 -msg timestamp=on

Thanks,
Xiong

> 
> Paolo

Starting kvm/qemu guest crash kernel linux-next 0221 tree

[Xiong Zhou]

Hi,

Starting a guest begin to crash kernel on 0221 -next tree.

It's fine on 0220 tree.

Thanks,
Xiong

-
Feb 22 09:24:29 host-12 systemd-journald[405]: Received SIGTERM from PID 1 
(systemd).
Feb 22 09:24:29 host-12 kernel: systemd: 24 output lines suppressed due to 
ratelimiting
Feb 22 09:24:29 host-12 kernel: audit: type=1404 audit(1487755465.919:2): 
enforcing=1 old_enforcing=0 auid=4294967295 ses=4294967295
Feb 22 09:24:29 host-12 kernel: SELinux:  Permission validate_trans in class 
security not defined in policy.
Feb 22 09:24:29 host-12 kernel: SELinux:  Permission module_load in class 
system not defined in policy.
Feb 22 09:24:29 host-12 kernel: SELinux:  Class binder not defined in policy.
Feb 22 09:24:29 host-12 kernel: SELinux:  Class cap_userns not defined in 
policy.
Feb 22 09:24:29 host-12 kernel: SELinux:  Class cap2_userns not defined in 
policy.
Feb 22 09:24:29 host-12 kernel: SELinux:  Class sctp_socket not defined in 
policy.
Feb 22 09:24:29 host-12 kernel: SELinux:  Class icmp_socket not defined in 
policy.
Feb 22 09:24:29 host-12 kernel: SELinux:  Class ax25_socket not defined in 
policy.
Feb 22 09:24:29 host-12 kernel: SELinux:  Class ipx_socket not defined in 
policy.
Feb 22 09:24:29 host-12 kernel: SELinux:  Class netrom_socket not defined in 
policy.
Feb 22 09:24:29 host-12 kernel: SELinux:  Class atmpvc_socket not defined in 
policy.
Feb 22 09:24:29 host-12 kernel: SELinux:  Class x25_socket not defined in 
policy.
Feb 22 09:24:29 host-12 kernel: SELinux:  Class rose_socket not defined in 
policy.
Feb 22 09:24:29 host-12 kernel: SELinux:  Class decnet_socket not defined in 
policy.
Feb 22 09:24:29 host-12 kernel: SELinux:  Class atmsvc_socket not defined in 
policy.
Feb 22 09:24:29 host-12 kernel: SELinux:  Class rds_socket not defined in 
policy.
Feb 22 09:24:29 host-12 kernel: SELinux:  Class irda_socket not defined in 
policy.
Feb 22 09:24:29 host-12 kernel: SELinux:  Class pppox_socket not defined in 
policy.
Feb 22 09:24:29 host-12 kernel: SELinux:  Class llc_socket not defined in 
policy.
Feb 22 09:24:29 host-12 kernel: SELinux:  Class can_socket not defined in 
policy.
Feb 22 09:24:29 host-12 kernel: SELinux:  Class tipc_socket not defined in 
policy.
Feb 22 09:24:29 host-12 kernel: SELinux:  Class bluetooth_socket not defined in 
policy.
Feb 22 09:24:29 host-12 kernel: SELinux:  Class iucv_socket not defined in 
policy.
Feb 22 09:24:29 host-12 kernel: SELinux:  Class rxrpc_socket not defined in 
policy.
Feb 22 09:24:29 host-12 kernel: SELinux:  Class isdn_socket not defined in 
policy.
Feb 22 09:24:29 host-12 kernel: SELinux:  Class phonet_socket not defined in 
policy.
Feb 22 09:24:29 host-12 kernel: SELinux:  Class ieee802154_socket not defined 
in policy.
Feb 22 09:24:29 host-12 kernel: SELinux:  Class caif_socket not defined in 
policy.
Feb 22 09:24:29 host-12 kernel: SELinux:  Class alg_socket not defined in 
policy.
Feb 22 09:24:29 host-12 kernel: SELinux:  Class nfc_socket not defined in 
policy.
Feb 22 09:24:29 host-12 kernel: SELinux:  Class vsock_socket not defined in 
policy.
Feb 22 09:24:29 host-12 kernel: SELinux:  Class kcm_socket not defined in 
policy.
Feb 22 09:24:29 host-12 kernel: SELinux:  Class qipcrtr_socket not defined in 
policy.
Feb 22 09:24:29 host-12 kernel: SELinux:  Class smc_socket not defined in 
policy.
Feb 22 09:24:29 host-12 kernel: SELinux: the above unknown classes and 
permissions will be allowed
Feb 22 09:24:29 host-12 kernel: audit: type=1403 audit(1487755467.188:3): 
policy loaded auid=4294967295 ses=4294967295
Feb 22 09:24:29 host-12 systemd[1]: Successfully loaded SELinux policy in 
1.293388s.
Feb 22 09:24:29 host-12 systemd[1]: RTC configured in localtime, applying delta 
of 480 minutes to system time.
Feb 22 09:24:29 host-12 kernel: ip_tables: (C) 2000-2006 Netfilter Core Team
Feb 22 09:24:29 host-12 systemd[1]: Inserted module 'ip_tables'
Feb 22 09:24:29 host-12 systemd[1]: Relabelled /dev and /run in 41.372ms.
Feb 22 09:24:29 host-12 journal: Journal started
Feb 22 09:24:29 host-12 systemd: systemd 219 running in system mode. (+PAM 
+AUDIT +SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT 
+GNUTLS +ACL +XZ -LZ4 -SECCOMP +BLKID +ELFUTILS +KMOD +IDN)
Feb 22 09:24:29 host-12 systemd: Detected architecture x86-64.
Feb 22 09:24:29 host-12 systemd: Set hostname to .
Feb 22 09:24:29 host-12 systemd: Starting Flush Journal to Persistent Storage...
Feb 22 09:24:29 host-12 systemd: Mounted Arbitrary Executable File Formats File 
System.
Feb 22 09:24:29 host-12 journal: Runtime journal is using 8.0M (max allowed 
1.6G, trying to leave 2.4G free of 16.4G available → current limit 1.6G).
Feb 22 09:24:29 host-12 kernel: RPC: Registered named UNIX socket transport 
module.
Feb 22 09:24:29 host-12 kernel: RPC: Registered udp transport module.
Feb 22 09:24:29 host-12 kernel: RPC: Registered tcp transport module.
Feb 22 09:24:29 host-12 kernel: RPC: Registered tcp NFSv4.1 backchannel 
transport module.
Feb 22 09

Re: linux-next 0112 tree breaks fs DAX

[Xiong Zhou]

On Fri, Jan 13, 2017 at 06:16:41PM +0800, Xiong Zhou wrote:
> Hi,
> 
> These cases "hang" when testing with -o dax mount option:
> xfstests generic/030 generic/34{0,4,5,6} generic/198
> (maybe more)
> 
> The test programme holetest or aiodio keep running for a
> long time. It's killable, but it seems never return.
> 
> With both ext4 and xfs as fs.
> 
> Without -o dax mount option, cases pass in seconds.
> 
> 0111 tree passed the tests.
> 
> sh-4.2# git log --oneline next-20170111..next-20170112 fs/dax.c
> 0c9a7909dd13 mm, dax: change pmd_fault() to take only vmf parameter
> f8dbc198d4ea mm, dax: make pmd_fault() and friends be the same as fault()

0112 tree with above 2 commits reverted pass the tests.

Re: [PATCH] dax: fix deadlock with DAX 4k holes

[Xiong Zhou]

On Tue, Jan 03, 2017 at 02:36:05PM -0700, Ross Zwisler wrote:
> Currently in DAX if we have three read faults on the same hole address we
> can end up with the following:
> 
> Thread 0  Thread 1Thread 2
>   
> dax_iomap_fault
>  grab_mapping_entry
>   lock_slot
>
> 
>   dax_iomap_fault
>grab_mapping_entry
> get_unlocked_mapping_entry
>  
> 
>   dax_iomap_fault
>grab_mapping_entry
> get_unlocked_mapping_entry
>  
>   dax_load_hole
>find_or_create_page
>...
> page_cache_tree_insert
>  dax_wake_mapping_entry_waiter
>   
>  __radix_tree_replace
>   
> 
>   
>   get_page
>   lock_page
>   ...
>   put_locked_mapping_entry
>   unlock_page
>   put_page
> 
>   wait queue>
> 
> The crux of the problem is that once we insert a 4k zero page, all locking
> from then on is done in terms of that 4k zero page and any additional
> threads sleeping on the empty DAX entry will never be woken.  Fix this by
> waking all sleepers when we replace the DAX radix tree entry with a 4k zero
> page.  This will allow all sleeping threads to successfully transition from
> locking based on the DAX empty entry to locking on the 4k zero page.
> 
> With the test case reported by Xiong this happens very regularly in my test
> setup, with some runs resulting in 9+ threads in this deadlocked state.
> With this fix I've been able to run that same test dozens of times in a
> loop without issue.
> 
> Signed-off-by: Ross Zwisler 
> Reported-by: Xiong Zhou 
> Fixes: commit ac401cc78242 ("dax: New fault locking")
> Cc: Jan Kara 
> Cc: sta...@vger.kernel.org # 4.7+
> ---

Positive test result of this patch for this issue and the regression
tests.

Great job!

> 
> This issue exists as far back as v4.7, and I was easly able to reproduce it
> with v4.7 using the same test.
> 
> Unfortunately this patch won't apply cleanly to the stable trees, but the
> change is very simple and should be easy to replicate by hand.  Please ping
> me if you'd like patches that apply cleanly to the v4.9 and v4.8.15 trees.
> 
> ---
>  mm/filemap.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/mm/filemap.c b/mm/filemap.c
> index d0e4d10..b772a33 100644
> --- a/mm/filemap.c
> +++ b/mm/filemap.c
> @@ -138,7 +138,7 @@ static int page_cache_tree_insert(struct address_space 
> *mapping,
>   dax_radix_locked_entry(0, RADIX_DAX_EMPTY));
>   /* Wakeup waiters for exceptional entry lock */
>   dax_wake_mapping_entry_waiter(mapping, page->index, p,
> -   false);
> +   true);
>   }
>   }
>   __radix_tree_replace(&mapping->page_tree, node, slot, page,
> -- 
> 2.7.4
> 

Re: LTP rwtest01 blocks on DAX mountpoint

[Xiong Zhou]

On Tue, Jan 03, 2017 at 09:57:10AM -0700, Ross Zwisler wrote:
> On Tue, Jan 03, 2017 at 02:49:22PM +0800, Xiong Zhou wrote:
> > On Mon, Jan 02, 2017 at 02:49:41PM -0700, Ross Zwisler wrote:
> > > On Mon, Jan 02, 2017 at 06:16:17PM +0100, Jan Kara wrote:
> > > > On Fri 30-12-16 17:33:53, Xiong Zhou wrote:
> > > > > On Sat, Dec 24, 2016 at 07:07:14PM +0800, Xiong Zhou wrote:
> > > > > > Hi lists,
> > snip
> > > > I was trying to reproduce this but for me rwtest01 completes just fine 
> > > > on
> > > > dax mountpoint (I've used your reproducer). So can you sample several
> > > > kernel stack traces to get a rough idea where the kernel is running?
> > > > Thanks!
> > > > 
> > > > Honza
> > > 
> > > I'm also unable to reproduce this issue.  I've tried with both the blamed
> > > commit:
> > > 4b4bb46 (HEAD) dax: clear dirty entry tags on cache flush
> > > and with v4.9-rc2.  Both pass the test in my setup.
> > > Perhaps the variable is the size of your PMEM partitions?
> > > # fdisk -l /dev/pmem0
> > > Disk /dev/pmem0: 16 GiB, 17179869184 bytes, 33554432 sectors
> > > Units: sectors of 1 * 512 = 512 bytes
> > > Sector size (logical/physical): 512 bytes / 4096 bytes
> > > I/O size (minimum/optimal): 4096 bytes / 4096 bytes
> > > Disklabel type: dos
> > > Disk identifier: 0xfe50c900
> > > Device   BootStart  End  Sectors Size Id Type
> > > /dev/pmem0p1  4096 25165823 25161728  12G 83 Linux
> > > /dev/pmem0p2  25165824 33550335  8384512   4G 83 Linux
> > > 
> > > What does your setup look like?
> > > I'm using the current tip of the LTP tree:
> > > 8cc4165  waitid02: define _XOPEN_SOURCE 500
> > > Thanks,
> > > - Ross
> > 
> > Thanks all for looking into it.
> > 
> > Turns out the rc2 relative updates fix this issue, so does
> > an old issue i reported a while ago:
> > multi-threads libvmmalloc fork test hang
> > https://lists.01.org/pipermail/linux-nvdimm/2016-October/007602.html
> > 
> > I'm able to reproduce these issues before rc2, now it
> > passes on current Linus tree:
> > c8b4ec8 Merge tag 'fscrypt-for-stable'
> 
> Hmm...I'm able to reproduce the other libvmmalloc issue with both v4.10-rc2
> and with "c8b4ec8 Merge tag 'fscrypt-for-stable'".  I'm debugging that issue
> today.
> 
> It's interesting that both tests started passing for you.  Did you change
> something in your test setup?

Hi,

Quick update:
  Ross's new patch fixed the vmmaloc_fork issue, not the rc2 update.
  Regression tests is going on, so far so good.

I'm able to reproduce the vmmalloc_fork issue on rc2 kernel
c8b4ec8 Merge tag 'fscrypt-for-stable'
with nvml commit to
77c2a5a Merge pull request #1554 from krzycz/win-libvmem_rc

My previous statement about rc2 fixed old vmmalloc_fork issue
was wrong, my mistake. I have changed my test setup.

Now after some tests, Ross's patch
[PATCH] dax: fix deadlock with DAX 4k holes
on top of Linus tree c8b4ec8 have fixed this vmmalloc_fork issue.
My DAX regression tests is going on, looks good so far. Gonna
update once it have finished.

> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: LTP rwtest01 blocks on DAX mountpoint

[Xiong Zhou]

On Tue, Jan 03, 2017 at 09:57:10AM -0700, Ross Zwisler wrote:
> On Tue, Jan 03, 2017 at 02:49:22PM +0800, Xiong Zhou wrote:
> > On Mon, Jan 02, 2017 at 02:49:41PM -0700, Ross Zwisler wrote:
> > > On Mon, Jan 02, 2017 at 06:16:17PM +0100, Jan Kara wrote:
> > > > On Fri 30-12-16 17:33:53, Xiong Zhou wrote:
> > > > > On Sat, Dec 24, 2016 at 07:07:14PM +0800, Xiong Zhou wrote:
> > > > > > Hi lists,
> > snip
> > > > I was trying to reproduce this but for me rwtest01 completes just fine 
> > > > on
> > > > dax mountpoint (I've used your reproducer). So can you sample several
> > > > kernel stack traces to get a rough idea where the kernel is running?
> > > > Thanks!
> > > > 
> > > > Honza
> > > 
> > > I'm also unable to reproduce this issue.  I've tried with both the blamed
> > > commit:
> > > 4b4bb46 (HEAD) dax: clear dirty entry tags on cache flush
> > > and with v4.9-rc2.  Both pass the test in my setup.
> > > Perhaps the variable is the size of your PMEM partitions?
> > > # fdisk -l /dev/pmem0
> > > Disk /dev/pmem0: 16 GiB, 17179869184 bytes, 33554432 sectors
> > > Units: sectors of 1 * 512 = 512 bytes
> > > Sector size (logical/physical): 512 bytes / 4096 bytes
> > > I/O size (minimum/optimal): 4096 bytes / 4096 bytes
> > > Disklabel type: dos
> > > Disk identifier: 0xfe50c900
> > > Device   BootStart  End  Sectors Size Id Type
> > > /dev/pmem0p1  4096 25165823 25161728  12G 83 Linux
> > > /dev/pmem0p2  25165824 33550335  8384512   4G 83 Linux
> > > 
> > > What does your setup look like?
> > > I'm using the current tip of the LTP tree:
> > > 8cc4165  waitid02: define _XOPEN_SOURCE 500
> > > Thanks,
> > > - Ross
> > 
> > Thanks all for looking into it.
> > 
> > Turns out the rc2 relative updates fix this issue, so does
> > an old issue i reported a while ago:
> > multi-threads libvmmalloc fork test hang
> > https://lists.01.org/pipermail/linux-nvdimm/2016-October/007602.html
> > 
> > I'm able to reproduce these issues before rc2, now it
> > passes on current Linus tree:
> > c8b4ec8 Merge tag 'fscrypt-for-stable'
> 
> Hmm...I'm able to reproduce the other libvmmalloc issue with both v4.10-rc2
> and with "c8b4ec8 Merge tag 'fscrypt-for-stable'".  I'm debugging that issue
> today.
> 
> It's interesting that both tests started passing for you.  Did you change
> something in your test setup?

Er.. After double-checking, I have reduced nvml check test time on
Dec 30,

-make -C src check -j $NR_CPU
+make -C src check -j $NR_CPU TEST_TIME=1m

Other then this, nothing changed but the kernel code, same machine,
same cmdline, same configs.

I'm going to dig this more, and test your patch.

Thanks for looking into this!
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: LTP rwtest01 blocks on DAX mountpoint

[Xiong Zhou]

On Tue, Jan 03, 2017 at 09:57:10AM -0700, Ross Zwisler wrote:
> On Tue, Jan 03, 2017 at 02:49:22PM +0800, Xiong Zhou wrote:
> > On Mon, Jan 02, 2017 at 02:49:41PM -0700, Ross Zwisler wrote:
> > > On Mon, Jan 02, 2017 at 06:16:17PM +0100, Jan Kara wrote:
> > > > On Fri 30-12-16 17:33:53, Xiong Zhou wrote:
> > > > > On Sat, Dec 24, 2016 at 07:07:14PM +0800, Xiong Zhou wrote:
> > > > > > Hi lists,
> > snip
> > > > I was trying to reproduce this but for me rwtest01 completes just fine 
> > > > on
> > > > dax mountpoint (I've used your reproducer). So can you sample several
> > > > kernel stack traces to get a rough idea where the kernel is running?
> > > > Thanks!
> > > > 
> > > > Honza
> > > 
> > > I'm also unable to reproduce this issue.  I've tried with both the blamed
> > > commit:
> > > 4b4bb46 (HEAD) dax: clear dirty entry tags on cache flush
> > > and with v4.9-rc2.  Both pass the test in my setup.
> > > Perhaps the variable is the size of your PMEM partitions?
> > > # fdisk -l /dev/pmem0
> > > Disk /dev/pmem0: 16 GiB, 17179869184 bytes, 33554432 sectors
> > > Units: sectors of 1 * 512 = 512 bytes
> > > Sector size (logical/physical): 512 bytes / 4096 bytes
> > > I/O size (minimum/optimal): 4096 bytes / 4096 bytes
> > > Disklabel type: dos
> > > Disk identifier: 0xfe50c900
> > > Device   BootStart  End  Sectors Size Id Type
> > > /dev/pmem0p1  4096 25165823 25161728  12G 83 Linux
> > > /dev/pmem0p2  25165824 33550335  8384512   4G 83 Linux
> > > 
> > > What does your setup look like?
> > > I'm using the current tip of the LTP tree:
> > > 8cc4165  waitid02: define _XOPEN_SOURCE 500
> > > Thanks,
> > > - Ross
> > 
> > Thanks all for looking into it.
> > 
> > Turns out the rc2 relative updates fix this issue, so does
> > an old issue i reported a while ago:
> > multi-threads libvmmalloc fork test hang
> > https://lists.01.org/pipermail/linux-nvdimm/2016-October/007602.html
> > 
> > I'm able to reproduce these issues before rc2, now it
> > passes on current Linus tree:
> > c8b4ec8 Merge tag 'fscrypt-for-stable'
> 
> Hmm...I'm able to reproduce the other libvmmalloc issue with both v4.10-rc2
> and with "c8b4ec8 Merge tag 'fscrypt-for-stable'".  I'm debugging that issue
> today.
> 
> It's interesting that both tests started passing for you.  Did you change
> something in your test setup?

Nope.

Re: LTP rwtest01 blocks on DAX mountpoint

[Xiong Zhou]

On Mon, Jan 02, 2017 at 02:49:41PM -0700, Ross Zwisler wrote:
> On Mon, Jan 02, 2017 at 06:16:17PM +0100, Jan Kara wrote:
> > On Fri 30-12-16 17:33:53, Xiong Zhou wrote:
> > > On Sat, Dec 24, 2016 at 07:07:14PM +0800, Xiong Zhou wrote:
> > > > Hi lists,
snip
> > I was trying to reproduce this but for me rwtest01 completes just fine on
> > dax mountpoint (I've used your reproducer). So can you sample several
> > kernel stack traces to get a rough idea where the kernel is running?
> > Thanks!
> > 
> > Honza
> 
> I'm also unable to reproduce this issue.  I've tried with both the blamed
> commit:
> 4b4bb46 (HEAD) dax: clear dirty entry tags on cache flush
> and with v4.9-rc2.  Both pass the test in my setup.
> Perhaps the variable is the size of your PMEM partitions?
> # fdisk -l /dev/pmem0
> Disk /dev/pmem0: 16 GiB, 17179869184 bytes, 33554432 sectors
> Units: sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 4096 bytes
> I/O size (minimum/optimal): 4096 bytes / 4096 bytes
> Disklabel type: dos
> Disk identifier: 0xfe50c900
> Device   BootStart  End  Sectors Size Id Type
> /dev/pmem0p1  4096 25165823 25161728  12G 83 Linux
> /dev/pmem0p2  25165824 33550335  8384512   4G 83 Linux
> 
> What does your setup look like?
> I'm using the current tip of the LTP tree:
> 8cc4165  waitid02: define _XOPEN_SOURCE 500
> Thanks,
> - Ross

Thanks all for looking into it.

Turns out the rc2 relative updates fix this issue, so does
an old issue i reported a while ago:
multi-threads libvmmalloc fork test hang
https://lists.01.org/pipermail/linux-nvdimm/2016-October/007602.html

I'm able to reproduce these issues before rc2, now it
passes on current Linus tree:
c8b4ec8 Merge tag 'fscrypt-for-stable'

Thanks,
Xiong

> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: LTP rwtest01 blocks on DAX mountpoint

[Xiong Zhou]

On Sat, Dec 24, 2016 at 07:07:14PM +0800, Xiong Zhou wrote:
> Hi lists,
> 
> Since around 20161129 tag, LTP rwtest01 on dax mountpoint blocks
> on linux-next tree, now on Linus tree.
> 
> In "normal", rwtest01 subcase ends in a few minutes, now it keeps
> running for hours on dax mountpoint, both ext4 and xfs. Ctrl + c
> can interrupt it.

Test programme is waiting for a memcpy call to return.

>From sysrq output, kernel code is not blocking on somewhere,
it just wont return.

> 
> It is always reproducible, blocking following tests.
> 
> It does not happen when mounting without dax option.
> It does not happen on v4.9.
> 
> Bisect point to:
> 
> commit 4b4bb46d00b386e1c972890dc5785a7966eaa9c0
> Author: Jan Kara 
> Date:   Wed Dec 14 15:07:53 2016 -0800
> 
> dax: clear dirty entry tags on cache flush
> 
> 
> Reverting this commit on top of Linus tree "fixes" this issue.
> 
> Reproducer:
> 
> sh-4.2# cat rwt
> rwtest01 export LTPROOT; rwtest -N rwtest01 -c -q -i 60s  -f sync 
> 10%25000:$TMPDIR/rw-sync-$$
> sh-4.2# 
> mkfs.xfs /dev/pmem0p1
> mount -o dax /dev/pmem0p1 /daxmnt && \
> /opt/ltp/runltp -q -d /daxmnt -f rwt -p -b /dev/pmem0p2 -B xfs
> umount /daxmnt
> 
> Bisect log is attached.
> 
> Thanks,
> Xiong

> git bisect start
> # bad: [50f6584e4c626b8fa39edb66f33fec27bab3996c] Merge tag 
> 'leds_for_4.10_email_update' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds
> git bisect bad 50f6584e4c626b8fa39edb66f33fec27bab3996c
> # good: [69973b830859bc6529a7a0468ba0d80ee5117826] Linux 4.9
> git bisect good 69973b830859bc6529a7a0468ba0d80ee5117826
> # good: [5266e70335dac35c35b5ca9cea4251c1389d4a68] Merge tag 'tty-4.10-rc1' 
> of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty
> git bisect good 5266e70335dac35c35b5ca9cea4251c1389d4a68
> # bad: [6df8b74b1720db1133ace0861cb6721bfe57819a] Merge tag 
> 'devicetree-for-4.10' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux
> git bisect bad 6df8b74b1720db1133ace0861cb6721bfe57819a
> # good: [f4000cd99750065d5177555c0a805c97174d1b9f] Merge tag 'arm64-upstream' 
> of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux
> git bisect good f4000cd99750065d5177555c0a805c97174d1b9f
> # bad: [e1e14ab8411df344a17687821f8f78f0a1e73cbb] radix tree test suite: 
> delete unused rcupdate.c
> git bisect bad e1e14ab8411df344a17687821f8f78f0a1e73cbb
> # good: [f5b893c947151d424a4ab55ea3a8544b81974b31] scsi: qla4xxx: switch to 
> pci_alloc_irq_vectors
> git bisect good f5b893c947151d424a4ab55ea3a8544b81974b31
> # good: [b9f98bd4034a3196ff068eb0fa376c5f41077480] Merge tag 'mmc-v4.10-2' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc
> git bisect good b9f98bd4034a3196ff068eb0fa376c5f41077480
> # good: [4d1f0fb096aedea7bb5489af93498a82e467c480] kernel/watchdog: use nmi 
> registers snapshot in hardlockup handler
> git bisect good 4d1f0fb096aedea7bb5489af93498a82e467c480
> # good: [5b56d49fc31dbb0487e14ead790fc81ca9fb2c99] mm: add locked parameter 
> to get_user_pages_remote()
> git bisect good 5b56d49fc31dbb0487e14ead790fc81ca9fb2c99
> # bad: [cfa40bcfd6fed7010b1633bf127ed8571d3b607e] radix tree test suite: 
> benchmark for iterator
> git bisect bad cfa40bcfd6fed7010b1633bf127ed8571d3b607e
> # good: [a41b70d6dfc28b9e1a17c2a9f3181c2b614bfd54] mm: use vmf->page during 
> WP faults
> git bisect good a41b70d6dfc28b9e1a17c2a9f3181c2b614bfd54
> # bad: [4b4bb46d00b386e1c972890dc5785a7966eaa9c0] dax: clear dirty entry tags 
> on cache flush
> git bisect bad 4b4bb46d00b386e1c972890dc5785a7966eaa9c0
> # good: [a19e25536ed3a20845f642ce531e10c27fb2add5] mm: change return values 
> of finish_mkwrite_fault()
> git bisect good a19e25536ed3a20845f642ce531e10c27fb2add5
> # good: [a6abc2c0e77b16480f4d2c1eb7925e5287ae1526] dax: make cache flushing 
> protected by entry lock
> git bisect good a6abc2c0e77b16480f4d2c1eb7925e5287ae1526
> # good: [2f89dc12a25ddf995b9acd7b6543fe892e3473d6] dax: protect PTE 
> modification on WP fault by radix tree entry lock
> git bisect good 2f89dc12a25ddf995b9acd7b6543fe892e3473d6
> # first bad commit: [4b4bb46d00b386e1c972890dc5785a7966eaa9c0] dax: clear 
> dirty entry tags on cache flush

> ___
> Linux-nvdimm mailing list
> linux-nvd...@lists.01.org
> https://lists.01.org/mailman/listinfo/linux-nvdimm

LTP rwtest01 blocks on DAX mountpoint

[Xiong Zhou]

Hi lists,

Since around 20161129 tag, LTP rwtest01 on dax mountpoint blocks
on linux-next tree, now on Linus tree.

In "normal", rwtest01 subcase ends in a few minutes, now it keeps
running for hours on dax mountpoint, both ext4 and xfs. Ctrl + c
can interrupt it.

It is always reproducible, blocking following tests.

It does not happen when mounting without dax option.
It does not happen on v4.9.

Bisect point to:

commit 4b4bb46d00b386e1c972890dc5785a7966eaa9c0
Author: Jan Kara 
Date:   Wed Dec 14 15:07:53 2016 -0800

dax: clear dirty entry tags on cache flush


Reverting this commit on top of Linus tree "fixes" this issue.

Reproducer:

sh-4.2# cat rwt
rwtest01 export LTPROOT; rwtest -N rwtest01 -c -q -i 60s  -f sync 
10%25000:$TMPDIR/rw-sync-$$
sh-4.2# 
mkfs.xfs /dev/pmem0p1
mount -o dax /dev/pmem0p1 /daxmnt && \
/opt/ltp/runltp -q -d /daxmnt -f rwt -p -b /dev/pmem0p2 -B xfs
umount /daxmnt

Bisect log is attached.

Thanks,
Xiong
git bisect start
# bad: [50f6584e4c626b8fa39edb66f33fec27bab3996c] Merge tag 
'leds_for_4.10_email_update' of 
git://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds
git bisect bad 50f6584e4c626b8fa39edb66f33fec27bab3996c
# good: [69973b830859bc6529a7a0468ba0d80ee5117826] Linux 4.9
git bisect good 69973b830859bc6529a7a0468ba0d80ee5117826
# good: [5266e70335dac35c35b5ca9cea4251c1389d4a68] Merge tag 'tty-4.10-rc1' of 
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty
git bisect good 5266e70335dac35c35b5ca9cea4251c1389d4a68
# bad: [6df8b74b1720db1133ace0861cb6721bfe57819a] Merge tag 
'devicetree-for-4.10' of 
git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux
git bisect bad 6df8b74b1720db1133ace0861cb6721bfe57819a
# good: [f4000cd99750065d5177555c0a805c97174d1b9f] Merge tag 'arm64-upstream' 
of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux
git bisect good f4000cd99750065d5177555c0a805c97174d1b9f
# bad: [e1e14ab8411df344a17687821f8f78f0a1e73cbb] radix tree test suite: delete 
unused rcupdate.c
git bisect bad e1e14ab8411df344a17687821f8f78f0a1e73cbb
# good: [f5b893c947151d424a4ab55ea3a8544b81974b31] scsi: qla4xxx: switch to 
pci_alloc_irq_vectors
git bisect good f5b893c947151d424a4ab55ea3a8544b81974b31
# good: [b9f98bd4034a3196ff068eb0fa376c5f41077480] Merge tag 'mmc-v4.10-2' of 
git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc
git bisect good b9f98bd4034a3196ff068eb0fa376c5f41077480
# good: [4d1f0fb096aedea7bb5489af93498a82e467c480] kernel/watchdog: use nmi 
registers snapshot in hardlockup handler
git bisect good 4d1f0fb096aedea7bb5489af93498a82e467c480
# good: [5b56d49fc31dbb0487e14ead790fc81ca9fb2c99] mm: add locked parameter to 
get_user_pages_remote()
git bisect good 5b56d49fc31dbb0487e14ead790fc81ca9fb2c99
# bad: [cfa40bcfd6fed7010b1633bf127ed8571d3b607e] radix tree test suite: 
benchmark for iterator
git bisect bad cfa40bcfd6fed7010b1633bf127ed8571d3b607e
# good: [a41b70d6dfc28b9e1a17c2a9f3181c2b614bfd54] mm: use vmf->page during WP 
faults
git bisect good a41b70d6dfc28b9e1a17c2a9f3181c2b614bfd54
# bad: [4b4bb46d00b386e1c972890dc5785a7966eaa9c0] dax: clear dirty entry tags 
on cache flush
git bisect bad 4b4bb46d00b386e1c972890dc5785a7966eaa9c0
# good: [a19e25536ed3a20845f642ce531e10c27fb2add5] mm: change return values of 
finish_mkwrite_fault()
git bisect good a19e25536ed3a20845f642ce531e10c27fb2add5
# good: [a6abc2c0e77b16480f4d2c1eb7925e5287ae1526] dax: make cache flushing 
protected by entry lock
git bisect good a6abc2c0e77b16480f4d2c1eb7925e5287ae1526
# good: [2f89dc12a25ddf995b9acd7b6543fe892e3473d6] dax: protect PTE 
modification on WP fault by radix tree entry lock
git bisect good 2f89dc12a25ddf995b9acd7b6543fe892e3473d6
# first bad commit: [4b4bb46d00b386e1c972890dc5785a7966eaa9c0] dax: clear dirty 
entry tags on cache flush

multi-threads libvmmalloc fork test hang

[Xiong Zhou]

# description

nvml test suite vmmalloc_fork test hang.

$ ps -eo stat,comm  | grep vmma
S+   vmmalloc_fork
Sl+  vmmalloc_fork
Z+   vmmalloc_fork 
Sl+  vmmalloc_fork
Z+   vmmalloc_fork 
Z+   vmmalloc_fork 
Sl+  vmmalloc_fork
Z+   vmmalloc_fork 
Z+   vmmalloc_fork 
Z+   vmmalloc_fork 

dmesg:

[  250.499097] INFO: task vmmalloc_fork:9805 blocked for more than 120 seconds.
[  250.530667]   Not tainted 4.9.09fe68ca+ #27
[  250.550901] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this 
message.
[  250.585752] vmmalloc_fork   D[  250.598362]  8171813c 0  9805   
9765 0x0080
[  250.623445]  88075dc68f80[  250.636052]   
88076058db00 88017c5b 880763b19340[  250.668510]  
c9000fe1bbb0 8171813c c9000fe1bc20 c9000fe1bbe0[  
250.704220]  82248898 88076058db00 82248898Call Trace:
[  250.738382]  [] ? __schedule+0x21c/0x6a0
[  250.763404]  [] schedule+0x36/0x80
[  250.786177]  [] get_unlocked_mapping_entry+0xc1/0x120
[  250.815869]  [] ? iomap_dax_rw+0x110/0x110
[  250.841350]  [] grab_mapping_entry+0x4a/0x220
[  250.868442]  [] iomap_dax_fault+0xa9/0x3b0
[  250.894437]  [] xfs_filemap_fault+0xce/0xf0 [xfs]
[  250.922805]  [] __do_fault+0x79/0x100
[  250.947035]  [] do_fault+0x49b/0x690
[  250.970964]  [] ? xfs_filemap_pmd_fault+0x9c/0x160 [xfs]
[  251.001812]  [] handle_mm_fault+0x61a/0xa50
[  251.027736]  [] __do_page_fault+0x22a/0x4a0
[  251.053700]  [] do_page_fault+0x30/0x80
[  251.077962]  [] ? do_syscall_64+0x175/0x180
[  251.103835]  [] page_fault+0x28/0x30


# kernel versions:

v4.6 pass in seconds
v4.7 hang
v4.9-rc1 hang
Linus tree to commit 9fe68ca hang

bisect points to 
 first bad commit: [ac401cc782429cc8560ce4840b1405d603740917] dax: New fault 
locking

v4.7 with these 3 commits reverted pass:
4d9a2c8 - Jan Kara, 6 months ago : dax: Remove i_mmap_lock protection
bc2466e - Jan Kara, 6 months ago : dax: Use radix tree entry lock to protect 
cow faults
ac401cc - Jan Kara, 6 months ago : dax: New fault locking

# nvml version:
https://github.com/pmem/nvml.git
to commit:
  feab4d6f65102139ce460890c898fcad09ce20ae

# How reproducible:
always

# Test steps:



$cd nvml
$make install -j64

$cat > src/test/testconfig.sh <

xfstests xfs fuzzers fail with DAX

[Xiong Zhou]

Hi,

A few xfs fuzzers in xfstests fail with dax mount option, pass without dax.
They are xfs/086 xfs/088 xfs/089 xfs/091.

xfstests to commit 4470ad4c7e  (Jul 26)
kernel   to commit dd95069545  (Jul 24)

+ ./check xfs/091
FSTYP -- xfs (non-debug)
PLATFORM  -- Linux/x86_64 rhel73 4.7.0+
MKFS_OPTIONS  -- -f -bsize=4096 /dev/pmem1
MOUNT_OPTIONS -- -o context=system_u:object_r:nfs_t:s0 /dev/pmem1 /daxsch

xfs/091  104s
Ran: xfs/091
Passed all 1 tests

+ echo 'MOUNT_OPTIONS="-o dax"'
+ ./check xfs/091
FSTYP -- xfs (non-debug)
PLATFORM  -- Linux/x86_64 rhel73 4.7.0+
MKFS_OPTIONS  -- -f -bsize=4096 /dev/pmem1
MOUNT_OPTIONS -- -o dax -o context=system_u:object_r:nfs_t:s0 /dev/pmem1 /daxsch

xfs/091 104s ...  - output mismatch (see 
/root/xfstests/results//xfs/091.out.bad)
--- tests/xfs/091.out   2016-07-18 02:57:47.67000 -0400
+++ /root/xfstests/results//xfs/091.out.bad 2016-08-03 22:38:14.94800 
-0400
@@ -6,6 +6,70 @@
 + corrupt image
 + mount image
 + modify files
+pwrite64: Structure needs cleaning
+pwrite64: Structure needs cleaning
+pwrite64: Structure needs cleaning
+pwrite64: Structure needs cleaning
...
(Run 'diff -u tests/xfs/091.out /root/xfstests/results//xfs/091.out.bad'  
to see the entire diff)
Ran: xfs/091
Failures: xfs/091
Failed 1 of 1 tests

# diff -u xfstests/tests/xfs/091.out /root/xfstests/results//xfs/091.out.bad
--- xfstests/tests/xfs/091.out  2016-07-18 02:57:47.67000 -0400
+++ /root/xfstests/results//xfs/091.out.bad 2016-08-03 22:38:14.94800 
-0400
@@ -6,6 +6,70 @@
 + corrupt image
 + mount image
 + modify files
+pwrite64: Structure needs cleaning

+pwrite64: Structure needs cleaning
 + repair fs
 + mount image
 + chattr -R -i


Thanks,
Xiong

Re: [PATCH] Fix reported kmemleak

[Xiong Zhou]

Hi,

On Tue, Jun 07, 2016 at 11:23:30AM -0500, Shaun Tancheff wrote:
> This fixes a memory leak reported by a few people in 4.7-rc1
> 
> kmemleak report after 9082e87bfbf8 ("block: remove struct bio_batch")
> 
> This patch just formalizes the one in this discussion here:
> https://lkml.kernel.org/r/20160606112620.ga29...@e104818-lin.cambridge.arm.com
> 
> The same issue appears here:
> https://lkml.kernel.org/r/20160607102651.ga6...@dhcp12-144.nay.redhat.com
> 
> Patch is also available at:
> 
> https://github.com/stancheff/linux.git
> branch: v4.7-rc2+bio_put
> 
> Cc: Christoph Hellwig 
> Cc: ax...@kernel.dk
> cc: David Drysdale 
> Cc: Xiong Zhou 

Thanks for the information!

> Cc: Stephen Rothwell 
> Cc: linux-n...@vger.kernel.org
> Cc: linux-nvd...@ml01.01.org
> Cc: Christoph Hellwig 
> Cc: Larry Finger 
> Cc: Catalin Marinas 
> Cc: LKML ,
> Cc: Jens Axboe ,
> Cc: bart.vanass...@sandisk.com
> 
> Shaun Tancheff (1):
>   Missing bio_put following submit_bio_wait
> 
>  block/blk-lib.c | 12 +---
>  1 file changed, 9 insertions(+), 3 deletions(-)
> 
> -- 
> 2.8.1
> 

Re: linux-next/linux memleak after IO on dax mountpoint

[Xiong Zhou]

adding block-list

On Fri, Jun 03, 2016 at 09:48:27AM -0700, Bart Van Assche wrote:
> On 06/02/2016 08:22 AM, David Drysdale wrote:
> > FWIW, I'm also seeing kmemleak report a leak with v4.7-rc1, in
> > a different scenario (just normal desktop use).  Not done much
> > digging so far, but this commit (9082e87bf) looks like it might be
> > relevant -- lots of the following:
> > 
> > unreferenced object 0x8800c288e900 (size 256):
> >   comm "dconf-service", pid 1461, jiffies 4294895636 (age 48.028s)
> >   hex dump (first 32 bytes):
> > 00 00 00 00 00 00 00 00 c0 a4 c0 c6 00 88 ff ff  
> > 02 20 00 20 00 00 00 00 11 00 00 00 00 00 00 00  . . 
> >   backtrace:
> > [] kmemleak_alloc+0x28/0x50
> > [] kmem_cache_alloc+0xfc/0x360
> > [] mempool_alloc_slab+0x15/0x20
> > [] mempool_alloc+0x6e/0x170
> > [] bio_alloc_bioset+0xb8/0x230
> > [] next_bio+0x24/0x50
> > [] blkdev_issue_zeroout+0xdf/0x1d0
> > [] ext4_issue_zeroout+0x39/0x50
> > [] ext4_ext_zeroout+0x2f/0x40
> > [] ext4_ext_map_blocks+0x1870/0x2190
> > [] ext4_map_blocks+0x111/0x620
> > [] ext4_writepages+0x7c8/0x10a0
> > [] do_writepages+0x21/0x30
> > [] __filemap_fdatawrite_range+0xaa/0xf0
> > [] filemap_write_and_wait_range+0x2d/0x70
> > [] ext4_sync_file+0x18d/0x500
> 
> (+Christoph)
> 
> With kernel v4.7-rc1 and XFS I see that the blkdev_issue_zeroout() calls
> triggered by xfstests make kmemleak complain. I hadn't seen this with any
> previous kernel version.
> 
> Bart.


unreferenced object 0x880c4bce2800 (size 2048):
  comm "dbench", pid 11389, jiffies 4294884573 (age 193.194s)
  hex dump (first 32 bytes):
c0 1d 09 00 00 ea ff ff 00 10 00 00 00 00 00 00  
c0 1d 09 00 00 ea ff ff 00 10 00 00 00 00 00 00  
  backtrace:
[] kmemleak_alloc+0x4e/0xb0
[] kmem_cache_alloc+0xc3/0x200
[] bvec_alloc+0x5c/0xf0
[] bio_alloc_bioset+0x1ce/0x2d0
[] next_bio+0x24/0x50
[] blkdev_issue_zeroout+0xe0/0x1d0
[] ext4_issue_zeroout+0x38/0x50 [ext4]
[] ext4_map_blocks+0x39e/0x640 [ext4]
[] _ext4_get_block+0x93/0xf0 [ext4]
[] ext4_get_block_trans+0xbf/0x110 [ext4]
[] ext4_dax_get_block+0x25/0x70 [ext4]
[] dax_do_io+0x446/0x610
[] ext4_direct_IO+0x494/0x750 [ext4]
[] generic_file_direct_write+0xb0/0x180
[] __generic_file_write_iter+0xbd/0x1e0
[] ext4_file_write_iter+0xf7/0x330 [ext4]

Re: linux-next/linux memleak after IO on dax mountpoint

[Xiong Zhou]

On Thu, Jun 02, 2016 at 04:22:37PM +0100, David Drysdale wrote:
> On Sat, May 28, 2016 at 5:05 AM, Xiong Zhou  wrote:
> > On Fri, May 27, 2016 at 04:46:17PM +0800, Xiong Zhou wrote:
> > ...
> >> Still working on to id which commit in this merge causes this issuer,
> >
> > Narrowed down to:
> >
> > 37e5823 block: add offset in blk_add_request_payload()
...
> > 0bf77e9 nvme: switch to RCU freeing the namespace
> > 9082e87 block: remove struct bio_batch
> 
> FWIW, I'm also seeing kmemleak report a leak with v4.7-rc1, in
> a different scenario (just normal desktop use).  Not done much
> digging so far, but this commit (9082e87bf) looks like it might be
> relevant



Thanks for the tip, accelerated my searching in the block merge.

On top of v4.7-rc1 , in order to revert this commit cleanly:

9082e87 block: remove struct bio_batch

, have to revert these two:

bbd848e0f block: reinstate early return of -EOPNOTSUPP from 
blkdev_issue_discard
38f2525 block: add __blkdev_issue_discard

, then have to revert these two dependances:

202bae5 dm thin: unroll issue_discard() to create longer discard bio chains
3dba53a9 dm thin: use __blkdev_issue_discard for async discard support

With all these five commits reverted, NO memleak happens.

Reverting other four commits while not reverting 9082e87, memleak
happens.

Thanks,
Xiong

Re: linux-next memleak after IO on dax mountpoint

[Xiong Zhou]

Hi, Jeff

On Wed, Jun 01, 2016 at 10:37:26AM -0400, Jeff Moyer wrote:
> Xiong Zhou  writes:
> 
> > On Fri, May 27, 2016 at 04:46:17PM +0800, Xiong Zhou wrote:
> > ...
> >> Still working on to id which commit in this merge causes this issuer,
> >
> > Narrowed down to:
> 
> Hi Xiong,
> 
> I don't see how any of those could be at all relevant to pmem.  Can you
> post the output from 'cat /proc/slabinfo' here?

Sure. It's now reproducible in Linus tree. i'm still hunting the
bad commit.. bisecting in Linus tree point to ext4 merge commit,
but checking out to its following commit passed the test. Commits
in my last email may also not be relevant to pmem as you said.


Thanks,
Xiong

# free
  totalusedfree  shared  buff/cache   available
Mem:   32806940  4033001823776894921416587218062772
Swap:  10485756   010485756
# cat /proc/slabinfo 
slabinfo - version: 2.1
# name
 : tunables: slabdata 
  
ext4_groupinfo_4k   2296   2296144   281 : tunables000 : 
slabdata 82 82  0
ext4_inode_cache4154   4402   1056   318 : tunables000 : 
slabdata142142  0
ext4_allocation_context   1184   1184128   321 : tunables00
0 : slabdata 37 37  0
ext4_io_end 5184   5184 64   641 : tunables000 : 
slabdata 81 81  0
ext4_extent_status  23562  23562 40  1021 : tunables000 : 
slabdata231231  0
jbd2_journal_handle   3145   3145 48   851 : tunables000 : 
slabdata 37 37  0
jbd2_journal_head   6290   6290120   341 : tunables000 : 
slabdata185185  0
jbd2_revoke_table_s   6144   6144 16  2561 : tunables000 : 
slabdata 24 24  0
jbd2_revoke_record_s   4096   4096 32  1281 : tunables000 : 
slabdata 32 32  0
mbcache0  0 56   731 : tunables000 : 
slabdata  0  0  0
nf_conntrack 918918320   514 : tunables000 : 
slabdata 18 18  0
kcopyd_job 0  0   331298 : tunables000 : 
slabdata  0  0  0
dm_uevent  0  0   2632   128 : tunables000 : 
slabdata  0  0  0
kvm_async_pf   0  0136   301 : tunables000 : 
slabdata  0  0  0
kvm_vcpu   0  0  1888018 : tunables000 : 
slabdata  0  0  0
kvm_mmu_page_header  0  0168   482 : tunables000 : 
slabdata  0  0  0
fat_inode_cache   46 46704   468 : tunables000 : 
slabdata  1  1  0
fat_cache  0  0 40  1021 : tunables000 : 
slabdata  0  0  0
nfsd4_stateids 0  0176   462 : tunables000 : 
slabdata  0  0  0
nfsd4_openowners   0  0440   374 : tunables000 : 
slabdata  0  0  0
rpc_inode_cache   51 51640   518 : tunables000 : 
slabdata  1  1  0
xfs_dqtrx  0  0528   314 : tunables000 : 
slabdata  0  0  0
xfs_dquot  0  0472   344 : tunables000 : 
slabdata  0  0  0
xfs_icr0  0144   281 : tunables000 : 
slabdata  0  0  0
xfs_ili 2809   2809152   532 : tunables000 : 
slabdata 53 53  0
xfs_inode  10200  10200960   348 : tunables000 : 
slabdata300300  0
xfs_efd_item1840   1840400   404 : tunables000 : 
slabdata 46 46  0
xfs_da_state1598   1598480   344 : tunables000 : 
slabdata 47 47  0
xfs_log_ticket  2156   2156184   442 : tunables000 : 
slabdata 49 49  0
bio-1   1734   1734320   514 : tunables000 : 
slabdata 34 34  0
RAWv6   1316   1316   1152   288 : tunables000 : 
slabdata 47 47  0
UDPLITEv6  0  0   1152   288 : tunables000 : 
slabdata  0  0  0
UDPv6644644   1152   288 : tunables000 : 
slabdata 23 23  0
tw_sock_TCPv6  0  0280   292 : tunables000 : 
slabdata  0  0  0
request_sock_TCPv6  0  0328   494 : tunables000 : 
slabdata  0  0  0
TCPv6300300   2112   158 : tunables000 : 
slabdata 20 20  0
cfq_queue 

Re: linux-next memleak after IO on dax mountpoint

[Xiong Zhou]

On Fri, May 27, 2016 at 04:46:17PM +0800, Xiong Zhou wrote:
...
> Still working on to id which commit in this merge causes this issuer,

Narrowed down to:

37e5823 block: add offset in blk_add_request_payload()
e048948 blk-mq: Export tagset iter function
58b4560 nvme: add helper nvme_map_len()
03b5929 nvme: rewrite discard support
8093f7c nvme: add helper nvme_setup_cmd()
21f033f NVMe: Skip async events for degraded controllers
82b4552 nvme: Use blk-mq helper for IO termination
93e9d8e block: add ability to flag write back caching on a device
519a7e1 dm: switch to using blk_queue_write_cache()
bb8d261 nvme: introduce a controller state machine
92911a5 nvme: tighten up state check for namespace scanning
5955be2 nvme: move namespace scanning to core
f866fc4 nvme: move AER handling to common code
0bf77e9 nvme: switch to RCU freeing the namespace
9082e87 block: remove struct bio_batch
38f2525 block: add __blkdev_issue_discard
57aac2f lightnvm: fix "warning: ‘ret’ may be used uninitialized"
ecfb40c lightnvm: handle submit_io failure
1145e63 lightnvm: implement nvm_submit_ppa_list
22e8c97 lightnvm: move block fold outside of get_bb_tbl()
7f7c5d0 lightnvm: avoid memory leak when lun_map kcalloc fails
5136061 lightnvm: introduce nvm_for_each_lun_ppa() macro
e11903f lightnvm: refactor device ops->get_bb_tbl()
5ebc7d9 lightnvm: make nvm_set_rqd_ppalist() aware of vblks
a63d5cf lightnvm: move responsibility for bad blk mgmt to target
00ee6cc lightnvm: refactor set_bb_tbl for accepting ppa list
003fad3 lightnvm: enable metadata to be sent to device
04a8aa1 lightnvm: expose gennvm_mark_blk to targets


These commits can not be reverted cleanly. 

linux-next memleak after IO on dax mountpoint

[Xiong Zhou]

Hi,

Reporting an oom/memleak issue in linux-next tree:

#Description:

dbench invokes oom-killer, make host unavaiable.

dbench was doing IO on nvdimm device mounted fs with dax mount option.
It happens on both xfs and ext4 filesystems.
It does not happen testing without dax mountoption.

Seems like memleak keep happening untill system run out of memory. On
good kernels, memory get freed after every dbench run.

#Hardware
lscpu
Architecture:  x86_64
CPU op-mode(s):32-bit, 64-bit
Byte Order:Little Endian
CPU(s):48
On-line CPU(s) list:   0-47
Thread(s) per core:2
Core(s) per socket:12
Socket(s): 2
NUMA node(s):  2
Vendor ID: GenuineIntel
CPU family:6
Model: 63
Model name:Intel(R) Xeon(R) CPU E5-2690 v3 @ 2.60GHz
Stepping:  2
CPU MHz:   2596.781
BogoMIPS:  5200.05
Virtualization:VT-x
L1d cache: 32K
L1i cache: 32K
L2 cache:  256K
L3 cache:  30720K
NUMA node0 CPU(s): 0-11,24-35
NUMA node1 CPU(s): 12-23,36-47

free -g
  totalusedfree  shared  buff/cache   available
Mem: 31   0  30   0   0  30
Swap: 9   0   9

#Version:
Since next-20150517 tree, till latest 0526 tree.
0516 tree survives testing.
dbench version 4.00 - Copyright Andrew Tridgell 1999-2004

#How reproducible:
always

#Reproduce steps:
Repeating fstests[1] generic/241, 30 times, which maybe is relative
to system total ram.

#bisect info

Bisect point to this commit:

commit d6cab70166b5bf2cbeec0c566e51725c793e3aed
Merge: cb9553d 661806a
Author: Stephen Rothwell 
Date:   Tue May 17 11:18:34 2016 +1000

Merge remote-tracking branch 'block/for-next'

which is forwarding to this:

commit 661806a319890962aaa839dc1dbf7ea356aa6b92
Merge: 1335822 b3a834b
Author: Jens Axboe 
Date:   Mon May 16 09:55:01 2016 -0600

Merge branch 'for-4.7/core' into for-next


On top of 0517 tree, reset --hard to commit cb9553d passed testing,
while reset --hard to commit d6cab70 reproduced issue.


Still working on to id which commit in this merge causes this issuer,
i noticed that lots of merge were going on there
Meminfo, config, oom msg, bisect log are attached.

Thanks,
Xiong

[1] http://oss.sgi.com/cgi-bin/gitweb.cgi?p=xfs/cmds/xfstests.git
# Additional info
meminfo after running generic/241 7~8 rounds:

-- bad --

[root@host linux]# free
  totalusedfree  shared  buff/cache   available
Mem:   32807280  422756257821169456 660240826044756
Swap:  10485756   010485756
[root@host linux]# free -g
  totalusedfree  shared  buff/cache   available
Mem: 31   0  24   0   6  24
Swap: 9   0   9
[root@host linux]# git log --oneline -1
d6cab70 Merge remote-tracking branch 'block/for-next'
[root@host linux]# echo 1 > /proc/sys/vm/drop_caches 
[root@host linux]# echo 2 > /proc/sys/vm/drop_caches 
[root@host linux]# echo 3 > /proc/sys/vm/drop_caches 
[root@host linux]# free -g
  totalusedfree  shared  buff/cache   available
Mem: 31   0  23   0   6  23
Swap: 9   0   9
[root@host linux]# free
  totalusedfree  shared  buff/cache   available
Mem:   32807280  419576250508689456 733683624938336
Swap:  10485756   010485756

 good 

[root@host linux]# free
  totalusedfree  shared  buff/cache   available
Mem:   32807280  421316304258929464 196007231884116
Swap:  10485756   010485756
[root@host linux]# free -g
  totalusedfree  shared  buff/cache   available
Mem: 31   0  29   0   1  30
Swap: 9   0   9
[root@host linux]# echo 1 > /proc/sys/vm/drop_caches 
[root@host linux]# echo 2 > /proc/sys/vm/drop_caches 
[root@host linux]# echo 3 > /proc/sys/vm/drop_caches 
[root@host linux]# free -g
  totalusedfree  shared  buff/cache   available
Mem: 31   0  30   0   0  30
Swap: 9   0   9
[root@host linux]# free
  totalusedfree  shared  buff/cache   available
Mem:   32807280  410820320701969464  32626431946400
Swap:  10485756   010485756
[root@host linux]# git log --oneline -1
cb9553d Merge remote-tracking branch 'input/next'

Re: linux-next: Tree for May 17

[Xiong Zhou]

Hi Stephen,

On Mon, May 23, 2016 at 4:37 PM, Stephen Rothwell  wrote:
> Hi Xiong,
>
> On Mon, 23 May 2016 16:13:28 +0800 Xiong Zhou  wrote:
>>
>> hi,
>>
>> On Tue, May 17, 2016 at 1:04 PM, Stephen Rothwell  
>> wrote:
>> >
>> > I have created today's linux-next tree at
>> > git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
>> > (patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
>>
>> Patches after 0516 are not there.
>>
>> i'm chasing an oom issue between 0516 and 0518 trees while missed
>> 0517 tag, so is the patch file the only way to get there trying 0517 tree?
>
> They are there, just the version numbering puts them out of order in the
> page listing - they appear before patch-v4.6-rc1-next-20160327.gz

Ya, my bad, i found them.

>
> All the (recent) tags are in the git tree as well, of course.

Yes! git fetch -t saved my mess git repo.

Thank you very much!

--
Xiong


> --
> Cheers,
> Stephen Rothwell

Re: linux-next: Tree for May 17

[Xiong Zhou]

hi,

On Tue, May 17, 2016 at 1:04 PM, Stephen Rothwell  wrote:
> Hi all,
>
> Please do not add any v4.8 destined material to your linux-next included
> branches until after v4.7-rc1 has been released.
>
> Changes since 20160516:
>
> The vfs tree gained a conflict against the ext4 tree.
>
> The net-next tree gained a conflict against the arm64 tree.
>
> The spi tree lost its build failure.
>
> Non-merge commits (relative to Linus' tree): 9737
>  8314 files changed, 424907 insertions(+), 177068 deletions(-)
>
> 
>
> I have created today's linux-next tree at
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
> (patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you

Patches after 0516 are not there.

i'm chasing an oom issue between 0516 and 0518 trees while missed
0517 tag, so is the patch file the only way to get there trying 0517 tree?

Re: [PATCH v3 2/5] /dev/dax, pmem: direct access to persistent memory

[Xiong Zhou]

On Wed, May 18, 2016 at 01:56:16PM -0700, Dan Williams wrote:
> Device DAX is the device-centric analogue of Filesystem DAX
> (CONFIG_FS_DAX).  It allows memory ranges to be allocated and mapped
> without need of an intervening file system.  Device DAX is strict,
> precise and predictable.  Specifically this interface:
> 
> 1/ Guarantees fault granularity with respect to a given page size (pte,
> pmd, or pud) set at configuration time.
> 
> 2/ Enforces deterministic behavior by being strict about what fault
> scenarios are supported.
> 
> For example, by forcing MADV_DONTFORK semantics and omitting MAP_PRIVATE
> support device-dax guarantees that a mapping always behaves/performs the
> same once established.  It is the "what you see is what you get" access
> mechanism to differentiated memory vs filesystem DAX which has
> filesystem specific implementation semantics.
> 
> Persistent memory is the first target, but the mechanism is also
> targeted for exclusive allocations of performance differentiated memory
> ranges.
> 
> This commit is limited to the base device driver infrastructure to
> associate a dax device with pmem range.
> 
> Cc: Jeff Moyer 
> Cc: Christoph Hellwig 
> Cc: Andrew Morton 
> Cc: Dave Hansen 
> Cc: Ross Zwisler 
> Signed-off-by: Dan Williams 
> ---
>  drivers/Kconfig |2 
>  drivers/Makefile|1 
>  drivers/dax/Kconfig |   25 +++
>  drivers/dax/Makefile|4 +
>  drivers/dax/dax.c   |  253 
> +++
>  drivers/dax/dax.h   |   24 +++
>  drivers/dax/pmem.c  |  158 ++

An entry in MAINTAINERS for these new files ?

Thanks,
Xiong

Re: Linux-next parallel cp workload hang

[Xiong Zhou]

On Thu, May 19, 2016 at 09:02:31AM +1000, Dave Chinner wrote:
> On Thu, May 19, 2016 at 12:17:26AM +1000, Dave Chinner wrote:
> > Patch below should fix the deadlock.
> 
> The test has been running for several hours without failure using
> this patch, so I'd say this fixes the problem...

Yes, the same for me.

Thanks.

Xiong

> 
> Cheers,
> 
> Dave.
> -- 
> Dave Chinner
> da...@fromorbit.com

Linux-next parallel cp workload hang

[Xiong Zhou]

Hi,

Parallel cp workload (xfstests generic/273) hangs like blow.
It's reproducible with a small chance, less the 1/100 i think.

Have hit this in linux-next 20160504 0506 0510 trees, testing on
xfs with loop or block device. Ext4 survived several rounds
of testing.

Linux next 20160510 tree hangs within 500 rounds testing several
times. The same tree with vfs parallel lookup patchset reverted
survived 900 rounds testing. Reverted commits are attached.

Bisecting in this patchset ided this commit:

3b0a3c1ac1598722fc289da19219d14f2a37b31f is the first bad commit
commit 3b0a3c1ac1598722fc289da19219d14f2a37b31f
Author: Al Viro 
Date:   Wed Apr 20 23:42:46 2016 -0400

simple local filesystems: switch to ->iterate_shared()

no changes needed (XFS isn't simple, but it has the same parallelism
in the interesting parts exercised from CXFS).

With this commit reverted on top of Linux next 0510 tree, 5000+ rounds
of testing passed.

Although 2000 rounds testing had been conducted before good/bad
verdict, i'm not 100 percent sure about all this, since it's
so hard to hit, and i am not that lucky..

Bisect log and full blocked state process dump log are also attached.

Furthermore, this was first hit when testing fs dax on nvdimm,
however it's reproducible without dax mount option, and also
reproducible on loop device, just seems harder to hit.

Thanks,
Xiong

[0.771475] INFO: task cp:49033 blocked for more than 120 seconds.
[0.794263]   Not tainted 4.6.0-rc6-next-20160504 #5
[0.812515] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables
this message.
[0.841801] cp  D 880b4e977928 0 49033  49014
0x0080
[0.868923]  880b4e977928 880ba275d380 880b8d712b80
880b4e978000
[0.897504]  7fff 0002 
880b8d712b80
[0.925234]  880b4e977940 816cbc25 88035a1dabb0
880b4e9779e8
[0.953237] Call Trace:
[0.958314]  [] schedule+0x35/0x80
[0.974854]  [] schedule_timeout+0x231/0x2d0
[0.995728]  [] ? down_trylock+0x2d/0x40
[1.015351]  [] ? xfs_iext_bno_to_ext+0xa2/0x190 [xfs]
[1.040182]  [] __down_common+0xaa/0x104
[1.059021]  [] ? _xfs_buf_find+0x162/0x340 [xfs]
[1.081357]  [] __down+0x1d/0x1f
[1.097166]  [] down+0x41/0x50
[1.112869]  [] xfs_buf_lock+0x3c/0xf0 [xfs]
[1.134504]  [] _xfs_buf_find+0x162/0x340 [xfs]
[1.156871]  [] xfs_buf_get_map+0x2a/0x270 [xfs]
[1.180010]  [] xfs_buf_read_map+0x2d/0x180 [xfs]
[1.203538]  [] xfs_trans_read_buf_map+0xf1/0x300 [xfs]
[1.229194]  [] xfs_da_read_buf+0xd1/0x100 [xfs]
[1.251948]  [] xfs_dir3_data_read+0x26/0x60 [xfs]
[1.275736]  []
xfs_dir2_leaf_readbuf.isra.12+0x1be/0x4a0 [xfs]
[1.305094]  [] ? down_read+0x12/0x30
[1.323787]  [] ? xfs_ilock+0xe4/0x110 [xfs]
[1.345114]  [] xfs_dir2_leaf_getdents+0x13b/0x3d0
[xfs]
[1.371818]  [] xfs_readdir+0x1a6/0x1c0 [xfs]
[1.393471]  [] xfs_file_readdir+0x2b/0x30 [xfs]
[1.416874]  [] iterate_dir+0x173/0x190
[1.436709]  [] ? do_audit_syscall_entry+0x66/0x70
[1.460951]  [] SyS_getdents+0x98/0x120
[1.480566]  [] ? iterate_dir+0x190/0x190
[1.500909]  [] do_syscall_64+0x62/0x110
[1.520847]  [] entry_SYSCALL64_slow_path+0x25/0x25
[1.545372] INFO: task cp:49040 blocked for more than 120 seconds.
[1.568933]   Not tainted 4.6.0-rc6-next-20160504 #5
[1.587943] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables
this message.
[1.618544] cp  D 880b91463b00 0 49040  49016
0x0080
[1.645502]  880b91463b00 880464d5c140 88029b475700
880b91464000
[1.674145]  880411c42610  880411c42628
8802c10bc610
[1.702834]  880b91463b18 816cbc25 88029b475700
880b91463b88
[1.731501] Call Trace:
[1.736866]  [] schedule+0x35/0x80
[1.754119]  [] rwsem_down_read_failed+0xf2/0x140
[1.777411]  [] ? xfs_ilock_data_map_shared+0x30/0x40
[xfs]
[1.805090]  [] call_rwsem_down_read_failed+0x18/0x30
[1.830482]  [] down_read+0x20/0x30
[1.848505]  [] xfs_ilock+0xe4/0x110 [xfs]
[1.869293]  [] xfs_ilock_data_map_shared+0x30/0x40
[xfs]
[1.896775]  [] xfs_dir_open+0x30/0x60 [xfs]
[1.917882]  [] do_dentry_open+0x20f/0x320
[1.938919]  [] ? xfs_file_mmap+0x50/0x50 [xfs]
[1.961532]  [] vfs_open+0x57/0x60
[1.978945]  [] path_openat+0x325/0x14e0
[1.999273]  [] ? putname+0x53/0x60
[2.017695]  [] do_filp_open+0x91/0x100
[2.036893]  [] ? __alloc_fd+0x46/0x180
[2.055479]  [] do_sys_open+0x124/0x210
[2.073783]  [] ? __audit_syscall_exit+0x1db/0x260
[2.096426]  [] SyS_openat+0x14/0x20
[2.113690]  [] do_syscall_64+0x62/0x110
[2.132417]  [] entry_SYSCALL64_slow_path+0x25/0x25



g273-block-dumps.tar.gz
Description: application/gzip

Re: [PATCH trivial] scripts/prune-kernel: remove kdump images

[Xiong Zhou]

ping ?

On Mon, Mar 7, 2016 at 3:56 PM, Xiong Zhou  wrote:
> Signed-off-by: Xiong Zhou 
> ---
>  scripts/prune-kernel | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/scripts/prune-kernel b/scripts/prune-kernel
> index ab5034e..9c67be2 100755
> --- a/scripts/prune-kernel
> +++ b/scripts/prune-kernel
> @@ -14,7 +14,7 @@ do
>  echo "removing $f"
>  rm -f "/boot/initramfs-$f.img" "/boot/System.map-$f"
>  rm -f "/boot/vmlinuz-$f"   "/boot/config-$f"
> -rm -rf "/lib/modules/$f"
> +rm -rf "/lib/modules/$f" "/boot/initramfs-${f}kdump.img"
>  new-kernel-pkg --remove $f
>  fi
>  done
> --
> 2.5.0

Re: binary execution from DAX mount hang since next-20160407

[Xiong Zhou]

On Fri, Apr 15, 2016 at 4:38 PM, Hugh Dickins  wrote:
> On Fri, 15 Apr 2016, Xiong Zhou wrote:
>
>> Hi, all
>>
>> Since tag next-20160407 in linux-next repo, executing binary
>> from/in DAX mount hangs.
>>
>> It does not hang if mount without dax option.
>> It hangs with both xfs and ext4.
>> It does not hang if execute from a -t tmpfs mount.
>> It does not hang on next-20160406 and still hangs on 0414 tree.
>>
>> # ps -axjf
>> ...
>> S+   0   0:00  |   \_ sh -x thl.sh
>> R+   0  42:33  |   \_ [hl]
>> ..
>> # cat thl.sh
>> mkfs.ext4 /dev/pmem0
>> mount -o dax /dev/pmem0 /daxmnt
>> cp hl /daxmnt
>> /daxmnt/hl
>> # cat hl.c
>> void main()
>> {
>> printf("ok\n");
>> }
>> # cc hl.c -o hl
>>
>> Bisecting commits between 0406 and 0407 tag, points to this:
>>
>> d7c7d56ca61aec18e5e0cb3a64e50073c42195f7 is the first bad commit
>> commit d7c7d56ca61aec18e5e0cb3a64e50073c42195f7
>> Author: Hugh Dickins 
>> Date:   Thu Apr 7 14:00:12 2016 +1000
>>
>> huge tmpfs: avoid premature exposure of new pagetable
>>
>> Bisect log and config are attatched.
>
> Excellent and very helpful bug report: thank you very much for taking
> the trouble to make such a good report.
>
> I see why this happens now: I've not been paying enough attention
> to the DAX changes.
>
> The fix requires a repositioning of where I allocate the new page
> table: which is a change we knew we had to make for other reasons,
> but it did not appear to be a high priority compared with other things
> - until your bug report showing that I have broken DAX rather badly.
>
> In return for your excellent bug report, I can immediately offer
> the most shameful patch I have ever posted: which has the virtue of
> simplicity, and will work so long as you have plenty of free memory;
> but might deadlock if it has to go into page reclaim (or maybe not:
> perhaps the DAXness would leave it as merely a lockdep violation).
>
> Maybe not so much worse than the current hang, but still shameful:
> I'm appending it here just in case you're in a hurry to see your "ok"
> program working on DAX; but I think I'd better rearrange priorities
> and try to provide a proper fix as soon as possible.

No hurry, :)  Take your time.

>
> Never-to-be-Signed-off-by: an anonymous hacker
>
> --- 4.6-rc2-mm1/mm/memory.c 2016-04-10 10:12:06.167769232 -0700
> +++ linux/mm/memory.c   2016-04-15 00:54:06.427085026 -0700
> @@ -2874,7 +2874,7 @@ static int __do_fault(struct vm_area_str
> ret = VM_FAULT_HWPOISON;
> goto err;
> }
> -
> + out:
> /*
>  * Use pte_alloc instead of pte_alloc_map, because we can't
>  * run pte_offset_map on the pmd, if an huge pmd could
> @@ -2892,7 +2892,7 @@ static int __do_fault(struct vm_area_str
> ret = VM_FAULT_NOPAGE;
> goto err;
> }
> - out:
> +
> *page = vmf.page;
> return ret;
>  err:

Yes, "ok" is printed ok!

Re: binary execution from DAX mount hang since next-20160407

[Xiong Zhou]

# cat /proc/cmdline
BOOT_IMAGE=/vmlinuz-4.6.0-rc3-next-20160414+
root=/dev/mapper/x--01-root ro crashkernel=auto
rd.lvm.lv=x-01/root rd.lvm.lv=xx/swap console=ttyS1,115200n81
memmap=10G!5G memmap=15G!15G selinux=0 LANG=en_US.UTF-8

# mkfs.ext4 -V
mke2fs 1.43-WIP (15-Mar-2016)
Using EXT2FS Library version 1.43-WIP

# mkfs.xfs -V
mkfs.xfs version 4.5.0

Re: [-next] BUG_ON in scsi_target_destroy()

[Xiong Zhou]

Hi,

On Wed, Apr 13, 2016 at 11:14 PM, James Bottomley
 wrote:
> On Wed, 2016-04-13 at 10:41 +0200, Johannes Thumshirn wrote:
>> Hi Sergey,  Xiong,
>>
>> Can you try below patch?
>>
>> On Montag, 11. April 2016 18:01:47 CEST Sergey Senozhatsky wrote:
>> > Hello,
>> >
>> > commit 7b106f2de6938c31ce5e9c86bc70ad3904666b96
>> > Author: Johannes Thumshirn 
>> > Date:   Tue Apr 5 11:50:44 2016 +0200
>> >
>> > scsi: Add intermediate STARGET_REMOVE state to
>> > scsi_target_state
>> >
>> >
>> > BUG_ON()s (next-20160411) each time I remove a usb flash
>> >
>> > [   49.561600]  [] scsi_target_destroy+0x5a/0xcb
>> > [scsi_mod]
>> > [   49.561607]  [] scsi_target_reap+0x4a/0x4f
>> > [scsi_mod]
>> > [   49.561613]  [] __scsi_remove_device+0xc3/0xd0
>> > [scsi_mod]
>> > [   49.561619]  [] scsi_forget_host+0x52/0x63
>> > [scsi_mod]
>> > [   49.561623]  [] scsi_remove_host+0x8c/0x102
>> > [scsi_mod]
>> > [   49.561627]  [] usb_stor_disconnect+0x6b/0xab
>> > [usb_storage]
>> > [   49.561634]  []
>> > usb_unbind_interface+0x77/0x1ca [usbcore]
>> > [   49.561636]  []
>> > __device_release_driver+0x9d/0x121
>> > [   49.561638]  []
>> > device_release_driver+0x23/0x30
>> > [   49.561639]  [] bus_remove_device+0xfb/0x10e
>> > [   49.561641]  [] device_del+0x164/0x1e6
>> > [   49.561648]  [] ?
>> > remove_intf_ep_devs+0x3b/0x48 [usbcore]
>> > [   49.561655]  [] usb_disable_device+0x84/0x1a5
>> > [usbcore]
>> > [   49.561661]  [] usb_disconnect+0x94/0x19f
>> > [usbcore]
>> > [   49.561667]  [] hub_event+0x5c1/0xdea
>> > [usbcore]
>> > [   49.561670]  [] process_one_work+0x1dc/0x37f
>> > [   49.561672]  [] worker_thread+0x282/0x36d
>> > [   49.561673]  [] ? rescuer_thread+0x2ae/0x2ae
>> > [   49.561675]  [] kthread+0xd2/0xda
>> > [   49.561678]  [] ret_from_fork+0x22/0x40
>> > [   49.561679]  [] ?
>> > kthread_worker_fn+0x13e/0x13e
>> >
>> > -ss
>> > --
>> > To unsubscribe from this list: send the line "unsubscribe linux
>> > -scsi" in
>> > the body of a message to majord...@vger.kernel.org
>> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> >
>>
>> diff --git a/drivers/scsi/scsi_sysfs.c b/drivers/scsi/scsi_sysfs.c
>> index 0734927..0c00928 100644
>> --- a/drivers/scsi/scsi_sysfs.c
>> +++ b/drivers/scsi/scsi_sysfs.c
>> @@ -1276,6 +1276,7 @@ int scsi_sysfs_add_sdev(struct scsi_device
>> *sdev)
>>  void __scsi_remove_device(struct scsi_device *sdev)
>>  {
>>   struct device *dev = &sdev->sdev_gendev;
>> + struct scsi_target *starget;
>>
>>   /*
>>* This cleanup path is not reentrant and while it is
>> impossible
>> @@ -1315,7 +1316,9 @@ void __scsi_remove_device(struct scsi_device
>> *sdev)
>>* remoed sysfs visibility from the device, so make the
>> target
>>* invisible if this was the last device underneath it.
>>*/
>> - scsi_target_reap(scsi_target(sdev));
>> + starget = scsi_target(sdev);
>> + starget->state = STARGET_REMOVE;
>> + scsi_target_reap(starget);
>
> How about good grief no!  A device with multiple targets will get it's
> lists screwed with this
>
> The STARGET_REMOVE state you added only applies to the case we're
> trying to kill a target.  In the natural operation case, which is what
> everyone else is running into, we will try to remove a running target
> when it has no more scsi devices left on it.  So the correct patch
> should be to make the BUG_ON see this:
>
> James
>
> ---
>
> diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c
> index 27df7e7..e0a78f5 100644
> --- a/drivers/scsi/scsi_scan.c
> +++ b/drivers/scsi/scsi_scan.c
> @@ -319,8 +319,7 @@ static void scsi_target_destroy(struct scsi_target 
> *starget)
> struct Scsi_Host *shost = dev_to_shost(dev->parent);
> unsigned long flags;
>
> -   BUG_ON(starget->state != STARGET_REMOVE &&
> -  starget->state != STARGET_CREATED);
> +   BUG_ON(starget->state == STARGET_DEL);
> starget->state = STARGET_DEL;
> transport_destroy_device(dev);
> spin_lock_irqsave(shost->host_lock, flags);
>


This will survive modprobe -r scsi_debug ..

Just to make sure, is this _REMOVE state able to do the latter thing what it was
trying to do, in this way ?


commit 7b106f2de6938c31ce5e9c86bc70ad3904666b96
Author: Johannes Thumshirn 
Date:   Tue Apr 5 11:50:44 2016 +0200

scsi: Add intermediate STARGET_REMOVE state to scsi_target_state

Add intermediate STARGET_REMOVE state to scsi_target_state to avoid
running into the BUG_ON() in scsi_target_reap(). The STARGET_REMOVE
state is only valid in the path from scsi_remove_target() to
scsi_target_destroy() indicating this target is going to be removed.

This re-fixes the problem introduced in commits bc3f02a795d3 ("[SCSI]
scsi_remove_target: fix softlockup regression on hot remove") and
40998193560d ("scsi: restart list search after unlock in
scsi_remove_target") in a more comprehensive way.

Re: [-next] BUG_ON in scsi_target_destroy()

[Xiong Zhou]

Hi,

On Wed, Apr 13, 2016 at 4:41 PM, Johannes Thumshirn  wrote:
> Hi Sergey,  Xiong,
>
> Can you try below patch?

This survives modprobe -r scsi_debug.

>
> On Montag, 11. April 2016 18:01:47 CEST Sergey Senozhatsky wrote:
>> Hello,
>>
>> commit 7b106f2de6938c31ce5e9c86bc70ad3904666b96
>> Author: Johannes Thumshirn 
>> Date:   Tue Apr 5 11:50:44 2016 +0200
>>
>> scsi: Add intermediate STARGET_REMOVE state to scsi_target_state
>>
>>
>> BUG_ON()s (next-20160411) each time I remove a usb flash
>>
>> [   49.561600]  [] scsi_target_destroy+0x5a/0xcb [scsi_mod]
>> [   49.561607]  [] scsi_target_reap+0x4a/0x4f [scsi_mod]
>> [   49.561613]  [] __scsi_remove_device+0xc3/0xd0 
>> [scsi_mod]
>> [   49.561619]  [] scsi_forget_host+0x52/0x63 [scsi_mod]
>> [   49.561623]  [] scsi_remove_host+0x8c/0x102 [scsi_mod]
>> [   49.561627]  [] usb_stor_disconnect+0x6b/0xab 
>> [usb_storage]
>> [   49.561634]  [] usb_unbind_interface+0x77/0x1ca 
>> [usbcore]
>> [   49.561636]  [] __device_release_driver+0x9d/0x121
>> [   49.561638]  [] device_release_driver+0x23/0x30
>> [   49.561639]  [] bus_remove_device+0xfb/0x10e
>> [   49.561641]  [] device_del+0x164/0x1e6
>> [   49.561648]  [] ? remove_intf_ep_devs+0x3b/0x48 
>> [usbcore]
>> [   49.561655]  [] usb_disable_device+0x84/0x1a5 [usbcore]
>> [   49.561661]  [] usb_disconnect+0x94/0x19f [usbcore]
>> [   49.561667]  [] hub_event+0x5c1/0xdea [usbcore]
>> [   49.561670]  [] process_one_work+0x1dc/0x37f
>> [   49.561672]  [] worker_thread+0x282/0x36d
>> [   49.561673]  [] ? rescuer_thread+0x2ae/0x2ae
>> [   49.561675]  [] kthread+0xd2/0xda
>> [   49.561678]  [] ret_from_fork+0x22/0x40
>> [   49.561679]  [] ? kthread_worker_fn+0x13e/0x13e
>>
>>   -ss
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>
> diff --git a/drivers/scsi/scsi_sysfs.c b/drivers/scsi/scsi_sysfs.c
> index 0734927..0c00928 100644
> --- a/drivers/scsi/scsi_sysfs.c
> +++ b/drivers/scsi/scsi_sysfs.c
> @@ -1276,6 +1276,7 @@ int scsi_sysfs_add_sdev(struct scsi_device *sdev)
>  void __scsi_remove_device(struct scsi_device *sdev)
>  {
> struct device *dev = &sdev->sdev_gendev;
> +   struct scsi_target *starget;
>
> /*
>  * This cleanup path is not reentrant and while it is impossible
> @@ -1315,7 +1316,9 @@ void __scsi_remove_device(struct scsi_device *sdev)
>  * remoed sysfs visibility from the device, so make the target
>  * invisible if this was the last device underneath it.
>  */
> -   scsi_target_reap(scsi_target(sdev));
> +   starget = scsi_target(sdev);
> +   starget->state = STARGET_REMOVE;
> +   scsi_target_reap(starget);

Yes, scsi_target_reap is alse called from __scsi_remove_device,  and ->state is
_RUNNING here.


>
> put_device(dev);
>  }
>
>
>
> --
> Johannes Thumshirn
> Storage
> jthumsh...@suse.de
>  +49 911 74053 689
> SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
> GF: Felix Imendörffer, Jane Smithard, Graham Norton
> HRB 21284 (AG Nürnberg)
> Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
>

Re: [PATCH v4 1/2] scsi: Add intermediate STARGET_REMOVE state to scsi_target_state

[Xiong Zhou]

On Wed, Apr 13, 2016 at 4:19 PM, Johannes Thumshirn  wrote:
> Hi Xiong
> Sorry for the late reply
>
> On Dienstag, 12. April 2016 21:01:53 CEST Xiong Zhou wrote:
>> How about this?
>>
>> drivers/scsi/scsi_scan: mark STARGET_REMOVE state before destroy
>>
>> Signed-off-by: Xiong Zhou 
>> ---
>>  drivers/scsi/scsi_scan.c | 3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c
>> index 27df7e7..21092e5 100644
>> --- a/drivers/scsi/scsi_scan.c
>> +++ b/drivers/scsi/scsi_scan.c
>> @@ -395,6 +395,8 @@ static void scsi_target_reap_ref_release(struct kref 
>> *kref)
>>   transport_remove_device(&starget->dev);
>>   device_del(&starget->dev);
>>   }
>> +
>> + starget->state = STARGET_REMOVE;
>>   scsi_target_destroy(starget);
>>  }
>
> The only scsi_target_reap_ref_release() caller is scsi_target_reap_ref_put(),
> which in turn is only called by scsi_target_reap(). scsi_target_reap()'s only
> callers are scsi_remove_target()/__scsi_remove_target(), which set the
> STARGET_REMOVE state and
>
> __scsi_add_device()
> scsi_get_host_dev()
> __scsi_scan_target()
>
> Which I'm currently investiganting (in parallel to reproducing the bug).

Thanks !

--
Xiong

>
>>
>> @@ -465,6 +467,7 @@ static struct scsi_target
>> *scsi_alloc_target(struct device *parent,
>>   dev_printk(KERN_ERR, dev, "target allocation failed, error %d\n", error);
>>   /* don't want scsi_target_reap to do the final
>>   * put because it will be under the host lock */
>> + starget->state = STARGET_REMOVE;
>>   scsi_target_destroy(starget);
>>   return NULL;
>>   }
>
> Here starget->state is STARGET_CREATED and the assertion is already aware of
> this state transitoin. IOTW this /shouldn't/ be needed.
>
>
> --
> Johannes Thumshirn
> Storage
> jthumsh...@suse.de
>  +49 911 74053 689
> SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
> GF: Felix Imendörffer, Jane Smithard, Graham Norton
> HRB 21284 (AG Nürnberg)
> Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
>

Re: [PATCH v4 1/2] scsi: Add intermediate STARGET_REMOVE state to scsi_target_state

[Xiong Zhou]

How about this?

drivers/scsi/scsi_scan: mark STARGET_REMOVE state before destroy

Signed-off-by: Xiong Zhou 
---
 drivers/scsi/scsi_scan.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c
index 27df7e7..21092e5 100644
--- a/drivers/scsi/scsi_scan.c
+++ b/drivers/scsi/scsi_scan.c
@@ -395,6 +395,8 @@ static void scsi_target_reap_ref_release(struct kref *kref)
  transport_remove_device(&starget->dev);
  device_del(&starget->dev);
  }
+
+ starget->state = STARGET_REMOVE;
  scsi_target_destroy(starget);
 }

@@ -465,6 +467,7 @@ static struct scsi_target
*scsi_alloc_target(struct device *parent,
  dev_printk(KERN_ERR, dev, "target allocation failed, error %d\n", error);
  /* don't want scsi_target_reap to do the final
  * put because it will be under the host lock */
+ starget->state = STARGET_REMOVE;
  scsi_target_destroy(starget);
  return NULL;
  }
-- 
1.8.3.1

On Tue, Apr 5, 2016 at 5:50 PM, Johannes Thumshirn  wrote:
> Add intermediate STARGET_REMOVE state to scsi_target_state to avoid
> running into the BUG_ON() in scsi_target_reap(). The STARGET_REMOVE
> state is only valid in the path from scsi_remove_target() to
> scsi_target_destroy() indicating this target is going to be removed.
>
> This re-fixes the problem introduced in commits
> bc3f02a795d3b4faa99d37390174be2a75d091bd  and
> 40998193560dab6c3ce8d25f4fa58a23e252ef38 in a more comprehensive way.
>
> Signed-off-by: Johannes Thumshirn 
> Fixes: 40998193560dab6c3ce8d25f4fa58a23e252ef38
> Cc: sta...@vger.kernel.org
> Reviewed-by: Ewan D. Milne 
> Reviewed-by: Hannes Reinecke 
> Reviewed-by: James Bottomley 
> ---
>  drivers/scsi/scsi_scan.c   | 2 ++
>  drivers/scsi/scsi_sysfs.c  | 2 ++
>  include/scsi/scsi_device.h | 1 +
>  3 files changed, 5 insertions(+)
>
> diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c
> index 6a82066..63b8bca 100644
> --- a/drivers/scsi/scsi_scan.c
> +++ b/drivers/scsi/scsi_scan.c
> @@ -315,6 +315,8 @@ static void scsi_target_destroy(struct scsi_target 
> *starget)
> struct Scsi_Host *shost = dev_to_shost(dev->parent);
> unsigned long flags;
>
> +   BUG_ON(starget->state != STARGET_REMOVE &&
> +  starget->state != STARGET_CREATED);
> starget->state = STARGET_DEL;
> transport_destroy_device(dev);
> spin_lock_irqsave(shost->host_lock, flags);
> diff --git a/drivers/scsi/scsi_sysfs.c b/drivers/scsi/scsi_sysfs.c
> index 00bc721..0df82e8 100644
> --- a/drivers/scsi/scsi_sysfs.c
> +++ b/drivers/scsi/scsi_sysfs.c
> @@ -1279,11 +1279,13 @@ restart:
> spin_lock_irqsave(shost->host_lock, flags);
> list_for_each_entry(starget, &shost->__targets, siblings) {
> if (starget->state == STARGET_DEL ||
> +   starget->state == STARGET_REMOVE ||
> starget == last_target)
> continue;
> if (starget->dev.parent == dev || &starget->dev == dev) {
> kref_get(&starget->reap_ref);
> last_target = starget;
> +   starget->state = STARGET_REMOVE;
> spin_unlock_irqrestore(shost->host_lock, flags);
> __scsi_remove_target(starget);
> scsi_target_reap(starget);
> diff --git a/include/scsi/scsi_device.h b/include/scsi/scsi_device.h
> index f63a167..2bffaa6 100644
> --- a/include/scsi/scsi_device.h
> +++ b/include/scsi/scsi_device.h
> @@ -240,6 +240,7 @@ scmd_printk(const char *, const struct scsi_cmnd *, const 
> char *, ...);
>  enum scsi_target_state {
> STARGET_CREATED = 1,
> STARGET_RUNNING,
> +   STARGET_REMOVE,
> STARGET_DEL,
>  };
>
> --
> 1.8.5.6
>

Re: [PATCH v4 1/2] scsi: Add intermediate STARGET_REMOVE state to scsi_target_state

[Xiong Zhou]

Hi,

On Tue, Apr 5, 2016 at 5:50 PM, Johannes Thumshirn  wrote:
> Add intermediate STARGET_REMOVE state to scsi_target_state to avoid
> running into the BUG_ON() in scsi_target_reap(). The STARGET_REMOVE
> state is only valid in the path from scsi_remove_target() to
> scsi_target_destroy() indicating this target is going to be removed.
>
> This re-fixes the problem introduced in commits
> bc3f02a795d3b4faa99d37390174be2a75d091bd  and
> 40998193560dab6c3ce8d25f4fa58a23e252ef38 in a more comprehensive way.
>
> Signed-off-by: Johannes Thumshirn 
> Fixes: 40998193560dab6c3ce8d25f4fa58a23e252ef38
> Cc: sta...@vger.kernel.org
> Reviewed-by: Ewan D. Milne 
> Reviewed-by: Hannes Reinecke 
> Reviewed-by: James Bottomley 
> ---
>  drivers/scsi/scsi_scan.c   | 2 ++
>  drivers/scsi/scsi_sysfs.c  | 2 ++
>  include/scsi/scsi_device.h | 1 +
>  3 files changed, 5 insertions(+)
>
> diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c
> index 6a82066..63b8bca 100644
> --- a/drivers/scsi/scsi_scan.c
> +++ b/drivers/scsi/scsi_scan.c
> @@ -315,6 +315,8 @@ static void scsi_target_destroy(struct scsi_target 
> *starget)
> struct Scsi_Host *shost = dev_to_shost(dev->parent);
> unsigned long flags;
>
> +   BUG_ON(starget->state != STARGET_REMOVE &&
> +  starget->state != STARGET_CREATED);


#modprobe scsi_debug
#modprobe -r scsi_debug

always triggers this BUG_ON in linux-next-20160411

printk says starget->state is _RUNNING

> starget->state = STARGET_DEL;
> transport_destroy_device(dev);
> spin_lock_irqsave(shost->host_lock, flags);
> diff --git a/drivers/scsi/scsi_sysfs.c b/drivers/scsi/scsi_sysfs.c
> index 00bc721..0df82e8 100644
> --- a/drivers/scsi/scsi_sysfs.c
> +++ b/drivers/scsi/scsi_sysfs.c
> @@ -1279,11 +1279,13 @@ restart:
> spin_lock_irqsave(shost->host_lock, flags);
> list_for_each_entry(starget, &shost->__targets, siblings) {
> if (starget->state == STARGET_DEL ||
> +   starget->state == STARGET_REMOVE ||
> starget == last_target)
> continue;
> if (starget->dev.parent == dev || &starget->dev == dev) {
> kref_get(&starget->reap_ref);
> last_target = starget;
> +   starget->state = STARGET_REMOVE;
> spin_unlock_irqrestore(shost->host_lock, flags);
> __scsi_remove_target(starget);
> scsi_target_reap(starget);
> diff --git a/include/scsi/scsi_device.h b/include/scsi/scsi_device.h
> index f63a167..2bffaa6 100644
> --- a/include/scsi/scsi_device.h
> +++ b/include/scsi/scsi_device.h
> @@ -240,6 +240,7 @@ scmd_printk(const char *, const struct scsi_cmnd *, const 
> char *, ...);
>  enum scsi_target_state {
> STARGET_CREATED = 1,
> STARGET_RUNNING,
> +   STARGET_REMOVE,
> STARGET_DEL,
>  };
>
> --
> 1.8.5.6
>

Re: 4.5.0+ panic when setup loop device

[Xiong Zhou]

Hi,

On Thu, Mar 17, 2016 at 7:39 PM, Thomas Gleixner  wrote:
> B1;2802;0cOn Thu, 17 Mar 2016, Peter Zijlstra wrote:
>
>> On Thu, Mar 17, 2016 at 11:21:24AM +0100, Thomas Gleixner wrote:
>> > On Thu, 17 Mar 2016, Peter Zijlstra wrote:
>> >
>> > > Could you please try? I'm not sure how this would explain your loop
>> > > device bug fail, but it certainly pointed towards broken.
>> >
>> > It definitely does not explain it. The wreckage that topo stuff causes is 
>> > that
>> > it disables a cpu, but that really is not a reason for block/loop to 
>> > explode.
>>
>> Right. Sadly I could not reproduce that error on my machine. But we can
>> at least start by fixing the 'obvious' problems and then maybe we get
>> more clues ;-)
>
> I'm able to reproduce by rejecting a cpu in that topology map function
> forcefully.
>
> That stuff explodes, because the block-mq code assumes that cpu_possible_mask
> has no holes.
>
> #define queue_for_each_ctx(q, ctx, i)   \
> for ((i) = 0; (i) < (q)->nr_queues &&   \
>  ({ ctx = per_cpu_ptr((q)->queue_ctx, (i)); 1; }); (i)++)
>
> is what makes that assumption about a consecutive possible mask.
>
> The cure for now is the patch below on top of PeterZ's patch.

No panic with both Peter's patch and yours.

Thanks all.

--
Xiong

>
> But we have to clarify and document whether holes in cpu_possible_mask are not
> allowed at all or if code like the above is simply broken.
>
> Thanks,
>
> tglx
> ---
> diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
> index 643dbdccf4bc..f2ed8a01f870 100644
> --- a/arch/x86/kernel/smpboot.c
> +++ b/arch/x86/kernel/smpboot.c
> @@ -345,7 +345,6 @@ static void __init smp_init_package_map(void)
> continue;
> pr_warn("CPU %u APICId %x disabled\n", cpu, apicid);
> per_cpu(x86_bios_cpu_apicid, cpu) = BAD_APICID;
> -   set_cpu_possible(cpu, false);
> set_cpu_present(cpu, false);
> }
>  }
>
>
>
>
>
>
>
>

[PATCH trivial] scripts/prune-kernel: remove kdump images

[Xiong Zhou]

Signed-off-by: Xiong Zhou 
---
 scripts/prune-kernel | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/prune-kernel b/scripts/prune-kernel
index ab5034e..9c67be2 100755
--- a/scripts/prune-kernel
+++ b/scripts/prune-kernel
@@ -14,7 +14,7 @@ do
 echo "removing $f"
 rm -f "/boot/initramfs-$f.img" "/boot/System.map-$f"
 rm -f "/boot/vmlinuz-$f"   "/boot/config-$f"
-rm -rf "/lib/modules/$f"
+rm -rf "/lib/modules/$f" "/boot/initramfs-${f}kdump.img"
 new-kernel-pkg --remove $f
 fi
 done
-- 
2.5.0

ext2/3 using ext4 module mkdir IO error on pmem DAX mount

[Xiong Zhou]

Hi,

mkdir failed IO error on pmem DAX ext2/3 fs mount using ext4 module.

This happends only on -next tree, not on Linus' tree,
at least from 4.5.0-rc5-next-20160224.

.config attached.

sh-4.2# uname -r
4.5.0-rc6-next-20160301
sh-4.2# sh -x extmod.sh
+ testmkdir ext2 /dev/pmem0 /daxmnt ext4
+ mkdir -p /daxmnt
+ mkfs.ext2 -Fq /dev/pmem0
+ lsmod
+ grep ext
ext2   73728  0 
ext4  585728  0 
jbd2  110592  1 ext4
mbcache16384  2 ext2,ext4
+ mount -t ext4 -o dax /dev/pmem0 /daxmnt
+ mount
+ grep dax
/dev/pmem0 on /daxmnt type ext4
(rw,relatime,seclabel,block_validity,delalloc,barrier,dax,user_xattr,acl)
+ lsmod
+ grep ext
ext2   73728  0 
ext4  585728  1 
jbd2  110592  1 ext4
mbcache16384  3 ext2,ext4
+ cd /daxmnt
+ mkdir -p 1/2/3/4
mkdir: cannot create directory ‘1’: Input/output error
+ touch 5
+ cd
+ umount /daxmnt
+ testmkdir ext3 /dev/pmem0 /daxmnt ext4
+ mkdir -p /daxmnt
+ mkfs.ext3 -Fq /dev/pmem0
+ lsmod
+ grep ext
ext2   73728  0 
ext4  585728  0 
jbd2  110592  1 ext4
mbcache16384  2 ext2,ext4
+ mount -t ext4 -o dax /dev/pmem0 /daxmnt
+ mount
+ grep dax
/dev/pmem0 on /daxmnt type ext4 (rw,relatime,seclabel,dax,data=ordered)
+ lsmod
+ grep ext
ext2   73728  0 
ext4  585728  1 
jbd2  110592  1 ext4
mbcache16384  3 ext2,ext4
+ cd /daxmnt
+ mkdir -p 1/2/3/4
mkdir: cannot create directory ‘1’: Input/output error
+ touch 5
+ cd
+ umount /daxmnt
sh-4.2# cat extmod.sh
#!/bin/bash

# param 1/2/3 mkfs.fstype/pmemdev/mountpoint/mountfstype
function testmkdir()
{
#modprobe -r $1
mkdir -p $3
mkfs.$1 -Fq $2
lsmod | grep ext
mount -t $4 -o dax $2 $3
mount | grep dax
lsmod | grep ext
cd $3
mkdir -p 1/2/3/4
touch 5
cd
umount $3
}

testmkdir ext2 /dev/pmem0 /daxmnt ext4
testmkdir ext3 /dev/pmem0 /daxmnt ext4
#testmkdir ext2 /dev/pmem0 /daxmnt ext2 # pass
#testmkdir ext4 /dev/pmem0 /daxmnt ext4 # pass
sh-4.2# 

--
Xiong
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86 4.5.0-rc6 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_PERF_EVENTS_INTEL_UNCORE=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MIN=28
CONFIG_ARCH_MMAP_RND_BITS_MAX=32
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ZONE_DMA32=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_HAVE_INTEL_TXT=y
CONFIG_X86_64_SMP=y
CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx 
-fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10 
-fcall-saved-r11"
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_DEBUG_RODATA=y
CONFIG_PGTABLE_LEVELS=4
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y

#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_POSIX_MQUEUE_SYSCTL=y
CONFIG_CROSS_MEMORY_ATTACH=y
CONFIG_FHANDLE=y
CONFIG_USELIB=y
CONFIG_AUDIT=y
CONFIG_HAVE_ARCH_AUDITSYSCALL=y
CONFIG_AUDITSYSCALL=y
CONFIG_AUDIT_WATCH=y
CONFIG_AUDIT_TREE=y

#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_IRQ_DOMAIN=y
CONFIG_IRQ_DOMAIN_HIERARCHY=y
CONFIG_GENERIC_MSI_IRQ=y
CONFIG_GENERIC_MSI_IRQ_DOMAIN=y
# CONFIG_IRQ_DOMAIN_DEBUG is not set
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_ARCH_CLOCKSOURCE_DATA=y
CONFIG_CLOCKSOURCE_VALID

[PATCH] staging: android: logger: fix kuid/uid in logger_entry

[Xiong Zhou]

From: Xiong Zhou 

struct logger_entry can be returned to userspace via ioctl,
so it is wrong to have a kuid_t member, fixing it to uid_t.
This was introduced by commit bd471258f2, to pass uidguid
type checks : UIDGID_STRICT_TYPE_CHECKS, which has been
removed from kernel in commit 261000a56b6.

Fixes: bd471258f2 (logger: use kuid_t instead of uid_t)
Signed-off-by: Xiong Zhou 
---
 drivers/staging/android/logger.c | 4 ++--
 drivers/staging/android/logger.h | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/android/logger.c b/drivers/staging/android/logger.c
index 28b93d3..fb06bf2 100644
--- a/drivers/staging/android/logger.c
+++ b/drivers/staging/android/logger.c
@@ -252,7 +252,7 @@ static size_t get_next_entry_by_uid(struct logger_log *log,

entry = get_entry_header(log, off, &scratch);

-   if (uid_eq(entry->euid, euid))
+   if (entry->euid == __kuid_val(euid))
return off;

next_len = sizeof(struct logger_entry) + entry->len;
@@ -430,7 +430,7 @@ static ssize_t logger_write_iter(struct kiocb *iocb, struct 
iov_iter *from)
header.tid = current->pid;
header.sec = now.tv_sec;
header.nsec = now.tv_nsec;
-   header.euid = current_euid();
+   header.euid = __kuid_val(current_euid());
header.len = count;
header.hdr_size = sizeof(struct logger_entry);

diff --git a/drivers/staging/android/logger.h b/drivers/staging/android/logger.h
index 70af7d8..cc6bbd9 100644
--- a/drivers/staging/android/logger.h
+++ b/drivers/staging/android/logger.h
@@ -66,7 +66,7 @@ struct logger_entry {
__s32   tid;
__s32   sec;
__s32   nsec;
-   kuid_t  euid;
+   uid_t   euid;
charmsg[0];
 };

--
1.9.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [vfs] WARNING: CPU: 3 PID: 2339 at mm/truncate.c:758 pagecache_isize_extended+0xdd/0x120()

[Xiong Zhou]

still in rc2
[ cut here ]
WARNING: CPU: 0 PID: 18152 at mm/truncate.c:758
pagecache_isize_extended+0xfd/0x110()
Modules linked in: btrfs xor zlib_deflate raid6_pq ntfs fuse
x86_pkg_temp_thermal wmi radeon e1000e ttm
CPU: 0 PID: 18152 Comm: Cache I/O Tainted: GW  3.18.0-rc2 #1
Hardware name: Hewlett-Packard HP Compaq Elite 8300 MT/3397, BIOS K01
v02.05 05/07/2012
 0009 8800d1b3bd38 81863216 
  8800d1b3bd78 8105046c ea0002e0b600
 1000 8800bb9a49a8  00031ada
Call Trace:
 [] dump_stack+0x46/0x58
 [] warn_slowpath_common+0x7c/0xa0
 [] warn_slowpath_null+0x15/0x20
 [] pagecache_isize_extended+0xfd/0x110
 [] ? __xfs_get_blocks+0x4d0/0x4d0
 [] truncate_setsize+0x22/0x40
 [] xfs_setattr_size+0x10b/0x3c0
 [] ? xfs_trans_commit+0x13e/0x220
 [] xfs_file_fallocate+0x2e7/0x300
 [] ? __sb_start_write+0x44/0xd0
 [] do_fallocate+0x12a/0x1d0
 [] SyS_fallocate+0x43/0x70
 [] system_call_fastpath+0x12/0x17
---[ end trace abf71ba1f4096942 ]---

2014-10-28 5:05 GMT+08:00 Dave Chinner :
> On Mon, Oct 27, 2014 at 10:58:12AM +0100, Jan Kara wrote:
>> On Mon 27-10-14 12:04:22, Dave Chinner wrote:
>> > On Thu, Oct 16, 2014 at 01:01:27PM +0200, Jan Kara wrote:
>> > > From de3426d6495f4b44b14c09b7c7202e9a86d864b9 Mon Sep 17 00:00:00 2001
>> > > From: Jan Kara 
>> > > Date: Thu, 16 Oct 2014 12:58:42 +0200
>> > > Subject: [PATCH] mm: Remove false WARN_ON from pagecache_isize_extended()
>> > >
>> > > The WARN_ON checking whether i_mutex is held in
>> > > pagecache_isize_extended() was wrong because some filesystems (e.g.
>> > > XFS) use different locks for serialization of truncates / writes. So
>> > > just remove the check.
>> > >
>> > > Signed-off-by: Jan Kara 
>> > > ---
>> > >  mm/truncate.c | 1 -
>> > >  1 file changed, 1 deletion(-)
>> > >
>> > > diff --git a/mm/truncate.c b/mm/truncate.c
>> > > index 261eaf6e5a19..c646084e5eec 100644
>> > > --- a/mm/truncate.c
>> > > +++ b/mm/truncate.c
>> > > @@ -755,7 +755,6 @@ void pagecache_isize_extended(struct inode *inode, 
>> > > loff_t from, loff_t to)
>> > >   struct page *page;
>> > >   pgoff_t index;
>> > >
>> > > - WARN_ON(!mutex_is_locked(&inode->i_mutex));
>> > >   WARN_ON(to > inode->i_size);
>> > >
>> > >   if (from >= to || bsize == PAGE_CACHE_SIZE)
>> >
>> > Jan, Have you sent this patch upstream yet? I'm seeing it fire in
>> > my testing in 3.18-rc1 kernels, so I was wondering what your plans
>> > are for this...
>>   I did send it but it got lost somewhere. I'll resend it.
>
> If it comes to it, I can push it through the XFS tree - I've got a
> few patches I need to send for -rc3...
>
> Cheers,
>
> Dave.
> --
> Dave Chinner
> da...@fromorbit.com
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2] nfs: remove redundant slash from nfs_path

[Xiong Zhou]

When export root dir(/) via nfs, and mount a particular dir under root, eg
/nfsexport, there will be defect double slash output in /proc/mounts, like
localhost://nfsexport. While this patch change it to localhost:/nfsexport.

Signed-off-by: Xiong Zhou 
---
 fs/nfs/namespace.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/nfs/namespace.c b/fs/nfs/namespace.c
index b5a0afc..24f954e 100644
--- a/fs/nfs/namespace.c
+++ b/fs/nfs/namespace.c
@@ -98,7 +98,7 @@ rename_retry:
return end;
}
namelen = strlen(base);
-   if (flags & NFS_PATH_CANONICAL) {
+   if ((flags & NFS_PATH_CANONICAL) || *end == '/') {
/* Strip off excess slashes in base string */
while (namelen > 0 && base[namelen - 1] == '/')
namelen--;
-- 
1.8.3.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] nfs: use canonical path in nfs_show_devname

[Xiong Zhou]

When export root dir(/) via nfs, and mount a particular dir under root, eg
/nfsexport, there will be defect double slash output in /proc/mounts, like
localhost://nfsexport.

Signed-off-by: Xiong Zhou 
---
 fs/nfs/super.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/nfs/super.c b/fs/nfs/super.c
index e4499d5..62b1cab 100644
--- a/fs/nfs/super.c
+++ b/fs/nfs/super.c
@@ -780,7 +780,7 @@ int nfs_show_devname(struct seq_file *m, struct dentry 
*root)
int err = 0;
if (!page)
return -ENOMEM;
-   devname = nfs_path(&dummy, root, page, PAGE_SIZE, 0);
+   devname = nfs_path(&dummy, root, page, PAGE_SIZE, 1);
if (IS_ERR(devname))
err = PTR_ERR(devname);
else
-- 
1.8.3.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [xen] double fault: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC

[Xiong Zhou]

How is this going?


regards,


2013/10/11 Fengguang Wu :
>> I think something like the below may address the issue - I've only build
>> tested this so far.
>>
>> We have another case where DRM does the wrong thing here too - a similar
>> thing goes on with connectors as well.  I've not yet looked into this,
>> but I'll take a look later today.
>>
>> Fengguang - could you give this some runs through your marvellous test
>> system and see whether it fixes the problem you're seeing please?
>
> Russell, I applied the patch (as commit 17e57131d4c2) on top of
> v3.12-rc4 and here are the test results for the kernels with
>
> CONFIG_DRM=y
> CONFIG_DEBUG_KOBJECT_RELEASE=y
>
> As you may see, it's pure improvements. :)
>
> Tested-by: Fengguang Wu 
>
>
> i386-randconfig-c3-1009
>
> +---+---+--+
> |   | v3.12-rc4 | 
> 17e57131d4c2 |
> +---+---+--+
> | has_kernel_error_warning  | 63| 
>  |
> | BUG:kernel_early_hang_without_any_printk_output   | 7 | 
>  |
> | WARNING:CPU:PID:at_fs/sysfs/dir.c:sysfs_add_one() | 56| 
>  |
> | WARNING:CPU:PID:at_lib/kobject.c:kobject_add_internal()   | 56| 
>  |
> | WARNING:CPU:PID:at_drivers/base/driver.c:driver_unregister()  | 56| 
>  |
> | WARNING:CPU:PID:at_lib/debugobjects.c:debug_print_object()| 56| 
>  |
> | INFO:trying_to_register_non-static_key| 56| 
>  |
> | BUG:unable_to_handle_kernel_NULL_pointer_dereference_at(null) | 56| 
>  |
> | Oops:PREEMPT_SMP  | 56| 
>  |
> | Kernel_panic-not_syncing:Fatal_exception_in_interrupt | 56| 
>  |
> | BUG:kernel_boot_oops  | 56| 
>  |
> | good_boots| 0 | 
> 9|
> +---+---+--+
>
> x86_64-randconfig-j5-1009
>
> ++---+--+
> || v3.12-rc4 | 17e57131d4c2 |
> ++---+--+
> | good_boots | 30| 9|
> ++---+--+
>
> x86_64-randconfig-j3-1009
>
> +---+---+--+
> |   | v3.12-rc4 | 
> 17e57131d4c2 |
> +---+---+--+
> | has_kernel_error_warning  | 60| 
>  |
> | WARNING:CPU:PID:at_fs/sysfs/dir.c:sysfs_add_one() | 60| 
>  |
> | WARNING:CPU:PID:at_lib/kobject.c:kobject_add_internal()   | 60| 
>  |
> | WARNING:CPU:PID:at_drivers/base/driver.c:driver_unregister()  | 60| 
>  |
> | WARNING:CPU:PID:at_lib/debugobjects.c:debug_print_object()| 60| 
>  |
> | WARNING:CPU:PID:at_arch/x86/kernel/irq_64.c:handle_irq()  | 3 | 
>  |
> | BUG:unable_to_handle_kernel_NULL_pointer_dereference_at   | 59| 
>  |
> | Oops:DEBUG_PAGEALLOC  | 28| 
>  |
> | WARNING:CPU:PID:at_lib/list_debug.c:__list_del_entry()| 28| 
>  |
> | BUG:scheduling_while_atomic   | 30| 
>  |
> | INFO:lockdep_is_turned_off| 30| 
>  |
> | BUG:unable_to_handle_kernel_paging_request_at | 55| 
>  |
> | kernel_BUG_at_kernel/smpboot.c| 13| 
>  |
> | invalid_opcode:DEBUG_PAGEALLOC| 13| 
>  |
> | general_protection_fault:DEBUG_PAGEALLOC  | 2 | 
>  |
> | Kernel_panic-not_syncing:Fatal_exception_in_interrupt | 4 | 
>  |
> | BUG:kernel_boot_oops  | 60| 
>  |
> | WARNING:CPU:PID:at_kernel/workqueue.c:work_fixup_activate()   | 24| 
>  |
> | WARNING:CPU:PID:at_kernel/workqueue.c:__queue_work()  | 10| 
>  |
> | BUG:unable_to_handle_kernel_NULL_pointer_dereference_at(null) | 2 | 
>  |
> | BUG:unable_to_handle_kernel   | 1 | 
>  |
> | BUG:unab

[PATCH] amilo-rfkill: add Kconfig depends on i8042

[Xiong Zhou]

From: Xiong Zhou 

Fix randconfig build failure for Amilo x86 platform driver.
AMILO_RFKILL requires SERIO_I8042 being available.

amilo-rfkill.c:(.text+0x108b5b): undefined reference to `i8042_lock_chip'
amilo-rfkill.c:(.text+0x108b69): undefined reference to `i8042_command'
amilo-rfkill.c:(.text+0x108b71): undefined reference to `i8042_unlock_chip'

Reported-by: Jim Davis 
Signed-off-by: Xiong Zhou 
Acked-by: Ben Hutchings 
---
 drivers/platform/x86/Kconfig |1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index 8577261..37645b9 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -176,6 +176,7 @@ config FUJITSU_TABLET
 config AMILO_RFKILL
tristate "Fujitsu-Siemens Amilo rfkill support"
depends on RFKILL
+   depends on SERIO_I8042
---help---
  This is a driver for enabling wifi on some Fujitsu-Siemens Amilo
  laptops.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] staging/lustre: lloop depends on BLOCK

[Xiong Zhou]

From: Xiong Zhou 

Add a config option for llite/lloop in lustre driver, making it depends
on BLOCK to fix this better:
drivers/staging/lustre/lustre/fid/../include/linux/lustre_compat25.h:117:2:
error: implicit declaration of function ‘unregister_blkdev'

Also, remove the wrapper ll_unregister_blkdev which depends on BLOCK in
the header and just call unregister_blkdev in lloop.c based on Peng Tao's
comment. Drop the redundant dependency on STAGING for LUSTRE_FS, remove
some unnecessary jdb header files which depends on BLOCK btw.

Signed-off-by: Xiong Zhou 
Reviewed-by: Peng Tao 
---
 drivers/staging/lustre/lustre/Kconfig  |7 ++-
 drivers/staging/lustre/lustre/fld/fld_cache.c  |1 -
 drivers/staging/lustre/lustre/fld/fld_request.c|1 -
 .../lustre/lustre/include/linux/lustre_compat25.h  |7 ---
 drivers/staging/lustre/lustre/llite/Makefile   |2 +-
 drivers/staging/lustre/lustre/llite/lloop.c|6 ++
 drivers/staging/lustre/lustre/lvfs/fsfilt.c|1 -
 7 files changed, 9 insertions(+), 16 deletions(-)

diff --git a/drivers/staging/lustre/lustre/Kconfig 
b/drivers/staging/lustre/lustre/Kconfig
index 0b45de0..4e898e4 100644
--- a/drivers/staging/lustre/lustre/Kconfig
+++ b/drivers/staging/lustre/lustre/Kconfig
@@ -1,6 +1,6 @@
 config LUSTRE_FS
tristate "Lustre file system client support"
-   depends on STAGING && INET && BLOCK && m
+   depends on INET && m
select LNET
select CRYPTO
select CRYPTO_CRC32
@@ -53,3 +53,8 @@ config LUSTRE_TRANSLATE_ERRNOS
bool
depends on LUSTRE_FS && !X86
default true
+
+config LUSTRE_LLITE_LLOOP
+   bool "Lustre virtual block device"
+   depends on LUSTRE_FS && BLOCK
+   default m
diff --git a/drivers/staging/lustre/lustre/fld/fld_cache.c 
b/drivers/staging/lustre/lustre/fld/fld_cache.c
index 347f2ae..8410107 100644
--- a/drivers/staging/lustre/lustre/fld/fld_cache.c
+++ b/drivers/staging/lustre/lustre/fld/fld_cache.c
@@ -45,7 +45,6 @@
 
 # include 
 # include 
-# include 
 # include 
 
 #include 
diff --git a/drivers/staging/lustre/lustre/fld/fld_request.c 
b/drivers/staging/lustre/lustre/fld/fld_request.c
index c99b945..049322a 100644
--- a/drivers/staging/lustre/lustre/fld/fld_request.c
+++ b/drivers/staging/lustre/lustre/fld/fld_request.c
@@ -44,7 +44,6 @@
 
 # include 
 # include 
-# include 
 # include 
 
 #include 
diff --git a/drivers/staging/lustre/lustre/include/linux/lustre_compat25.h 
b/drivers/staging/lustre/lustre/include/linux/lustre_compat25.h
index 426533b..018e604 100644
--- a/drivers/staging/lustre/lustre/include/linux/lustre_compat25.h
+++ b/drivers/staging/lustre/lustre/include/linux/lustre_compat25.h
@@ -111,13 +111,6 @@ static inline void ll_set_fs_pwd(struct fs_struct *fs, 
struct vfsmount *mnt,
 #define TREE_READ_LOCK_IRQ(mapping)spin_lock_irq(&(mapping)->tree_lock)
 #define TREE_READ_UNLOCK_IRQ(mapping)  spin_unlock_irq(&(mapping)->tree_lock)
 
-static inline
-int ll_unregister_blkdev(unsigned int dev, const char *name)
-{
-   unregister_blkdev(dev, name);
-   return 0;
-}
-
 #define ll_invalidate_bdev(a,b) invalidate_bdev((a))
 
 #ifndef FS_HAS_FIEMAP
diff --git a/drivers/staging/lustre/lustre/llite/Makefile 
b/drivers/staging/lustre/lustre/llite/Makefile
index dff0c04..f493e07 100644
--- a/drivers/staging/lustre/lustre/llite/Makefile
+++ b/drivers/staging/lustre/lustre/llite/Makefile
@@ -1,5 +1,5 @@
 obj-$(CONFIG_LUSTRE_FS) += lustre.o
-obj-$(CONFIG_LUSTRE_FS) += llite_lloop.o
+obj-$(CONFIG_LUSTRE_LLITE_LLOOP) += llite_lloop.o
 lustre-y := dcache.o dir.o file.o llite_close.o llite_lib.o llite_nfs.o \
rw.o lproc_llite.o namei.o symlink.o llite_mmap.o \
xattr.o remote_perm.o llite_rmtacl.o llite_capa.o \
diff --git a/drivers/staging/lustre/lustre/llite/lloop.c 
b/drivers/staging/lustre/lustre/llite/lloop.c
index e063efc..ae3dc9d 100644
--- a/drivers/staging/lustre/lustre/llite/lloop.c
+++ b/drivers/staging/lustre/lustre/llite/lloop.c
@@ -848,10 +848,8 @@ static void lloop_exit(void)
blk_cleanup_queue(loop_dev[i].lo_queue);
put_disk(disks[i]);
}
-   if (ll_unregister_blkdev(lloop_major, "lloop"))
-   CWARN("lloop: cannot unregister blkdev\n");
-   else
-   CDEBUG(D_CONFIG, "unregistered lloop major %d\n", lloop_major);
+
+   unregister_blkdev(lloop_major, "lloop");
 
OBD_FREE(disks, max_loop * sizeof(*disks));
OBD_FREE(loop_dev, max_loop * sizeof(*loop_dev));
diff --git a/drivers/staging/lustre/lustre/lvfs/fsfilt.c 
b/drivers/staging/lustre/lustre/lvfs/fsfilt.c
index 064445c..ce71f80 100644
--- a/drivers/staging/lustre/lustre/lvfs/fsfilt.c
+++ b/drivers/staging/lustre/lustre/lvfs/fsfilt.c
@@ -35,7 +35,6 @@
 #define DEBUG_SUBSYSTEM S_FILTER
 
 #include 
-#include 
 #include 
 #include 
 #include 

Re: [PATCH v2] staging/lustre: lloop depends on BLOCK

[Xiong Zhou]

On Wed, 31 Jul 2013, Greg Kroah-Hartman wrote:

> On Wed, Jul 31, 2013 at 10:30:41AM +0800, Xiong Zhou wrote:
> > From: Xiong Zhou 
> > 
> > First version of this patch makes LUSTRE_FS depends on BLOCK.  Second
> > version makes only lloop depends on BLOCK with a config option for this
> > dependence, and remove unnecessary jdb header files which depends on
> > BLOCK.
> > 
> > This version removes the wrapper ll_unregister_blkdev which depends on
> > BLOCK in header and just call unregister_blkdev in lloop.c based on Peng
> > Tao's comment.
> 
> This isn't all needed in the patch changelog info, just say what it
> does.
> 
> Also, it doesn't apply for some reason, care to refresh this against my
> latest tree and resend?
> 
> thanks,
> 
> greg k-h
> 

OK, this patch is based on the staging-next branch of your staging tree.


From: Xiong Zhou 

Add a config option for llite/lloop in lustre driver, making it 
depends on BLOCK to fix this better:
drivers/staging/lustre/lustre/fid/../include/linux/lustre_compat25.h:117:2: 
error: implicit declaration of function ‘unregister_blkdev’ 

Also, remove the wrapper ll_unregister_blkdev which depends on BLOCK in
the header and just call unregister_blkdev in lloop.c based on Peng Tao's
comment. Drop the redundant dependency on STAGING for LUSTRE_FS, remove 
some unnecessary jdb header files which depends on BLOCK btw.

Signed-off-by: Xiong Zhou 
Reviewed-by: Peng Tao 
---
 drivers/staging/lustre/lustre/Kconfig  |7 ++-
 drivers/staging/lustre/lustre/fld/fld_cache.c  |1 -
 drivers/staging/lustre/lustre/fld/fld_request.c|1 -
 .../lustre/lustre/include/linux/lustre_compat25.h  |7 ---
 drivers/staging/lustre/lustre/llite/Makefile   |2 +-
 drivers/staging/lustre/lustre/llite/lloop.c|6 ++
 drivers/staging/lustre/lustre/lvfs/fsfilt.c|1 -
 7 files changed, 9 insertions(+), 16 deletions(-)

diff --git a/drivers/staging/lustre/lustre/Kconfig 
b/drivers/staging/lustre/lustre/Kconfig
index 0b45de0..4e898e4 100644
--- a/drivers/staging/lustre/lustre/Kconfig
+++ b/drivers/staging/lustre/lustre/Kconfig
@@ -1,6 +1,6 @@
 config LUSTRE_FS
tristate "Lustre file system client support"
-   depends on STAGING && INET && BLOCK && m
+   depends on INET && m
select LNET
select CRYPTO
select CRYPTO_CRC32
@@ -53,3 +53,8 @@ config LUSTRE_TRANSLATE_ERRNOS
bool
depends on LUSTRE_FS && !X86
default true
+
+config LUSTRE_LLITE_LLOOP
+   bool "Lustre virtual block device"
+   depends on LUSTRE_FS && BLOCK
+   default m
diff --git a/drivers/staging/lustre/lustre/fld/fld_cache.c 
b/drivers/staging/lustre/lustre/fld/fld_cache.c
index 347f2ae..8410107 100644
--- a/drivers/staging/lustre/lustre/fld/fld_cache.c
+++ b/drivers/staging/lustre/lustre/fld/fld_cache.c
@@ -45,7 +45,6 @@
 
 # include 
 # include 
-# include 
 # include 
 
 #include 
diff --git a/drivers/staging/lustre/lustre/fld/fld_request.c 
b/drivers/staging/lustre/lustre/fld/fld_request.c
index c99b945..049322a 100644
--- a/drivers/staging/lustre/lustre/fld/fld_request.c
+++ b/drivers/staging/lustre/lustre/fld/fld_request.c
@@ -44,7 +44,6 @@
 
 # include 
 # include 
-# include 
 # include 
 
 #include 
diff --git a/drivers/staging/lustre/lustre/include/linux/lustre_compat25.h 
b/drivers/staging/lustre/lustre/include/linux/lustre_compat25.h
index 426533b..018e604 100644
--- a/drivers/staging/lustre/lustre/include/linux/lustre_compat25.h
+++ b/drivers/staging/lustre/lustre/include/linux/lustre_compat25.h
@@ -111,13 +111,6 @@ static inline void ll_set_fs_pwd(struct fs_struct *fs, 
struct vfsmount *mnt,
 #define TREE_READ_LOCK_IRQ(mapping)spin_lock_irq(&(mapping)->tree_lock)
 #define TREE_READ_UNLOCK_IRQ(mapping)  spin_unlock_irq(&(mapping)->tree_lock)
 
-static inline
-int ll_unregister_blkdev(unsigned int dev, const char *name)
-{
-   unregister_blkdev(dev, name);
-   return 0;
-}
-
 #define ll_invalidate_bdev(a,b) invalidate_bdev((a))
 
 #ifndef FS_HAS_FIEMAP
diff --git a/drivers/staging/lustre/lustre/llite/Makefile 
b/drivers/staging/lustre/lustre/llite/Makefile
index dff0c04..f493e07 100644
--- a/drivers/staging/lustre/lustre/llite/Makefile
+++ b/drivers/staging/lustre/lustre/llite/Makefile
@@ -1,5 +1,5 @@
 obj-$(CONFIG_LUSTRE_FS) += lustre.o
-obj-$(CONFIG_LUSTRE_FS) += llite_lloop.o
+obj-$(CONFIG_LUSTRE_LLITE_LLOOP) += llite_lloop.o
 lustre-y := dcache.o dir.o file.o llite_close.o llite_lib.o llite_nfs.o \
rw.o lproc_llite.o namei.o symlink.o llite_mmap.o \
xattr.o remote_perm.o llite_rmtacl.o llite_capa.o \
diff --git a/drivers/staging/lustre/lustre/llite/lloop.c 
b/drivers/staging/lustre/lustre/llite/lloop.c
index e063efc..ae3dc9d 100644
--- a/

Re: [PATCH v2] staging/lustre: lloop depends on BLOCK

[Xiong Zhou]

On Tue, 30 Jul 2013, Peng Tao wrote:

> On Tue, Jul 30, 2013 at 8:29 AM, Xiong Zhou  wrote:
> > From: Xiong Zhou 
> >
> > In the lustre client driver, lloop depends on BLOCK. Add an
> > option for this dependence. Last version of this patch makes
> > LUSTRE_FS depends on BLOCK.
> > Remove unnecessary jdb head files which depends on BLOCK.
> >
> Thanks for the patch. One minor comment below. Other than that, you can add
> Reviewed-by: Peng Tao 
> 
> > Signed-off-by: Xiong Zhou 
> > ---
> >  drivers/staging/lustre/lustre/Kconfig  |7 ++-
> >  drivers/staging/lustre/lustre/fld/fld_cache.c  |1 -
> >  drivers/staging/lustre/lustre/fld/fld_request.c|1 -
> >  .../lustre/lustre/include/linux/lustre_compat25.h  |2 ++
> >  drivers/staging/lustre/lustre/llite/Makefile   |2 +-
> >  drivers/staging/lustre/lustre/lvfs/fsfilt.c|1 -
> >  6 files changed, 9 insertions(+), 5 deletions(-)
> >
> >  #define TREE_READ_UNLOCK_IRQ(mapping)  
> > spin_unlock_irq(&(mapping)->tree_lock)
> >
> > +#ifdef CONFIG_BLOCK
> >  static inline
> >  int ll_unregister_blkdev(unsigned int dev, const char *name)
> It is better to remove the wrapper and just call unregister_blkdev in
> lloop.c. The wrapper exists to support old kernels in Lustre master
> but doesn't make sense in upstream kernel.
> 
> Thanks,
> Tao
> 

Good comment, Thanks for the review.



From: Xiong Zhou 

First version of this patch makes LUSTRE_FS depends on BLOCK.
Second version makes only lloop depends on BLOCK with a config
option for this dependence, and remove unnecessary jdb header
files which depends on BLOCK.
This version removes the wrapper ll_unregister_blkdev which 
depends on BLOCK in header and just call unregister_blkdev in 
lloop.c based on Peng Tao's comment.

Signed-off-by: Xiong Zhou 
Reviewed-by: Peng Tao 
---
 drivers/staging/lustre/lustre/Kconfig  |7 ++-
 drivers/staging/lustre/lustre/fld/fld_cache.c  |1 -
 drivers/staging/lustre/lustre/fld/fld_request.c|1 -
 .../lustre/lustre/include/linux/lustre_compat25.h  |7 ---
 drivers/staging/lustre/lustre/llite/Makefile   |2 +-
 drivers/staging/lustre/lustre/llite/lloop.c|6 ++
 drivers/staging/lustre/lustre/lvfs/fsfilt.c|1 -
 7 files changed, 9 insertions(+), 16 deletions(-)

diff --git a/drivers/staging/lustre/lustre/Kconfig 
b/drivers/staging/lustre/lustre/Kconfig
index 0b45de0..4e898e4 100644
--- a/drivers/staging/lustre/lustre/Kconfig
+++ b/drivers/staging/lustre/lustre/Kconfig
@@ -1,6 +1,6 @@
 config LUSTRE_FS
tristate "Lustre file system client support"
-   depends on STAGING && INET && BLOCK && m
+   depends on INET && m
select LNET
select CRYPTO
select CRYPTO_CRC32
@@ -53,3 +53,8 @@ config LUSTRE_TRANSLATE_ERRNOS
bool
depends on LUSTRE_FS && !X86
default true
+
+config LUSTRE_LLITE_LLOOP
+   bool "Lustre virtual block device"
+   depends on LUSTRE_FS && BLOCK
+   default m
diff --git a/drivers/staging/lustre/lustre/fld/fld_cache.c 
b/drivers/staging/lustre/lustre/fld/fld_cache.c
index 347f2ae..8410107 100644
--- a/drivers/staging/lustre/lustre/fld/fld_cache.c
+++ b/drivers/staging/lustre/lustre/fld/fld_cache.c
@@ -45,7 +45,6 @@
 
 # include 
 # include 
-# include 
 # include 
 
 #include 
diff --git a/drivers/staging/lustre/lustre/fld/fld_request.c 
b/drivers/staging/lustre/lustre/fld/fld_request.c
index c99b945..049322a 100644
--- a/drivers/staging/lustre/lustre/fld/fld_request.c
+++ b/drivers/staging/lustre/lustre/fld/fld_request.c
@@ -44,7 +44,6 @@
 
 # include 
 # include 
-# include 
 # include 
 
 #include 
diff --git a/drivers/staging/lustre/lustre/include/linux/lustre_compat25.h 
b/drivers/staging/lustre/lustre/include/linux/lustre_compat25.h
index 426533b..018e604 100644
--- a/drivers/staging/lustre/lustre/include/linux/lustre_compat25.h
+++ b/drivers/staging/lustre/lustre/include/linux/lustre_compat25.h
@@ -111,13 +111,6 @@ static inline void ll_set_fs_pwd(struct fs_struct *fs, 
struct vfsmount *mnt,
 #define TREE_READ_LOCK_IRQ(mapping)spin_lock_irq(&(mapping)->tree_lock)
 #define TREE_READ_UNLOCK_IRQ(mapping)  spin_unlock_irq(&(mapping)->tree_lock)
 
-static inline
-int ll_unregister_blkdev(unsigned int dev, const char *name)
-{
-   unregister_blkdev(dev, name);
-   return 0;
-}
-
 #define ll_invalidate_bdev(a,b) invalidate_bdev((a))
 
 #ifndef FS_HAS_FIEMAP
diff --git a/drivers/staging/lustre/lustre/llite/Makefile 
b/drivers/staging/lustre/lustre/llite/Makefile
index dff0c04..f493e07 100644
--- a/drivers/staging/lustre/lustre/llite/Makefile
+++ b/drivers/staging/lustre/lustre/llite/Makefile

[PATCH] include/jbd: add missing ifdef CONFIG_BLOCK

[Xiong Zhou]

From: Xiong Zhou 

In jbd{2}.h, BH_PrivateStart is used in the define of enum jbd_state_bits,
which is defined in buffer_head.h under ifdef CONFIG_BLOCK. In these
two headers, BUFFER_FNS and TAS_BUFFER_FNS and jbd_common.h refer to
enum jbd_state_bits, so they should under ifdef CONFIG_BLOCK.

Signed-off-by: Xiong Zhou 
---
 include/linux/jbd.h  |2 ++
 include/linux/jbd2.h |2 ++
 2 files changed, 4 insertions(+)

diff --git a/include/linux/jbd.h b/include/linux/jbd.h
index 8685d1b..e9dcf47 100644
--- a/include/linux/jbd.h
+++ b/include/linux/jbd.h
@@ -244,6 +244,7 @@ typedef struct journal_superblock_s
 #include 
 #include 
 
+#ifdef CONFIG_BLOCK
 enum jbd_state_bits {
BH_JBD  /* Has an attached ext3 journal_head */
  = BH_PrivateStart,
@@ -269,6 +270,7 @@ TAS_BUFFER_FNS(RevokeValid, revokevalid)
 BUFFER_FNS(Freed, freed)
 
 #include 
+#endif
 
 #define J_ASSERT(assert)   BUG_ON(!(assert))
 
diff --git a/include/linux/jbd2.h b/include/linux/jbd2.h
index d5b50a1..6214b80 100644
--- a/include/linux/jbd2.h
+++ b/include/linux/jbd2.h
@@ -298,6 +298,7 @@ typedef struct journal_superblock_s
 #include 
 #include 
 
+#ifdef CONFIG_BLOCK
 enum jbd_state_bits {
BH_JBD  /* Has an attached ext3 journal_head */
  = BH_PrivateStart,
@@ -326,6 +327,7 @@ BUFFER_FNS(Shadow, shadow)
 BUFFER_FNS(Verified, verified)
 
 #include 
+#endif
 
 #define J_ASSERT(assert)   BUG_ON(!(assert))
 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2] staging/lustre: lloop depends on BLOCK

[Xiong Zhou]

From: Xiong Zhou 

In the lustre client driver, lloop depends on BLOCK. Add an
option for this dependence. Last version of this patch makes
LUSTRE_FS depends on BLOCK.
Remove unnecessary jdb head files which depends on BLOCK.

Signed-off-by: Xiong Zhou 
---
 drivers/staging/lustre/lustre/Kconfig  |7 ++-
 drivers/staging/lustre/lustre/fld/fld_cache.c  |1 -
 drivers/staging/lustre/lustre/fld/fld_request.c|1 -
 .../lustre/lustre/include/linux/lustre_compat25.h  |2 ++
 drivers/staging/lustre/lustre/llite/Makefile   |2 +-
 drivers/staging/lustre/lustre/lvfs/fsfilt.c|1 -
 6 files changed, 9 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/lustre/lustre/Kconfig 
b/drivers/staging/lustre/lustre/Kconfig
index 0b45de0..4e898e4 100644
--- a/drivers/staging/lustre/lustre/Kconfig
+++ b/drivers/staging/lustre/lustre/Kconfig
@@ -1,6 +1,6 @@
 config LUSTRE_FS
tristate "Lustre file system client support"
-   depends on STAGING && INET && BLOCK && m
+   depends on INET && m
select LNET
select CRYPTO
select CRYPTO_CRC32
@@ -53,3 +53,8 @@ config LUSTRE_TRANSLATE_ERRNOS
bool
depends on LUSTRE_FS && !X86
default true
+
+config LUSTRE_LLITE_LLOOP
+   bool "Lustre virtual block device"
+   depends on LUSTRE_FS && BLOCK
+   default m
diff --git a/drivers/staging/lustre/lustre/fld/fld_cache.c 
b/drivers/staging/lustre/lustre/fld/fld_cache.c
index 347f2ae..8410107 100644
--- a/drivers/staging/lustre/lustre/fld/fld_cache.c
+++ b/drivers/staging/lustre/lustre/fld/fld_cache.c
@@ -45,7 +45,6 @@
 
 # include 
 # include 
-# include 
 # include 
 
 #include 
diff --git a/drivers/staging/lustre/lustre/fld/fld_request.c 
b/drivers/staging/lustre/lustre/fld/fld_request.c
index c99b945..049322a 100644
--- a/drivers/staging/lustre/lustre/fld/fld_request.c
+++ b/drivers/staging/lustre/lustre/fld/fld_request.c
@@ -44,7 +44,6 @@
 
 # include 
 # include 
-# include 
 # include 
 
 #include 
diff --git a/drivers/staging/lustre/lustre/include/linux/lustre_compat25.h 
b/drivers/staging/lustre/lustre/include/linux/lustre_compat25.h
index 426533b..c0156e3 100644
--- a/drivers/staging/lustre/lustre/include/linux/lustre_compat25.h
+++ b/drivers/staging/lustre/lustre/include/linux/lustre_compat25.h
@@ -111,12 +111,14 @@ static inline void ll_set_fs_pwd(struct fs_struct *fs, 
struct vfsmount *mnt,
 #define TREE_READ_LOCK_IRQ(mapping)spin_lock_irq(&(mapping)->tree_lock)
 #define TREE_READ_UNLOCK_IRQ(mapping)  spin_unlock_irq(&(mapping)->tree_lock)
 
+#ifdef CONFIG_BLOCK
 static inline
 int ll_unregister_blkdev(unsigned int dev, const char *name)
 {
unregister_blkdev(dev, name);
return 0;
 }
+#endif
 
 #define ll_invalidate_bdev(a,b) invalidate_bdev((a))
 
diff --git a/drivers/staging/lustre/lustre/llite/Makefile 
b/drivers/staging/lustre/lustre/llite/Makefile
index dff0c04..f493e07 100644
--- a/drivers/staging/lustre/lustre/llite/Makefile
+++ b/drivers/staging/lustre/lustre/llite/Makefile
@@ -1,5 +1,5 @@
 obj-$(CONFIG_LUSTRE_FS) += lustre.o
-obj-$(CONFIG_LUSTRE_FS) += llite_lloop.o
+obj-$(CONFIG_LUSTRE_LLITE_LLOOP) += llite_lloop.o
 lustre-y := dcache.o dir.o file.o llite_close.o llite_lib.o llite_nfs.o \
rw.o lproc_llite.o namei.o symlink.o llite_mmap.o \
xattr.o remote_perm.o llite_rmtacl.o llite_capa.o \
diff --git a/drivers/staging/lustre/lustre/lvfs/fsfilt.c 
b/drivers/staging/lustre/lustre/lvfs/fsfilt.c
index 064445c..ce71f80 100644
--- a/drivers/staging/lustre/lustre/lvfs/fsfilt.c
+++ b/drivers/staging/lustre/lustre/lvfs/fsfilt.c
@@ -35,7 +35,6 @@
 #define DEBUG_SUBSYSTEM S_FILTER
 
 #include 
-#include 
 #include 
 #include 
 #include 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] staging/lustre: add BLOCK depends in Kconfig

[Xiong Zhou]

2013/7/26 Dilger, Andreas :
> On 2013/07/25 1:06 AM, "Xiong Zhou"  wrote:
>
>>From: Xiong Zhou 
>>
>>Add BLOCK depends in Kconfig for LUSTRE to fix this:
>>drivers/staging/lustre/lustre/fid/../include/linux/lustre_compat25.h:117:2
>>:
>>error: implicit declaration of function ʽunregister_blkdevʼ
>>
>>Signed-off-by: Xiong Zhou 
>>---
>> drivers/staging/lustre/lustre/Kconfig |2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>>diff --git a/drivers/staging/lustre/lustre/Kconfig
>>b/drivers/staging/lustre/lustre/Kconfig
>>index 9ae7fa8..0b45de0 100644
>>--- a/drivers/staging/lustre/lustre/Kconfig
>>+++ b/drivers/staging/lustre/lustre/Kconfig
>>@@ -1,6 +1,6 @@
>> config LUSTRE_FS
>>   tristate "Lustre file system client support"
>>-  depends on STAGING && INET && m
>>+  depends on STAGING && INET && BLOCK && m
>>   select LNET
>>   select CRYPTO
>>   select CRYPTO_CRC32
>
> The Lustre client does not need a block device - it is a network
> filesystem.
> The one piece of code that is relevant here relates to a Lustre-optimized
> "loop" device that bypasses the VFS, data copying, and DLM locking for use
> by swap and such.  It would be better instead to make that code conditional
> and add a new CONFIG_LUSTRE_LLOOP or similar, and only make that part
> dependent
> on BLOCK.
>
> Cheers, Andreas
> --
> Andreas Dilger
>

This makes sence. I noticed that this patch has gone into Greg's tree,
so a coming patch
based on this patch is cool?

> Lustre Software Architect
> Intel High Performance Data Division
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] staging/lustre: add BLOCK depends in Kconfig

[Xiong Zhou]

2013/7/25 Paul Bolle :
> On Thu, 2013-07-25 at 15:06 +0800, Xiong Zhou wrote:
>> Add BLOCK depends in Kconfig for LUSTRE to fix this:
>> drivers/staging/lustre/lustre/fid/../include/linux/lustre_compat25.h:117:2:
>> error: implicit declaration of function ‘unregister_blkdev’
>>
>> Signed-off-by: Xiong Zhou 
>> ---
>>  drivers/staging/lustre/lustre/Kconfig |2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/staging/lustre/lustre/Kconfig 
>> b/drivers/staging/lustre/lustre/Kconfig
>> index 9ae7fa8..0b45de0 100644
>> --- a/drivers/staging/lustre/lustre/Kconfig
>> +++ b/drivers/staging/lustre/lustre/Kconfig
>> @@ -1,6 +1,6 @@
>>  config LUSTRE_FS
>> tristate "Lustre file system client support"
>> -   depends on STAGING && INET && m
>> +   depends on STAGING && INET && BLOCK && m
>
> Everything below drivers/staging/lustre/Kconfig is only sourced if
> STAGING is set. You can drop the dependency on STAGING.
>

Yes, it is. Thanks~

>> select LNET
>> select CRYPTO
>> select CRYPTO_CRC32
>
>
> Paul Bolle
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] staging/lustre: add BLOCK depends in Kconfig

[Xiong Zhou]

From: Xiong Zhou 

Add BLOCK depends in Kconfig for LUSTRE to fix this:
drivers/staging/lustre/lustre/fid/../include/linux/lustre_compat25.h:117:2: 
error: implicit declaration of function ‘unregister_blkdev’ 

Signed-off-by: Xiong Zhou 
---
 drivers/staging/lustre/lustre/Kconfig |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/lustre/lustre/Kconfig 
b/drivers/staging/lustre/lustre/Kconfig
index 9ae7fa8..0b45de0 100644
--- a/drivers/staging/lustre/lustre/Kconfig
+++ b/drivers/staging/lustre/lustre/Kconfig
@@ -1,6 +1,6 @@
 config LUSTRE_FS
tristate "Lustre file system client support"
-   depends on STAGING && INET && m
+   depends on STAGING && INET && BLOCK && m
select LNET
select CRYPTO
select CRYPTO_CRC32

[tip:x86/urgent] x86/platform/ce4100: Add header file for reboot type

[tip-bot for Xiong Zhou]

Commit-ID:  ff5599816711d2e67da2d7561fd36ac48debd433
Gitweb: http://git.kernel.org/tip/ff5599816711d2e67da2d7561fd36ac48debd433
Author: Xiong Zhou 
AuthorDate: Tue, 9 Jul 2013 11:06:27 +0800
Committer:  Ingo Molnar 
CommitDate: Fri, 12 Jul 2013 12:21:20 +0200

x86/platform/ce4100: Add header file for reboot type

Add header file for reboot type to fix this build failure:

 error: 'reboot_type' undeclared (first use in this function)
 error: 'BOOT_KBD' undeclared (first use in this function)

Signed-off-by: Xiong Zhou 
Cc: rui.zh...@intel.com
Cc: a...@linux.intel.com
Cc: ffaine...@freebox.fr
Cc: mbi...@freebox.fr
Cc: matthew.garr...@nebula.com
Link: http://lkml.kernel.org/r/alpine.DEB.2.02.1307091053280.28371@M2420
Signed-off-by: Ingo Molnar 
---
 arch/x86/platform/ce4100/ce4100.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/x86/platform/ce4100/ce4100.c 
b/arch/x86/platform/ce4100/ce4100.c
index f8ab494..9962015 100644
--- a/arch/x86/platform/ce4100/ce4100.c
+++ b/arch/x86/platform/ce4100/ce4100.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] x86: ce4100: add head file for reboot type

[Xiong Zhou]

2013/7/9 Xiong Zhou :
> From: Xiong Zhou 
>
> Add head file for reboot type stuff to fix this:
> error: ‘reboot_type’ undeclared (first use in this function)
> error: ‘BOOT_KBD’ undeclared (first use in this function)
>
> Signed-off-by: Xiong Zhou 
> ---
>  arch/x86/platform/ce4100/ce4100.c |1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/arch/x86/platform/ce4100/ce4100.c 
> b/arch/x86/platform/ce4100/ce4100.c
> index baec704..643b8b5e 100644
> --- a/arch/x86/platform/ce4100/ce4100.c
> +++ b/arch/x86/platform/ce4100/ce4100.c
> @@ -14,6 +14,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #include 
>  #include 



cc Jiri Kosina 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH]amilo-rfkill: add depends on i8042 in Kconfig

[Xiong Zhou]

2013/6/28 Randy Dunlap :
> On 06/18/13 18:09, Xiong Zhou wrote:
>> 2013/6/18 Randy Dunlap :
>>> On 06/18/13 06:04, Ben Hutchings wrote:
>>>> On Tue, 2013-06-18 at 17:21 +0800, Xiong Zhou wrote:
>>>>> From: Xiong Zhou 
>>>>>
>>>>> Fix randconfig build failure for Amilo x86 platform driver.
>>>>> AMILO_RFKILL requires SERIO_I8042 being available.
>>>>>
>>>>> amilo-rfkill.c:(.text+0x108b5b): undefined reference to `i8042_lock_chip'
>>>>> amilo-rfkill.c:(.text+0x108b69): undefined reference to `i8042_command'
>>>>> amilo-rfkill.c:(.text+0x108b71): undefined reference to 
>>>>> `i8042_unlock_chip'
>>>>>
>>>>> Reported-by: Jim Davis 
>>>>> Signed-off-by: Xiong Zhou 
>>>>
>>>> Acked-by: Ben Hutchings 
>>>>
>>>> But I thought somehow sent this same fix a while back...
>>>
>>> Yes, I reported it and sent a patch for it that you acked...
>>> I guess my patch was never picked up.
>>>
>>
>> ... Better someone pick this up.
>>
>
> This build error is still occurring in linux-next (20130627).
> I first reported it and posted a patch for it on May-15 2013.
>
> Please merge either patch...
>
> Is anybody out there?
>
>
>>
>>>>
>>>> Ben.
>>>>
>>>>> ---
>>>>>  drivers/platform/x86/Kconfig |1 +
>>>>>  1 file changed, 1 insertion(+)
>>>>>
>>>>> diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
>>>>> index 8577261..37645b9 100644
>>>>> --- a/drivers/platform/x86/Kconfig
>>>>> +++ b/drivers/platform/x86/Kconfig
>>>>> @@ -176,6 +176,7 @@ config FUJITSU_TABLET
>>>>>  config AMILO_RFKILL
>>>>>  tristate "Fujitsu-Siemens Amilo rfkill support"
>>>>>  depends on RFKILL
>>>>> +depends on SERIO_I8042
>>>>>  ---help---
>>>>>This is a driver for enabling wifi on some Fujitsu-Siemens Amilo
>>>>>laptops.
>>>>
>>>
>>>
>>> --
>>> ~Randy
>> --
>
>
> --
> ~Randy



cc Jiri Kosina 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] x86: ce4100: add head file for reboot type

[Xiong Zhou]

From: Xiong Zhou 

Add head file for reboot type stuff to fix this:
error: ‘reboot_type’ undeclared (first use in this function)
error: ‘BOOT_KBD’ undeclared (first use in this function)

Signed-off-by: Xiong Zhou 
---
 arch/x86/platform/ce4100/ce4100.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/x86/platform/ce4100/ce4100.c 
b/arch/x86/platform/ce4100/ce4100.c
index baec704..643b8b5e 100644
--- a/arch/x86/platform/ce4100/ce4100.c
+++ b/arch/x86/platform/ce4100/ce4100.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 

Re: [PATCH]amilo-rfkill: add depends on i8042 in Kconfig

[Xiong Zhou]

2013/6/18 Randy Dunlap :
> On 06/18/13 06:04, Ben Hutchings wrote:
>> On Tue, 2013-06-18 at 17:21 +0800, Xiong Zhou wrote:
>>> From: Xiong Zhou 
>>>
>>> Fix randconfig build failure for Amilo x86 platform driver.
>>> AMILO_RFKILL requires SERIO_I8042 being available.
>>>
>>> amilo-rfkill.c:(.text+0x108b5b): undefined reference to `i8042_lock_chip'
>>> amilo-rfkill.c:(.text+0x108b69): undefined reference to `i8042_command'
>>> amilo-rfkill.c:(.text+0x108b71): undefined reference to `i8042_unlock_chip'
>>>
>>> Reported-by: Jim Davis 
>>> Signed-off-by: Xiong Zhou 
>>
>> Acked-by: Ben Hutchings 
>>
>> But I thought somehow sent this same fix a while back...
>
> Yes, I reported it and sent a patch for it that you acked...
> I guess my patch was never picked up.
>

... Better someone pick this up.


>>
>> Ben.
>>
>>> ---
>>>  drivers/platform/x86/Kconfig |1 +
>>>  1 file changed, 1 insertion(+)
>>>
>>> diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
>>> index 8577261..37645b9 100644
>>> --- a/drivers/platform/x86/Kconfig
>>> +++ b/drivers/platform/x86/Kconfig
>>> @@ -176,6 +176,7 @@ config FUJITSU_TABLET
>>>  config AMILO_RFKILL
>>>  tristate "Fujitsu-Siemens Amilo rfkill support"
>>>  depends on RFKILL
>>> +depends on SERIO_I8042
>>>  ---help---
>>>This is a driver for enabling wifi on some Fujitsu-Siemens Amilo
>>>laptops.
>>
>
>
> --
> ~Randy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH]amilo-rfkill: add depends on i8042 in Kconfig

[Xiong Zhou]

From: Xiong Zhou 

Fix randconfig build failure for Amilo x86 platform driver.
AMILO_RFKILL requires SERIO_I8042 being available.

amilo-rfkill.c:(.text+0x108b5b): undefined reference to `i8042_lock_chip'
amilo-rfkill.c:(.text+0x108b69): undefined reference to `i8042_command'
amilo-rfkill.c:(.text+0x108b71): undefined reference to `i8042_unlock_chip'

Reported-by: Jim Davis 
Signed-off-by: Xiong Zhou 
---
 drivers/platform/x86/Kconfig |1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index 8577261..37645b9 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -176,6 +176,7 @@ config FUJITSU_TABLET
 config AMILO_RFKILL
tristate "Fujitsu-Siemens Amilo rfkill support"
depends on RFKILL
+   depends on SERIO_I8042
---help---
  This is a driver for enabling wifi on some Fujitsu-Siemens Amilo
  laptops.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] staging/solo6x10: select the desired font

[Xiong Zhou]

From: Xiong Zhou 

Make sure FONT_8x16 can be found by find_font().

Signed-off-by: Xiong Zhou 
---
 drivers/staging/media/solo6x10/Kconfig |1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/staging/media/solo6x10/Kconfig 
b/drivers/staging/media/solo6x10/Kconfig
index ec32776..0bc743b 100644
--- a/drivers/staging/media/solo6x10/Kconfig
+++ b/drivers/staging/media/solo6x10/Kconfig
@@ -4,6 +4,7 @@ config SOLO6X10
select VIDEOBUF2_DMA_SG
select VIDEOBUF2_DMA_CONTIG
select SND_PCM
+   select FONT_8x16
---help---
  This driver supports the Softlogic based MPEG-4 and h.264 codec
  cards.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for May 15 (crypto /crct10dif)

[Xiong Zhou]

2013/5/17 Tim Chen :
> On Thu, 2013-05-16 at 09:59 -0700, Tim Chen wrote:
>> On Thu, 2013-05-16 at 09:22 +0200, Geert Uytterhoeven wrote:
>> > On Thu, May 16, 2013 at 5:57 AM, Xiong Zhou  
>> > wrote:
>> > > --- a/crypto/Kconfig
>> > > +++ b/crypto/Kconfig
>> > > @@ -378,6 +378,7 @@ config CRYPTO_CRC32_PCLMUL
>> > >
>> > >  config CRYPTO_CRCT10DIF
>> > > tristate "CRCT10DIF algorithm"
>> > > +   depends on CRC_T10DIF
>> >
>> > This is a library symbol, so "select CRC_T10DIF"?
>> >
>> > > select CRYPTO_HASH
>> > > help
>> > >   CRC T10 Data Integrity Field computation is being cast as
>> >
>> > Gr{oetje,eeting}s,
>> >
>> > Geert
>> >
>>
>> This is the fix I think that will resolve the build issues.  The generic
>> crc-t10dif transform depends on the library function crc_t10dif_generic
>> in lib/crc-t10dif.c, so "depends on CRC_T10DIF" for CRYPTO_CRCT10DIF is
>> needed.
>>
>> Now for CRC_T10DIF, we should use select CRYPTO_HASH, so it can try to
>> allocate a T10DIF transform if it is available.  If not, it will simply
>> use the crc_t10dif_generic function. Loading the
>> generic t10dif crypto transform is not mandatory for the library
>> function crc_t10dif.
>>
>> Thanks for catching the issues.
>>
>> Tim
>>

cool.

>
> Need to also add select CRYPTO for CRC_T10DIF.  Updated fix below:
>
>
> Signed-off-by: Tim Chen 
> ---
> diff --git a/crypto/Kconfig b/crypto/Kconfig
> index d1ca631..015df24 100644
> --- a/crypto/Kconfig
> +++ b/crypto/Kconfig
> @@ -379,6 +379,7 @@ config CRYPTO_CRC32_PCLMUL
>  config CRYPTO_CRCT10DIF
> tristate "CRCT10DIF algorithm"
> select CRYPTO_HASH
> +   depends on CRC_T10DIF
> help
>   CRC T10 Data Integrity Field computation is being cast as
>   a crypto transform.  This allows for faster crc t10 diff
> diff --git a/lib/Kconfig b/lib/Kconfig
> index 0cee056..6407793 100644
> --- a/lib/Kconfig
> +++ b/lib/Kconfig
> @@ -63,7 +63,8 @@ config CRC16
>
>  config CRC_T10DIF
> tristate "CRC calculation for the T10 Data Integrity Field"
> -   select CRYPTO_CRCT10DIF
> +   select CRYPTO
> +   select CRYPTO_HASH
> help
>   This option is only needed if a module that's not in the
>   kernel tree needs to calculate CRC checks for use with the
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for May 15 (crypto /crct10dif)

[Xiong Zhou]

2013/5/16 Geert Uytterhoeven :
> On Thu, May 16, 2013 at 5:57 AM, Xiong Zhou  wrote:
>> --- a/crypto/Kconfig
>> +++ b/crypto/Kconfig
>> @@ -378,6 +378,7 @@ config CRYPTO_CRC32_PCLMUL
>>
>>  config CRYPTO_CRCT10DIF
>> tristate "CRCT10DIF algorithm"
>> +   depends on CRC_T10DIF
>
> This is a library symbol, so "select CRC_T10DIF"?

En.. make sense, Thanks.

Xiong

>
>> select CRYPTO_HASH
>> help
>>   CRC T10 Data Integrity Field computation is being cast as
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- 
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like 
> that.
> -- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for May 15 (crypto /crct10dif)

[Xiong Zhou]

On Wed, 15 May 2013, Randy Dunlap wrote:

> On 05/14/13 20:26, Stephen Rothwell wrote:
> > Hi all,
> > 
> > Changes since 20130514:
> > 
> 
> on x86_64:
> 
> crypto/built-in.o: In function `chksum_digest':
> crct10dif.c:(.text+0x2789f): undefined reference to `crc_t10dif_generic'
> crypto/built-in.o: In function `chksum_finup':
> crct10dif.c:(.text+0x278c7): undefined reference to `crc_t10dif_generic'
> crypto/built-in.o: In function `chksum_update':
> crct10dif.c:(.text+0x278ef): undefined reference to `crc_t10dif_generic'
> 
> 
> CONFIG_CRYPTO_CRCT10DIF=y
> CONFIG_CRC_T10DIF=m
> 
> 
> 
> Full randconfig file is attached.
> 
> 
> -- 
> ~Randy
> 
just try.

From: Xiong Zhou 

Try to fix randconfig build error reported by Randy Dunlap:

on x86_64:

crypto/built-in.o: In function `chksum_digest':
crct10dif.c:(.text+0x2789f): undefined reference to `crc_t10dif_generic'
crypto/built-in.o: In function `chksum_finup':
crct10dif.c:(.text+0x278c7): undefined reference to `crc_t10dif_generic'
crypto/built-in.o: In function `chksum_update':
crct10dif.c:(.text+0x278ef): undefined reference to `crc_t10dif_generic'

CONFIG_CRYPTO_CRCT10DIF=y
CONFIG_CRC_T10DIF=m

Cc: Randy Dunlap 
Signed-off-by: Xiong Zhou 
---
 crypto/Kconfig |1 +
 1 file changed, 1 insertion(+)

diff --git a/crypto/Kconfig b/crypto/Kconfig
index 25b5209..28655bc 100644
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -378,6 +378,7 @@ config CRYPTO_CRC32_PCLMUL
 
 config CRYPTO_CRCT10DIF
tristate "CRCT10DIF algorithm"
+   depends on CRC_T10DIF
select CRYPTO_HASH
help
  CRC T10 Data Integrity Field computation is being cast as

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for May 9

[Xiong Zhou]

On Thu, 9 May 2013, Stephen Rothwell wrote:

> Hi all,
> 
> Please do not add any v3.11 destined work to your linux-next included
> branches until after v3.10-rc1 is released.
> 
> Changes since 20130508:
> 
> The microblaze tree gained a conflict against Linus' tree
> 
> The regmap tree gained a conflict against Linus' tree
> 
> The vhost tree gained a conflict against Linus' tree.
> 
> 

on i386 randconfig, when USB_DWC3=y USB_DWC3_DUAL_ROLE=y USB_GADGET=m:

drivers/built-in.o: In function `dwc3_gadget_giveback':
next20130509/drivers/usb/dwc3/gadget.c:271: undefined reference to 
`usb_gadget_unmap_request'
drivers/built-in.o: In function `__dwc3_gadget_kick_transfer':
next20130509/drivers/usb/dwc3/gadget.c:1005: undefined reference to 
`usb_gadget_unmap_request'
drivers/built-in.o: In function `__dwc3_gadget_ep_queue':
next20130509/drivers/usb/dwc3/gadget.c:1073: undefined reference to 
`usb_gadget_map_request'
drivers/built-in.o: In function `dwc3_gadget_reset_interrupt':
next20130509/drivers/usb/dwc3/gadget.c:2165: undefined reference to 
`usb_gadget_set_state'
drivers/built-in.o: In function `dwc3_gadget_init':
next20130509/drivers/usb/dwc3/gadget.c:2647: undefined reference to 
`usb_add_gadget_udc'
drivers/built-in.o: In function `dwc3_gadget_exit':
next20130509/drivers/usb/dwc3/gadget.c:2681: undefined reference to 
`usb_del_gadget_udc'
drivers/built-in.o: In function `__dwc3_ep0_do_control_data':
next20130509/drivers/usb/dwc3/ep0.c:906: undefined reference to 
`usb_gadget_map_request'
next20130509/drivers/usb/dwc3/ep0.c:929: undefined reference to 
`usb_gadget_map_request'
drivers/built-in.o: In function `dwc3_ep0_set_config':
next20130509/drivers/usb/dwc3/ep0.c:575: undefined reference to 
`usb_gadget_set_state'
next20130509/drivers/usb/dwc3/ep0.c:556: undefined reference to 
`usb_gadget_set_state'
drivers/built-in.o: In function `dwc3_ep0_set_address':
next20130509/drivers/usb/dwc3/ep0.c:522: undefined reference to 
`usb_gadget_set_state'
next20130509/drivers/usb/dwc3/ep0.c:520: undefined reference to 
`usb_gadget_set_state'
make: *** [vmlinux] Error 1


> 
> I have created today's linux-next tree at
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
> (patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
> are tracking the linux-next tree using git, you should not use "git pull"
> to do so as that will try to merge the new linux-next release with the
> old one.  You should use "git fetch" as mentioned in the FAQ on the wiki
> (see below).
> 
> You can see which trees have been included by looking in the Next/Trees
> file in the source.  There are also quilt-import.log and merge.log files
> in the Next directory.  Between each merge, the tree was built with
> a ppc64_defconfig for powerpc and an allmodconfig for x86_64. After the
> final fixups (if any), it is also built with powerpc allnoconfig (32 and
> 64 bit), ppc44x_defconfig and allyesconfig (minus
> CONFIG_PROFILE_ALL_BRANCHES - this fails its final link) and i386, sparc,
> sparc64 and arm defconfig. These builds also have
> CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and
> CONFIG_DEBUG_INFO disabled when necessary.
> 
> Below is a summary of the state of the merge.
> 
> We are up to 224 trees (counting Linus' and 31 trees of patches pending
> for Linus' tree), more are welcome (even if they are currently empty).
> Thanks to those who have contributed, and to those who haven't, please do.
> 
> Status of my local build tests will be at
> http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
> advice about cross compilers/configs that work, we are always open to add
> more builds.
> 
> Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
> Gortmaker for triage and bug fixes.
> 
> There is a wiki covering stuff to do with linux-next at
> http://linux.f-seidel.de/linux-next/pmwiki/ .  Thanks to Frank Seidel.
> 
> -- 
> Cheers,
> Stephen Rothwells...@canb.auug.org.au
> 
> $ git checkout master
> $ git reset --hard stable
> Merging origin/master (e0fd9af Merge tag 'rdma-for-linus' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband)
> Merging fixes/master (0279b3c Merge branch 'sched-urgent-for-linus' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip)
> Merging kbuild-current/rc-fixes (a54292f kbuild: generate generic headers 
> before recursing into scripts)
> Merging arc-current/for-curr (eacd0e9 ARC: [mm] Lazy D-cache flush (non 
> aliasing VIPT))
> Merging arm-current/fixes (1783d45 ARM: 7700/2: Make cpu_init() notrace)
> Merging m68k-current/for-linus (e00c73e m68k: Remove inline strlen() 
> implementation)
> Merging powerpc-merge/merge (5737789 powerpc: Make hard_irq_disable() do the 
> right thing vs. irq tracing)
> Merging sparc/master (de9c9f8 Merge tag 'remoteproc-3.10' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/ohad/remoteproc

Re: [PATCH] staging: android: logger: use kuid_t instead of uid_t

[Xiong Zhou]

Thanks all for reviewing.

xiong

2013/5/8 Greg KH :
> On Wed, May 08, 2013 at 06:52:48PM +0800, Xiong Zhou wrote:
>> From: Xiong Zhou 
>>
>> Use kuid_t instead of uid_t, to pass the UIDGID_STRICT_TYPE_CHECKS.
>>
>> Signed-off-by: Xiong Zhou 
>
> Nice job, I'll queue this up after 3.10-rc1 is out.
>
> greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] staging: android: logger: use kuid_t instead of uid_t

[Xiong Zhou]

From: Xiong Zhou 

Use kuid_t instead of uid_t, to pass the UIDGID_STRICT_TYPE_CHECKS.

Signed-off-by: Xiong Zhou 
---
drivers/staging/android/logger.c |4 ++--
drivers/staging/android/logger.h |2 +-
2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/android/logger.c b/drivers/staging/android/logger.c
index b040200..9bd8747 100644
--- a/drivers/staging/android/logger.c
+++ b/drivers/staging/android/logger.c
@@ -242,7 +242,7 @@ static ssize_t do_read_log_to_user(struct logger_log *log,
  * 'log->buffer' which contains the first entry readable by 'euid'
  */
 static size_t get_next_entry_by_uid(struct logger_log *log,
-   size_t off, uid_t euid)
+   size_t off, kuid_t euid)
 {
while (off != log->w_off) {
struct logger_entry *entry;
@@ -251,7 +251,7 @@ static size_t get_next_entry_by_uid(struct logger_log *log,
 
entry = get_entry_header(log, off, &scratch);
 
-   if (entry->euid == euid)
+   if (uid_eq(entry->euid, euid))
return off;
 
next_len = sizeof(struct logger_entry) + entry->len;
diff --git a/drivers/staging/android/logger.h b/drivers/staging/android/logger.h
index cc6bbd9..70af7d8 100644
--- a/drivers/staging/android/logger.h
+++ b/drivers/staging/android/logger.h
@@ -66,7 +66,7 @@ struct logger_entry {
__s32   tid;
__s32   sec;
__s32   nsec;
-   uid_t   euid;
+   kuid_t  euid;
charmsg[0];
 };
 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH -next] power: fix bq27x00_battery kconfig

[Xiong Zhou]

From: Xiong Zhou 

This patch fixes build failure(randconfig) of next-20130501.
When config I2C as m, BATTERY_BQ27x00 as y, here comes the failure.
The driver depends on I2C only if I2C is not disabled, as Lars
commented. Last version of this patch make the driver depend on I2C
unconditionally.

Failure message:
drivers/built-in.o: In function `bq27x00_read_i2c':
bq27x00_battery.c:(.text+0x1082a7): undefined reference to `i2c_transfer'
drivers/built-in.o: In function `bq27x00_battery_init':
bq27x00_battery.c:(.init.text+0x6085): undefined reference to 
`i2c_register_driver'
bq27x00_battery.c:(.init.text+0x60c7): undefined reference to `i2c_del_driver'
drivers/built-in.o: In function `bq27x00_battery_exit':
bq27x00_battery.c:(.exit.text+0xbf0): undefined reference to `i2c_del_driver'
make: *** [vmlinux] Error 1

Signed-off-by: Xiong Zhou 
Cc: Lars-Peter Clausen 
---
drivers/power/Kconfig |1 +
1 file changed, 1 insertion(+)

diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
index 0d0b5d7..f11bacd 100644
--- a/drivers/power/Kconfig
+++ b/drivers/power/Kconfig
@@ -152,6 +152,7 @@ config BATTERY_SBS
 
 config BATTERY_BQ27x00
tristate "BQ27x00 battery driver"
+   depends on I2C || I2C=n
help
  Say Y here to enable support for batteries with BQ27x00 (I2C/HDQ) 
chips.
 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH -next] power: fix bq27x00_battery kconfig

[Xiong Zhou]

From: Xiong Zhou 

This patch fixes build failure(randconfig) of next-20130501.
When config I2C as m, BATTERY_BQ27x00 as y, here comes the failure.
BATTERY_BQ27x00 depends on I2C according to the code.

Failure message:
drivers/built-in.o: In function `bq27x00_read_i2c':
bq27x00_battery.c:(.text+0x1082a7): undefined reference to `i2c_transfer'
drivers/built-in.o: In function `bq27x00_battery_init':
bq27x00_battery.c:(.init.text+0x6085): undefined reference to 
`i2c_register_driver'
bq27x00_battery.c:(.init.text+0x60c7): undefined reference to `i2c_del_driver'
drivers/built-in.o: In function `bq27x00_battery_exit':
bq27x00_battery.c:(.exit.text+0xbf0): undefined reference to `i2c_del_driver'
make: *** [vmlinux] Error 1

Signed-off-by: Xiong Zhou 
---
drivers/power/Kconfig |1 +
1 file changed, 1 insertion(+)

diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
index 0d0b5d7..89e5ebd 100644
--- a/drivers/power/Kconfig
+++ b/drivers/power/Kconfig
@@ -152,6 +152,7 @@ config BATTERY_SBS
 
 config BATTERY_BQ27x00
tristate "BQ27x00 battery driver"
+   depends on I2C
help
  Say Y here to enable support for batteries with BQ27x00 (I2C/HDQ) 
chips.
 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2] gma500:fix build failure for 3.9-rc5

[Xiong Zhou]

From: Xiong Zhou 

Last version of this patch is not clear enough and X86 duplicated.

This patch fixes build failure of v3.9-rc5 and rc6.
When config ACPI_VIDEO as m, DRM_GMA500 as y, here comes the failure.
GMA5/600 needs acpi_video just like nouveau.
And some tab type fix by the way.

Failure message:
drivers/built-in.o: In function `psb_driver_load':
kernel-3.9-rc5/drivers/gpu/drm/gma500/psb_drv.c:340: \
undefined reference to `acpi_video_register'
make: *** [vmlinux] Error 1

Signed-off-by: Xiong Zhou 
---
drivers/gpu/drm/gma500/Kconfig |   13 +
1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/gma500/Kconfig b/drivers/gpu/drm/gma500/Kconfig
index 1188f0f..1f6e2df 100644
--- a/drivers/gpu/drm/gma500/Kconfig
+++ b/drivers/gpu/drm/gma500/Kconfig
@@ -2,10 +2,15 @@ config DRM_GMA500
tristate "Intel GMA5/600 KMS Framebuffer"
depends on DRM && PCI && X86
select FB_CFB_COPYAREA
-select FB_CFB_FILLRECT
-select FB_CFB_IMAGEBLIT
-select DRM_KMS_HELPER
-select DRM_TTM
+   select FB_CFB_FILLRECT
+   select FB_CFB_IMAGEBLIT
+   select DRM_KMS_HELPER
+   select DRM_TTM
+   # GMA500 depends on ACPI_VIDEO when ACPI is enabled, just like i915
+   select ACPI_VIDEO if ACPI
+   select BACKLIGHT_CLASS_DEVICE if ACPI
+   select VIDEO_OUTPUT_CONTROL if ACPI
+   select INPUT if ACPI
help
  Say yes for an experimental 2D KMS framebuffer driver for the
  Intel GMA500 ('Poulsbo') and other Intel IMG based graphics
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] drivers/gpu/drm/gma500:fix build failure for 3.9-rc5

[Xiong Zhou]

On Tue, 9 Apr 2013, Patrik Jakobsson wrote:

> On Tue, Apr 9, 2013 at 8:35 AM, Xiong Zhou  wrote:
> > From: Xiong Zhou 
> >
> > This patch fixes build failure of v3.9-rc5.
> > When config ACPI_VIDEO as m, DRM_GMA500 as y, here comes the failure.
> > gma5/600 needs acpi_video just like nouveau.
> >
> > Failure message:
> > drivers/built-in.o: In function `psb_driver_load':
> > kernel-3.9-rc5/drivers/gpu/drm/gma500/psb_drv.c:340: \
> > undefined reference to `acpi_video_register'
> > make: *** [vmlinux] Error 1
> >
> > Signed-off-by: Xiong Zhou 
> > ---
> > drivers/gpu/drm/gma500/Kconfig |1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/gpu/drm/gma500/Kconfig b/drivers/gpu/drm/gma500/Kconfig
> > index 1188f0f..d64fc45 100644
> > --- a/drivers/gpu/drm/gma500/Kconfig
> > +++ b/drivers/gpu/drm/gma500/Kconfig
> > @@ -6,6 +6,7 @@ config DRM_GMA500
> >  select FB_CFB_IMAGEBLIT
> >  select DRM_KMS_HELPER
> >  select DRM_TTM
> > +select ACPI_VIDEO if ACPI && X86 && BACKLIGHT_CLASS_DEVICE && 
> > VIDEO_OUTPUT_CONTROL && INPUT
> > help
> >   Say yes for an experimental 2D KMS framebuffer driver for the
> >   Intel GMA500 ('Poulsbo') and other Intel IMG based graphics
> > --
> 
> Hi
> 
> Thanks for catching this, but if I can be picky, I'd prefer if you wrote it
> like i915 does. E.g.
> 
>   select ACPI_VIDEO if ACPI
>   select BACKLIGHT_CLASS_DEVICE if ACPI
>   ...
> 
> And you can skip X86 since we already 'depend' on it.
> 
> Thanks
> Patrik
> 

Nice advices, Thanks!


Xiong
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] drivers/gpu/drm/gma500:fix build failure for 3.9-rc5

[Xiong Zhou]

From: Xiong Zhou 

This patch fixes build failure of v3.9-rc5.
When config ACPI_VIDEO as m, DRM_GMA500 as y, here comes the failure.
gma5/600 needs acpi_video just like nouveau.

Failure message:
drivers/built-in.o: In function `psb_driver_load':
kernel-3.9-rc5/drivers/gpu/drm/gma500/psb_drv.c:340: \
undefined reference to `acpi_video_register'
make: *** [vmlinux] Error 1

Signed-off-by: Xiong Zhou 
---
drivers/gpu/drm/gma500/Kconfig |1 +
1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/gma500/Kconfig b/drivers/gpu/drm/gma500/Kconfig
index 1188f0f..d64fc45 100644
--- a/drivers/gpu/drm/gma500/Kconfig
+++ b/drivers/gpu/drm/gma500/Kconfig
@@ -6,6 +6,7 @@ config DRM_GMA500
 select FB_CFB_IMAGEBLIT
 select DRM_KMS_HELPER
 select DRM_TTM
+select ACPI_VIDEO if ACPI && X86 && BACKLIGHT_CLASS_DEVICE && 
VIDEO_OUTPUT_CONTROL && INPUT
help
  Say yes for an experimental 2D KMS framebuffer driver for the
  Intel GMA500 ('Poulsbo') and other Intel IMG based graphics
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] drivers/gpu/drm/gma500:fix build failure for 3.9-rc5

[Xiong Zhou]

From: Xiong Zhou 

This patch fixes build failure of v3.9-rc5.
When config ACPI_VIDEO as m, DRM_GMA500 as y, here comes the failure.
gma5/600 needs acpi_video just like nouveau.

Failure message:
drivers/built-in.o: In function `psb_driver_load':
kernel-3.9-rc5/drivers/gpu/drm/gma500/psb_drv.c:340: \
undefined reference to `acpi_video_register'
make: *** [vmlinux] Error 1

Signed-off-by: Xiong Zhou 
---
drivers/gpu/drm/gma500/Kconfig |1 +
1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/gma500/Kconfig b/drivers/gpu/drm/gma500/Kconfig
index 1188f0f..d64fc45 100644
--- a/drivers/gpu/drm/gma500/Kconfig
+++ b/drivers/gpu/drm/gma500/Kconfig
@@ -6,6 +6,7 @@ config DRM_GMA500
 select FB_CFB_IMAGEBLIT
 select DRM_KMS_HELPER
 select DRM_TTM
+select ACPI_VIDEO if ACPI && X86 && BACKLIGHT_CLASS_DEVICE && 
VIDEO_OUTPUT_CONTROL && INPUT
help
  Say yes for an experimental 2D KMS framebuffer driver for the
  Intel GMA500 ('Poulsbo') and other Intel IMG based graphics
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[patch v2] sound/soc/codecs : fix build failure for next-20130325

[Xiong Zhou]

From: Xiong Zhou 

This patch fixes build failure of next-20130325 (and also next-20130322), 
about sound soc codec modules. 

I try to fix this by moving arrays to the header last time.

Failing message:

  ERROR: "arizona_rate_text" [sound/soc/codecs/snd-soc-wm-adsp.ko] undefined!
  ERROR: "arizona_rate_val" [sound/soc/codecs/snd-soc-wm-adsp.ko] undefined!
  WARNING: modpost: Found 5 section mismatch(es).

These arrays, "arizona_rate_text" and "arizona_rate_val" are defined in 
arizona.c, while having a declaration in arizona.h which is included by 
wm_adsp.c.

When config MFD_ARIZONA_I2C is not choosed, neither is SND_SOC_ARIZONA.
But, if I2C is choosed at the same time, SND_SOC_WM_ADSP is selected.
So this is the problem. SND_SOC_WM_ADSP depends on SND_SOC_ARIZONA. 

After make SND_SOC_WM_ADSP depends on SND_SOC_ARIZONA:

 ERROR: "wm_adsp1_init" [sound/soc/codecs/snd-soc-wm2200.ko] undefined!
 ERROR: "wm_adsp1_event" [sound/soc/codecs/snd-soc-wm2200.ko] undefined!
 ERROR: "wm_adsp_fw_controls" [sound/soc/codecs/snd-soc-wm2200.ko] undefined!

This is the same like above. So make SND_SOC_WM2200 depends on SND_SOC_ARIZONA
too, and I2C.

Signed-off-by: Xiong Zhou 
---
sound/soc/codecs/Kconfig |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
index 18fea10..f38af70 100644
--- a/sound/soc/codecs/Kconfig
+++ b/sound/soc/codecs/Kconfig
@@ -79,7 +79,6 @@ config SND_SOC_ALL_CODECS
select SND_SOC_WM0010 if SPI_MASTER
select SND_SOC_WM1250_EV1 if I2C
select SND_SOC_WM2000 if I2C
-   select SND_SOC_WM2200 if I2C
select SND_SOC_WM5100 if I2C
select SND_SOC_WM5102 if MFD_WM5102
select SND_SOC_WM5110 if MFD_WM5110
@@ -370,6 +369,7 @@ config SND_SOC_WM2000
tristate
 
 config SND_SOC_WM2200
+   depends on SND_SOC_ARIZONA && I2C
tristate
 
 config SND_SOC_WM5100
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch] sound/soc/codec : fix build failure in next-201303225

[Xiong Zhou]

On Mon, 25 Mar 2013, Mark Brown wrote:

> On Mon, Mar 25, 2013 at 07:59:43PM +0800, Xiong Zhou wrote:
> 
> > -const char *arizona_rate_text[ARIZONA_RATE_ENUM_SIZE] = {
> > -   "SYNCCLK rate", "8kHz", "16kHz", "ASYNCCLK rate",
> > -};
> > +extern const char *arizona_rate_text[ARIZONA_RATE_ENUM_SIZE];
> >  EXPORT_SYMBOL_GPL(arizona_rate_text);
> 
> No, this isn't a good fix at all - we're moving the array to the header
> but still exporting it from this file which is not clever at all.  The
> user should be conditional.
> 

Yes, I agree with you much. Do you have some plan with this array? 
The exproting seems not necesary right now, How about just moving 
the array to the header?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[patch] sound/soc/codec : fix build failure in next-201303225

[Xiong Zhou]

From: Xiong Zhou 

This patch fixes build failure of next-20130325 (and also next-20130322), 
about sound soc codec modules, based on previous implementation. 
Failing message:

  MODPOST 2490 modules
  ERROR: "arizona_rate_text" [sound/soc/codecs/snd-soc-wm-adsp.ko] undefined!
  ERROR: "arizona_rate_val" [sound/soc/codecs/snd-soc-wm-adsp.ko] undefined!
  WARNING: modpost: Found 5 section mismatch(es).

Signed-off-by: Xiong Zhou 
---
sound/soc/codecs/arizona.c |8 ++--
sound/soc/codecs/arizona.h |   10 --
2 files changed, 10 insertions(+), 8 deletions(-)

diff --git a/sound/soc/codecs/arizona.c b/sound/soc/codecs/arizona.c
index 26e1579..166db32 100644
--- a/sound/soc/codecs/arizona.c
+++ b/sound/soc/codecs/arizona.c
@@ -433,14 +433,10 @@ EXPORT_SYMBOL_GPL(arizona_mixer_values);
 const DECLARE_TLV_DB_SCALE(arizona_mixer_tlv, -3200, 100, 0);
 EXPORT_SYMBOL_GPL(arizona_mixer_tlv);
 
-const char *arizona_rate_text[ARIZONA_RATE_ENUM_SIZE] = {
-   "SYNCCLK rate", "8kHz", "16kHz", "ASYNCCLK rate",
-};
+extern const char *arizona_rate_text[ARIZONA_RATE_ENUM_SIZE];
 EXPORT_SYMBOL_GPL(arizona_rate_text);
 
-const int arizona_rate_val[ARIZONA_RATE_ENUM_SIZE] = {
-   0, 1, 2, 8,
-};
+extern const int arizona_rate_val[ARIZONA_RATE_ENUM_SIZE];
 EXPORT_SYMBOL_GPL(arizona_rate_val);
 
 
diff --git a/sound/soc/codecs/arizona.h b/sound/soc/codecs/arizona.h
index a754a1c..3e43456 100644
--- a/sound/soc/codecs/arizona.h
+++ b/sound/soc/codecs/arizona.h
@@ -181,8 +181,14 @@ extern int arizona_mixer_values[ARIZONA_NUM_MIXER_INPUTS];
ARIZONA_MIXER_ROUTES(name, name "R")
 
 #define ARIZONA_RATE_ENUM_SIZE 4
-extern const char *arizona_rate_text[ARIZONA_RATE_ENUM_SIZE];
-extern const int arizona_rate_val[ARIZONA_RATE_ENUM_SIZE];
+
+const char *arizona_rate_text[ARIZONA_RATE_ENUM_SIZE] = {
+   "SYNCCLK rate", "8kHz", "16kHz", "ASYNCCLK rate",
+};
+
+const int arizona_rate_val[ARIZONA_RATE_ENUM_SIZE] = {
+   0, 1, 2, 8,
+};
 
 extern const struct soc_enum arizona_isrc_fsl[];
 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/