Red Hat Bugzilla – Bug 1048
Linux gets the swap info all wrong when pushed...
Last modified: 2008-05-01 11:37:49 EDT
And I do mean pushed.
1. Have two swap paritions, both 127MB.
2. create /tmp/loop, containing:
while :; do /tmp/loop ; done
3. Be in X-windows, with a loadaverage window open.
(Yes, the idea of this was just to watch the exponential
decay. It really is identical shape all the way down the
tail, until the scaling factor gets in the way (when the
indicated load-max goes to about 15-20, it stops being a
4. As root, run /tmp/loop.
5. Hit ctrl-Z along the way when the system gets sluggish.
6. Resume it, and let it run until you get the message "fork
failed -- resource temporarily unavailable". (Like I said, I
pushed the kernel for this one)
7. Somewhere around here, a ctrl-C brought me back to a
prompt, but did not kill all of the loops. One still ran.
This step is not as clear from memory.
8. As soon as you realize that the load is still going up,
9. When you eventually get a prompt back, and the load
starts dropping, there are a lot of mode S bash's still on
the process chart. Swapfile space used (from /proc/meminfo)
is over 121 MB.
10. kill the X server.
11. At the console: A lot of mode S (sleeping, waiting for
something) bash's, with sequential process ID's. Occasional
(every 60 seconds or so) messages from rpc_doio or rpc_send
saying "sending evil packet" with a packet hex dump.
12. Try to kill one of those S mode bash's: get a stream of
messages from the kernel about invalid swap file maps.
swap_free: swap space map bad (entry 00xxxxxx)
13. Next step is to reboot, but not to try this a second
This fork bomb attack will probably succeed less well against a
2.2.x kernel than a 2.0.x kernel but yes, much more so with some
hardware than other hardware, it is possible to get effects like
this. I've marked this fixed because I think that the later
kernel we released as part of 5.2 fixed some bugs that might be
related to this, and because the 2.2.x kernels have many more
improvements in the way the deal with swap.
If you have users who are crashing machines like this, disabling
their accounts is a good option; instituting process and cpu
limits is another option if the first is not open to you. I hope
that is useful information.