mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Szabolcs Nagy <nsz@port70.net>
To: musl@lists.openwall.com
Subject: Re: [PATCH] mlock2 and memfd_create
Date: Fri, 22 Jun 2018 20:25:22 +0200	[thread overview]
Message-ID: <20180622182522.GW4418@port70.net> (raw)
In-Reply-To: <20180622175833.GA13498@gmail.com>

* Andrei Vagin <avagin@gmail.com> [2018-06-22 10:58:34 -0700]:
> 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.
> 
> 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


  reply	other threads:[~2018-06-22 18:25 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-19 20:43 Szabolcs Nagy
2018-06-22  0:16 ` Andrei Vagin
2018-06-22  9:10   ` Szabolcs Nagy
2018-06-22 17:58     ` Andrei Vagin
2018-06-22 18:25       ` Szabolcs Nagy [this message]
2018-06-22 19:02     ` Rich Felker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180622182522.GW4418@port70.net \
    --to=nsz@port70.net \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).