Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752379AbcDMPjf (ORCPT ); Wed, 13 Apr 2016 11:39:35 -0400 Received: from mail.efficios.com ([78.47.125.74]:47686 "EHLO mail.efficios.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752333AbcDMPje (ORCPT ); Wed, 13 Apr 2016 11:39:34 -0400 Date: Wed, 13 Apr 2016 15:39:22 +0000 (UTC) From: Mathieu Desnoyers To: "Richard W.M. Jones" Cc: linux-kernel@vger.kernel.org, Thomas Gleixner , mingo@redhat.com, "H. Peter Anvin" , Andrew Morton , luto@kernel.org, viro@zeniv.linux.org.uk, zab@redhat.com, emunson@akamai.com, "Paul E. McKenney" , Andrea Arcangeli , josh@joshtriplett.org, Pavel Emelyanov , sfr@canb.auug.org.au, Milosz Tanski , rostedt , arnd@arndb.de, ebiederm@xmission.com, gorcunov , iulia manda21 , dave hansen , mguzik@redhat.com, adobriyan@gmail.com, Davidlohr Bueso , linux-api , gorcunov@gmail.com, fw@deneb.enyo.de, Linus Torvalds Message-ID: <2143735451.55767.1460561962122.JavaMail.zimbra@efficios.com> In-Reply-To: <1460552272-15985-1-git-send-email-rjones@redhat.com> References: <1460552272-15985-1-git-send-email-rjones@redhat.com> Subject: Re: [PATCH v2 0/2] vfs: Define new syscall getumask. MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [78.47.125.74] X-Mailer: Zimbra 8.6.0_GA_1178 (ZimbraWebClient - FF45 (Linux)/8.6.0_GA_1178) Thread-Topic: Define new syscall getumask. Thread-Index: Vjx/H6ltHl+QU/SfuzergQydQLba1w== Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2437 Lines: 84 ----- 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. 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 > #include > #include > #include > > 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