Re: [PATCH] mlock2 and memfd_create

[Rich Felker <dalias@libc.org>]

On Fri, Jun 22, 2018 at 11:10:52AM +0200, Szabolcs Nagy wrote:
> * Andrei Vagin <avagin@gmail.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.

Generally my leaning is not to program around seccomp, and further to
treat seccomp filters that forbid one operation but allow a
semantically-equivalent (or even logical-permissions-equivalent) one
as a bug in the seccomp filter. Yes that does make a little bit more
work for anyone writing seccomp filters, but it's positive work --
it's making the filters more-portable, less-specific to a particular
libc implementation.

Rich