----- On Apr 13, 2016, at 11:39 AM, Mathieu Desnoyers mathieu.desnoyers@xxxxxxxxxxxx wrote: > ----- On Apr 13, 2016, at 8:57 AM, Richard W.M. Jones rjones@xxxxxxxxxx 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. Thanks, Mathieu > This could also allow quickly blocking and unblocking > signal delivery from user-space by storing a mask to this TLS area. > > The kernel could then look into the signal mask in this TLS area whenever > it needs to deliver a signal (assuming this code path can take > user-space faults), in addition to the mask kept within the > task struct. > > This "tls cache" idea could also apply to setting a CPU affinity to the > currently running CPU for short user-space critical sections. > > The benefit here is to get _very_ fast operations on the thread umask > and cpu affinity. > > Are those ideas too far-fetched ? > > Thanks, > > Mathieu > >> >> Another approach to this has been attempted before, adding something >> to /proc, although it didn't go anywhere. See: >> >> http://comments.gmane.org/gmane.linux.kernel/1292109 >> >> Another way to solve this would be to add a thread-safe getumask to >> glibc. Since glibc could own the mutex, this would permit libraries >> linked to this glibc to read umask safely. >> >> I should also note that man-pages documents getumask(3), but no >> version of glibc has ever implemented it. >> >> Typical test script: >> >> #include <stdio.h> >> #include <stdlib.h> >> #include <linux/unistd.h> >> #include <sys/syscall.h> >> >> int main(int argc, char *argv[]) >> { >> int r = syscall(329); >> if (r == -1) { >> perror("getumask"); >> exit(1); >> } >> printf("umask = %o\n", r); >> exit(0); >> } >> >> $ ./getumask >> umask = 22 >> >> Rich. > > -- > Mathieu Desnoyers > EfficiOS Inc. > http://www.efficios.com -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
