From: Andrew Morton <akpm@linux-foundation.org>
To: Vasiliy Kulikov <segoon@openwall.com>
Cc: Luis Henriques <henrix@camandro.org>,
Miles Lane <miles.lane@gmail.com>,
LKML <linux-kernel@vger.kernel.org>,
Ingo Molnar <mingo@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Alexey Dobriyan <adobriyan@gmail.com>,
stable@vger.kernel.org
Subject: Re: Linus GIT - INFO: possible circular locking dependency detected
Date: Tue, 8 Nov 2011 15:57:16 -0800 [thread overview]
Message-ID: <20111108155716.33c04ce1.akpm@linux-foundation.org> (raw)
In-Reply-To: <20111105093146.GA14338@albatros>
On Sat, 5 Nov 2011 13:31:46 +0400
Vasiliy Kulikov <segoon@openwall.com> wrote:
> (cc'ed Andrew and Alexey)
>
> On Thu, Nov 03, 2011 at 20:49 +0000, Luis Henriques wrote:
> > On Thu, Nov 03, 2011 at 11:57:20AM -0400, Miles Lane wrote:
> > ...
> >
> > I'm hitting the exact same problem, using a minimal .config file (can send
> > it if required), by just running "find /".
> >
> > I have bisected the problem and found that commit
> > aa6afca5bcaba8101f3ea09d5c3e4100b2b9f0e5 seems to be the cause of it.
Well, let's tell the -stable maintainer(s?) that aa6afca5bca ("proc:
fix races against execve() of /proc/PID/fd**") is known to cause a
regression.
> procfs holds sig->cred_guard_mutex to ensure the target's credentials are
> not changed. It is held for a little timeslice. From the stack trace I
> don't understand how sys_execve() can happen with ->cred_guard_mutex
> held:
>
> static struct dentry *proc_lookupfd_common(struct inode *dir,
> struct dentry *dentry,
> instantiate_t instantiate)
> {
> ...
> if (lock_trace(task))
> goto out;
>
> result = instantiate(dir, dentry, task, &fd);
> unlock_trace(task);
> ...
> }
>
>
> static int lock_trace(struct task_struct *task)
> {
> int err = mutex_lock_killable(&task->signal->cred_guard_mutex);
> if (err)
> return err;
> if (!ptrace_may_access(task, PTRACE_MODE_ATTACH)) {
> mutex_unlock(&task->signal->cred_guard_mutex);
> return -EPERM;
> }
> return 0;
> }
>
> proc_lookupfd_common() always exits without ->cred_guard_mutex held.
>
Yes, it's a strange trace. udev is a strange thing and can be
triggered by the kernel at odd times. I wonder if it's possible that
some other process is now synchronously running udevd while holding
cred_guard_mutex. That wouldn't show up in the backtrace. But I doubt
if lockdep would notice it either...
Either way, it would be prudent to revert aa6afca5bca from mainline if
we can't get this fixed up soon.
next parent reply other threads:[~2011-11-08 23:57 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CAHFgRy8S0xLfhZxTUOEH5A0PL_Fb79-0-gmbQ=9h2D-xMqt1hA@mail.gmail.com>
[not found] ` <20111103204930.GA3599@hades>
[not found] ` <20111105093146.GA14338@albatros>
2011-11-08 23:57 ` Andrew Morton [this message]
2011-11-09 0:17 ` Linus GIT - INFO: possible circular locking dependency detected Greg KH
2011-11-09 0:40 ` Greg KH
2011-11-09 19:11 ` Luis Henriques
2011-11-09 19:52 ` Peter Zijlstra
2011-11-09 20:05 ` Luis Henriques
2011-11-14 17:27 ` Paul E. McKenney
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=20111108155716.33c04ce1.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=adobriyan@gmail.com \
--cc=henrix@camandro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=miles.lane@gmail.com \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=segoon@openwall.com \
--cc=stable@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).