linux-kernel - Re: commit dd4cf8c9e1f4 leads to failed boot

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: <8ded350c-fc05-4bc2-aff2-33b440f6e2d6@paulmck-laptop>
Date: Wed, 23 Apr 2025 12:56:53 -0700
From: "Paul E. McKenney" <paulmck@...nel.org>
To: Bert Karwatzki <spasswolf@....de>
Cc: "Aithal, Srikanth" <sraithal@....com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Kuniyuki Iwashima <kuniyu@...zon.com>,
	Mateusz Guzik <mjguzik@...il.com>, Petr Mladek <pmladek@...e.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	John Ogness <john.ogness@...utronix.de>,
	Sergey Senozhatsky <senozhatsky@...omium.org>,
	linux-kernel@...r.kernel.org,
	Linux-Next Mailing List <linux-next@...r.kernel.org>
Subject: Re: commit dd4cf8c9e1f4 leads to failed boot

On Wed, Apr 23, 2025 at 09:19:56PM +0200, Bert Karwatzki wrote:
> Am Mittwoch, dem 23.04.2025 um 11:07 -0700 schrieb Paul E. McKenney:
> > On Wed, Apr 23, 2025 at 08:49:08PM +0530, Aithal, Srikanth wrote:
> > > On 4/23/2025 7:48 PM, Paul E. McKenney wrote:
> > > > On Wed, Apr 23, 2025 at 07:09:42PM +0530, Aithal, Srikanth wrote:
> > > > > On 4/23/2025 5:24 PM, Bert Karwatzki wrote:
> > > > > > Since linux next-20250422 booting fails on my MSI Alpha 15 Laptop runnning
> > > > > > debian sid. When booting kernel message appear on screen but no messages from
> > > > > > init (systemd). There are also no logs written even thought emergency sync
> > > > > > via magic sysrq works (a message is printed on screen), presumably because
> > > > > > / is not mounted. I bisected this (from 6.15-rc3 to next-20250422) and found
> > > > > > commit dd4cf8c9e1f4 as the first bad commit.
> > > > > > Reverting commit dd4cf8c9e1f4 in next-20250422 fixes the issue.
> > > > > 
> > > > > 
> > > > > Hello,
> > > > > 
> > > > > On AMD platform as well boot failed starting next-20250422, bisecting the
> > > > > issue led me to same commit dd4cf8c9e1f4. I have attached kernel config and
> > > > > logs.
> > > > 
> > > > Thank you all for the bisection and the report!
> > > > 
> > > > Please check out the predecessor of commit dd4cf8c9e1f4 ("ratelimit:
> > > > Force re-initialization when rate-limiting re-enabled"):
> > > > 
> > > > 13fa70e052dd ("ratelimit: Allow zero ->burst to disable ratelimiting")
> > > > 
> > > > Then please apply the patch shown below, and let me know what happens?
> > > > (Yes, I should have split that commit up...)
> > > > 
> > > > 							Thanx, Paul
> > > > 
> > > > ------------------------------------------------------------------------
> > > > 
> > > > diff --git a/lib/ratelimit.c b/lib/ratelimit.c
> > > > index 04f16b8e24575..13ed636642270 100644
> > > > --- a/lib/ratelimit.c
> > > > +++ b/lib/ratelimit.c
> > > > @@ -35,7 +35,7 @@ int ___ratelimit(struct ratelimit_state *rs, const char *func)
> > > >   	unsigned long flags;
> > > >   	int ret;
> > > > -	if (!interval || !burst)
> > > > +	if (interval <= 0 || burst <= 0)
> > > >   		return 1;
> > > >   	/*
> > > 
> > > 
> > > I applied above patch on top of 13fa70e052dd ("ratelimit: Allow zero ->burst
> > > to disable ratelimiting") [linux-20250423]. This is fixing the boot issue.
> > > 
> > > Tested-by: Srikanth Aithal <sraithal@....com>
> > 
> > Thank you both, and to Bert for intuiting the correct -next commit!
> > 
> > Could you please try the next increment, which is this patch, again
> > on top of 24ff89c63355 ("ratelimit: Allow zero ->burst to > disable
> > ratelimiting")?
> > 
> > In the meantime, I will expose the version you two just tested to
> > -next.
> > 
> > 							Thanx, Paul
> > 
> > ------------------------------------------------------------------------
> > 
> > diff --git a/lib/ratelimit.c b/lib/ratelimit.c
> > index 04f16b8e24575..8f6c54f719ef2 100644
> > --- a/lib/ratelimit.c
> > +++ b/lib/ratelimit.c
> > @@ -35,8 +35,10 @@ int ___ratelimit(struct ratelimit_state *rs, const char *func)
> >  	unsigned long flags;
> >  	int ret;
> >  
> > -	if (!interval || !burst)
> > +	if (interval <= 0 || burst <= 0) {
> > +		ret = burst > 0;
> >  		return 1;
> > +	}
> >  
> >  	/*
> >  	 * If we contend on this state's lock then just check if
> 
> If you set "ret = burst > 0", but "return 1" this will make no difference
> (except in the case of a major compiler bug, probably), as I wrote in my other
> email which overlapped yours, this fixes the issue in next-20250422:
> 
> diff --git a/lib/ratelimit.c b/lib/ratelimit.c
> index b5c727e976d2..fc28f6cf8269 100644
> --- a/lib/ratelimit.c
> +++ b/lib/ratelimit.c
> @@ -40,7 +40,7 @@ int ___ratelimit(struct ratelimit_state *rs, const char *func)
>          * interval says never limit.
>          */
>         if (interval <= 0 || burst <= 0) {
> -               ret = burst > 0;
> +               ret = 1;
>                 if (!(READ_ONCE(rs->flags) & RATELIMIT_INITIALIZED) ||
>                     !raw_spin_trylock_irqsave(&rs->lock, flags))
>                         return ret;

You are quite right, your patch does fix the issue that you three say.
Unfortunately, it prevents someone from completely suppressing output
by setting burst to zero.  Could you please try the patch below?

							Thanx, Paul

------------------------------------------------------------------------

diff --git a/lib/ratelimit.c b/lib/ratelimit.c
index 04f16b8e24575..d6531e5c6ec4e 100644
--- a/lib/ratelimit.c
+++ b/lib/ratelimit.c
@@ -35,8 +35,8 @@ int ___ratelimit(struct ratelimit_state *rs, const char *func)
 	unsigned long flags;
 	int ret;
 
-	if (!interval || !burst)
-		return 1;
+	if (interval <= 0 || burst <= 0)
+		return interval == 0 || burst > 0;
 
 	/*
 	 * If we contend on this state's lock then just check if