Re: "fs/namei.c: keep track of nd->root refcount status" causes boot panic
On Thu, Sep 05, 2019 at 02:43:12PM +0530, Naresh Kamboju wrote:
> Hi Christoph and Al Viro,
>
> Linux next 20190904 boot PASS now.
> May i know which patch fixed this problem ?
commit 84a2bd39405ffd5fa6d6d77e408c5b9210da98de
Author: Al Viro
Date: Tue Jul 16 21:20:17 2019 -0400
fs/namei.c: keep track of nd->root refcount status
And I'm not going to abstain from folding the trivial fix
(LOOKUP_ROOT_GRABBED had been given the same value as LOOKUP_EMPTY)
into the commit. Sorry. I don't know how to tell CI systems out
there about cases like that ("earlier version of this commit used
to have a bug, fix folded in"). Something like
Supersedes:
might or might not be useful for tracking; not sure.
Re: "fs/namei.c: keep track of nd->root refcount status" causes boot panic
On Tue, Sep 03, 2019 at 06:56:10PM +0100, Al Viro wrote: > On Tue, Sep 03, 2019 at 08:39:30AM -0700, Christoph Hellwig wrote: > > > > There's much nastier situation than "new upstream kernel released, > > > need to rebuild" - it's bisect in mainline trying to locate something... > > > > I really don't get the point. And it's not like we've card about > > this anywhere else. And jumping wildly around with the numeric values > > for constants will lead to bugs like the one you added and fixed again > > and again. > > The thing is, there are several groups - it's not as if all additions > were guaranteed to be at the end. So either we play with renumbering > again and again, or we are back to the square one... > > Is there any common trick that would allow to verify the lack of duplicates > at the build time? What about: static_assert( (LOOKUP_FOLLOW^LOOKUP_DIRECTORY^LOOKUP_AUTOMOUNT^LOOKUP_EMPTY^LOOKUP_DOWN^ LOOKUP_REVAL^LOOKUP_RCU^ LOOKUP_OPEN^LOOKUP_CREATE^LOOKUP_EXCL^LOOKUP_RENAME_TARGET^ LOOKUP_PARENT^LOOKUP_NO_REVAL^LOOKUP_JUMPED^LOOKUP_ROOT^LOOKUP_ROOT_GRABBED) == (LOOKUP_FOLLOW|LOOKUP_DIRECTORY|LOOKUP_AUTOMOUNT|LOOKUP_EMPTY|LOOKUP_DOWN| LOOKUP_REVAL|LOOKUP_RCU| LOOKUP_OPEN|LOOKUP_CREATE|LOOKUP_EXCL|LOOKUP_RENAME_TARGET| LOOKUP_PARENT|LOOKUP_NO_REVAL|LOOKUP_JUMPED|LOOKUP_ROOT|LOOKUP_ROOT_GRABBED) , "duplicated LOOKUP_* constant"); ? - Kevin
Re: "fs/namei.c: keep track of nd->root refcount status" causes boot panic
Hi Christoph and Al Viro, Linux next 20190904 boot PASS now. May i know which patch fixed this problem ? - Naresh
Re: "fs/namei.c: keep track of nd->root refcount status" causes boot panic
On Tue, Sep 03, 2019 at 06:56:10PM +0100, Al Viro wrote:
> On Tue, Sep 03, 2019 at 08:39:30AM -0700, Christoph Hellwig wrote:
>
> > > There's much nastier situation than "new upstream kernel released,
> > > need to rebuild" - it's bisect in mainline trying to locate something...
> >
> > I really don't get the point. And it's not like we've card about
> > this anywhere else. And jumping wildly around with the numeric values
> > for constants will lead to bugs like the one you added and fixed again
> > and again.
>
> The thing is, there are several groups - it's not as if all additions
> were guaranteed to be at the end. So either we play with renumbering
> again and again, or we are back to the square one...
>
> Is there any common trick that would allow to verify the lack of duplicates
> at the build time?
>
> Or we can reorder the list by constant value, with no grouping visible
> anywhere...
Here is what I'd do. No validation of duplicates, but the 1 << bit
notation makes them very easy to spot:
diff --git a/include/linux/namei.h b/include/linux/namei.h
index 397a08ade6a2..a9536f90936c 100644
--- a/include/linux/namei.h
+++ b/include/linux/namei.h
@@ -16,28 +16,47 @@ enum { MAX_NESTED_LINKS = 8 };
*/
enum {LAST_NORM, LAST_ROOT, LAST_DOT, LAST_DOTDOT, LAST_BIND};
-/* pathwalk mode */
-#define LOOKUP_FOLLOW 0x0001 /* follow links at the end */
-#define LOOKUP_DIRECTORY 0x0002 /* require a directory */
-#define LOOKUP_AUTOMOUNT 0x0004 /* force terminal automount */
-#define LOOKUP_EMPTY 0x4000 /* accept empty path [user_... only] */
-#define LOOKUP_DOWN0x8000 /* follow mounts in the starting point
*/
-
-#define LOOKUP_REVAL 0x0020 /* tell ->d_revalidate() to trust no
cache */
-#define LOOKUP_RCU 0x0040 /* RCU pathwalk mode; semi-internal */
-
-/* These tell filesystem methods that we are dealing with the final
component... */
-#define LOOKUP_OPEN0x0100 /* ... in open */
-#define LOOKUP_CREATE 0x0200 /* ... in object creation */
-#define LOOKUP_EXCL0x0400 /* ... in exclusive creation */
-#define LOOKUP_RENAME_TARGET 0x0800 /* ... in destination of rename() */
-
-/* internal use only */
-#define LOOKUP_PARENT 0x0010
-#define LOOKUP_NO_REVAL0x0080
-#define LOOKUP_JUMPED 0x1000
-#define LOOKUP_ROOT0x2000
-#define LOOKUP_ROOT_GRABBED0x0008
+/*
+ * Pathwalk mode:
+ */
+
+/* follow links at the end */
+#define LOOKUP_FOLLOW (1 << 0)
+/* require a directory */
+#define LOOKUP_DIRECTORY (1 << 1)
+/* force terminal automount */
+#define LOOKUP_AUTOMOUNT (1 << 2)
+/* accept empty path [user_... only] */
+#define LOOKUP_EMPTY (1 << 3)
+/* follow mounts in the starting point */
+#define LOOKUP_DOWN(1 << 4)
+/* tell ->d_revalidate() to trust no cache */
+#define LOOKUP_REVAL (1 << 5)
+/* RCU pathwalk mode; semi-internal */
+#define LOOKUP_RCU (1 << 6)
+
+
+/*
+ * These tell filesystem methods that we are dealing with the final component:
+ */
+
+/* ... in open */
+#define LOOKUP_OPEN(1 << 10)
+/* ... in object creation */
+#define LOOKUP_CREATE (1 << 11)
+/* ... in exclusive creation */
+#define LOOKUP_EXCL(1 << 12)
+/* ... in destination of rename() */
+#define LOOKUP_RENAME_TARGET (1 << 13)
+
+/*
+ * Internal use only:
+ */
+#define LOOKUP_PARENT (1 << 20)
+#define LOOKUP_NO_REVAL(1 << 21)
+#define LOOKUP_JUMPED (1 << 22)
+#define LOOKUP_ROOT(1 << 23)
+#define LOOKUP_ROOT_GRABBED(1 << 24)
extern int path_pts(struct path *path);
Re: "fs/namei.c: keep track of nd->root refcount status" causes boot panic
On Tue, Sep 03, 2019 at 06:50:24AM -0700, Christoph Hellwig wrote: > On Tue, Sep 03, 2019 at 02:48:32PM +0100, Al Viro wrote: > > Not sure what would be the best way to do it... I don't mind breaking > > the out-of-tree modules, whatever their license is; what I would rather > > avoid is _quiet_ breaking of such. > > Any out of tree module running against an upstream kernel will need > a recompile for a new version anyway. So I would not worry about it > at all. I'm really confused. What out-of-tree module are people needing to use when doing linux-next testing? That seems like a recipe for disaster... - Ted
Re: "fs/namei.c: keep track of nd->root refcount status" causes boot panic
On Tue, Sep 03, 2019 at 08:39:30AM -0700, Christoph Hellwig wrote: > > There's much nastier situation than "new upstream kernel released, > > need to rebuild" - it's bisect in mainline trying to locate something... > > I really don't get the point. And it's not like we've card about > this anywhere else. And jumping wildly around with the numeric values > for constants will lead to bugs like the one you added and fixed again > and again. The thing is, there are several groups - it's not as if all additions were guaranteed to be at the end. So either we play with renumbering again and again, or we are back to the square one... Is there any common trick that would allow to verify the lack of duplicates at the build time? Or we can reorder the list by constant value, with no grouping visible anywhere...
Re: "fs/namei.c: keep track of nd->root refcount status" causes boot panic
On Tue, Sep 03, 2019 at 02:53:54PM +0100, Al Viro wrote: > On Tue, Sep 03, 2019 at 06:50:24AM -0700, Christoph Hellwig wrote: > > On Tue, Sep 03, 2019 at 02:48:32PM +0100, Al Viro wrote: > > > Not sure what would be the best way to do it... I don't mind breaking > > > the out-of-tree modules, whatever their license is; what I would rather > > > avoid is _quiet_ breaking of such. > > > > Any out of tree module running against an upstream kernel will need > > a recompile for a new version anyway. So I would not worry about it > > at all. > > There's much nastier situation than "new upstream kernel released, > need to rebuild" - it's bisect in mainline trying to locate something... I really don't get the point. And it's not like we've card about this anywhere else. And jumping wildly around with the numeric values for constants will lead to bugs like the one you added and fixed again and again.
Re: "fs/namei.c: keep track of nd->root refcount status" causes boot panic
On Tue, Sep 03, 2019 at 06:50:24AM -0700, Christoph Hellwig wrote: > On Tue, Sep 03, 2019 at 02:48:32PM +0100, Al Viro wrote: > > Not sure what would be the best way to do it... I don't mind breaking > > the out-of-tree modules, whatever their license is; what I would rather > > avoid is _quiet_ breaking of such. > > Any out of tree module running against an upstream kernel will need > a recompile for a new version anyway. So I would not worry about it > at all. There's much nastier situation than "new upstream kernel released, need to rebuild" - it's bisect in mainline trying to locate something...
Re: "fs/namei.c: keep track of nd->root refcount status" causes boot panic
Hi
On Tue, 3 Sep 2019 at 19:01, Al Viro wrote:
>
> On Tue, Sep 03, 2019 at 01:37:19PM +0100, Al Viro wrote:
> > On Tue, Sep 03, 2019 at 12:21:36AM -0400, Qian Cai wrote:
> > > The linux-next commit "fs/namei.c: keep track of nd->root refcount
> > > status” [1] causes boot panic on all
> > > architectures here on today’s linux-next (0902). Reverted it will fix the
> > > issue.
> >
> >
> >
> > OK, I see what's going on. Incremental to be folded in:
>
> ... or, better yet,
>
> diff --git a/include/linux/namei.h b/include/linux/namei.h
> index 20ce2f917ef4..397a08ade6a2 100644
> --- a/include/linux/namei.h
> +++ b/include/linux/namei.h
> @@ -37,7 +37,7 @@ enum {LAST_NORM, LAST_ROOT, LAST_DOT, LAST_DOTDOT,
> LAST_BIND};
> #define LOOKUP_NO_REVAL0x0080
> #define LOOKUP_JUMPED 0x1000
> #define LOOKUP_ROOT0x2000
> -#define LOOKUP_ROOT_GRABBED0x4000
> +#define LOOKUP_ROOT_GRABBED0x0008
>
> extern int path_pts(struct path *path);
>
I have applied above patch and tested on arm64 juno-r2 and boot pass [1].
Thanks for the fix patch.
>
> to avoid breaking out-of-tree stuff for now good reason.
> Folded and pushed out.
[1] https://lkft.validation.linaro.org/scheduler/job/898187#L511
- Naresh
Re: "fs/namei.c: keep track of nd->root refcount status" causes boot panic
On Tue, Sep 03, 2019 at 02:48:32PM +0100, Al Viro wrote: > Not sure what would be the best way to do it... I don't mind breaking > the out-of-tree modules, whatever their license is; what I would rather > avoid is _quiet_ breaking of such. Any out of tree module running against an upstream kernel will need a recompile for a new version anyway. So I would not worry about it at all.
Re: "fs/namei.c: keep track of nd->root refcount status" causes boot panic
On Tue, Sep 03, 2019 at 06:04:56AM -0700, Christoph Hellwig wrote:
> On Tue, Sep 03, 2019 at 01:37:19PM +0100, Al Viro wrote:
> > On Tue, Sep 03, 2019 at 12:21:36AM -0400, Qian Cai wrote:
> > > The linux-next commit "fs/namei.c: keep track of nd->root refcount
> > > status” [1] causes boot panic on all
> > > architectures here on today’s linux-next (0902). Reverted it will fix the
> > > issue.
> >
> >
> >
> > OK, I see what's going on. Incremental to be folded in:
> >
> > diff --git a/include/linux/namei.h b/include/linux/namei.h
> > index 20ce2f917ef4..2ed0942a67f8 100644
> > --- a/include/linux/namei.h
> > +++ b/include/linux/namei.h
> > @@ -20,8 +20,8 @@ enum {LAST_NORM, LAST_ROOT, LAST_DOT, LAST_DOTDOT,
> > LAST_BIND};
> > #define LOOKUP_FOLLOW 0x0001 /* follow links at the end */
> > #define LOOKUP_DIRECTORY 0x0002 /* require a directory */
> > #define LOOKUP_AUTOMOUNT 0x0004 /* force terminal automount */
> > -#define LOOKUP_EMPTY 0x4000 /* accept empty path [user_...
> > only] */
> > -#define LOOKUP_DOWN0x8000 /* follow mounts in the
> > starting point */
> > +#define LOOKUP_EMPTY 0x8000 /* accept empty path [user_...
> > only] */
> > +#define LOOKUP_DOWN0x1 /* follow mounts in the
> > starting point */
> >
> > #define LOOKUP_REVAL 0x0020 /* tell ->d_revalidate() to
> > trust no cache */
> > #define LOOKUP_RCU 0x0040 /* RCU pathwalk mode; semi-internal */
>
> Any chance to keep these ordered numerically to avoid someone else
> introdcing this kind of bug again later on?
Not sure what would be the best way to do it... I don't mind breaking
the out-of-tree modules, whatever their license is; what I would rather
avoid is _quiet_ breaking of such.
Re: "fs/namei.c: keep track of nd->root refcount status" causes boot panic
On Tue, Sep 03, 2019 at 01:37:19PM +0100, Al Viro wrote:
> On Tue, Sep 03, 2019 at 12:21:36AM -0400, Qian Cai wrote:
> > The linux-next commit "fs/namei.c: keep track of nd->root refcount status”
> > [1] causes boot panic on all
> > architectures here on today’s linux-next (0902). Reverted it will fix the
> > issue.
>
>
>
> OK, I see what's going on. Incremental to be folded in:
... or, better yet,
diff --git a/include/linux/namei.h b/include/linux/namei.h
index 20ce2f917ef4..397a08ade6a2 100644
--- a/include/linux/namei.h
+++ b/include/linux/namei.h
@@ -37,7 +37,7 @@ enum {LAST_NORM, LAST_ROOT, LAST_DOT, LAST_DOTDOT, LAST_BIND};
#define LOOKUP_NO_REVAL0x0080
#define LOOKUP_JUMPED 0x1000
#define LOOKUP_ROOT0x2000
-#define LOOKUP_ROOT_GRABBED0x4000
+#define LOOKUP_ROOT_GRABBED0x0008
extern int path_pts(struct path *path);
to avoid breaking out-of-tree stuff for now good reason.
Folded and pushed out.
Re: "fs/namei.c: keep track of nd->root refcount status" causes boot panic
On Tue, Sep 03, 2019 at 01:37:19PM +0100, Al Viro wrote:
> On Tue, Sep 03, 2019 at 12:21:36AM -0400, Qian Cai wrote:
> > The linux-next commit "fs/namei.c: keep track of nd->root refcount status”
> > [1] causes boot panic on all
> > architectures here on today’s linux-next (0902). Reverted it will fix the
> > issue.
>
>
>
> OK, I see what's going on. Incremental to be folded in:
>
> diff --git a/include/linux/namei.h b/include/linux/namei.h
> index 20ce2f917ef4..2ed0942a67f8 100644
> --- a/include/linux/namei.h
> +++ b/include/linux/namei.h
> @@ -20,8 +20,8 @@ enum {LAST_NORM, LAST_ROOT, LAST_DOT, LAST_DOTDOT,
> LAST_BIND};
> #define LOOKUP_FOLLOW0x0001 /* follow links at the end */
> #define LOOKUP_DIRECTORY 0x0002 /* require a directory */
> #define LOOKUP_AUTOMOUNT 0x0004 /* force terminal automount */
> -#define LOOKUP_EMPTY 0x4000 /* accept empty path [user_... only] */
> -#define LOOKUP_DOWN 0x8000 /* follow mounts in the starting point
> */
> +#define LOOKUP_EMPTY 0x8000 /* accept empty path [user_... only] */
> +#define LOOKUP_DOWN 0x1 /* follow mounts in the starting point
> */
>
> #define LOOKUP_REVAL 0x0020 /* tell ->d_revalidate() to trust no
> cache */
> #define LOOKUP_RCU 0x0040 /* RCU pathwalk mode; semi-internal */
Any chance to keep these ordered numerically to avoid someone else
introdcing this kind of bug again later on?
Re: "fs/namei.c: keep track of nd->root refcount status" causes boot panic
On Tue, Sep 03, 2019 at 12:21:36AM -0400, Qian Cai wrote:
> The linux-next commit "fs/namei.c: keep track of nd->root refcount status”
> [1] causes boot panic on all
> architectures here on today’s linux-next (0902). Reverted it will fix the
> issue.
OK, I see what's going on. Incremental to be folded in:
diff --git a/include/linux/namei.h b/include/linux/namei.h
index 20ce2f917ef4..2ed0942a67f8 100644
--- a/include/linux/namei.h
+++ b/include/linux/namei.h
@@ -20,8 +20,8 @@ enum {LAST_NORM, LAST_ROOT, LAST_DOT, LAST_DOTDOT, LAST_BIND};
#define LOOKUP_FOLLOW 0x0001 /* follow links at the end */
#define LOOKUP_DIRECTORY 0x0002 /* require a directory */
#define LOOKUP_AUTOMOUNT 0x0004 /* force terminal automount */
-#define LOOKUP_EMPTY 0x4000 /* accept empty path [user_... only] */
-#define LOOKUP_DOWN0x8000 /* follow mounts in the starting point
*/
+#define LOOKUP_EMPTY 0x8000 /* accept empty path [user_... only] */
+#define LOOKUP_DOWN0x1 /* follow mounts in the starting point
*/
#define LOOKUP_REVAL 0x0020 /* tell ->d_revalidate() to trust no
cache */
#define LOOKUP_RCU 0x0040 /* RCU pathwalk mode; semi-internal */
Re: "fs/namei.c: keep track of nd->root refcount status" causes boot panic
> On 03-Sep-2019, at 1:43 PM, Naresh Kamboju wrote: > > On Tue, 3 Sep 2019 at 09:51, Qian Cai wrote: >> >> The linux-next commit "fs/namei.c: keep track of nd->root refcount status” >> [1] causes boot panic on all >> architectures here on today’s linux-next (0902). Reverted it will fix the >> issue. Similar problem is seen on ppc64le arch. [0.493235] BUG: Kernel NULL pointer dereference at 0x0cc0 [0.493241] Faulting instruction address: 0xc03e9260 [0.493245] Oops: Kernel access of bad area, sig: 11 [#1] [0.493250] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries [0.493254] Modules linked in: [0.493260] CPU: 1 PID: 1 Comm: systemd Not tainted 5.3.0-rc6-next-20190902-autotest-autotest #1 [0.493265] NIP: c03e9260 LR: c03e925c CTR: 01fc [0.493270] REGS: c004f85038c0 TRAP: 0300 Not tainted (5.3.0-rc6-next-20190902-autotest-autotest) [0.493274] MSR: 80009033 CR: 28002842 XER: [0.493282] CFAR: c000df44 DAR: 0cc0 DSISR: 4000 IRQMASK: 0 [0.493282] GPR00: c03e925c c004f8503b50 c1458e00 [0.493282] GPR04: c004f8503ce0 0064 [0.493282] GPR08: c0ff7a65 c004f70100c0 [0.493282] GPR12: 2200 c0001ecaee00 [0.493282] GPR16: [0.493282] GPR20: 00077624 7fffa1099e20 [0.493282] GPR24: 00010f9572a4 0001 [0.493282] GPR28: 00080060 00080040 0cc0 [0.493327] NIP [c03e9260] dput+0x70/0x4e0 [0.493332] LR [c03e925c] dput+0x6c/0x4e0 [0.493334] Call Trace: [0.493338] [c004f8503b50] [c03e925c] dput+0x6c/0x4e0 (unreliable) [0.493345] [c004f8503bc0] [c03d5da4] terminate_walk+0x104/0x130 [0.493351] [c004f8503c00] [c03da9d8] path_lookupat+0xe8/0x2b0 [0.493356] [c004f8503c70] [c03dd668] filename_lookup+0xa8/0x1c0 [0.493362] [c004f8503da0] [c046c4d4] sys_name_to_handle_at+0xe4/0x2d0 [0.493369] [c004f8503e20] [c000b378] system_call+0x5c/0x68 [0.493373] Instruction dump: [0.493376] f8010010 f821ff91 7c7f1b79 41820050 3d28 3b61 613c0060 613d0040 [0.493383] 3b40 3b00 48707b11 6000 <813f> 3bdf0058 7fc3f378 71390008 [0.493391] ---[ end trace 7701d360352c734d ]— Reverting the mentioned commit allows next to boot. Thanks -Sachin
Re: "fs/namei.c: keep track of nd->root refcount status" causes boot panic
On Tue, 3 Sep 2019 at 09:51, Qian Cai wrote: > > The linux-next commit "fs/namei.c: keep track of nd->root refcount status” > [1] causes boot panic on all > architectures here on today’s linux-next (0902). Reverted it will fix the > issue. I have same problem and reverting this patch fixed the kernel crash. > > [1] > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=e013ec23b8231cf7f95605cbb0e47aa0e3d047a4 > FYI, on x86_64 device I have noticed kernel bug [1]. [ 12.941007] Run /sbin/init as init process [ 12.946381] random: fast init done [ 13.023482] BUG: kernel NULL pointer dereference, address: 0235 [ 13.030444] #PF: supervisor read access in kernel mode [ 13.035576] #PF: error_code(0x) - not-present page [ 13.040725] PGD 0 P4D 0 [ 13.043263] Oops: [#1] SMP PTI [ 13.046755] CPU: 2 PID: 1 Comm: systemd Not tainted 5.3.0-rc6-next-20190902 #1 [ 13.053966] Hardware name: Supermicro SYS-5019S-ML/X11SSH-F, BIOS 2.0b 07/27/2017 [ 13.061438] RIP: 0010:dput+0x72/0x4a0 [ 13.065101] Code: 68 0d 5f 41 56 31 d2 45 31 c9 45 31 c0 31 f6 b9 02 00 00 00 48 c7 c7 e0 dd 66 a2 e8 48 6c e1 ff e8 e3 9f e3 ff 85 c0 5a 75 76 03 08 4c 8d a3 80 00 00 00 4c 89 e7 0f 85 7b 01 00 00 e8 16 66 [ 13.083838] RSP: 0018:b16100027c00 EFLAGS: 00010202 [ 13.089055] RAX: 0001 RBX: 0235 RCX: fff78e19 [ 13.096180] RDX: a0f3f630 RSI: RDI: [ 13.103301] RBP: b16100027c30 R08: R09: [ 13.110425] R10: R11: R12: b16100027e30 [ 13.117550] R13: a23a557f R14: a0f3f630 R15: b16100027e30 [ 13.124685] FS: 7f2541dc4840() GS:9983dfb0() knlGS: [ 13.132767] CS: 0010 DS: ES: CR0: 80050033 [ 13.138506] CR2: 0235 CR3: 00045a2fe003 CR4: 003606e0 [ 13.145630] DR0: DR1: DR2: [ 13.152752] DR3: DR6: fffe0ff0 DR7: 0400 [ 13.159875] Call Trace: [ 13.162323] terminate_walk+0x104/0x160 [ 13.166162] path_lookupat+0xa4/0x210 [ 13.169828] filename_lookup+0xb6/0x180 [ 13.173682] ? fs_reclaim_release.part.107+0x5/0x30 [ 13.178581] ? getname_flags+0x4b/0x1e0 [ 13.182419] ? rcu_read_lock_sched_held+0x4f/0x80 [ 13.187116] ? kmem_cache_alloc+0x290/0x2c0 [ 13.191293] ? __might_fault+0x85/0x90 [ 13.195037] user_path_at_empty+0x36/0x40 [ 13.199041] ? user_path_at_empty+0x36/0x40 [ 13.203217] vfs_statx+0x76/0xe0 [ 13.206442] __do_sys_newfstatat+0x35/0x70 [ 13.210535] ? entry_SYSCALL_64_after_hwframe+0x3e/0xbe [ 13.215758] ? trace_hardirqs_off_caller+0x22/0xf0 [ 13.220542] ? do_syscall_64+0x17/0x1c0 [ 13.224374] ? lockdep_hardirqs_on+0xf6/0x190 [ 13.228730] ? do_syscall_64+0x17/0x1c0 [ 13.232564] ? trace_hardirqs_on+0x4c/0x100 [ 13.236747] __x64_sys_newfstatat+0x1e/0x20 [ 13.240925] do_syscall_64+0x55/0x1c0 [ 13.244582] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 13.249625] RIP: 0033:0x7f25405bba09 [ 13.253196] Code: 64 c7 00 16 00 00 00 b8 ff ff ff ff c3 0f 1f 40 00 89 f0 48 89 d6 83 ff 01 77 36 89 c7 45 89 c2 48 89 ca b8 06 01 00 00 0f 05 <48> 3d 00 f0 ff ff 77 07 c3 66 0f 1f 44 00 00 48 8b 15 59 94 2c 00 [ 13.271934] RSP: 002b:7ffd6722dfc8 EFLAGS: 0246 ORIG_RAX: 0106 [ 13.279490] RAX: ffda RBX: 0001 RCX: 7f25405bba09 [ 13.286614] RDX: 7ffd6722e090 RSI: 7f25418c06d6 RDI: 0004 [ 13.293738] RBP: 0004 R08: 1000 R09: 0001 [ 13.300860] R10: 1000 R11: 0246 R12: 55bd9f667281 [ 13.307984] R13: 0400 R14: 7ffd6722e518 R15: 0001 [ 13.315111] Modules linked in: [ 13.318170] CR2: 0235 [ 13.321489] ---[ end trace 2f1042f3cbf26726 ]--- [ 13.326107] RIP: 0010:dput+0x72/0x4a0 [ 13.329763] Code: 68 0d 5f 41 56 31 d2 45 31 c9 45 31 c0 31 f6 b9 02 00 00 00 48 c7 c7 e0 dd 66 a2 e8 48 6c e1 ff e8 e3 9f e3 ff 85 c0 5a 75 76 03 08 4c 8d a3 80 00 00 00 4c 89 e7 0f 85 7b 01 00 00 e8 16 66 [ 13.348499] RSP: 0018:b16100027c00 EFLAGS: 00010202 [ 13.353740] RAX: 0001 RBX: 0235 RCX: fff78e19 [ 13.360865] RDX: a0f3f630 RSI: RDI: [ 13.367990] RBP: b16100027c30 R08: R09: [ 13.375115] R10: R11: R12: b16100027e30 [ 13.382238] R13: a23a557f R14: a0f3f630 R15: b16100027e30 [ 13.389361] FS: 7f2541dc4840() GS:9983dfb0() knlGS: [ 13.397439] CS: 0010 DS: ES: CR0: 80050033 [ 13.403176] CR2: 0235 CR3: 00045a2fe003 CR4: 003606e0 [ 13.410301] DR0:
RE: "fs/namei.c: keep track of nd->root refcount status" causes boot panic
FYI: this is a slightly different call-trace. I believe this also show a memory corruption... [ 17.848975] Run /init as init process Loading, please wait... starting version 239 [ 18.045913] BUG: unable to handle page fault for address: 8884bb8f4b98 [ 18.046012] #PF: supervisor write access in kernel mode [ 18.046061] #PF: error_code(0x0002) - not-present page [ 18.046124] PGD 3a02067 P4D 3a02067 PUD 505af0067 PMD 505913067 PTE 800b4470b060 [ 18.046286] Oops: 0002 [#1] PREEMPT SMP DEBUG_PAGEALLOC PTI [ 18.046355] CPU: 33 PID: 428 Comm: udevadm Not tainted 5.3.0-rc6-next-20190902+ #2 [ 18.046528] RIP: 0010:__lock_acquire+0xa8/0x16c0 [ 18.046590] Code: 48 89 c3 44 8b 4c 24 10 0f 84 13 04 00 00 48 81 eb 80 d7 a9 ... [ 18.046782] RSP: 0018:c900043ffc10 EFLAGS: 00010803 [ 18.046828] RAX: 2e8ba2e8ba2e8ba3 RBX: 466db384fa0cbc7a RCX: [ 18.046893] RDX: RSI: RDI: 8884e3382458 [ 18.046959] RBP: 8884e289cc00 R08: 0001 R09: [ 18.047022] R10: 0001 R11: fa0cbc7a R12: [ 18.047101] R13: 0001 R14: R15: 8884e3382458 [ 18.047163] FS: 7fd8183a88c0() GS:8884eb28() knlGS: [ 18.047238] CS: 0010 DS: ES: CR0: 80050033 [ 18.047287] CR2: 8884bb8f4b98 CR3: 0004e3298005 CR4: 003606e0 [ 18.047356] DR0: DR1: DR2: [ 18.047424] DR3: DR6: fffe0ff0 DR7: 0400 [ 18.047486] Call Trace: [ 18.047543] lock_acquire+0xb5/0x1c0 [ 18.047639] _raw_spin_lock+0x2f/0x40 [ 18.047706] dput.part.33+0x1fb/0x4f0 [ 18.047736] terminate_walk+0x126/0x150 [ 18.04] path_lookupat.isra.63+0xa3/0x220 [ 18.047826] filename_lookup.part.78+0xa0/0x170 [ 18.247277] do_readlinkat+0x5d/0x110 [ 18.247277] __x64_sys_readlinkat+0x1a/0x20 [ 18.247277] do_syscall_64+0x58/0x270 [ 18.247277] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 18.247277] RIP: 0033:0x7fd818c26a4a [ 18.247277] Code: 48 8b 0d 49 84 0d 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f ... [ 18.247277] RSP: 002b:7ffecb1bade8 EFLAGS: 0202 ORIG_RAX: 010b [ 18.247277] RAX: ffda RBX: 560d56bca220 RCX: 7fd818c26a4a [ 18.247277] RDX: 560d56bca220 RSI: 560d56bca201 RDI: 0005 [ 18.247277] RBP: 0064 R08: 560d56bb9010 R09: [ 18.247277] R10: 0063 R11: 0202 R12: 560d56bca201 [ 18.247277] R13: 0005 R14: 7ffecb1bae78 R15: 0063 [ 18.247277] Modules linked in: [ 18.247277] CR2: 8884bb8f4b98 Thanks, -- Dexuan
RE: "fs/namei.c: keep track of nd->root refcount status" causes boot panic
> From: Dexuan-Linux Cui
> Sent: Monday, September 2, 2019 10:22 PM
> To: Qian Cai
> Cc: Al Viro ; linux-fsde...@vger.kernel.org; LKML
> ; Dexuan Cui ; Lili Deng
> (Wicresoft North America Ltd)
> Subject: Re: "fs/namei.c: keep track of nd->root refcount status" causes boot
> panic
>
> On Mon, Sep 2, 2019 at 9:22 PM Qian Cai wrote:
> >
> > The linux-next commit "fs/namei.c: keep track of nd->root refcount status”
> [1] causes boot panic on all
> > architectures here on today’s linux-next (0902). Reverted it will fix the
> > issue.
>
> I believe I'm seeing the same issue with next-20190902 in a Linux VM
> running on Hyper-V (next-20190830 is good).
>
> git-bisect points to the same commit in linux-next:
> e013ec23b823 ("fs/namei.c: keep track of nd->root refcount status")
>
> I can reproduce the issue every time I reboot the system.
>
> Thanks,
> Dexuan
BTW, I tried the patch https://lkml.org/lkml/2019/8/31/158 -- not helpful at
all.
FYI: this is my call-trace:
[ 16.843452] Run /init as init process
Loading, please wait...
starting version 239
[ 16.936476] [ cut here ]
[ 16.937929] DEBUG_LOCKS_WARN_ON(!test_bit(class_idx, lock_classes_in_use))
[ 16.937929] WARNING: CPU: 10 PID: 366 at kernel/locking/lockdep.c:3850
__lock_acquire.isra.34+0x50c/0x560
[ 16.937929] Modules linked in:
[ 16.937929] CPU: 10 PID: 366 Comm: udevadm Not tainted 5.3.0-rc1+ #26
[ 16.937929] Hardware name: Microsoft Corporation Virtual Machine/Virtual
Machine, BIOS 090008 12/07/2018
[ 16.937929] RIP: 0010:__lock_acquire.isra.34+0x50c/0x560
[ 16.937929] Code: 00 85 c0 0f 84 72 fe ff ff 8b 1d af 5b 2b 01 85 db 0f 85
64 fe ff ff 48 c7 c6 08 97 07...
[ 16.937929] RSP: 0018:c90003ff3c40 EFLAGS: 00010086
[ 16.937929] RAX: RBX: RCX:
[ 16.937929] RDX: 810e3d63 RSI: 0001 RDI: 822628a0
[ 16.937929] RBP: R08: 82c0e420 R09: 00039440
[ 16.937929] R10: 001209f646b6 R11: 016e R12: 888276440040
[ 16.937929] R13: R14: R15: 888276440818
[ 16.937929] FS: 7f4ee2f0f8c0() GS:88827d70()
knlGS:
[ 16.937929] CS: 0010 DS: ES: CR0: 80050033
[ 16.937929] CR2: 55dce7403000 CR3: 000276772003 CR4: 003606e0
[ 16.937929] DR0: DR1: DR2:
[ 16.937929] DR3: DR6: fffe0ff0 DR7: 0400
[ 16.937929] Call Trace:
[ 16.937929] lock_acquire+0xae/0x160
[ 16.937929] ? dput.part.34+0x164/0x380
[ 16.937929] ? dput.part.34+0x29/0x380
[ 16.937929] _raw_spin_lock+0x2c/0x40
[ 16.937929] ? dput.part.34+0x164/0x380
[ 16.937929] dput.part.34+0x164/0x380
[ 17.098529] terminate_walk+0xde/0x100
[ 17.098529] path_lookupat.isra.62+0xa3/0x220
[ 17.098529] filename_lookup.part.77+0xa0/0x170
[ 17.098529] ? kmem_cache_alloc+0x169/0x2a0
[ 17.098529] do_readlinkat+0x5d/0x110
[ 17.098529] __x64_sys_readlinkat+0x1a/0x20
[ 17.098529] do_syscall_64+0x5d/0x1c0
[ 17.098529] ? prepare_exit_to_usermode+0x7b/0xb0
[ 17.098529] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 17.098529] RIP: 0033:0x7f4ee378da4a
[ 17.098529] Code: 48 8b 0d 49 84 0d 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e
0f 1f 84 00 00 ...
[ 17.098529] RSP: 002b:7fffbddb7968 EFLAGS: 0202 ORIG_RAX:
010b
[ 17.098529] RAX: ffda RBX: 55dce740b220 RCX: 7f4ee378da4a
[ 17.098529] RDX: 55dce740b220 RSI: 55dce740b201 RDI: 0005
[ 17.098529] RBP: 0064 R08: 55dce73fa010 R09:
[ 17.098529] R10: 0063 R11: 0202 R12: 55dce740b201
[ 17.098529] R13: 0005 R14: 7fffbddb79f8 R15: 0063
[ 17.098529] ---[ end trace 6af6f6ebcc3937e8 ]---
It looks the aforementioned patch causes a memory corruption.
If I revert the patch, everything will be back to normal.
Thanks,
Dexuan
Re: "fs/namei.c: keep track of nd->root refcount status" causes boot panic
On Mon, Sep 2, 2019 at 9:22 PM Qian Cai wrote:
>
> The linux-next commit "fs/namei.c: keep track of nd->root refcount status”
> [1] causes boot panic on all
> architectures here on today’s linux-next (0902). Reverted it will fix the
> issue.
I believe I'm seeing the same issue with next-20190902 in a Linux VM
running on Hyper-V (next-20190830 is good).
git-bisect points to the same commit in linux-next:
e013ec23b823 ("fs/namei.c: keep track of nd->root refcount status")
I can reproduce the issue every time I reboot the system.
Thanks,
Dexuan
