Re: RFC: chasing all idr_remove() misses

[Matthew Wilcox <willy@infradead.org>]

On Sun, Nov 17, 2024 at 04:07:43PM +0100, Alexandre Ferrieux wrote:
> On 16/11/2024 20:43, Dan Carpenter wrote:
> >
> > On Sat, Nov 16, 2024 at 06:45:37PM +0100, Alexandre Ferrieux wrote:
> >>
> >>   73af53d82076 net: sched: cls_u32: Fix u32's systematic failure to free IDR
> >>                entries for hnodes.
> >>
> >> So, unless we have reasons to think cls_u32 was the only place where two ID
> >> encodings might lend themselves to confusion, I'm wondering if it wouldn't
> >> make sense to chase the issue more systematically
> >>
> > Matthew Wilcox maintains IDR so it's really up to him.  I don't think adding
> > a WARN_ON_ONCE() in idr_remove() for NULL returns is a bad idea but we could
> > hide it behind a #if DEBUG_IDR or something and try run syzkaller on it first.
> 
> Thanks Dan. Now, I'm not familiar with the syzbot feeding process, can you help
> me out ? Is the next step to:
> 
>  (a) invent the new debug flag (e.g. "DEBUG_IDR") then post a patch using it;
> wait for its acceptation and merge ; then contact syzbot operators to add it in
> (some of) its builds
> 
>  (b) use some existing wide-range debug flag so that syzbot will automagically
> test IDR once the patch is merged
> 
>  (c) wait for you or Matthew to handle all of this

IDR is deprecated.  I'm not excited about patches that make it better.
IDR users should be converted to use the XArray API.