[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180622175833.GA13498@gmail.com>
Date: Fri, 22 Jun 2018 10:58:34 -0700
From: Andrei Vagin <avagin@...il.com>
To: musl@...ts.openwall.com
Subject: Re: [PATCH] mlock2 and memfd_create
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.
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.
