linux-kernel - Re: [RFC PATCH 1/1] idr: do not create idr if new id would be outside given range

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

Message-ID: <aSng8hKuttOWQuds@casper.infradead.org>
Date: Fri, 28 Nov 2025 17:50:42 +0000
From: Matthew Wilcox <willy@...radead.org>
To: "Sokolowski, Jan" <jan.sokolowski@...el.com>
Cc: Christian König <christian.koenig@....com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
	"linux-mm@...ck.org" <linux-mm@...ck.org>
Subject: Re: [RFC PATCH 1/1] idr: do not create idr if new id would be
 outside given range

On Fri, Nov 28, 2025 at 04:47:17PM +0000, Sokolowski, Jan wrote:
> > No.  You didn't co-develop anything.  You reported the bug, badly.
> > 
> And I've sent a potential patch on how it should've been fixed. That should count for something, right?

Literally everything about that patch was wrong.  If I'd used any of it,
you'd have a point, but the entire approach was wrong.

You _can't_allow the allocation to succeed and then undo it.  There might
be an RCU-protected reader which would see the intermediate state.
And that's an inconsistency we guarantee can't happen; an RCU reader
can see the state before the lock, the state after the lock.  It must
not see a state that never happened.

If you'd written a test case, I'd happily add a co-developed-by tag.
But you didn't do that either.