> On 15 Feb 2022, at 18:01, Jason Gunthorpe <jgg@xxxxxxxxxx> wrote: > > On Tue, Feb 15, 2022 at 04:53:25PM +0000, Pearson, Robert B wrote: >>>> spinlock_irqsave() >>>> write_lock_bh() >>>> write_unlock_bh() >>>> spinunlock_irqrestore() >>> >>>> Which is illegal locking. >>> >>>> Jason >>> >> Jason, can you tell me what the problem is with this. I'm not fighting it just want to know. > > I don't know the exact reason, judging from the code it looks like the > implementation of unlock_bh is allowed to assume hard irqs were not > blocked and unblock them - probably some micro-optimization. > > I don't think there is a deadlock issue with the above because irqsave > is a superset of the _bh varient. I worked on an issue in peernet2id(), which called _unlock_bh() whilst IRQs were off. Simply, you cannot unlock a _bh lock while IRQs are off. I did actually find archaic bugs reported due to this, see https://lore.kernel.org/netdev/7F058034-8A2B-4C19-A39E-12B0DB117328@xxxxxxxxxx/ Thxs, Håkon
