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