Messages in this thread | | | Date | Fri, 9 Oct 2009 23:39:35 -0700 | From | Andrew Morton <> | Subject | Re: [resend][PATCH] Added PR_SET_PROCTITLE_AREA option for prctl() |
| |
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.
| |