linux-kernel - Re: linux-next: boottime warning from todays linux-next

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAA5qM4C8MBmichi5UC2S-tR3xjVNY=StAkuaXnG8VhKsi-1s5Q@mail.gmail.com>
Date:   Fri, 11 Feb 2022 11:12:47 -0800
From:   Tong Zhang <ztong0001@...il.com>
To:     Luis Chamberlain <mcgrof@...nel.org>
Cc:     Stephen Rothwell <sfr@...b.auug.org.au>,
        "Eric W. Biederman" <ebiederm@...ssion.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Domenico Andreoli <domenico.andreoli@...ux.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux Next Mailing List <linux-next@...r.kernel.org>
Subject: Re: linux-next: boottime warning from todays linux-next

On Fri, Feb 11, 2022 at 10:51 AM Luis Chamberlain <mcgrof@...nel.org> 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 <mcgrof@...nel.org> 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