From: David Howells <dhowells@redhat.com>
To: Roland McGrath <roland@redhat.com>
Cc: dhowells@redhat.com, Oleg Nesterov <oleg@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
James Morris <jmorris@namei.org>,
Tom Horsley <tom.horsley@att.net>,
linux-kernel@vger.kernel.org, stable@kernel.org
Subject: Re: [PATCH 1/1] exec: do not sleep in TASK_TRACED under ->cred_guard_mutex
Date: Fri, 04 Sep 2009 09:43:40 +0100 [thread overview]
Message-ID: <30013.1252053820@redhat.com> (raw)
In-Reply-To: <20090903200924.E46DF47C94@magilla.sf.frob.com>
Roland McGrath <roland@redhat.com> wrote:
> I certainly think it's right to hold the mutex only as long as necessary.
> Clearly holding it when we stop is wrong.
As far as I can tell, we don't hold it when we stop for debugging, or stop on
signal.
> I'm a bit concerned about holding it for arbitrary periods while we block
> in the filesystem code. e.g., consider the scenario with a hangs-forever
> NFS server or suchlike. But I'm not sure there is a reasonable way around
> that one.
If you drop the sem before committing the creds, you have to recalculate the
new credentials.
> The paired calls that leave the mutex locked in between should have some
> clear comments calling attention to their pairing. Aside from that making
> sure that subtlety is clear, I don't see any problems in the patch off hand.
> But I haven't scoured the code path lately to have full confidence.
> I'd like to hear David's reactions.
Looking at the patch description, I don't see how the patch it relevant to the
problem. There must be something else, either a call that's now being
skipped, or it's a matter of timing.
David
next prev parent reply other threads:[~2009-09-04 8:45 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-03 16:05 [PATCH 1/1] exec: do not sleep in TASK_TRACED under ->cred_guard_mutex Oleg Nesterov
2009-09-03 20:09 ` Roland McGrath
2009-09-04 8:43 ` David Howells [this message]
2009-09-04 13:39 ` Oleg Nesterov
2009-09-04 14:47 ` David Howells
2009-09-04 15:49 ` Oleg Nesterov
2009-09-04 17:26 ` [PATCH v3] " Oleg Nesterov
2009-09-04 19:42 ` Andrew Morton
2009-09-04 21:33 ` Oleg Nesterov
2009-09-09 21:57 ` Chuck Ebbert
2009-09-09 22:58 ` Oleg Nesterov
2009-09-04 8:39 ` [PATCH 1/1] " David Howells
2009-09-04 9:24 ` Roland McGrath
2009-09-04 12:46 ` Oleg Nesterov
2009-09-04 13:39 ` David Howells
2009-09-04 13:55 ` Oleg Nesterov
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=30013.1252053820@redhat.com \
--to=dhowells@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=jmorris@namei.org \
--cc=linux-kernel@vger.kernel.org \
--cc=oleg@redhat.com \
--cc=roland@redhat.com \
--cc=stable@kernel.org \
--cc=tom.horsley@att.net \
--cc=torvalds@linux-foundation.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 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.