From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michal Hocko Subject: Re: [PATCH] mm: mlockall error for flag MCL_ONFAULT Date: Mon, 27 May 2019 09:04:15 +0200 Message-ID: <20190527070415.GA1658@dhcp22.suse.cz> References: <20190522112329.GA25483@er01809n.ebgroup.elektrobit.com> <20190524214304.enntpu4tvzpyxzfe@ca-dmjordan1.us.oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Content-Disposition: inline In-Reply-To: <20190524214304.enntpu4tvzpyxzfe@ca-dmjordan1.us.oracle.com> Sender: linux-kernel-owner@vger.kernel.org To: Daniel Jordan Cc: "Potyra, Stefan" , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , "Jordan, Tobias" , akpm@linux-foundation.org, vbabka@suse.cz, kirill.shutemov@linux.intel.com, linux-api@vger.kernel.org List-Id: linux-api@vger.kernel.org On Fri 24-05-19 17:43:04, Daniel Jordan wrote: > [ Adding linux-api and some of the people who were involved in the > MCL_ONFAULT/mlock2/etc discussions. Author of the Fixes patch appears to > have moved on. ] > > On Wed, May 22, 2019 at 11:23:37AM +0000, Potyra, Stefan wrote: > > If mlockall() is called with only MCL_ONFAULT as flag, > > it removes any previously applied lockings and does > > nothing else. > > The change looks reasonable. Hard to imagine any application relies on it, and > they really shouldn't be if they are. Debian codesearch turned up only a few > cases where stress-ng was doing this for unknown reasons[1] and this change > isn't gonna break those. In this case I think changing the syscall's behavior > is justified. > > > This behavior is counter-intuitive and doesn't match the > > Linux man page. > > I'd quote it for the changelog: > > For mlockall(): > > EINVAL Unknown flags were specified or MCL_ONFAULT was specified with‐ > out either MCL_FUTURE or MCL_CURRENT. > > With that you can add > > Reviewed-by: Daniel Jordan > > [1] https://sources.debian.org/src/stress-ng/0.09.50-1/stress-mlock.c/?hl=203#L203 Well spotted and the fix looks reasonable as well. Quoting the man page seems useful as well. Acked-by: Michal Hocko Thanks! -- Michal Hocko SUSE Labs