[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180622182522.GW4418@port70.net>
Date: Fri, 22 Jun 2018 20:25:22 +0200
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com
Subject: Re: [PATCH] mlock2 and memfd_create
* Andrei Vagin <avagin@...il.com> [2018-06-22 10:58:34 -0700]:
> On Fri, Jun 22, 2018 at 11:10:52AM +0200, Szabolcs Nagy wrote:
> > * Andrei Vagin <avagin@...il.com> [2018-06-21 17:16:03 -0700]:
> > > On Tue, Jun 19, 2018 at 10:43:14PM +0200, Szabolcs Nagy wrote:
> > > > +
> > > > +int mlock2(const void *addr, size_t len, unsigned flags)
> > > > +{
> > > > + if (flags == 0)
> > > > + return mlock(addr, len);
> > > > + return syscall(SYS_mlock2, addr, len, flags);
> > >
> > > I would prefer another way to support old kernels:
> > >
> > > int ret;
> > >
> > > ret = syscall(SYS_mlock2, addr, len, flags);
> > > if (ret == -1 && errno == ENOSYS && flags == 0)
> > > return mlock(addr, len);
> > > return ret;
> > >
> > > This way works a bit slower on old kernels, but it doesn't have side
> > > effects if mlock2 is supported.
> > >
> > > For example, the user can set seccomp rules, and he will not expect that
> > > the mlock syscall will be executed, when he calls mlock2() in a code.
> > >
> >
> > mlock2 is documented to be equivalent to mlock if flags==0,
> > the glibc logic is the same and seccomp (or whatever else
> > operating on the syscall layer) has to deal with mlock
> > anyway (unless we change the mlock implementation too).
> > so i would not be too worried about this.
>
> Glibc has the __ASSUME_MLOCK2 option, and if it is set only mlock2() is
> used. Modern distributions will probably build glibc with this option.
> I mean the glibc logic isn't exectly the same. And a concern about
> seccomp is still valid.
>
glibc sets __ASSUME_MLOCK2 to true when the minimum required kernel
version is linux v4.4 and then glibc stops working on older kernels.
i don't know what distros set the minimum version to (the default
is 3.2.0 and i don't expect it to be set higher by distros otherwise
running in a container on a stable host with old kernel would fail),
but musl tries not to break behaviour on older kernels whenever
possible, so there is no minimum required kernel version, i.e. musl
is equivalent to glibc with all __ASSUME_* set to false.
> Anyway, I don't have strong objections about this patch, I just suggest
> another way how it can be done and, from my point of view, it is better.
>
> Thanks,
> Andrei
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.
