linux-kernel - Re: [PATCH v2 ratelimit 11/14] ratelimit: Force re-initialization when rate-limiting re-enabled

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: <559db775-f151-4694-86e6-72809b386097@paulmck-laptop>
Date: Wed, 23 Apr 2025 11:20:59 -0700
From: "Paul E. McKenney" <paulmck@...nel.org>
To: Mark Brown <broonie@...nel.org>
Cc: linux-kernel@...r.kernel.org, kernel-team@...a.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>,
	Jon Pan-Doh <pandoh@...gle.com>,
	Bjorn Helgaas <bhelgaas@...gle.com>,
	Karolina Stolarek <karolina.stolarek@...cle.com>,
	Aishwarya.TCV@....com, sraithal@....com
Subject: Re: [PATCH v2 ratelimit 11/14] ratelimit: Force re-initialization
 when rate-limiting re-enabled

On Wed, Apr 23, 2025 at 04:59:49PM +0100, Mark Brown wrote:
> On Fri, Apr 18, 2025 at 10:13:56AM -0700, Paul E. McKenney wrote:
> > Currently, rate limiting being disabled results in an immediate early
> > return with no state changes.  This can result in false-positive drops
> > when re-enabling rate limiting.  Therefore, mark the ratelimit_state
> > structure "uninitialized" when rate limiting is disabled.
> 
> Today's -next is failing to boot a defconfig on a wide range of arm64
> ACPI platforms.  One ACPI platform (Softiron) is still fine, and I've
> not noticed any DT platforms having issues.  Output grinds to a halt
> during boot shortly after userspace starts on affected systems:
> 
> [   23.334050] Freeing unused kernel memory: 11328K
> [   23.355182] Run /init as init process
> [   23.378221] NET: Registered PF_INET6 protocol family
> [   23.396506] Segment Routing with IPv6
> [   23.414054] In-situ OAM (IOAM) with IPv6
> 
> A bisect converges fairly smoothly on this patch in -next, which doesn't
> look completely implausible for something that stops console output - I
> didn't dig into it at all though.  I see that Sirkanth (CCed) seems to
> have reported a similar issue though with a different SHA1 since he
> noticed on yesterday's -next.

Thank you for the confirmation of Bert's and Srikanth's reports!

They reported that the replacing the offending commit with the following
patch fixed things up:

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

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;
 
 	/*

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

If that fixes things for you, could you also please try the following,
also replacing that same commit?

							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