linux-kernel - Re: Boot warning at rcu_check_gp_start

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] [thread-next>] [day] [month] [year] [list]

Message-Id: <A230E332-07D0-40A8-A034-33ADB4BFB767@lca.pw>
Date:   Tue, 21 Jan 2020 09:37:13 -0500
From:   Qian Cai <cai@....pw>
To:     paulmck@...nel.org
Cc:     rcu@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>
Subject: Re: Boot warning at rcu_check_gp_start_stall()



> On Jan 21, 2020, at 9:19 AM, Paul E. McKenney <paulmck@...nel.org> wrote:
> 
> One approach would be to boot with rcupdate.rcu_cpu_stall_timeout=300,
> which would allow more time.

It works for me if once that warning triggered,  give a bit information about adjusting the parameter when debugging options are on to suppress the warning due to expected long boot.

> 
> Longer term, I could suppress this warning during boot when
> CONFIG_EFI_PGT_DUMP=y, but that sounds quite specific.  Alternatively,
> I could provide a Kconfig option that suppressed this during boot
> that was selected by whatever long-running boot-time Kconfig option
> needed it.  Yet another approach would be for long-running operations
> like efi_dump_pagetable() to suppress stalls on entry and re-enable them
> upon exit.
> 
> Thoughts?

None of the options sounds particularly better for me because there could come up with other options may trigger this, memtest comes in mind, for example. Then, it is a bit of pain to maintain of unknown.