From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/12930 Path: news.gmane.org!.POSTED!not-for-mail From: Andrei Vagin Newsgroups: gmane.linux.lib.musl.general Subject: Re: [PATCH] mlock2 and memfd_create Date: Fri, 22 Jun 2018 10:58:34 -0700 Message-ID: <20180622175833.GA13498@gmail.com> References: <20180619204314.GU4418@port70.net> <20180622001602.GA13372@gmail.com> <20180622091052.GV4418@port70.net> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r X-Trace: blaine.gmane.org 1529690207 2180 195.159.176.226 (22 Jun 2018 17:56:47 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 22 Jun 2018 17:56:47 +0000 (UTC) User-Agent: Mutt/1.9.3 (2018-01-21) To: musl@lists.openwall.com Original-X-From: musl-return-12946-gllmg-musl=m.gmane.org@lists.openwall.com Fri Jun 22 19:56:43 2018 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1fWQIb-0000Qn-P5 for gllmg-musl@m.gmane.org; Fri, 22 Jun 2018 19:56:41 +0200 Original-Received: (qmail 29990 invoked by uid 550); 22 Jun 2018 17:58:49 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 29960 invoked from network); 22 Jun 2018 17:58:48 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=Qc35NwJMWt42tjUKCZhzNle8jpNLFbog/6lIUWUNQBY=; b=KsestC5yPpGRB0fCQxe6lkI0NdZROf7FmFYxKyr/GqTDk9HwUug9poTGLgeMi7TTDL ttfr5usMSqVqyXCJfbZLFxih9pcMsXi+4Oi0w2a7C24MzRaXGZRx+NdrjDUM1yxmcu0h NO/dxEFyCxP7Jddoff5z+IhJxYFxgTPkyrbf2Ybt+RnSKuRhvDCxpo7zz59nAenWrzvr Napp59rYrEFdkjJ4VKEs2Jia93uLAOLqtfDQtJYDq/yxqkIzDByle/+uXngI8l/LjbXQ vFltd/hWVJdUsdET0zJur3ufo+fj5R/UdaoQu0HisfuJU3XFSjuQTEWv7L1kwH+OrWQ4 43ig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=Qc35NwJMWt42tjUKCZhzNle8jpNLFbog/6lIUWUNQBY=; b=ODo42OXnIZIS64qUsCm34GS8cg8cFRPfBm+Yk/EXDE2NtPc8rbKP6k4niaswyJVQk0 kNVhvQ9PnKlEjal+BqX2eA1duz5qBJL/6hR09QSr4/WCia75flUGpvRzAkazucsmkW+G 7lXLs10M8LZpkzSaHkhMuqFxuk/sccD/o+suDdmG8JSlTeIO9Do1JJQyH2Cqp3rszp3r yOPNvF9FQWaBtg8NcbO8prYnCrNds2l8hPatgNC705G4GpOEmIy6gX6yUXtEy6UejIY2 56BvE2HHoh8flHOC9tT78I8vy87ec3lzV1DOMaFKjIvbrqXMSrv5az+5tfhcgeX3utwo EQjg== X-Gm-Message-State: APt69E3Us2h5RV4vbstQOu31x4JzeWOrhg1VgfHoPit1KwHp8tJWQpK5 drXKET4QE1SiKqML7Bf9p/qAOAaU X-Google-Smtp-Source: ADUXVKINWNb+qOsQ6QDotF6lMW6wX8MFYofYYGYCQbvoeTxk8clNGXi+auJCuW+uMtK7PH0hxBJEqw== X-Received: by 2002:a17:902:2884:: with SMTP id f4-v6mr2707393plb.204.1529690316493; Fri, 22 Jun 2018 10:58:36 -0700 (PDT) Content-Disposition: inline In-Reply-To: <20180622091052.GV4418@port70.net> Xref: news.gmane.org gmane.linux.lib.musl.general:12930 Archived-At: On Fri, Jun 22, 2018 at 11:10:52AM +0200, Szabolcs Nagy wrote: > * Andrei Vagin [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