2016-03-14 00:48:40

by kernel test robot

[permalink] [raw]
Subject: [lkp] [namei] fda89e6574: kernel BUG at fs/namei.c:679!

FYI, we noticed the below changes on

https://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git work.lookups
commit fda89e65743179d09e55bc6c265d06fa5efa8803 ("namei: untanlge lookup_fast()")


+------------------------------------------+------------+------------+
| | 6c51e513a3 | fda89e6574 |
+------------------------------------------+------------+------------+
| boot_successes | 0 | 1 |
| boot_failures | 1 | 4 |
| invoked_oom-killer:gfp_mask=0x | 1 | 1 |
| Mem-Info | 1 | 1 |
| Out_of_memory:Kill_process | 1 | 1 |
| kernel_BUG_at_fs/namei.c | 0 | 3 |
| invalid_opcode:#[##]SMP | 0 | 3 |
| RIP:unlazy_walk | 0 | 3 |
| Kernel_panic-not_syncing:Fatal_exception | 0 | 3 |
| backtrace:SYSC_newfstatat | 0 | 3 |
| backtrace:SyS_newfstatat | 0 | 3 |
+------------------------------------------+------------+------------+



[ 19.082726] gre: GRE over IPv4 demultiplexor driver
[ 19.084132] PPTP driver version 0.8.5
[ 19.622035] ------------[ cut here ]------------
[ 19.623051] kernel BUG at fs/namei.c:679!
[ 19.624142] invalid opcode: 0000 [#1] SMP
[ 19.625196] Modules linked in: pptp gre nfnetlink scsi_transport_iscsi pppoe inet_diag crypto_user sctp vmw_vsock_vmci_transport vsock vmw_vmci ieee802154_socket ieee802154 pppox ppp_generic slhc atm rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver sg sr_mod cdrom ata_generic pata_acpi snd_pcm ppdev snd_timer snd soundcore pcspkr serio_raw ata_piix parport_pc parport floppy acpi_cpufreq libata i2c_piix4
[ 19.634478] CPU: 2 PID: 471 Comm: trinity-main Not tainted 4.5.0-rc4-00017-gfda89e6 #1
[ 19.636222] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Debian-1.8.2-1 04/01/2014
[ 19.638068] task: ffff88007e49a440 ti: ffff88007ecfc000 task.ti: ffff88007ecfc000
[ 19.639728] RIP: 0010:[<ffffffff811fc7c1>] [<ffffffff811fc7c1>] unlazy_walk+0x151/0x170
[ 19.641705] RSP: 0018:ffff88007ecffc30 EFLAGS: 00010246
[ 19.643337] RAX: 0000000000001000 RBX: ffff88007ecffd40 RCX: ffff88007ecffcc4
[ 19.644713] RDX: 0000000000000002 RSI: ffff8800a486a240 RDI: ffff88007ecffd40
[ 19.646082] RBP: ffff88007ecffc58 R08: 0000000000000001 R09: 0000000000200000
[ 19.647451] R10: ffffffffffffffff R11: 0000000b5ae0aec3 R12: ffff8800a486a240
[ 19.648820] R13: ffff8800a486a480 R14: ffff88007ecffcc8 R15: ffff88013a53aaa0
[ 19.650323] FS: 00007f1ba2185700(0000) GS:ffff88013fd00000(0000) knlGS:0000000000000000
[ 19.652545] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 19.654211] CR2: 000000000239b000 CR3: 000000007f654000 CR4: 00000000000006e0
[ 19.656138] Stack:
[ 19.657186] ffff88007ecffd40 ffff8800a486a240 ffff88007ecffcd0 ffff88007ecffcc8
[ 19.660359] ffff88013a53aaa0 ffff88007ecffcb0 ffffffff811fc937 ffff88007ecffcc4
[ 19.663448] ffff88007ecffcc4 ffff88007ecffcc4 0000000280808080 ffff88007ecffd40
[ 19.666064] Call Trace:
[ 19.666835] [<ffffffff811fc937>] lookup_fast+0x157/0x330
[ 19.667898] [<ffffffff811fd3aa>] walk_component+0x3a/0x410
[ 19.668968] [<ffffffff811fe1fd>] path_lookupat+0x5d/0x110
[ 19.670047] [<ffffffff8120176e>] filename_lookup+0x9e/0x150
[ 19.671163] [<ffffffff8109d479>] ? __might_sleep+0x49/0x80
[ 19.672276] [<ffffffff812013b6>] ? getname_flags+0x56/0x1f0
[ 19.673370] [<ffffffff811ce84e>] ? kmem_cache_alloc+0x18e/0x1f0
[ 19.674545] [<ffffffff812013b6>] ? getname_flags+0x56/0x1f0
[ 19.675665] [<ffffffff812013d2>] ? getname_flags+0x72/0x1f0
[ 19.676755] [<ffffffff812018d6>] user_path_at_empty+0x36/0x40
[ 19.677859] [<ffffffff811f6a33>] vfs_fstatat+0x53/0xa0
[ 19.678902] [<ffffffff811f6f55>] SYSC_newfstatat+0x15/0x30
[ 19.679998] [<ffffffff811f716e>] SyS_newfstatat+0xe/0x10
[ 19.681087] [<ffffffff818daf6e>] entry_SYSCALL_64_fastpath+0x12/0x6d
[ 19.682253] Code: 00 41 8b 7e 40 49 8d 76 20 e8 6c fe ff ff 84 c0 75 ba 48 89 df 65 ff 0d a6 f5 e0 7e e8 69 cb 00 00 b8 f6 ff ff ff e9 53 ff ff ff <0f> 0b 48 89 df 65 ff 0d 8b f5 e0 7e e8 4e cb 00 00 e9 29 ff ff
[ 19.690108] RIP [<ffffffff811fc7c1>] unlazy_walk+0x151/0x170
[ 19.691269] RSP <ffff88007ecffc30>
[ 19.692149] ---[ end trace 563d316f4eb96ab1 ]---
[ 19.693134] Kernel panic - not syncing: Fatal exception


To reproduce:

git clone git://git.kernel.org/pub/scm/linux/kernel/git/wfg/lkp-tests.git
cd lkp-tests
bin/lkp install job.yaml # job file is attached in this email
bin/lkp run job.yaml



Thanks,
Kernel Test Robot


Attachments:
(No filename) (4.75 kB)
config-4.5.0-rc4-00017-gfda89e6 (142.01 kB)
dmesg.xz (13.39 kB)
job.yaml (2.68 kB)
Download all attachments

2016-03-14 00:57:20

by Al Viro

[permalink] [raw]
Subject: Re: [lkp] [namei] fda89e6574: kernel BUG at fs/namei.c:679!

On Mon, Mar 14, 2016 at 08:48:26AM +0800, kernel test robot wrote:
> FYI, we noticed the below changes on
>
> https://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git work.lookups
> commit fda89e65743179d09e55bc6c265d06fa5efa8803 ("namei: untanlge lookup_fast()")

Could you check if the diff below fixes it?

diff --git a/fs/namei.c b/fs/namei.c
index 35b10fa..428a34f 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -1563,6 +1563,7 @@ static int lookup_fast(struct nameidata *nd,
dput(dentry);
return status;
}
+ goto l;
}
}
/*
@@ -1590,6 +1591,7 @@ static int lookup_fast(struct nameidata *nd,
return status;
}
}
+l:
if (unlikely(d_is_negative(dentry))) {
dput(dentry);
return -ENOENT;

2016-03-14 03:10:12

by Al Viro

[permalink] [raw]
Subject: Re: [lkp] [namei] fda89e6574: kernel BUG at fs/namei.c:679!

On Mon, Mar 14, 2016 at 08:48:26AM +0800, kernel test robot wrote:
> FYI, we noticed the below changes on
>
> https://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git work.lookups
> commit fda89e65743179d09e55bc6c265d06fa5efa8803 ("namei: untanlge lookup_fast()")

Unfortunately, while with my normal .config it reliably triggers an oops
in x86_pmu_enable() (with or without those patches), yours triggers nothing
but a pile of OOMs. How much RAM do you give those suckers? I'm _not_
testing those on bare hardware, obviously - it's KVM image.

FWIW, see below for hopefully cleaner fix (will fold once I manage to trigger
the damn thing and verify that fix indeed fixes). It's on top of offending
commit. Folks, could you please check if it fixes that crap on your setup?

diff --git a/fs/namei.c b/fs/namei.c
index 7a5f79f..d721821 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -1519,6 +1519,7 @@ static int lookup_fast(struct nameidata *nd,
struct vfsmount *mnt = nd->path.mnt;
struct dentry *dentry, *parent = nd->path.dentry;
int err;
+ int status = 1;

/*
* Rename seqlock is not required here because in the off chance
@@ -1555,54 +1556,45 @@ static int lookup_fast(struct nameidata *nd,
return -ECHILD;

*seqp = seq;
- if (unlikely(dentry->d_flags & DCACHE_OP_REVALIDATE)) {
- int status = d_revalidate(dentry, nd->flags);
- if (unlikely(status <= 0)) {
- if (unlazy_walk(nd, dentry, seq))
- return -ECHILD;
- if (status == -ECHILD)
- status = d_revalidate(dentry, nd->flags);
- if (status <= 0) {
- if (!status) {
- d_invalidate(dentry);
- status = 1;
- }
- dput(dentry);
- return status;
- }
- }
+ if (unlikely(dentry->d_flags & DCACHE_OP_REVALIDATE))
+ status = d_revalidate(dentry, nd->flags);
+ if (unlikely(status <= 0)) {
+ if (unlazy_walk(nd, dentry, seq))
+ return -ECHILD;
+ if (status == -ECHILD)
+ status = d_revalidate(dentry, nd->flags);
+ } else {
+ /*
+ * Note: do negative dentry check after revalidation in
+ * case that drops it.
+ */
+ if (unlikely(negative))
+ return -ENOENT;
+ path->mnt = mnt;
+ path->dentry = dentry;
+ if (likely(__follow_mount_rcu(nd, path, inode, seqp)))
+ return 0;
+ if (unlazy_walk(nd, dentry, seq))
+ return -ECHILD;
}
- /*
- * Note: do negative dentry check after revalidation in
- * case that drops it.
- */
- if (unlikely(negative))
- return -ENOENT;
- path->mnt = mnt;
- path->dentry = dentry;
- if (likely(__follow_mount_rcu(nd, path, inode, seqp)))
- return 0;
- if (unlazy_walk(nd, dentry, seq))
- return -ECHILD;
} else {
dentry = __d_lookup(parent, &nd->last);
if (unlikely(!dentry))
return 1;
- if (unlikely(dentry->d_flags & DCACHE_OP_REVALIDATE)) {
- int status = d_revalidate(dentry, nd->flags);
- if (unlikely(status <= 0)) {
- if (!status) {
- d_invalidate(dentry);
- status = 1;
- }
- dput(dentry);
- return status;
- }
- }
- if (unlikely(d_is_negative(dentry))) {
- dput(dentry);
- return -ENOENT;
+ if (unlikely(dentry->d_flags & DCACHE_OP_REVALIDATE))
+ status = d_revalidate(dentry, nd->flags);
+ }
+ if (unlikely(status <= 0)) {
+ if (!status) {
+ d_invalidate(dentry);
+ status = 1;
}
+ dput(dentry);
+ return status;
+ }
+ if (unlikely(d_is_negative(dentry))) {
+ dput(dentry);
+ return -ENOENT;
}

path->mnt = mnt;

2016-03-14 05:30:50

by Huang, Ying

[permalink] [raw]
Subject: Re: [LKP] [lkp] [namei] fda89e6574: kernel BUG at fs/namei.c:679!

Al Viro <[email protected]> writes:

> On Mon, Mar 14, 2016 at 08:48:26AM +0800, kernel test robot wrote:
>> FYI, we noticed the below changes on
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git work.lookups
>> commit fda89e65743179d09e55bc6c265d06fa5efa8803 ("namei: untanlge lookup_fast()")
>
> Unfortunately, while with my normal .config it reliably triggers an oops
> in x86_pmu_enable() (with or without those patches), yours triggers nothing
> but a pile of OOMs. How much RAM do you give those suckers? I'm _not_
> testing those on bare hardware, obviously - it's KVM image.

qemu-system-x86_64 -enable-kvm -cpu qemu64,+ssse3 -kernel /pkg/linux/x86_64-rhel/gcc-4.9/fda89e65743179d09e55bc6c265d06fa5efa8803/vmlinuz-4.5.0-rc4-00017-gfda89e6 -append 'root=/dev/ram0 user=lkp job=/lkp/scheduled/vm-kbuild-4G-3/bisect_trinity-300s-debian-x86_64-2015-02-07.cgz-x86_64-rhel-fda89e65743179d09e55bc6c265d06fa5efa8803-20160312-104797-ow7uw0-0.yaml ARCH=x86_64 kconfig=x86_64-rhel branch=linux-devel/devel-catchup-201603120257 commit=fda89e65743179d09e55bc6c265d06fa5efa8803 BOOT_IMAGE=/pkg/linux/x86_64-rhel/gcc-4.9/fda89e65743179d09e55bc6c265d06fa5efa8803/vmlinuz-4.5.0-rc4-00017-gfda89e6 max_uptime=1500 RESULT_ROOT=/result/trinity/300s/vm-kbuild-4G/debian-x86_64-2015-02-07.cgz/x86_64-rhel/gcc-4.9/fda89e65743179d09e55bc6c265d06fa5efa8803/0 LKP_SERVER=inn earlyprintk=ttyS0,115200 systemd.log_level=err debug apic=debug sysrq_always_enabled rcupdate.rcu_cpu_stall_timeout=100 panic=-1 softlockup_panic=1 nmi_watchdog=panic oops=panic load_ramdisk=2 prompt_ramdisk=0 console=ttyS0,115200 console=tty0 vga=normal rw ip=::::vm-kbuild-4G-3::dhcp' -initrd /fs/sdg1/initrd-vm-kbuild-4G-3 -m 4096 -smp 4 -device e1000,netdev=net0 -netdev user,id=net0,hostfwd=tcp::23034-:22 -boot order=nc -no-reboot -watchdog i6300esb -rtc base=localtime -drive file=/fs/sdg1/disk0-vm-kbuild-4G-3,media=disk,if=virtio -drive file=/fs/sdg1/disk1-vm-kbuild-4G-3,media=disk,if=virtio -drive file=/fs/sdg1/disk2-vm-kbuild-4G-3,media=disk,if=virtio -drive file=/fs/sdg1/disk3-vm-kbuild-4G-3,media=disk,if=virtio -drive file=/fs/sdg1/disk4-vm-kbuild-4G-3,media=disk,if=virtio -drive file=/fs/sdg1/disk5-vm-kbuild-4G-3,media=disk,if=virtio -drive file=/fs/sdg1/disk6-vm-kbuild-4G-3,media=disk,if=virtio -pidfile /dev/shm/kboot/pid-vm-kbuild-4G-3 -serial file:/dev/shm/kboot/serial-vm-kbuild-4G-3 -daemonize -display none -monitor null

This is the qemu command line we used for testing.

Best Regards,
Huang, Ying

> FWIW, see below for hopefully cleaner fix (will fold once I manage to trigger
> the damn thing and verify that fix indeed fixes). It's on top of offending
> commit. Folks, could you please check if it fixes that crap on your setup?
>
> diff --git a/fs/namei.c b/fs/namei.c
> index 7a5f79f..d721821 100644
> --- a/fs/namei.c
> +++ b/fs/namei.c
> @@ -1519,6 +1519,7 @@ static int lookup_fast(struct nameidata *nd,
> struct vfsmount *mnt = nd->path.mnt;
> struct dentry *dentry, *parent = nd->path.dentry;
> int err;
> + int status = 1;
>
> /*
> * Rename seqlock is not required here because in the off chance
> @@ -1555,54 +1556,45 @@ static int lookup_fast(struct nameidata *nd,
> return -ECHILD;
>
> *seqp = seq;
> - if (unlikely(dentry->d_flags & DCACHE_OP_REVALIDATE)) {
> - int status = d_revalidate(dentry, nd->flags);
> - if (unlikely(status <= 0)) {
> - if (unlazy_walk(nd, dentry, seq))
> - return -ECHILD;
> - if (status == -ECHILD)
> - status = d_revalidate(dentry, nd->flags);
> - if (status <= 0) {
> - if (!status) {
> - d_invalidate(dentry);
> - status = 1;
> - }
> - dput(dentry);
> - return status;
> - }
> - }
> + if (unlikely(dentry->d_flags & DCACHE_OP_REVALIDATE))
> + status = d_revalidate(dentry, nd->flags);
> + if (unlikely(status <= 0)) {
> + if (unlazy_walk(nd, dentry, seq))
> + return -ECHILD;
> + if (status == -ECHILD)
> + status = d_revalidate(dentry, nd->flags);
> + } else {
> + /*
> + * Note: do negative dentry check after revalidation in
> + * case that drops it.
> + */
> + if (unlikely(negative))
> + return -ENOENT;
> + path->mnt = mnt;
> + path->dentry = dentry;
> + if (likely(__follow_mount_rcu(nd, path, inode, seqp)))
> + return 0;
> + if (unlazy_walk(nd, dentry, seq))
> + return -ECHILD;
> }
> - /*
> - * Note: do negative dentry check after revalidation in
> - * case that drops it.
> - */
> - if (unlikely(negative))
> - return -ENOENT;
> - path->mnt = mnt;
> - path->dentry = dentry;
> - if (likely(__follow_mount_rcu(nd, path, inode, seqp)))
> - return 0;
> - if (unlazy_walk(nd, dentry, seq))
> - return -ECHILD;
> } else {
> dentry = __d_lookup(parent, &nd->last);
> if (unlikely(!dentry))
> return 1;
> - if (unlikely(dentry->d_flags & DCACHE_OP_REVALIDATE)) {
> - int status = d_revalidate(dentry, nd->flags);
> - if (unlikely(status <= 0)) {
> - if (!status) {
> - d_invalidate(dentry);
> - status = 1;
> - }
> - dput(dentry);
> - return status;
> - }
> - }
> - if (unlikely(d_is_negative(dentry))) {
> - dput(dentry);
> - return -ENOENT;
> + if (unlikely(dentry->d_flags & DCACHE_OP_REVALIDATE))
> + status = d_revalidate(dentry, nd->flags);
> + }
> + if (unlikely(status <= 0)) {
> + if (!status) {
> + d_invalidate(dentry);
> + status = 1;
> }
> + dput(dentry);
> + return status;
> + }
> + if (unlikely(d_is_negative(dentry))) {
> + dput(dentry);
> + return -ENOENT;
> }
>
> path->mnt = mnt;
> _______________________________________________
> LKP mailing list
> [email protected]
> https://lists.01.org/mailman/listinfo/lkp