Re: [PATCH v2] serial: 8250: fix shared IRQ startup race causing IRQ warning

[Wang Zhaolong]

> From: "Jiri Slaby"<jirislaby@xxxxxxxxxx>
> Date:  Wed, Jul 8, 2026, 2:03 PM
> Subject:  Re: [PATCH v2] serial: 8250: fix shared IRQ startup race causing IRQ warning
> To: "Wang Zhaolong"<wangzhaolong@xxxxxxxxx>, <gregkh@xxxxxxxxxxxxxxxxxxx>
> Cc: <linux-serial@xxxxxxxxxxxxxxx>, <linux-kernel@xxxxxxxxxxxxxxx>, <stable@xxxxxxxxxxxxxxx>, <andriy.shevchenko@xxxxxxxxxxxxxxx>, <albanhuang@xxxxxxxxxxx>, <tombinfan@xxxxxxxxxxx>, <jackzxcui1989@xxxxxxx>, <kees@xxxxxxxxxx>, <osama.abdelkader@xxxxxxxxx>, <realwujing@xxxxxxxxx>
> Ah, you are fixing the same thing as:
> https://lore.kernel.org/all/20260707-bug-221579-8250-shared-irq-race-v6-1-f8c499a90bdd@xxxxxxxxx/
> 
> I did not look up who of you was first.
> 
> Note the above contains you in the commit log:
> Reported-by: Wang Zhaolong <wangzhaolong@xxxxxxxxx>
> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221579
> 
> You both CCed each other, so you know the other's submission. I don't 
> understand why you both send the patch? Anyway, you guys speak to each 
> other and decide who sends the (fixed) patch.
> 
> On 08. 07. 26, 5:11, Wang Zhaolong wrote:
> ...
> > --- a/drivers/tty/serial/8250/8250_core.c
> > +++ b/drivers/tty/serial/8250/8250_core.c
> > @@ -154,10 +152,18 @@ static struct irq_info *serial_get_or_create_irq_info(const struct uart_8250_por
> >   static int serial_link_irq_chain(struct uart_8250_port *up)
> >   {
> >           struct irq_info *i;
> >           int ret;
> >   
> > +        /*
> > +         * Keep the hash lock held until the first request_irq() completes.
> > +         * The first port publishes i->head before request_irq() starts the IRQ;
> > +         * a second port sharing the IRQ must not join the chain and run the
> > +         * THRE test while the IRQ core is still bringing the line up.
> > +         */
> > +        guard(mutex)(&hash_mutex);
> 
> The same as in the other patch:
> hash_mutex is no longer an appropriate name for this lock.
> 
> > +
> >           i = serial_get_or_create_irq_info(up);
> >           if (IS_ERR(i))
> >                   return PTR_ERR(i);
> >   
> >           scoped_guard(spinlock_irq, &i->lock) {
> 
> thanks,
> -- 
> js
> suse labs
> 

Hi Jiri,

Thanks for looking.

Just to clarify the timeline: I reported this issue and posted the original
minimal fix on May 27:

  https://lore.kernel.org/r/20260527092052.2086342-1-wangzhaolong@xxxxxxxxx

I also pinged it on Jun 24:

  https://lore.kernel.org/r/ajtFoTHUQHJGYV5Q@MiniServer/

The other series was posted after my original submission and eventually
converged on the same core locking change.  I had also commented on that
series around v2/v3, pointing out the same startup race and the need to cover
the first request_irq() completion, so I was aware of that thread.

I sent v2 to refresh my earlier minimal fix with a clearer subject and commit
message, since the original patch had not received review.  My intent was not
to create two competing fixes for the same issue.

I agree with your comment that hash_mutex is no longer a great name once it
also serializes the first request_irq() completion.  I can send a v3 which
renames it and keeps the patch focused on the required locking change.

Thanks,
Wang Zhaolong