From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 95830 invoked by alias); 16 May 2018 15:18:55 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 95806 invoked by uid 89); 16 May 2018 15:18:54 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.1 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,KAM_SHORT,RDNS_DYNAMIC,TVD_RCVD_IP autolearn=no version=3.3.2 spammy=rights X-HELO: brightrain.aerifal.cx Date: Wed, 16 May 2018 15:18:00 -0000 From: Rich Felker To: Florian Weimer Cc: Szabolcs Nagy , mtk.manpages@gmail.com, nd@arm.com, linux-man@vger.kernel.org, GNU C Library Subject: Re: glibc and linux-man disagrees about pkey_alloc Message-ID: <20180516151844.GX1392@brightrain.aerifal.cx> References: <1f2551f3-3d6d-3905-433e-967af2c3be87@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1f2551f3-3d6d-3905-433e-967af2c3be87@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-SW-Source: 2018-05/txt/msg00622.txt.bz2 On Wed, May 16, 2018 at 04:36:03PM +0200, Florian Weimer wrote: > On 05/16/2018 01:10 PM, Szabolcs Nagy wrote: > >glibc sysdeps/unix/sysv/linux/bits/mman-shared.h: > > > >int pkey_alloc (unsigned int __flags, unsigned int > >__access_rights) __THROW; > > > >linux-man http://man7.org/linux/man-pages/man2/pkey_alloc.2.html : > > > >int pkey_alloc(unsigned long flags, unsigned long access_rights); > > > >i assume the documentation should be fixed (as the glibc > >code is already in use) > > unsigned long on the kernel side is unsigned long long in userspace > for the x32 variant of x86-64, so the kernel types aren't that > helpful for describing the user-space interface in an > architecture-independent fashion. I expect the flags to be > consistent across architectures, so there can only be 32 of them > anyway, and access rights currently use two bits on x86 (and three > on POWER, I think). There's possibly some argument to be made that by the time 32 bits are filled, 32-bit archs will be legacy-only and won't be getting new pkey hardware features, in which case having the full 64 bits available would be nice... But I don't really care what decision is made as long as it's consistent. Rich