From: ebiederm@xmission.com (Eric W. Biederman)
To: Nikolay Borisov <n.borisov.lkml@gmail.com>
Cc: Dmitry Vyukov <dvyukov@google.com>, avagin <avagin@openvz.org>,
serge@hallyn.com, Kees Cook <keescook@chromium.org>,
Al Viro <viro@zeniv.linux.org.uk>,
LKML <linux-kernel@vger.kernel.org>,
syzkaller <syzkaller@googlegroups.com>
Subject: Re: namespace: deadlock in dec_pid_namespaces
Date: Sat, 21 Jan 2017 13:28:09 +1300 [thread overview]
Message-ID: <87lgu5w92e.fsf@xmission.com> (raw)
In-Reply-To: <fba89f51-5db7-a6e2-2715-eee120146b9e@gmail.com> (Nikolay Borisov's message of "Sat, 21 Jan 2017 00:44:24 +0200")
Nikolay Borisov <n.borisov.lkml@gmail.com> writes:
> On 20.01.2017 20:05, Eric W. Biederman wrote:
>> Nikolay Borisov <n.borisov.lkml@gmail.com> 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.
Eric
next prev parent reply other threads:[~2017-01-21 0:33 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-20 13:07 namespace: deadlock in dec_pid_namespaces Dmitry Vyukov
2017-01-20 13:26 ` Nikolay Borisov
2017-01-20 18:05 ` Eric W. Biederman
2017-01-20 22:44 ` Nikolay Borisov
2017-01-21 0:28 ` Eric W. Biederman [this message]
2017-01-23 9:35 ` Dmitry Vyukov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87lgu5w92e.fsf@xmission.com \
--to=ebiederm@xmission.com \
--cc=avagin@openvz.org \
--cc=dvyukov@google.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=n.borisov.lkml@gmail.com \
--cc=serge@hallyn.com \
--cc=syzkaller@googlegroups.com \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.