Re: [PATCH v2 0/2] vfs: Define new syscall getumask.

----- On Apr 13, 2016, at 11:39 AM, Mathieu Desnoyers mathieu.desnoyers-vg+e7yoeK/dWk0Htik3J/w@public.gmane.org wrote:

----- On Apr 13, 2016, at 8:57 AM, Richard W.M. Jones rjones-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org wrote:

quoted

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

quoted

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