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

["Christian König" <christian.koenig@amd.com>]

On 11/27/25 15:55, Matthew Wilcox wrote:
> 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.

Oh wow, not every day that we stumble over a bug in such a core kernel functionality.

> 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);
> 

Not sure what it's worth but feel free to add Reviewed-by: Christian König <christian.koenig@amd.com> to both the test case and the solution.

Thanks for the quick help,
Christian.