linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Matthew Wilcox <willy@infradead.org>
To: "Sokolowski, Jan" <jan.sokolowski@intel.com>
Cc: "Christian König" <christian.koenig@amd.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
	"linux-mm@kvack.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: Fri, 28 Nov 2025 15:52:16 +0000	[thread overview]
Message-ID: <aSnFME6-LqQXKazB@casper.infradead.org> (raw)
In-Reply-To: <IA4PR11MB9251BBCF39B18A557BF08C0799DCA@IA4PR11MB9251.namprd11.prod.outlook.com>

On Fri, Nov 28, 2025 at 09:03:08AM +0000, Sokolowski, Jan wrote:
> So, shall I send a V2 of that patch and add you as co-developer there?

No.  You didn't co-develop anything.  You reported the bug, badly.

What I'm trying to do right now is figure out what the syzbot report
actually was.  In all the DRM specialness, you've lost the original
information, so I can't add the original syzbot links.  All I can find
is https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/6449
which doesn't link to a syzbot report, so that's a dead end.

> Regards
> Jan
> 
> > -----Original Message-----
> > From: Matthew Wilcox <willy@infradead.org>
> > Sent: Thursday, November 27, 2025 3:55 PM
> > To: Christian König <christian.koenig@amd.com>
> > Cc: Sokolowski, Jan <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
> > 
> > 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);
> 


  reply	other threads:[~2025-11-28 15:52 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
2025-11-27 15:02           ` Christian König
2025-11-28  9:03           ` Sokolowski, Jan
2025-11-28 15:52             ` Matthew Wilcox [this message]
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=aSnFME6-LqQXKazB@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