Hi all,
My qemu boot of a powerpc pseries_le_defconfig kernel produced these
kernel messages:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.17.0-rc3 #2
Call Trace:
[c0000000073e3a80] [c0000000007bfd40] dump_stack_lvl+0x74/0xa8 (unreliable)
[c0000000073e3ac0] [c00000000057e3dc] __register_sysctl_table+0x60c/0x9f0
[c0000000073e3bd0] [c000000002041170] init_fs_stat_sysctls+0x48/0x60
[c0000000073e3bf0] [c000000000012110] do_one_initcall+0x60/0x2d0
[c0000000073e3cd0] [c0000000020049f0] kernel_init_freeable+0x334/0x3dc
[c0000000073e3db0] [c000000000012710] kernel_init+0x30/0x1a0
[c0000000073e3e10] [c00000000000cd64] ret_from_kernel_thread+0x5c/0x64
Presumably introduced by commit
b42bc9a3c511 ("Fix regression due to "fs: move binfmt_misc sysctl to its own file"")
--
Cheers,
Stephen Rothwell
Hi all,
On Thu, 10 Feb 2022 18:43:40 +1100 Stephen Rothwell <[email protected]> wrote:
>
> My qemu boot of a powerpc pseries_le_defconfig kernel produced these
> kernel messages:
>
> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.17.0-rc3 #2
> Call Trace:
> [c0000000073e3a80] [c0000000007bfd40] dump_stack_lvl+0x74/0xa8 (unreliable)
> [c0000000073e3ac0] [c00000000057e3dc] __register_sysctl_table+0x60c/0x9f0
> [c0000000073e3bd0] [c000000002041170] init_fs_stat_sysctls+0x48/0x60
> [c0000000073e3bf0] [c000000000012110] do_one_initcall+0x60/0x2d0
> [c0000000073e3cd0] [c0000000020049f0] kernel_init_freeable+0x334/0x3dc
> [c0000000073e3db0] [c000000000012710] kernel_init+0x30/0x1a0
> [c0000000073e3e10] [c00000000000cd64] ret_from_kernel_thread+0x5c/0x64
>
> Presumably introduced by commit
>
> b42bc9a3c511 ("Fix regression due to "fs: move binfmt_misc sysctl to its own file"")
OK, I cannot reproduce this with just Linus' tree. I will try to bisect.
--
Cheers,
Stephen Rothwell
Hi all,
On Thu, 10 Feb 2022 21:41:25 +1100 Stephen Rothwell <[email protected]> wrote:
>
> On Thu, 10 Feb 2022 19:33:02 +1100 Stephen Rothwell <[email protected]> wrote:
> >
> > On Thu, 10 Feb 2022 18:43:40 +1100 Stephen Rothwell <[email protected]> wrote:
> > >
> > > My qemu boot of a powerpc pseries_le_defconfig kernel produced these
> > > kernel messages:
> > >
> > > CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.17.0-rc3 #2
> > > Call Trace:
> > > [c0000000073e3a80] [c0000000007bfd40] dump_stack_lvl+0x74/0xa8 (unreliable)
> > > [c0000000073e3ac0] [c00000000057e3dc] __register_sysctl_table+0x60c/0x9f0
> > > [c0000000073e3bd0] [c000000002041170] init_fs_stat_sysctls+0x48/0x60
> > > [c0000000073e3bf0] [c000000000012110] do_one_initcall+0x60/0x2d0
> > > [c0000000073e3cd0] [c0000000020049f0] kernel_init_freeable+0x334/0x3dc
> > > [c0000000073e3db0] [c000000000012710] kernel_init+0x30/0x1a0
> > > [c0000000073e3e10] [c00000000000cd64] ret_from_kernel_thread+0x5c/0x64
> > >
> > > Presumably introduced by commit
> > >
> > > b42bc9a3c511 ("Fix regression due to "fs: move binfmt_misc sysctl to its own file"")
> >
> > OK, I cannot reproduce this with just Linus' tree. I will try to bisect.
>
> It bisected to commit
>
> 43a9443d5da2 ("Merge branch 'akpm-current/current'")
>
> and both parents of that commit are fine :-(
So it seems that the parent of "fs/binfmt_misc" is a permanently empty
directory - the is_empty_dir() check in insert_header() succeeds.
--
Cheers,
Stephen Rothwell
Hi all,
On Thu, 10 Feb 2022 19:33:02 +1100 Stephen Rothwell <[email protected]> wrote:
>
> On Thu, 10 Feb 2022 18:43:40 +1100 Stephen Rothwell <[email protected]> wrote:
> >
> > My qemu boot of a powerpc pseries_le_defconfig kernel produced these
> > kernel messages:
> >
> > CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.17.0-rc3 #2
> > Call Trace:
> > [c0000000073e3a80] [c0000000007bfd40] dump_stack_lvl+0x74/0xa8 (unreliable)
> > [c0000000073e3ac0] [c00000000057e3dc] __register_sysctl_table+0x60c/0x9f0
> > [c0000000073e3bd0] [c000000002041170] init_fs_stat_sysctls+0x48/0x60
> > [c0000000073e3bf0] [c000000000012110] do_one_initcall+0x60/0x2d0
> > [c0000000073e3cd0] [c0000000020049f0] kernel_init_freeable+0x334/0x3dc
> > [c0000000073e3db0] [c000000000012710] kernel_init+0x30/0x1a0
> > [c0000000073e3e10] [c00000000000cd64] ret_from_kernel_thread+0x5c/0x64
> >
> > Presumably introduced by commit
> >
> > b42bc9a3c511 ("Fix regression due to "fs: move binfmt_misc sysctl to its own file"")
>
> OK, I cannot reproduce this with just Linus' tree. I will try to bisect.
It bisected to commit
43a9443d5da2 ("Merge branch 'akpm-current/current'")
and both parents of that commit are fine :-(
"git diff-tree --cc 43a9443d5da2" looks like this:
43a9443d5da2d53dc06095b90b1aca18b72caef5
diff --cc lib/Kconfig.debug
index f15dd96028b5,efc1a1908e04..682c776ae73d
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@@ -317,6 -339,7 +339,7 @@@ config DEBUG_INFO_BT
depends on !DEBUG_INFO_SPLIT && !DEBUG_INFO_REDUCED
depends on !GCC_PLUGIN_RANDSTRUCT || COMPILE_TEST
depends on BPF_SYSCALL
- depends on !DEBUG_INFO_DWARF5
++ depends on !DEBUG_INFO_DWARF5 || PAHOLE_VERSION >= 121
help
Generate deduplicated BTF type information from DWARF debug info.
Turning this on expects presence of pahole tool, which will convert
diff --cc tools/include/linux/gfp.h
index b238dbc9eb85,22030756fbc0..56eec4445bc9
--- a/tools/include/linux/gfp.h
+++ b/tools/include/linux/gfp.h
@@@ -2,31 -1,4 +2,30 @@@
#ifndef _TOOLS_INCLUDE_LINUX_GFP_H
#define _TOOLS_INCLUDE_LINUX_GFP_H
+#include <linux/types.h>
+
+#define __GFP_BITS_SHIFT 26
+#define __GFP_BITS_MASK ((gfp_t)((1 << __GFP_BITS_SHIFT) - 1))
+
+#define __GFP_HIGH 0x20u
+#define __GFP_IO 0x40u
+#define __GFP_FS 0x80u
+#define __GFP_NOWARN 0x200u
+#define __GFP_ZERO 0x8000u
- #define __GFP_ATOMIC 0x80000u
+#define __GFP_ACCOUNT 0x100000u
+#define __GFP_DIRECT_RECLAIM 0x400000u
+#define __GFP_KSWAPD_RECLAIM 0x2000000u
+
+#define __GFP_RECLAIM (__GFP_DIRECT_RECLAIM | __GFP_KSWAPD_RECLAIM)
+
+#define GFP_ZONEMASK 0x0fu
- #define GFP_ATOMIC (__GFP_HIGH | __GFP_ATOMIC | __GFP_KSWAPD_RECLAIM)
++#define GFP_ATOMIC (__GFP_HIGH | __GFP_KSWAPD_RECLAIM)
+#define GFP_KERNEL (__GFP_RECLAIM | __GFP_IO | __GFP_FS)
+#define GFP_NOWAIT (__GFP_KSWAPD_RECLAIM)
+
+static inline bool gfpflags_allow_blocking(const gfp_t gfp_flags)
+{
+ return !!(gfp_flags & __GFP_DIRECT_RECLAIM);
+}
+
#endif /* _TOOLS_INCLUDE_LINUX_GFP_H */
Which looks pretty innocuous.
--
Cheers,
Stephen Rothwell
Hi Luis,
On Thu, 10 Feb 2022 15:19:09 -0800 Luis Chamberlain <[email protected]> wrote:
>
> FWIW Linus merged a more newer version of the regression fix, and only
> until today did we get that version on linux-next.
>
> > So it seems that the parent of "fs/binfmt_misc" is a permanently empty
> > directory - the is_empty_dir() check in insert_header() succeeds.
>
> I am not seeing this issue on x86_64 KVM guest with:
>
> CONFIG_BINFMT_MISC=m
> or
> CONFIG_BINFMT_MISC=y
>
> I think the issue might be that linux-next has Andrew's earlier
> version of the fix merged, and Linus now has the new version. So
> linux-next has these extra things below. But I can't understand
> why this is seen on ppc and not on x86_64.
>
> diff --git a/kernel/sysctl.c b/kernel/sysctl.c
> index 241cfc6bc36f..788b9a34d5ab 100644
> --- a/kernel/sysctl.c
> +++ b/kernel/sysctl.c
> @@ -2735,17 +2735,6 @@ static struct ctl_table vm_table[] = {
> { }
> };
>
> -static struct ctl_table fs_table[] = {
> -#if defined(CONFIG_BINFMT_MISC) || defined(CONFIG_BINFMT_MISC_MODULE)
> - {
> - .procname = "binfmt_misc",
> - .mode = 0555,
> - .child = sysctl_mount_point,
> - },
> -#endif
> - { }
> -};
> -
> static struct ctl_table debug_table[] = {
> #ifdef CONFIG_SYSCTL_EXCEPTION_TRACE
> {
> @@ -2765,7 +2754,6 @@ static struct ctl_table dev_table[] = {
>
> DECLARE_SYSCTL_BASE(kernel, kern_table);
> DECLARE_SYSCTL_BASE(vm, vm_table);
> -DECLARE_SYSCTL_BASE(fs, fs_table);
> DECLARE_SYSCTL_BASE(debug, debug_table);
> DECLARE_SYSCTL_BASE(dev, dev_table);
>
> @@ -2773,7 +2761,6 @@ int __init sysctl_init_bases(void)
> {
> register_sysctl_base(kernel);
> register_sysctl_base(vm);
> - register_sysctl_base(fs);
> register_sysctl_base(debug);
> register_sysctl_base(dev);
>
Thanks for noticing that. I have removed the old version from my copy
of mmotm today.
--
Cheers,
Stephen Rothwell
On Fri, Feb 11, 2022 at 12:33:36PM +1100, Stephen Rothwell wrote:
> Hi Luis,
>
> On Thu, 10 Feb 2022 15:19:09 -0800 Luis Chamberlain <[email protected]> wrote:
> >
> > FWIW Linus merged a more newer version of the regression fix, and only
> > until today did we get that version on linux-next.
> >
> > > So it seems that the parent of "fs/binfmt_misc" is a permanently empty
> > > directory - the is_empty_dir() check in insert_header() succeeds.
> >
> > I am not seeing this issue on x86_64 KVM guest with:
> >
> > CONFIG_BINFMT_MISC=m
> > or
> > CONFIG_BINFMT_MISC=y
> >
> > I think the issue might be that linux-next has Andrew's earlier
> > version of the fix merged, and Linus now has the new version. So
> > linux-next has these extra things below. But I can't understand
> > why this is seen on ppc and not on x86_64.
> >
> > diff --git a/kernel/sysctl.c b/kernel/sysctl.c
> > index 241cfc6bc36f..788b9a34d5ab 100644
> > --- a/kernel/sysctl.c
> > +++ b/kernel/sysctl.c
> > @@ -2735,17 +2735,6 @@ static struct ctl_table vm_table[] = {
> > { }
> > };
> >
> > -static struct ctl_table fs_table[] = {
> > -#if defined(CONFIG_BINFMT_MISC) || defined(CONFIG_BINFMT_MISC_MODULE)
> > - {
> > - .procname = "binfmt_misc",
> > - .mode = 0555,
> > - .child = sysctl_mount_point,
> > - },
> > -#endif
> > - { }
> > -};
> > -
> > static struct ctl_table debug_table[] = {
> > #ifdef CONFIG_SYSCTL_EXCEPTION_TRACE
> > {
> > @@ -2765,7 +2754,6 @@ static struct ctl_table dev_table[] = {
> >
> > DECLARE_SYSCTL_BASE(kernel, kern_table);
> > DECLARE_SYSCTL_BASE(vm, vm_table);
> > -DECLARE_SYSCTL_BASE(fs, fs_table);
> > DECLARE_SYSCTL_BASE(debug, debug_table);
> > DECLARE_SYSCTL_BASE(dev, dev_table);
> >
> > @@ -2773,7 +2761,6 @@ int __init sysctl_init_bases(void)
> > {
> > register_sysctl_base(kernel);
> > register_sysctl_base(vm);
> > - register_sysctl_base(fs);
> > register_sysctl_base(debug);
> > register_sysctl_base(dev);
> >
>
> Thanks for noticing that. I have removed the old version from my copy
> of mmotm today.
And ... does that fix your boot?
Luis
On Thu, Feb 10, 2022 at 07:33:02PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> On Thu, 10 Feb 2022 18:43:40 +1100 Stephen Rothwell <[email protected]> wrote:
> >
> > My qemu boot of a powerpc pseries_le_defconfig kernel produced these
> > kernel messages:
> >
> > CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.17.0-rc3 #2
> > Call Trace:
> > [c0000000073e3a80] [c0000000007bfd40] dump_stack_lvl+0x74/0xa8 (unreliable)
> > [c0000000073e3ac0] [c00000000057e3dc] __register_sysctl_table+0x60c/0x9f0
> > [c0000000073e3bd0] [c000000002041170] init_fs_stat_sysctls+0x48/0x60
> > [c0000000073e3bf0] [c000000000012110] do_one_initcall+0x60/0x2d0
> > [c0000000073e3cd0] [c0000000020049f0] kernel_init_freeable+0x334/0x3dc
> > [c0000000073e3db0] [c000000000012710] kernel_init+0x30/0x1a0
> > [c0000000073e3e10] [c00000000000cd64] ret_from_kernel_thread+0x5c/0x64
> >
> > Presumably introduced by commit
> >
> > b42bc9a3c511 ("Fix regression due to "fs: move binfmt_misc sysctl to its own file"")
>
> OK, I cannot reproduce this with just Linus' tree. I will try to bisect.
I could not reproduce it on either my amd64 or arm64.
Dom
--
rsa4096: 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13
ed25519: FFB4 0CC3 7F2E 091D F7DA 356E CC79 2832 ED38 CB05
On Thu, Feb 10, 2022 at 10:29:53PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> On Thu, 10 Feb 2022 21:41:25 +1100 Stephen Rothwell <[email protected]> wrote:
> >
> > On Thu, 10 Feb 2022 19:33:02 +1100 Stephen Rothwell <[email protected]> wrote:
> > >
> > > On Thu, 10 Feb 2022 18:43:40 +1100 Stephen Rothwell <[email protected]> wrote:
> > > >
> > > > My qemu boot of a powerpc pseries_le_defconfig kernel produced these
> > > > kernel messages:
> > > >
> > > > CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.17.0-rc3 #2
> > > > Call Trace:
> > > > [c0000000073e3a80] [c0000000007bfd40] dump_stack_lvl+0x74/0xa8 (unreliable)
> > > > [c0000000073e3ac0] [c00000000057e3dc] __register_sysctl_table+0x60c/0x9f0
> > > > [c0000000073e3bd0] [c000000002041170] init_fs_stat_sysctls+0x48/0x60
> > > > [c0000000073e3bf0] [c000000000012110] do_one_initcall+0x60/0x2d0
> > > > [c0000000073e3cd0] [c0000000020049f0] kernel_init_freeable+0x334/0x3dc
> > > > [c0000000073e3db0] [c000000000012710] kernel_init+0x30/0x1a0
> > > > [c0000000073e3e10] [c00000000000cd64] ret_from_kernel_thread+0x5c/0x64
> > > >
> > > > Presumably introduced by commit
> > > >
> > > > b42bc9a3c511 ("Fix regression due to "fs: move binfmt_misc sysctl to its own file"")
> > >
> > > OK, I cannot reproduce this with just Linus' tree. I will try to bisect.
OK so that's not the issue.
> > It bisected to commit
> >
> > 43a9443d5da2 ("Merge branch 'akpm-current/current'")
> >
> > and both parents of that commit are fine :-(
FWIW Linus merged a more newer version of the regression fix, and only
until today did we get that version on linux-next.
> So it seems that the parent of "fs/binfmt_misc" is a permanently empty
> directory - the is_empty_dir() check in insert_header() succeeds.
I am not seeing this issue on x86_64 KVM guest with:
CONFIG_BINFMT_MISC=m
or
CONFIG_BINFMT_MISC=y
I think the issue might be that linux-next has Andrew's earlier
version of the fix merged, and Linus now has the new version. So
linux-next has these extra things below. But I can't understand
why this is seen on ppc and not on x86_64.
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index 241cfc6bc36f..788b9a34d5ab 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -2735,17 +2735,6 @@ static struct ctl_table vm_table[] = {
{ }
};
-static struct ctl_table fs_table[] = {
-#if defined(CONFIG_BINFMT_MISC) || defined(CONFIG_BINFMT_MISC_MODULE)
- {
- .procname = "binfmt_misc",
- .mode = 0555,
- .child = sysctl_mount_point,
- },
-#endif
- { }
-};
-
static struct ctl_table debug_table[] = {
#ifdef CONFIG_SYSCTL_EXCEPTION_TRACE
{
@@ -2765,7 +2754,6 @@ static struct ctl_table dev_table[] = {
DECLARE_SYSCTL_BASE(kernel, kern_table);
DECLARE_SYSCTL_BASE(vm, vm_table);
-DECLARE_SYSCTL_BASE(fs, fs_table);
DECLARE_SYSCTL_BASE(debug, debug_table);
DECLARE_SYSCTL_BASE(dev, dev_table);
@@ -2773,7 +2761,6 @@ int __init sysctl_init_bases(void)
{
register_sysctl_base(kernel);
register_sysctl_base(vm);
- register_sysctl_base(fs);
register_sysctl_base(debug);
register_sysctl_base(dev);
Hi Luis,
On Thu, 10 Feb 2022 17:38:22 -0800 Luis Chamberlain <[email protected]> wrote:
>
> On Fri, Feb 11, 2022 at 12:33:36PM +1100, Stephen Rothwell wrote:
> >
> > Thanks for noticing that. I have removed the old version from my copy
> > of mmotm today.
>
> And ... does that fix your boot?
Yes, the messages are all gone.
Thanks again.
--
Cheers,
Stephen Rothwell
On Wed, Feb 9, 2022 at 11:43 PM Stephen Rothwell <[email protected]> wrote:
>
> Hi all,
>
> My qemu boot of a powerpc pseries_le_defconfig kernel produced these
> kernel messages:
>
> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.17.0-rc3 #2
> Call Trace:
> [c0000000073e3a80] [c0000000007bfd40] dump_stack_lvl+0x74/0xa8 (unreliable)
> [c0000000073e3ac0] [c00000000057e3dc] __register_sysctl_table+0x60c/0x9f0
> [c0000000073e3bd0] [c000000002041170] init_fs_stat_sysctls+0x48/0x60
> [c0000000073e3bf0] [c000000000012110] do_one_initcall+0x60/0x2d0
> [c0000000073e3cd0] [c0000000020049f0] kernel_init_freeable+0x334/0x3dc
> [c0000000073e3db0] [c000000000012710] kernel_init+0x30/0x1a0
> [c0000000073e3e10] [c00000000000cd64] ret_from_kernel_thread+0x5c/0x64
>
> Presumably introduced by commit
>
> b42bc9a3c511 ("Fix regression due to "fs: move binfmt_misc sysctl to its own file"")
>
> --
> Cheers,
> Stephen Rothwell
Hi Stephen,
I am trying to see if I can reproduce this.
Could you share the QEMU command line and pseries_le_defconfig?
Latest kernel does not have pseries_le_defconfig so I assume you have
your own version.
Thanks!
- Tong
Hi Tong,
On Thu, 10 Feb 2022 15:35:30 -0800 Tong Zhang <[email protected]> wrote:
>
> I am trying to see if I can reproduce this.
> Could you share the QEMU command line and pseries_le_defconfig?
> Latest kernel does not have pseries_le_defconfig so I assume you have
> your own version.
This is a ARCH=powerpc build and qemu run.
qemu-system-ppc64 -M pseries -cpu POWER8 -m 2G -vga none -nographic -kernel $vmlinux -initrd $initrd
I have a simple initrd that just boots to a login prompt.
Anyway, it seems that the mystery has been solved (hopefully).
--
Cheers,
Stephen Rothwell
On Fri, Feb 11, 2022 at 06:46:47PM +1100, Stephen Rothwell wrote:
> Hi Luis,
>
> On Thu, 10 Feb 2022 17:38:22 -0800 Luis Chamberlain <[email protected]> wrote:
> >
> > On Fri, Feb 11, 2022 at 12:33:36PM +1100, Stephen Rothwell wrote:
> > >
> > > Thanks for noticing that. I have removed the old version from my copy
> > > of mmotm today.
> >
> > And ... does that fix your boot?
>
> Yes, the messages are all gone.
Fantastic, thanks for the confirmation!
OK so now a side independent curiousity remains though. Double sysctl
registration should not happen. But if someone introduces a bug by doing
that, it seems to not crash on x86. But it does cause a crash or a
kernel warning on ppc.
Why?
And I think we should just WARN_ONCE() for this case, and make the
issue clearer so that if it happens again, folks don't go scrambling
as if chickens running around with their heads cut off.
Luis
On Thu, Feb 10, 2022 at 5:43 PM Stephen Rothwell <[email protected]> wrote:
>
> Hi Tong,
>
> On Thu, 10 Feb 2022 15:35:30 -0800 Tong Zhang <[email protected]> wrote:
> >
> > I am trying to see if I can reproduce this.
> > Could you share the QEMU command line and pseries_le_defconfig?
> > Latest kernel does not have pseries_le_defconfig so I assume you have
> > your own version.
>
> This is a ARCH=powerpc build and qemu run.
>
> qemu-system-ppc64 -M pseries -cpu POWER8 -m 2G -vga none -nographic -kernel $vmlinux -initrd $initrd
>
> I have a simple initrd that just boots to a login prompt.
>
> Anyway, it seems that the mystery has been solved (hopefully).
> --
> Cheers,
> Stephen Rothwell
Thanks for providing the configuration.
I tried the same setup and it worked. No crash whatsoever.
As mentioned by Luis, if I enable the line below, the kernel will
throw out a similar message like in your original mail.
@@ -2773,7 +2761,6 @@ int __init sysctl_init_bases(void)
{
register_sysctl_base(kernel);
register_sysctl_base(vm);
+ register_sysctl_base(fs);
register_sysctl_base(debug);
register_sysctl_base(dev);
[ 0.190779][ T1] Call Trace:
[ 0.190836][ T1] [c0000000073e3a90] [c0000000007bc2e0]
dump_stack_lvl+0x74/0xa8 (unreliable)
[ 0.190940][ T1] [c0000000073e3ad0] [c000000000581d9c]
__register_sysctl_table+0x59c/0x8f0
[ 0.191054][ T1] [c0000000073e3bd0] [c0000000020416fc]
init_fs_stat_sysctls+0x48/0x60
[ 0.191110][ T1] [c0000000073e3bf0] [c000000000012190]
do_one_initcall+0x60/0x2c0
[ 0.191139][ T1] [c0000000073e3cc0] [c000000002004a24]
kernel_init_freeable+0x33c/0x3dc
[ 0.191189][ T1] [c0000000073e3da0] [c0000000000127a4]
kernel_init+0x34/0x1a0
[ 0.191231][ T1] [c0000000073e3e10] [c00000000000cd64]
ret_from_kernel_thread+0x5c/0x64
I believe this issue can be marked as resolved now.
- Tong
On Fri, Feb 11, 2022 at 10:51 AM Luis Chamberlain <[email protected]> wrote:
>
> On Fri, Feb 11, 2022 at 06:46:47PM +1100, Stephen Rothwell wrote:
> > Hi Luis,
> >
> > On Thu, 10 Feb 2022 17:38:22 -0800 Luis Chamberlain <[email protected]> wrote:
> > >
> > > On Fri, Feb 11, 2022 at 12:33:36PM +1100, Stephen Rothwell wrote:
> > > >
> > > > Thanks for noticing that. I have removed the old version from my copy
> > > > of mmotm today.
> > >
> > > And ... does that fix your boot?
> >
> > Yes, the messages are all gone.
>
> Fantastic, thanks for the confirmation!
>
> OK so now a side independent curiousity remains though. Double sysctl
> registration should not happen. But if someone introduces a bug by doing
> that, it seems to not crash on x86. But it does cause a crash or a
> kernel warning on ppc.
>
IMO this is ARCH irrelevant, it will definitely give the same result
on double registration.
Tested on a x86 using the same double registration code.
[ 1.098835] Call Trace:
[ 1.098835] <TASK>
[ 1.098835] dump_stack_lvl+0x34/0x44
[ 1.098835] __register_sysctl_table+0x6f4/0x720
[ 1.098835] ? early_memunmap+0x5/0x5
[ 1.098835] init_fs_stat_sysctls+0x3e/0x41
[ 1.098835] do_one_initcall+0x82/0x280
[ 1.098835] ? trace_event_raw_event_initcall_finish+0x150/0x150
[ 1.098835] ? parameq+0x80/0x80
[ 1.098835] ? _raw_spin_unlock_irq+0x20/0x30
[ 1.098835] ? create_object+0x395/0x510
[ 1.098835] kernel_init_freeable+0x2a5/0x2fe
[ 1.098835] ? rest_init+0xe0/0xe0
[ 1.098835] kernel_init+0x14/0x130
[ 1.098835] ret_from_fork+0x1f/0x30
[ 1.098835] </TASK>
However this is not a fatal error and the kernel is still operable in
both PPC and X86 cases, the bug can be catched and we can use
WARN_ONCE().
> Why?
>
> And I think we should just WARN_ONCE() for this case, and make the
> issue clearer so that if it happens again, folks don't go scrambling
> as if chickens running around with their heads cut off.
>
> Luis
- Tong