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

On Apr 13, 2016 2:01 PM, "Mathieu Desnoyers"
[off-list ref] wrote:

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

quoted

----- 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.

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