On Apr 13, 2016 2:01 PM, "Mathieu Desnoyers" <mathieu.desnoy...@efficios.com> wrote: > > ----- On Apr 13, 2016, at 11:39 AM, Mathieu Desnoyers > mathieu.desnoy...@efficios.com wrote: > > > ----- On Apr 13, 2016, at 8:57 AM, Richard W.M. Jones rjo...@redhat.com > > wrote: > > > >> v1 -> v2: > >> > >> - Use current_umask() instead of current->fs->umask. > >> > >> - Retested it. > >> > >> ---------------------------------------------------------------------- > >> > >> It's not possible to read the process umask without also modifying it, > >> which is what umask(2) does. A library cannot read umask safely, > >> especially if the main program might be multithreaded. > >> > >> This patch series adds a trivial system call "getumask" which returns > >> the umask of the current process. > > > > In addition to this system call, we could extend a variation of my > > thread_local_abi system call (https://lkml.org/lkml/2016/4/4/455) > > (could be without features flags, or an entirely new system call > > specifically for a umask cache) to register a "current umask" cache > > located in a TLS area. > > > > Basically, reading the current umask value would be a simple load from > > a TLS variable. > > I'm actually discussing 3 separate things here: the umask, sigmask, and > cpu affinity mask. > > Not sure if caching the umask in a TLS would be that useful, though. > The caching idea seems to make more sense for signal mask and cpu > affinity mask. >
I think this is of questionable value. Keep in mind that every feature like this adds overhead to lots of code paths as well as additional complexity. Such features should be justified by big performance benefits. Given that processes can easily track their own umasks and signal masks if they care, I don't see why the kernel would want to help. --Andy
