Bug 1048 - Linux gets the swap info all wrong when pushed...
Summary: Linux gets the swap info all wrong when pushed...
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel
Version: 5.1
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: David Lawrence
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 1999-02-05 00:32 UTC by keybounce
Modified: 2008-05-01 15:37 UTC (History)
0 users

Clone Of:
Last Closed: 1999-04-10 03:03:51 UTC

Attachments (Terms of Use)

Description keybounce 1999-02-05 00:32:55 UTC
And I do mean pushed.

Repeat by:
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
perfect match).

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,
"killall bash".

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
time :-)

Comment 1 Michael K. Johnson 1999-04-10 03:03:59 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.