From: Andrew Morton <akpm@linux-foundation.org>
To: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: Bryan Donlan <bdonlan@gmail.com>,
linux-kernel@vger.kernel.org, Ulrich Drepper <drepper@redhat.com>,
linux-api@vger.kernel.org, Timo Sirainen <tss@iki.fi>
Subject: Re: [resend][PATCH] Added PR_SET_PROCTITLE_AREA option for prctl()
Date: Fri, 9 Oct 2009 23:39:35 -0700 [thread overview]
Message-ID: <20091009233935.1be0edf9.akpm@linux-foundation.org> (raw)
In-Reply-To: <2f11576a0910092332s6e0e3dcs35864e3a2164be0@mail.gmail.com>
On Sat, 10 Oct 2009 15:32:35 +0900 KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> wrote:
> >>> The solution is to use the seqlock to detect this, and prevent the
> >>> secret information from ever making it back to process B's userspace.
> >>> Note that it's not enough to just recheck arg_start, as process A may
> >>> reassign the proctitle area back to its original position after having
> >>> it somewhere else for a while.
> >>
> >> Well seqlock is _a_ solution. __Another is to use a mutex or an rwsem
> >> around the whole operation.
> >>
> >> With the code as you propose it, what happens if a process sits in a
> >> tight loop running setproctitle? __Do other processes running `ps' get
> >> stuck in a livelock until the offending process gets scheduled out?
> >
> > It does seem like a maximum spin count should be put in there - and
> > maybe a timeout as well (since with FUSE etc it's possible to engineer
> > page faults that take arbitrarily long).
> > Also, it occurs to me that:
>
> makes sense.
> I like maximum spin rather than timeout.
Start simple. What's wrong with mutex_lock() on the reader and writer
sides? rwsems might be OK too.
In both cases we should think about whether persistent readers can
block the writer excessively though.
next prev parent reply other threads:[~2009-10-10 6:40 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-09 4:50 [resend][PATCH] Added PR_SET_PROCTITLE_AREA option for prctl() KOSAKI Motohiro
2009-10-10 0:13 ` Andrew Morton
2009-10-10 2:22 ` Bryan Donlan
2009-10-10 2:42 ` Andrew Morton
2009-10-10 2:57 ` Bryan Donlan
2009-10-10 6:32 ` KOSAKI Motohiro
2009-10-10 6:39 ` Andrew Morton [this message]
2009-10-12 19:03 ` KOSAKI Motohiro
2009-10-12 19:22 ` Andrew Morton
2009-10-13 0:03 ` KOSAKI Motohiro
2009-10-10 7:11 ` Bryan Donlan
2009-10-12 19:03 ` KOSAKI Motohiro
2009-10-12 19:33 ` Bryan Donlan
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=20091009233935.1be0edf9.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=bdonlan@gmail.com \
--cc=drepper@redhat.com \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tss@iki.fi \
/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