On Sun, Oct 11, 2026 at 11:30:13AM +0200, Markus Elfring wrote:
> > The bind_evtchn_to_irqhandler() function can never return 0.
> …
>
> I suggest to reconsider information once more also according to the
> probability
> of return values from such a function.
> https://elixir.bootlin.com/linux/v7.3-rc6/source/drivers/xen/events/events_base.c#L1453-L1461
>
> bind_evtchn_to_irqhandler_chip()
> https://elixir.bootlin.com/linux/v7.3-rc6/source/drivers/xen/events/events_base.c#L1432-L1451
I'm not sure what you are trying to exactly or have hard time following
this response but if there is a problem it can be investigated. All I'm
seeing now is a collection of links and abstract statements.
I guess this is the function that picks the IRQ number:
static struct irq_info *xen_allocate_irq_dynamic(void)
{
int irq = irq_alloc_desc_from(0, -1);
struct irq_info *info = NULL;
if (irq >= 0) {
info = xen_irq_init(irq);
if (!info)
xen_irq_free_desc(irq);
}
return info;
}
And if I did not get loss while scavenging the call hierachy it ends
up to:
static int irq_find_free_area(unsigned int from, unsigned int cnt)
{
MA_STATE(mas, &sparse_irqs, 0, 0);
if (mas_empty_area(&mas, from, MAX_SPARSE_IRQS, cnt))
return -ENOSPC;
return mas.index;
}
And if I looked it up right @from == -1 and @cnt == 1 when
irq_find_free_area is reached.
I'm not IRQ code expert per se but in order to this never return zero,
sparse_irqs should not have it available?
I do agree that something in this patch does not appear right, or
at least not very well explained so it is a good catch anyhow.
My decision on this is that:
1. I'll drop the current patch as it actually does not make a case
why zero could not possibly happen. I spent 45 minutes browsing
because commit message did not have any technical details.
2. Even if it was legit it is hard to see that the change is high
priority for anyone.
3. However, I'm open for v2 with better tecnical backing if there
is any.
Br, Jarkko
