From: Ingo Molnar <mingo@elte.hu>
To: Chris Wright <chrisw@osdl.org>
Cc: johansen@immunix.com, Stephen Smalley <sds@epoch.ncsc.mil>,
Thomas Bleher <bleher@informatik.uni-muenchen.de>,
linux-kernel@vger.kernel.org
Subject: Re: [RFC][PATCH] delay rq_lock acquisition in setscheduler
Date: Thu, 21 Oct 2004 09:56:13 +0200 [thread overview]
Message-ID: <20041021075613.GC20573@elte.hu> (raw)
In-Reply-To: <20041020183238.U2357@build.pdx.osdl.net>
* Chris Wright <chrisw@osdl.org> wrote:
> Hi Ingo,
>
> Doing access control checks with rq_lock held can cause deadlock when
> audit messages are created (via printk or audit infrastructure), as
> noted by both SELinux and SubDomain folks. This patch will let the
> security checks happen w/out lock held, then re-sample the p->policy
> in case it was raced. Original patch from John Johansen, with some
> updates from me. What do you think?
i dont this this patch is correct, because it changes semantics by
pushing a security-subsystem failure back into userspace. There's
nothing wrong with two tasks trying to change a third task's policy in
parallel - our API allows that.
I agree that this is a very special case of lock dependency and that the
security subsystem should not be burdened with double-buffering messages
just to avoid the runqueue lock on syslogd wakeup. Only this single
scheduling-related system-call is affected by this problem.
i think the right solution would be to retry the permission check if the
policy has changed (an unlikely event). It is livelockable the same way
seqlocks are livelockable so i'd not worry about it too much. It is also
preemptible with PREEMPT so not a big issue. Also, the check & repeat
code should possibly be #ifdef CONFIG_SECURITY.
Ingo
next prev parent reply other threads:[~2004-10-21 8:07 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-21 1:32 [RFC][PATCH] delay rq_lock acquisition in setscheduler Chris Wright
2004-10-21 2:00 ` Andrea Arcangeli
2004-10-21 5:16 ` Chris Wright
2004-10-21 12:53 ` Andrea Arcangeli
2004-10-21 7:56 ` Ingo Molnar [this message]
2004-10-21 17:25 ` Chris Wright
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=20041021075613.GC20573@elte.hu \
--to=mingo@elte.hu \
--cc=bleher@informatik.uni-muenchen.de \
--cc=chrisw@osdl.org \
--cc=johansen@immunix.com \
--cc=linux-kernel@vger.kernel.org \
--cc=sds@epoch.ncsc.mil \
/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