Re: [patch v2 09/14] genirq: Expose irq_find_desc_at_or_after() in core code

[Thomas Gleixner]

On Thu, Mar 26 2026 at 22:11, Thomas Gleixner wrote:
> On Thu, Mar 26 2026 at 19:13, Dmitry Ilvokhin wrote:
>>> -static unsigned int irq_find_at_or_after(unsigned int offset)
>>> +struct irq_desc *irq_find_desc_at_or_after(unsigned int offset)
>>>  {
>>>  	unsigned long index = offset;
>>> -	struct irq_desc *desc;
>>> -
>>> -	guard(rcu)();
>>
>> Is the drop of guard(rcu)() intentional here? irq_get_next_irq()
>> dereferences the returned pointer after mt_find() has dropped
>> rcu_read_unlock(). Should it hold its own guard(rcu)() to keep the same
>> behaviour as before?
>
> Good catch. The caller of irq_find_at_or_after() needs to hold it.

Just double checked. I have lockdep enabled, but it can't catch it the
way the code is written. The new iterater code holds it otherwise
rcuref_get() would have triggered it.

I've added it back and added a lockdep assert into
irq_find_at_or_after().

You just caught it before I was preparing the V3 post. Let me re-run the
test before I do so.

Thanks,

        tglx