From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk0-f198.google.com (mail-qk0-f198.google.com [209.85.220.198]) by kanga.kvack.org (Postfix) with ESMTP id D1CBA6B0253 for ; Mon, 18 Jul 2016 00:43:51 -0400 (EDT) Received: by mail-qk0-f198.google.com with SMTP id k16so185958935qke.3 for ; Sun, 17 Jul 2016 21:43:51 -0700 (PDT) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com. [2607:f8b0:400c:c05::234]) by mx.google.com with ESMTPS id 21si1236205vkm.114.2016.07.17.21.43.51 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 17 Jul 2016 21:43:51 -0700 (PDT) Received: by mail-vk0-x234.google.com with SMTP id x130so224173586vkc.0 for ; Sun, 17 Jul 2016 21:43:51 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20160714080701.GA14613@gmail.com> References: <20160708071810.GA27457@gmail.com> <577FD587.6050101@sr71.net> <20160709083715.GA29939@gmail.com> <5783AE8F.3@sr71.net> <5783BFB0.70203@intel.com> <20160713075550.GA515@gmail.com> <20160714080701.GA14613@gmail.com> From: Andy Lutomirski Date: Sun, 17 Jul 2016 21:43:31 -0700 Message-ID: Subject: Re: [PATCH 6/9] x86, pkeys: add pkey set/get syscalls Content-Type: text/plain; charset=UTF-8 Sender: owner-linux-mm@kvack.org List-ID: To: Ingo Molnar Cc: Dave Hansen , Thomas Gleixner , Dave Hansen , Al Viro , X86 ML , Hugh Dickins , Andrew Morton , Linux API , Mel Gorman , Linus Torvalds , linux-arch , "linux-mm@kvack.org" , Arnd Bergmann , Peter Zijlstra , "linux-kernel@vger.kernel.org" , "H. Peter Anvin" On Thu, Jul 14, 2016 at 1:07 AM, Ingo Molnar wrote: > > * Andy Lutomirski wrote: > >> On Wed, Jul 13, 2016 at 12:56 AM, Ingo Molnar wrote: >> > >> > * Andy Lutomirski wrote: >> > >> >> > If we push a PKRU value into a thread between the rdpkru() and wrpkru(), we'll >> >> > lose the content of that "push". I'm not sure there's any way to guarantee >> >> > this with a user-controlled register. >> >> >> >> We could try to insist that user code uses some vsyscall helper that tracks >> >> which bits are as-yet-unassigned. That's quite messy, though. >> > >> > Actually, if we turned the vDSO into something more like a minimal user-space >> > library with the ability to run at process startup as well to prepare stuff >> > then it's painful to get right only *once*, and there will be tons of other >> > areas where a proper per thread data storage on the user-space side would be >> > immensely useful! >> >> Doing this could be tricky: how exactly is the vDSO supposed to find per-thread >> data without breaking existing glibc? > > So I think the way this could be done is by allocating it itself. The vDSO vma > itself is 'external' to glibc as well to begin with - this would be a small > extension to that concept. But how does the vdso code find it? FS and GS are both spoken for by existing userspace. --Andy -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org