Date: Tue, 19 Jun 2018 21:11:34 -0400 From: Rich Felker <dalias@...c.org> To: musl@...ts.openwall.com Subject: Re: [PATCH 00/16] Linux v4.16 and v4.17 updates On Tue, Jun 19, 2018 at 09:55:17PM +0200, Szabolcs Nagy wrote: > * Rich Felker <dalias@...c.org> [2018-06-19 13:33:15 -0400]: > > On Fri, Jun 15, 2018 at 01:03:38AM +0200, Szabolcs Nagy wrote: > > > From 45493abeb3918e3722ef8d75bf231ef155a2b755 Mon Sep 17 00:00:00 2001 > > > From: Szabolcs Nagy <nsz@...t70.net> > > > Date: Sat, 9 Jun 2018 23:22:51 +0000 > > > Subject: [PATCH 15/16] add si_codes from linux v4.17 > > > > > > target specific si_codes were made generic in linux commits > > > a402ab8cc7b0578c445f348c9010e62ab390bee8 (ia64) and > > > 75abf64287cab73546382a4fa7fa2f4e3516efeb (parisc) > > > --- > > > include/signal.h | 13 +++++++++++++ > > > 1 file changed, 13 insertions(+) > > > > > > diff --git a/include/signal.h b/include/signal.h > > > index a4f85cca..69395468 100644 > > > --- a/include/signal.h > > > +++ b/include/signal.h > > > @@ -61,6 +61,13 @@ typedef struct sigaltstack stack_t; > > > #define FPE_FLTRES 6 > > > #define FPE_FLTINV 7 > > > #define FPE_FLTSUB 8 > > > +#define __FPE_DECOVF 9 > > > +#define __FPE_DECDIV 10 > > > +#define __FPE_DECERR 11 > > > +#define __FPE_INVASC 12 > > > +#define __FPE_INVDEC 13 > > > +#define FPE_FLTUNK 14 > > > +#define FPE_CONDTRAP 15 > > > > > > #define ILL_ILLOPC 1 > > > #define ILL_ILLOPN 2 > > > @@ -70,11 +77,17 @@ typedef struct sigaltstack stack_t; > > > #define ILL_PRVREG 6 > > > #define ILL_COPROC 7 > > > #define ILL_BADSTK 8 > > > +#define ILL_BADIADDR 9 > > > +#define __ILL_BREAK 10 > > > +#define __ILL_BNDMOD 11 > > > > Is there a reason some of these are __-prefixed? They don't need too > > be (FPE_* and ILL_* are reserved for signal.h) and it seems wrong that > > macros intended to be used by the application are in the > > reserved-for-implementation-use namespace rather than the public one > > for the interface. > > > > this is how linux uapi exposes them > > however it seems glibc has them without __ (and only on ia64) > > i thought glibc included linux uapi but apparently it has its > own thing, so probably it's better if we don't do this. If they're ia64 (itanic) only we can just omit them entirely, I think. > > > From 9e18e6e7854d17aa1639d6145584df27f4b4f856 Mon Sep 17 00:00:00 2001 > > > From: Szabolcs Nagy <nsz@...t70.net> > > > Date: Sat, 28 Apr 2018 17:25:41 +0000 > > > Subject: [PATCH 16/16] Add memfd_create, mlock2 and pkey_* apis > > > > > > This patch adds support for the following linux syscalls and related > > > interfaces following glibc: > > > > > > memfd_create (linux v3.17) > > > mlock2 (linux v4.4) > > > pkey_alloc (linux v4.9) > > > pkey_free (linux v4.9) > > > pkey_mprotect (linux v4.9) > > > pkey_get (glibc 2.27) > > > pkey_set (glibc 2.27) > > > > > > pkey_get / pkey_set are glibc apis, not syscalls, only an always > > > failing generic implementation is provided in this patch, for pkey_ > > > apis to be useful these will need target specific implementations. > > > > > > MLOCK_ONFAULT is moved under _GNU_SOURCE following glibc. > > > > > > Similar to glibc, mlock2 and pkey_mprotect have fallbacks to mlock and > > > mprotect respectively in case of special arguments. > > > > I'm holding off on this one just because I don't understand the pkey > > stuff, and it looks like it's not actually functional without > > additional arch-specific code. > > > > It might also make sense to split this into 2 or 3 patches, since > > memfd_create and mlock2 seem like separate, simple functionality > > unrelated to the pkey stuff. > > > > ok, i'll split those out. Sounds good. Then I can merge the trivial ones and we can discuss the pkey stuff and what the requirements for a working implementation are. Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.