Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20220210184340.7eba108a@canb.auug.org.au> <20220210193302.686fa61a@canb.auug.org.au>
 <20220210214125.2b248790@canb.auug.org.au> <20220210222953.6e078d20@canb.auug.org.au>
 <YgWdbYfWgHP2jBmI@bombadil.infradead.org> <20220211123336.54eff9de@canb.auug.org.au>
 <YgW+DopXpFNZTj4k@bombadil.infradead.org> <20220211184647.0a62dad4@canb.auug.org.au>
 <YgawN2b1MOF7DN7g@bombadil.infradead.org>
In-Reply-To: <YgawN2b1MOF7DN7g@bombadil.infradead.org>
From:   Tong Zhang <ztong0001@gmail.com>
Date:   Fri, 11 Feb 2022 11:12:47 -0800
Message-ID: <CAA5qM4C8MBmichi5UC2S-tR3xjVNY=StAkuaXnG8VhKsi-1s5Q@mail.gmail.com>
Subject: Re: linux-next: boottime warning from todays linux-next
To:     Luis Chamberlain <mcgrof@kernel.org>
Cc:     Stephen Rothwell <sfr@canb.auug.org.au>,
        "Eric W. Biederman" <ebiederm@xmission.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Domenico Andreoli <domenico.andreoli@linux.com>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Linux Next Mailing List <linux-next@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

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