Hi!
A year ago, I wrote a small mlockall()-wrapper ("noswap") to make
certain programs unswappable. It used to work perfectly, until I
upgraded to kernel 2.6.x (2.6.13.1 in my case, but that shouldn't
matter), which made the mlockall() execute without error, but also
without any effect (the "L" in the STAT column of "ps axf" which
indicates locked pages is missing).
The complete program source and the strace log of
strace -v -f -s 4096 noswap sleep 9999
is here:
http://marc-jano.de/tmp/noswap-10935/
Here are the most important lines:
-----< snip >-----
/* mark process as unswappable for all times */
if (ret = mlockall (MCL_CURRENT | MCL_FUTURE))
perror ("mlockall()");
/* give up root privileges */
if (ret = setuid (getuid()) ) { perror ("setuid()"); exit (ret); };
if (ret = setgid (getgid()) ) { perror ("setgid()"); exit (ret); };
/* execute program */
if (ret = execvp (argv[1], exec_argv)) perror ("execvp()");
exit (ret);
-----< snip >-----
The strace log shows that mlockall() returns with no error.
If I replace the execvp() call with a sleep(9999), then the current
process (noswap) is properly locked, as can be checked by looking
for a capital "L" in the ps STAT column.
So it seems that the mlockall() flags are not passed somehow when
using execvp().
Best regards
Marc-Jano (not subscribed to the list, so for further questions,
please Cc:)
Marc-Jano Knopp <[email protected]> wrote:
>
> Hi!
>
> A year ago, I wrote a small mlockall()-wrapper ("noswap") to make
> certain programs unswappable. It used to work perfectly, until I
> upgraded to kernel 2.6.x (2.6.13.1 in my case, but that shouldn't
> matter), which made the mlockall() execute without error, but also
> without any effect (the "L" in the STAT column of "ps axf" which
> indicates locked pages is missing).
>
Question is: what kernel version did you upgrade from?
Prior to 2.4.18 the kernel would allow MCL_FUTURE to propagate into child
processes. But that was disabled in 2.4.18 and later. I seem to recall
that we did this because inheriting MCL_FUTURE is standards-incorrect.
On Mon, 19 Dec 2005 at 02:21 (-0800), Andrew Morton wrote:
> Marc-Jano Knopp <[email protected]> wrote:
> >
> > A year ago, I wrote a small mlockall()-wrapper ("noswap") to make
> > certain programs unswappable. It used to work perfectly, until I
> > upgraded to kernel 2.6.x (2.6.13.1 in my case, but that shouldn't
> > matter), which made the mlockall() execute without error, but also
> > without any effect (the "L" in the STAT column of "ps axf" which
> > indicates locked pages is missing).
> >
>
> Question is: what kernel version did you upgrade from?
2.4.31. Just rebooted to 2.4.31 and tried again - mlockall() seems to
work perfectly:
# ps axf|grep [9]99
1037 tty1 SL+ 0:00 \_ sleep 999
# uname -a
Linux pc8 2.4.31 #3 Thu Sep 8 16:49:45 CEST 2005 i686 unknown
#
> Prior to 2.4.18 the kernel would allow MCL_FUTURE to propagate into child
> processes. But that was disabled in 2.4.18 and later. I seem to recall
> that we did this because inheriting MCL_FUTURE is standards-incorrect.
Oh! So how can I make programs unswappable with kernel 2.6.x then?
Best regards
Marc-Jano
On Mon, 2005-12-19 12:42:31 +0100, Marc-Jano Knopp <[email protected]> wrote:
> On Mon, 19 Dec 2005 at 02:21 (-0800), Andrew Morton wrote:
> > Marc-Jano Knopp <[email protected]> wrote:
> > > A year ago, I wrote a small mlockall()-wrapper ("noswap") to make
> > > certain programs unswappable. It used to work perfectly, until I
> > > upgraded to kernel 2.6.x (2.6.13.1 in my case, but that shouldn't
> > > matter), which made the mlockall() execute without error, but also
> > > without any effect (the "L" in the STAT column of "ps axf" which
> > > indicates locked pages is missing).
> > Prior to 2.4.18 the kernel would allow MCL_FUTURE to propagate into child
> > processes. But that was disabled in 2.4.18 and later. I seem to recall
> > that we did this because inheriting MCL_FUTURE is standards-incorrect.
>
> Oh! So how can I make programs unswappable with kernel 2.6.x then?
That would mean that you cannot just exec() another program that will
also be mlockall()ed. The new program has to do that on its own...
MfG, JBG
--
Jan-Benedict Glaw [email protected] . +49-172-7608481 _ O _
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O
für einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
On Llu, 2005-12-19 at 18:27 +0100, Jan-Benedict Glaw wrote:
> > > that we did this because inheriting MCL_FUTURE is standards-incorrect.
> >
> > Oh! So how can I make programs unswappable with kernel 2.6.x then?
>
> That would mean that you cannot just exec() another program that will
> also be mlockall()ed. The new program has to do that on its own...
mlockall MCL_FUTURE applies to this image only and the 2.6 behaviour is
correct if less useful in some ways. It would be possible to add an
inheriting MCL_ flag that was Linux specific but then how do you control
the depth of inheritance ? If that isn't an issue it looks the easiest.
Another possibility would be pmlockall(pid, flag), but that looks even
more nasty if it races an exec.
On Mon, 2005-12-19 at 17:47 +0000, Alan Cox wrote:
> On Llu, 2005-12-19 at 18:27 +0100, Jan-Benedict Glaw wrote:
> > > > that we did this because inheriting MCL_FUTURE is standards-incorrect.
> > >
> > > Oh! So how can I make programs unswappable with kernel 2.6.x then?
> >
> > That would mean that you cannot just exec() another program that will
> > also be mlockall()ed. The new program has to do that on its own...
>
> mlockall MCL_FUTURE applies to this image only and the 2.6 behaviour is
> correct if less useful in some ways. It would be possible to add an
> inheriting MCL_ flag that was Linux specific but then how do you control
> the depth of inheritance ? If that isn't an issue it looks the easiest.
>
> Another possibility would be pmlockall(pid, flag), but that looks even
> more nasty if it races an exec.
How about clearing MCL_FUTURE on fork but allow exec to inherit it?
That way a parent process could fork, mlockall in the child and exec a
memlocked child. A regular fork,exec by a memlocked parent would not
create a memlocked child.
Seems less messy than a new flag, while keeping the benefits.
--
Zan Lynx <[email protected]>
On Llu, 2005-12-19 at 11:38 -0700, Zan Lynx wrote:
> How about clearing MCL_FUTURE on fork but allow exec to inherit it?
> That way a parent process could fork, mlockall in the child and exec a
> memlocked child. A regular fork,exec by a memlocked parent would not
> create a memlocked child.
>
> Seems less messy than a new flag, while keeping the benefits.
The behaviour of MCL_FUTURE is standards defined so we don't get to
change it. The behaviour of an added flag is up to us.