| Message ID | 20190522112329.GA25483@er01809n.ebgroup.elektrobit.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | mm: mlockall error for flag MCL_ONFAULT | expand |
[ 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 <daniel.m.jordan@oracle.com> [1] https://sources.debian.org/src/stress-ng/0.09.50-1/stress-mlock.c/?hl=203#L203
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 <daniel.m.jordan@oracle.com> > > [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 <mhocko@suse.com> Thanks!
diff --git a/mm/mlock.c b/mm/mlock.c index e492a155c51a..03f39cbdd4c4 100644 --- a/mm/mlock.c +++ b/mm/mlock.c @@ -797,7 +797,8 @@ SYSCALL_DEFINE1(mlockall, int, flags) unsigned long lock_limit; int ret; - if (!flags || (flags & ~(MCL_CURRENT | MCL_FUTURE | MCL_ONFAULT))) + if (!flags || (flags & ~(MCL_CURRENT | MCL_FUTURE | MCL_ONFAULT)) || + flags == MCL_ONFAULT) return -EINVAL; if (!can_do_mlock())
If mlockall() is called with only MCL_ONFAULT as flag, it removes any previously applied lockings and does nothing else. This behavior is counter-intuitive and doesn't match the Linux man page. Consequently, return the error EINVAL, if only MCL_ONFAULT is passed. That way, applications will at least detect that they are calling mlockall() incorrectly. Fixes: b0f205c2a308 ("mm: mlock: add mlock flags to enable VM_LOCKONFAULT usage") Signed-off-by: Stefan Potyra <Stefan.Potyra@elektrobit.com> --- Sparse shows a warning for mlock.c, but it is not related to this patch. mm/mlock.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)