> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
