Messages in this thread | | | Date | Tue, 19 Jun 2012 18:54:32 +0100 | From | Alan Cox <> | Subject | Re: [RFC PATCH] pch_uart: Add eg20t_port lock field, avoid recursive spinlocks |
| |
> I see, the oops_in_progress test right? My thinking was that the > oops_in_progress was only relevant to the port.lock as that could be > taken outside of the pch_uart driver, while the priv.lock is only used > within the driver. But, as the oops uses the pch_console_write itself, I > can see the recursive spinlock failure case there.
Until your driver crashes...
> As for the printk, it seems the 8250 driver would also suffer from that > in the serial8250_console_write function on the port.lock, and it does > not make any allowances for printk.
I think 8250 probably wants fixing too then!
> > I would like to hold the priv.lock for a smaller window, but ordering > requires that I take it prior to the port.lock. > > So I can test for oops_in_progress on the priv->lock too, but that won't > address the printk issue. Is the oops the bigger concern?
the oops is the main one - a printk would have to be in driver as a screwup, and you can force an oops on a stall so pick it up later
Alan
| |