On Sat, Jan 21, 2017 at 1:28 AM, Eric W. Biederman <[email protected]> wrote: > Nikolay Borisov <[email protected]> writes: > >> On 20.01.2017 20:05, Eric W. Biederman wrote: >>> Nikolay Borisov <[email protected]> writes: >>> >>>> On 20.01.2017 15:07, Dmitry Vyukov wrote: >>>>> Hello, >>>>> >>>>> I've got the following deadlock report while running syzkaller fuzzer >>>>> on eec0d3d065bfcdf9cd5f56dd2a36b94d12d32297 of linux-next (on odroid >>>>> device if it matters): >>> >>> I am puzzled I thought we had fixed this with: >>> add7c65ca426 ("pid: fix lockdep deadlock warning due to ucount_lock") >>> But apparently not. We just moved it from hardirq to softirq context. >>> Bah. >>> >>> Thank you very much for the report. >>> >>> Nikolay can you make your change use spinlock_irq? And have put_ucounts >>> do spin_lock_irqsave? That way we just don't care where we call this. >> >> Like the one attached? > > Exactly thank you. Dmitry if you have time to test that patch and > verify it fixes your issue I would appreciate it. > >> I haven't really taken careful look as to whether >> the function where _irq versions do fiddle with irq state, since this >> might cause a problem if we unconditionally enable them. > > In code paths where we can sleep irqs must come in enabled or it's a > bug. > > spin_lock_irq which unconditionally disables irqs is thus safe on the > allocation path. > > Similary spin_unlock_irq which unconditionally enables irqs is also safe > on the allocation path.
Yes, it fixes the issue for me: Tested-by: Dmitry Vyukov <[email protected]>
