[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180619195516.GT4418@port70.net>
Date: Tue, 19 Jun 2018 21:55:17 +0200
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com
Subject: Re: [PATCH 00/16] Linux v4.16 and v4.17 updates
* 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.
> > 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.
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.
