7:14 p.m.
Greetings,
0day kernel testing robot got the below dmesg and the first bad commit is
https://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git fixes
commit e56b43b971a7c08762fceab330a52b7245041dbc
Author: Al Viro <viro(a)zeniv.linux.org.uk>
AuthorDate: Fri Jan 10 17:17:19 2020 -0500
Commit: Al Viro <viro(a)zeniv.linux.org.uk>
CommitDate: Fri Jan 10 17:43:05 2020 -0500
reimplement path_mountpoint() with less magic
... and get rid of a bunch of bugs in it. Background:
the reason for path_mountpoint() is that umount() really doesn't
want attempts to revalidate the root of what it's trying to umount.
The thing we want to avoid actually happen from complete_walk();
solution was to do something parallel to normal path_lookupat()
and it both went overboard and got the boilerplate subtly
(and not so subtly) wrong.
A better solution is to do pretty much what the normal path_lookupat()
does, but instead of complete_walk() do unlazy_walk(). All it takes
to avoid that ->d_weak_revalidate() call... mountpoint_last() goes
away, along with everything it got wrong, and so does the magic around
LOOKUP_NO_REVAL.
Another source of bugs is that when we traverse mounts at the final
location (and we need to do that - umount . expects to get whatever's
overmounting ., if any, out of the lookup) we really ought to take
care of ->d_manage() - as it is, manual umount of autofs automount
in progress can lead to unpleasant surprises for the daemon. Easily
solved by using handle_lookup_down() instead of follow_mount().
Signed-off-by: Al Viro <viro(a)zeniv.linux.org.uk>
1edc8eb2e9 fs: call fsnotify_sb_delete after evict_inodes
e56b43b971 reimplement path_mountpoint() with less magic
+------------------------------------------+------------+------------+
| | 1edc8eb2e9 | e56b43b971 |
+------------------------------------------+------------+------------+
| boot_successes | 44 | 5 |
| boot_failures | 0 | 12 |
| kernel_BUG_at_fs/namei.c | 0 | 11 |
| invalid_opcode:#[##] | 0 | 12 |
| EIP:unlazy_walk | 0 | 12 |
| Kernel_panic-not_syncing:Fatal_exception | 0 | 12 |
+------------------------------------------+------------+------------+
If you fix the issue, kindly add following tag
Reported-by: kernel test robot <lkp(a)intel.com>
[child2:652] setfsgid16 (139) returned ENOSYS, marking as inactive.
[child2:652] pkey_mprotect (380) returned ENOSYS, marking as inactive.
[child0:643] migrate_pages (294) returned ENOSYS, marking as inactive.
[child1:644] fanotify_mark (339) returned ENOSYS, marking as inactive.
[child2:672] io_destroy (246) returned ENOSYS, marking as inactive.
[ 10.425400] kernel BUG at fs/namei.c:676!
[ 10.426013] invalid opcode: 0000 [#1] PREEMPT
[ 10.426474] CPU: 0 PID: 722 Comm: trinity-c3 Not tainted 5.5.0-rc1-00004-ge56b43b971a7c
#1
[ 10.427348] EIP: unlazy_walk+0x120/0x130
[ 10.427788] Code: 8d b4 26 00 00 00 00 8d 76 00 c7 03 00 00 00 00 c7 43 04 00 00 00 00
e8 3e c7 e7 ff b8 f6 ff ff ff 83 c4 08 5b 5e 5f 5d c3 90 <0f> 0b 8d b6 00 00 00 00
0f 0b 8d b6 00 00 00 00 55 89 e5 83 ec 10
[ 10.429762] EAX: 00000000 EBX: e911fe88 ECX: 00000000 EDX: 00000001
[ 10.430415] ESI: 00000000 EDI: e8fff918 EBP: e911fe64 ESP: e911fe50
[ 10.431070] DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068 EFLAGS: 00010246
[ 10.431768] CR0: 80050033 CR2: 77707718 CR3: 692ef000 CR4: 000006d0
[ 10.432391] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
[ 10.433015] DR6: fffe0ff0 DR7: 00000400
[ 10.433407] Call Trace:
[ 10.433667] path_mountpoint+0x79/0xc0
[ 10.434343] filename_mountpoint+0xa8/0x180
[ 10.434923] user_path_mountpoint_at+0x2a/0x40
[ 10.435549] ksys_umount+0x65/0x510
[ 10.436042] sys_umount+0xe/0x10
[ 10.436495] do_int80_syscall_32+0x8d/0x240
[ 10.437067] entry_INT80_32+0x12b/0x12b
[ 10.437595] EIP: 0x809b132
[ 10.437972] Code: 89 c8 c3 90 8d 74 26 00 85 c0 c7 01 01 00 00 00 75 d8 a1 6c 94 a8 08
eb d1 66 90 66 90 66 90 66 90 66 90 66 90 66 90 90 cd 80 <c3> 8d b6 00 00 00 00 8d
bc 27 00 00 00 00 8b 10 a3 94 94 a8 08 85
[ 10.439958] EAX: ffffffda EBX: 0a51b6c0 ECX: 00000000 EDX: fffffff8
[ 10.440481] ESI: 00800000 EDI: fffffffd EBP: 0000fffd ESP: 7f8469f8
[ 10.441013] DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 007b EFLAGS: 00000212
[ 10.441578] Modules linked in:
[ 10.507683] EIP: unlazy_walk+0x120/0x130
[ 10.508017] Code: 8d b4 26 00 00 00 00 8d 76 00 c7 03 00 00 00 00 c7 43 04 00 00 00 00
e8 3e c7 e7 ff b8 f6 ff ff ff 83 c4 08 5b 5e 5f 5d c3 90 <0f> 0b 8d b6 00 00 00 00
0f 0b 8d b6 00 00 00 00 55 89 e5 83 ec 10
[ 10.533706] EAX: 00000000 EBX: e911fe88 ECX: 00000000 EDX: 00000001
[ 10.537649] ESI: 00000000 EDI: e8fff918 EBP: e911fe64 ESP: e911fe50
[ 10.538509] DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068 EFLAGS: 00010246
[ 10.564618] CR0: 80050033 CR2: 77707718 CR3: 692ef000 CR4: 000006d0
[ 10.565157] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
[ 10.565681] DR6: fffe0ff0 DR7: 00000400
[ 10.566011] Kernel panic - not syncing: Fatal exception
[ 10.566455] Kernel Offset: disabled
# HH:MM RESULT GOOD BAD
GOOD_BUT_DIRTY DIRTY_NOT_BAD
git bisect start f8c1fbea36529c91f6ee9750569b36ab1d26a66b
c79f46a282390e0f5b306007bf7b11a46d529538 --
git bisect bad 908b184fd2525b43f2405219d26e0f41400b9158 # 10:27 B 0 1 18 0
Merge
'linux-review/Milind-Parab/net-macb-fix-for-fixed-link-mode/20200111-060202' into
devel-hourly-2020011115
git bisect bad ce9d04cd2c4b49989e0a97f6b40ddb1aecebb50b # 11:12 B 0 3 19 0
Merge
'linux-review/Cong-Wang/netfilter-fix-a-use-after-free-in-mtype_destroy/20200111-101941'
into devel-hourly-2020011115
git bisect bad a6aaccd584fa2f03560a67b5d706865176f34c4f # 11:32 B 0 9 25 0
Merge 'stm32/stm32-defconfig-for-v5.6' into devel-hourly-2020011115
git bisect bad 75d6788277d3db22869b4a6c923ce2e11496b716 # 11:46 B 0 9 25 0
Merge 'tomoyo-tomoyo-test1/master' into devel-hourly-2020011115
git bisect good d8bd7c0a3859c13fc6faa75c22fc06b517752423 # 13:06 G 11 0 0 0
Merge
'linux-review/Pierre-Louis-Bossart/soundwire-intel-report-slave_ids-for-each-link-to-SOF-driver/20200111-124439'
into devel-hourly-2020011115
git bisect bad 6fc8dfca0952663163b430fdf3e711434d452b24 # 13:21 B 0 9 26 1
Merge 'm68k/m68k-queue' into devel-hourly-2020011115
git bisect bad 9abb2cbefc9a73fe31c8be90eb10f96834ab370c # 13:35 B 0 4 20 0
Merge 'xlnx/zynqmp/dt' into devel-hourly-2020011115
git bisect bad c289246f5b313d88689f178a7f124b4bf8b2ec98 # 14:05 B 0 1 18 0
Merge 'vfs/fixes' into devel-hourly-2020011115
git bisect bad e56b43b971a7c08762fceab330a52b7245041dbc # 14:52 B 0 2 18 0
reimplement path_mountpoint() with less magic
# first bad commit: [e56b43b971a7c08762fceab330a52b7245041dbc] reimplement
path_mountpoint() with less magic
git bisect good 1edc8eb2e93130e36ac74ac9c80913815a57d413 # 15:26 G 31 0 0 0
fs: call fsnotify_sb_delete after evict_inodes
# extra tests with debug options
git bisect bad e56b43b971a7c08762fceab330a52b7245041dbc # 15:51 B 0 6 22 0
reimplement path_mountpoint() with less magic
# extra tests on head commit of vfs/fixes
git bisect bad e56b43b971a7c08762fceab330a52b7245041dbc # 16:11 B 1 12 0 0
reimplement path_mountpoint() with less magic
# bad: [e56b43b971a7c08762fceab330a52b7245041dbc] reimplement path_mountpoint() with less
magic
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/hyperkitty/list/lkp@lists.01.org Intel Corporation
11:45 p.m.
New subject: e56b43b971 ("reimplement path_mountpoint() with less magic"): kernel BUG at fs/namei.c:676!
On Tue, Jan 28, 2020 at 04:14:09PM +0800, kernel test robot wrote:
Greetings,
0day kernel testing robot got the below dmesg and the first bad commit is
https://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git fixes
commit e56b43b971a7c08762fceab330a52b7245041dbc
Author: Al Viro <viro(a)zeniv.linux.org.uk>
AuthorDate: Fri Jan 10 17:17:19 2020 -0500
Commit: Al Viro <viro(a)zeniv.linux.org.uk>
CommitDate: Fri Jan 10 17:43:05 2020 -0500
reimplement path_mountpoint() with less magic
*blink*
Which tree are you looking at? The one you've mentioned has a version
of that commit with fix folded in, and had it there for nearly two weeks -
replacement is
commit c64cd6e34ea340adbb2a0a2f99cc884b96dcdca5
Author: Al Viro <viro(a)zeniv.linux.org.uk>
AuthorDate: Fri Jan 10 17:17:19 2020 -0500
Commit: Al Viro <viro(a)zeniv.linux.org.uk>
CommitDate: Wed Jan 15 01:36:06 2020 -0500
reimplement path_mountpoint() with less magic
Moreover, that fixed commit has been pulled into mainline since then, so
whatever tree this has come from would be impossible to merge without
a mainline conflict...
Please, explain.
12:09 a.m.
New subject: e56b43b971 ("reimplement path_mountpoint() with less magic"): kernel BUG at fs/namei.c:676!
Subject: Re: e56b43b971 ("reimplement path_mountpoint() with
less magic"):
kernel BUG at fs/namei.c:676!
On Tue, Jan 28, 2020 at 04:14:09PM +0800, kernel test robot wrote:
> Greetings,
>
> 0day kernel testing robot got the below dmesg and the first bad commit is
>
> https://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git fixes
>
> commit e56b43b971a7c08762fceab330a52b7245041dbc
> Author: Al Viro <viro(a)zeniv.linux.org.uk>
> AuthorDate: Fri Jan 10 17:17:19 2020 -0500
> Commit: Al Viro <viro(a)zeniv.linux.org.uk>
> CommitDate: Fri Jan 10 17:43:05 2020 -0500
>
> reimplement path_mountpoint() with less magic
*blink*
Which tree are you looking at? The one you've mentioned has a version
the
testing was conducted on "fixed" branch, which has below commits
commit d0cb50185ae942b03c4327be322055d622dc79f6
Author: Al Viro <viro(a)zeniv.linux.org.uk>
Date: Sun Jan 26 09:29:34 2020 -0500
do_last(): fetch directory ->i_mode and ->i_uid before it's too late
commit 508c8772760d4ef9c1a044519b564710c3684fc5
Author: Al Viro <viro(a)zeniv.linux.org.uk>
Date: Tue Jan 14 22:09:57 2020 -0500
fix autofs regression caused by follow_managed() changes
commit c64cd6e34ea340adbb2a0a2f99cc884b96dcdca5
Author: Al Viro <viro(a)zeniv.linux.org.uk>
Date: Fri Jan 10 17:17:19 2020 -0500
reimplement path_mountpoint() with less magic
of that commit with fix folded in, and had it there for nearly two
weeks -
replacement is
thanks, this is a problem we will look into, why it reports out old
commit.
commit c64cd6e34ea340adbb2a0a2f99cc884b96dcdca5
Author: Al Viro <viro(a)zeniv.linux.org.uk>
AuthorDate: Fri Jan 10 17:17:19 2020 -0500
Commit: Al Viro <viro(a)zeniv.linux.org.uk>
CommitDate: Wed Jan 15 01:36:06 2020 -0500
reimplement path_mountpoint() with less magic
Moreover, that fixed commit has been pulled into mainline since then, so
Typically
if the head of mainline works without the same issue, we should not report it.
Kindly ignore this report. We will also check the bisection detail to understand
what can possibly be wrong here.
> whatever tree this has come from would be impossible to merge without
> a mainline conflict...
>
> Please, explain.
12:25 a.m.
New subject: e56b43b971 ("reimplement path_mountpoint() with less magic"): kernel BUG at fs/namei.c:676!
On Tue, Jan 28, 2020 at 01:09:01PM +0000, Li, Philip wrote:
> Subject: Re: e56b43b971 ("reimplement path_mountpoint()
with less magic"):
> kernel BUG at fs/namei.c:676!
>
> On Tue, Jan 28, 2020 at 04:14:09PM +0800, kernel test robot wrote:
> > Greetings,
> >
> > 0day kernel testing robot got the below dmesg and the first bad commit is
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git fixes
> >
> > commit e56b43b971a7c08762fceab330a52b7245041dbc
> > Author: Al Viro <viro(a)zeniv.linux.org.uk>
> > AuthorDate: Fri Jan 10 17:17:19 2020 -0500
> > Commit: Al Viro <viro(a)zeniv.linux.org.uk>
> > CommitDate: Fri Jan 10 17:43:05 2020 -0500
> >
> > reimplement path_mountpoint() with less magic
>
> *blink*
>
> Which tree are you looking at? The one you've mentioned has a version
the testing was conducted on "fixed" branch, which has below commits
commit d0cb50185ae942b03c4327be322055d622dc79f6
Author: Al Viro <viro(a)zeniv.linux.org.uk>
Date: Sun Jan 26 09:29:34 2020 -0500
do_last(): fetch directory ->i_mode and ->i_uid before it's too late
commit 508c8772760d4ef9c1a044519b564710c3684fc5
Author: Al Viro <viro(a)zeniv.linux.org.uk>
Date: Tue Jan 14 22:09:57 2020 -0500
fix autofs regression caused by follow_managed() changes
commit c64cd6e34ea340adbb2a0a2f99cc884b96dcdca5
Author: Al Viro <viro(a)zeniv.linux.org.uk>
Date: Fri Jan 10 17:17:19 2020 -0500
reimplement path_mountpoint() with less magic
> of that commit with fix folded in, and had it there for nearly two weeks -
> replacement is
thanks, this is a problem we will look into, why it reports out old commit.
> commit c64cd6e34ea340adbb2a0a2f99cc884b96dcdca5
> Author: Al Viro <viro(a)zeniv.linux.org.uk>
> AuthorDate: Fri Jan 10 17:17:19 2020 -0500
> Commit: Al Viro <viro(a)zeniv.linux.org.uk>
> CommitDate: Wed Jan 15 01:36:06 2020 -0500
>
> reimplement path_mountpoint() with less magic
>
> Moreover, that fixed commit has been pulled into mainline since then, so
Typically if the head of mainline works without the same issue, we should not report it.
Kindly ignore this report. We will also check the bisection detail to understand
what can possibly be wrong here.
FWIW, there are 4 branches in vfs.git with names similar to that:
fixes fixes-2 fixes-old fixes1
The last two do not contain anything of that sort (#fixes-old is from May 2018
and #fixes1 - Nov 2019) and as for the rest...
; git show vfs/fixes^^|head -5
commit c64cd6e34ea340adbb2a0a2f99cc884b96dcdca5
Author: Al Viro <viro(a)zeniv.linux.org.uk>
Date: Fri Jan 10 17:17:19 2020 -0500
reimplement path_mountpoint() with less magic
; git show vfs/fixes-2^^^^|head -5
commit c64cd6e34ea340adbb2a0a2f99cc884b96dcdca5
Author: Al Viro <viro(a)zeniv.linux.org.uk>
Date: Fri Jan 10 17:17:19 2020 -0500
reimplement path_mountpoint() with less magic
;
IOW, both contain the replacement and had it there since Jan 15, when oops
had been reported (very shortly after linux-next had picked a broken
variant) and fixed... So either it's started testing that tree two
weeks ago and hadn't caught anything until now, or you have a seriously
out-of-date mirror...
FWIW, oops is correctly bisected and absolutely recognizable - if you
check the diff between broken and fixed variants of that commit,
you'll see
- if (!err)
+ if (!err && (nd->flags & LOOKUP_RCU))
err = unlazy_walk(nd);
in path_mountpoint(), i.e. prevention of unlazy_walk() call in
non-RCU mode, which is precisely what the BUG_ON() in unlazy_walk()
is supposed to catch. So the only question had been "where has
it managed to run into that version of commit?" Well, should be
"where and when", I guess...
12:30 a.m.
New subject: e56b43b971 ("reimplement path_mountpoint() with less magic"): kernel BUG at fs/namei.c:676!
> > >
> > > commit e56b43b971a7c08762fceab330a52b7245041dbc
> > > Author: Al Viro <viro(a)zeniv.linux.org.uk>
> > > AuthorDate: Fri Jan 10 17:17:19 2020 -0500
> > > Commit: Al Viro <viro(a)zeniv.linux.org.uk>
> > > CommitDate: Fri Jan 10 17:43:05 2020 -0500
> > >
> > > reimplement path_mountpoint() with less magic
> >
> > *blink*
> >
> > Which tree are you looking at? The one you've mentioned has a version
> the testing was conducted on "fixed" branch, which has below commits
thanks for the detail information below, we will continue improving the testing.
Correct my early typo here, the test is on "fixes" branch not "fixed"
branch.
> >
> > commit d0cb50185ae942b03c4327be322055d622dc79f6
> > Author: Al Viro <viro(a)zeniv.linux.org.uk>
> > Date: Sun Jan 26 09:29:34 2020 -0500
> >
> > do_last(): fetch directory ->i_mode and ->i_uid before it's too
late
> >
> > commit 508c8772760d4ef9c1a044519b564710c3684fc5
> > Author: Al Viro <viro(a)zeniv.linux.org.uk>
> > Date: Tue Jan 14 22:09:57 2020 -0500
> >
> > fix autofs regression caused by follow_managed() changes
> >
> > commit c64cd6e34ea340adbb2a0a2f99cc884b96dcdca5
> > Author: Al Viro <viro(a)zeniv.linux.org.uk>
> > Date: Fri Jan 10 17:17:19 2020 -0500
> >
> > reimplement path_mountpoint() with less magic
> >
> > > of that commit with fix folded in, and had it there for nearly two weeks -
> > > replacement is
> > thanks, this is a problem we will look into, why it reports out old commit.
> >
> > > commit c64cd6e34ea340adbb2a0a2f99cc884b96dcdca5
> > > Author: Al Viro <viro(a)zeniv.linux.org.uk>
> > > AuthorDate: Fri Jan 10 17:17:19 2020 -0500
> > > Commit: Al Viro <viro(a)zeniv.linux.org.uk>
> > > CommitDate: Wed Jan 15 01:36:06 2020 -0500
> > >
> > > reimplement path_mountpoint() with less magic
> > >
> > > Moreover, that fixed commit has been pulled into mainline since then, so
> > Typically if the head of mainline works without the same issue, we should not
> report it.
> > Kindly ignore this report. We will also check the bisection detail to
understand
> > what can possibly be wrong here.
>
> FWIW, there are 4 branches in vfs.git with names similar to that:
> fixes fixes-2 fixes-old fixes1
> The last two do not contain anything of that sort (#fixes-old is from May 2018
> and #fixes1 - Nov 2019) and as for the rest...
> ; git show vfs/fixes^^|head -5
> commit c64cd6e34ea340adbb2a0a2f99cc884b96dcdca5
> Author: Al Viro <viro(a)zeniv.linux.org.uk>
> Date: Fri Jan 10 17:17:19 2020 -0500
>
> reimplement path_mountpoint() with less magic
> ; git show vfs/fixes-2^^^^|head -5
> commit c64cd6e34ea340adbb2a0a2f99cc884b96dcdca5
> Author: Al Viro <viro(a)zeniv.linux.org.uk>
> Date: Fri Jan 10 17:17:19 2020 -0500
>
> reimplement path_mountpoint() with less magic
> ;
>
> IOW, both contain the replacement and had it there since Jan 15, when oops
> had been reported (very shortly after linux-next had picked a broken
> variant) and fixed... So either it's started testing that tree two
> weeks ago and hadn't caught anything until now, or you have a seriously
> out-of-date mirror...
>
> FWIW, oops is correctly bisected and absolutely recognizable - if you
> check the diff between broken and fixed variants of that commit,
> you'll see
> - if (!err)
> + if (!err && (nd->flags & LOOKUP_RCU))
> err = unlazy_walk(nd);
> in path_mountpoint(), i.e. prevention of unlazy_walk() call in
> non-RCU mode, which is precisely what the BUG_ON() in unlazy_walk()
> is supposed to catch. So the only question had been "where has
> it managed to run into that version of commit?" Well, should be
> "where and when", I guess...
964
days inactive
964
days old
4 comments
3 participants
participants (3)
-
Al Viro -
kernel test robot -
Li, Philip