Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932489AbcDNR5B (ORCPT ); Thu, 14 Apr 2016 13:57:01 -0400 Received: from mail-ob0-f170.google.com ([209.85.214.170]:33659 "EHLO mail-ob0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753330AbcDNR47 (ORCPT ); Thu, 14 Apr 2016 13:56:59 -0400 MIME-Version: 1.0 In-Reply-To: <1736004700.56566.1460581285951.JavaMail.zimbra@efficios.com> References: <1460552272-15985-1-git-send-email-rjones@redhat.com> <2143735451.55767.1460561962122.JavaMail.zimbra@efficios.com> <1736004700.56566.1460581285951.JavaMail.zimbra@efficios.com> From: Andy Lutomirski Date: Thu, 14 Apr 2016 10:56:38 -0700 Message-ID: Subject: Re: [PATCH v2 0/2] vfs: Define new syscall getumask. To: Mathieu Desnoyers Cc: Thomas Gleixner , Pavel Emelyanov , Andrew Morton , Florian Weimer , Josh Triplett , iulia manda21 , Cyrill Gorcunov , Alexey Dobriyan , dave hansen , gorcunov , Stephen Rothwell , Ingo Molnar , Eric B Munson , "Eric W. Biederman" , linux-api , rostedt , Linus Torvalds , Andrea Arcangeli , mguzik , "Paul E. McKenney" , "Richard W.M. Jones" , Arnd Bergmann , zab , "linux-kernel@vger.kernel.org" , Davidlohr Bueso , Milosz Tanski , Al Viro , "H. Peter Anvin" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1813 Lines: 49 On Apr 13, 2016 2:01 PM, "Mathieu Desnoyers" wrote: > > ----- On Apr 13, 2016, at 11:39 AM, Mathieu Desnoyers mathieu.desnoyers@efficios.com wrote: > > > ----- On Apr 13, 2016, at 8:57 AM, Richard W.M. Jones rjones@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