On Sat, 10 Oct 2009 15:32:35 +0900 KOSAKI Motohiro <[email protected]> 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. -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
