Bug 1048

Summary: Linux gets the swap info all wrong when pushed...
Product: [Retired] Red Hat Linux Reporter: keybounce
Component: kernelAssignee: David Lawrence <dkl>
Status: CLOSED CURRENTRELEASE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 5.1   
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 1999-04-10 03:03:51 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

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.