From: Matthew Wilcox <willy@infradead.org>
To: "Christian König" <christian.koenig@amd.com>
Cc: Jan Sokolowski <jan.sokolowski@intel.com>,
linux-kernel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
linux-fsdevel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [RFC PATCH 1/1] idr: do not create idr if new id would be outside given range
Date: Thu, 27 Nov 2025 14:55:23 +0000 [thread overview]
Message-ID: <aShmW2gMTyRwyC6m@casper.infradead.org> (raw)
In-Reply-To: <aShb9lLyR537WDNq@casper.infradead.org>
On Thu, Nov 27, 2025 at 02:11:02PM +0000, Matthew Wilcox wrote:
> Hm. That's not what it does for me. It gives me id == 1, which isn't
> correct! I'll look into that, but it'd be helpful to know what
> combination of inputs gives us 2.
Oh, never mind, I see what's happening.
int idr_alloc(struct idr *idr, void *ptr, int start, int end, gfp_t gfp)
ret = idr_alloc_u32(idr, ptr, &id, end > 0 ? end - 1 : INT_MAX, gfp);
so it's passing 0 as 'max' to idr_alloc_u32() which does:
slot = idr_get_free(&idr->idr_rt, &iter, gfp, max - base);
and max - base becomes -1 or rather ULONG_MAX, and so we'll literally
allocate any number. If the first slot is full, we'll get back 1
and then add 'base' to it, giving 2.
Here's the new test-case:
+void idr_alloc2_test(void)
+{
+ int id;
+ struct idr idr = IDR_INIT_BASE(idr, 1);
+
+ id = idr_alloc(&idr, idr_alloc2_test, 0, 1, GFP_KERNEL);
+ assert(id == -ENOSPC);
+
+ id = idr_alloc(&idr, idr_alloc2_test, 1, 2, GFP_KERNEL);
+ assert(id == 1);
+
+ id = idr_alloc(&idr, idr_alloc2_test, 0, 1, GFP_KERNEL);
+ assert(id == -ENOSPC);
+
+ id = idr_alloc(&idr, idr_alloc2_test, 0, 2, GFP_KERNEL);
+ assert(id == -ENOSPC);
+
+ idr_destroy(&idr);
+}
and with this patch, it passes:
+++ b/lib/idr.c
@@ -40,6 +40,8 @@ int idr_alloc_u32(struct idr *idr, void *ptr, u32 *nextid,
if (WARN_ON_ONCE(!(idr->idr_rt.xa_flags & ROOT_IS_IDR)))
idr->idr_rt.xa_flags |= IDR_RT_MARKER;
+ if (max < base)
+ return -ENOSPC;
id = (id < base) ? 0 : id - base;
radix_tree_iter_init(&iter, id);
next prev parent reply other threads:[~2025-11-27 14:55 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-27 9:27 [RFC PATCH 0/1] IDR fix for potential id mismatch Jan Sokolowski
2025-11-27 9:27 ` [RFC PATCH 1/1] idr: do not create idr if new id would be outside given range Jan Sokolowski
2025-11-27 13:38 ` Matthew Wilcox
2025-11-27 13:54 ` Matthew Wilcox
2025-11-27 14:03 ` Christian König
2025-11-27 14:11 ` Matthew Wilcox
2025-11-27 14:55 ` Matthew Wilcox [this message]
2025-11-27 15:02 ` Christian König
2025-11-28 9:03 ` Sokolowski, Jan
2025-11-28 15:52 ` Matthew Wilcox
2025-11-28 16:47 ` Sokolowski, Jan
2025-11-28 17:50 ` Matthew Wilcox
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aShmW2gMTyRwyC6m@casper.infradead.org \
--to=willy@infradead.org \
--cc=akpm@linux-foundation.org \
--cc=christian.koenig@amd.com \
--cc=jan.sokolowski@intel.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox