lkml.org 
[lkml]   [2000]   [Oct]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] OOM killer API (was: [PATCH] VM fix for 2.4.0-test9 & OOM handler)
    On Thu, 12 Oct 2000, Matthew Hawkins wrote:

    >
    > Seriously, am I missing something obvious or is it far simpler just to
    > keel over and die if the system goes OOM? I mean, seriously, if the
    > administrator lets it get to that state then he/she/it deserves a dead
    > system. It's akin to having your car run out of petrol - you don't
    > start shooting passengers because their extra load made the engine chew
    > more. You pack up your kitty and go to the nearest petrol station and
    > buy more, plug it into the car then learn from the experience so this
    > fringe case of it happening doesn't happen again. I don't really see
    > much difference between a car going "OOP" and a computer going OOM.
    > Should we start deleting files according to some randomly-chosen
    > heueristic if a filesystem goes "OOS" ?

    Excellent point. However, the idea is to kill an attacker if your 'car'
    is being hijacked.

    Whatever is being designed should ideally have zero impact on the usual
    performance and only come into play if something runs away, deliberately
    or by accident.

    If Linux doesn't track down and kill deliberate attempts to kill the
    system, there will always be those who say; "Linux is no good because
    a user can readily kill it....". Of course we could track down and
    kill those who say this, but it'd get messy.

    FYI, a fork() bomb on my Sun Workstation does not kill it. Also
    malloc()ing and writing all over the place doesn't kill it either.


    Script started on Wed Oct 11 10:41:38 2000
    # cat xxx.c

    main()
    {
    for(;;)
    fork();
    }

    # gcc -o xxx xxx.c
    # ./xxx
    ^C
    # # ^C
    # ps
    PID TTY TIME CMD
    24800 pts/1 0:00 xxx
    24335 pts/1 0:00 sh
    24688 pts/1 0:00 xxx
    24690 pts/1 0:00 xxx
    24692 pts/1 0:00 xxx
    24694 pts/1 0:00 xxx
    24696 pts/1 0:00 xxx
    24697 pts/1 0:00 xxx
    24699 pts/1 0:00 xxx
    24701 pts/1 0:00 xxx
    24703 pts/1 0:00 xxx
    24704 pts/1 0:00 xxx
    24706 pts/1 0:00 xxx
    24708 pts/1 0:00 xxx
    24710 pts/1 0:00 xxx
    24712 pts/1 0:00 xxx
    24714 pts/1 0:00 xxx
    24716 pts/1 0:00 xxx
    24717 pts/1 0:00 xxx
    24719 pts/1 0:00 xxx
    24720 pts/1 0:00 xxx
    24721 pts/1 0:00 xxx
    24722 pts/1 0:00 xxx
    24723 pts/1 0:00 xxx
    24724 pts/1 0:00 xxx
    24725 pts/1 0:00 xxx
    24726 pts/1 0:00 xxx
    24727 pts/1 0:00 xxx
    24728 pts/1 0:00 xxx
    24729 pts/1 0:00 xxx
    24730 pts/1 0:00 xxx
    24731 pts/1 0:00 xxx
    24732 pts/1 0:00 xxx
    24733 pts/1 0:00 xxx
    24734 pts/1 0:00 xxx
    24735 pts/1 0:00 xxx
    24736 pts/1 0:00 xxx
    24737 pts/1 0:00 xxx
    24738 pts/1 0:00 xxx
    24739 pts/1 0:00 xxx
    24740 pts/1 0:00 xxx
    24741 pts/1 0:00 xxx
    24742 pts/1 0:00 xxx
    24743 pts/1 0:00 xxx
    24744 pts/1 0:00 xxx
    24801 pts/1 0:00 ps
    24687 pts/1 0:00 xxx
    24689 pts/1 0:00 xxx
    24691 pts/1 0:00 xxx
    24693 pts/1 0:00 xxx
    24695 pts/1 0:00 xxx
    24698 pts/1 0:00 xxx
    24700 pts/1 0:00 xxx
    24702 pts/1 0:00 xxx
    24705 pts/1 0:00 xxx
    24707 pts/1 0:00 xxx
    24709 pts/1 0:00 xxx
    24711 pts/1 0:00 xxx
    24713 pts/1 0:00 xxx
    24715 pts/1 0:00 xxx
    24718 pts/1 0:00 xxx
    24653 pts/1 0:00 xxx
    24610 pts/1 0:00 xxx
    24614 pts/1 0:00 xxx
    24615 pts/1 0:00 xxx
    24616 pts/1 0:00 xxx
    24617 pts/1 0:00 xxx
    24618 pts/1 0:00 xxx
    24619 pts/1 0:00 xxx
    24620 pts/1 0:00 xxx
    24621 pts/1 0:00 xxx
    24622 pts/1 0:00 xxx
    24623 pts/1 0:00 xxx
    24624 pts/1 0:00 xxx
    24625 pts/1 0:00 xxx
    24626 pts/1 0:00 xxx
    24627 pts/1 0:00 xxx
    24628 pts/1 0:00 xxx
    24629 pts/1 0:00 xxx
    24630 pts/1 0:00 xxx
    24631 pts/1 0:00 xxx
    24632 pts/1 0:00 xxx
    24686 pts/1 0:00 xxx
    24685 pts/1 0:00 xxx
    24684 pts/1 0:00 xxx
    24683 pts/1 0:00 xxx
    24682 pts/1 0:00 xxx
    24681 pts/1 0:00 xxx
    24680 pts/1 0:00 xxx
    24679 pts/1 0:00 xxx
    24678 pts/1 0:00 xxx
    24677 pts/1 0:00 xxx
    24676 pts/1 0:00 xxx
    24675 pts/1 0:00 xxx
    24674 pts/1 0:00 xxx
    24673 pts/1 0:00 xxx
    24672 pts/1 0:00 xxx
    24671 pts/1 0:00 xxx
    24670 pts/1 0:00 xxx
    24669 pts/1 0:00 xxx
    24668 pts/1 0:00 xxx
    24667 pts/1 0:00 xxx
    24666 pts/1 0:00 xxx
    24665 pts/1 0:00 xxx
    24664 pts/1 0:00 xxx
    24663 pts/1 0:00 xxx
    24662 pts/1 0:00 xxx
    24661 pts/1 0:00 xxx
    24660 pts/1 0:00 xxx
    24659 pts/1 0:00 xxx
    24658 pts/1 0:00 xxx
    24657 pts/1 0:00 xxx
    24656 pts/1 0:00 xxx
    24655 pts/1 0:00 xxx
    24654 pts/1 0:00 xxx
    24652 pts/1 0:00 xxx
    24651 pts/1 0:00 xxx
    24650 pts/1 0:00 xxx
    24649 pts/1 0:00 xxx
    24648 pts/1 0:00 xxx
    24647 pts/1 0:00 xxx
    24646 pts/1 0:00 xxx
    24645 pts/1 0:00 xxx
    24644 pts/1 0:00 xxx
    24643 pts/1 0:00 xxx
    24642 pts/1 0:00 xxx
    24634 pts/1 0:00 xxx
    24633 pts/1 0:00 xxx
    24641 pts/1 0:00 xxx
    24640 pts/1 0:00 xxx
    24639 pts/1 0:00 xxx
    24638 pts/1 0:00 xxx
    24637 pts/1 0:00 xxx
    24636 pts/1 0:00 xxx
    24635 pts/1 0:00 xxx
    24613 pts/1 0:00 xxx
    24611 pts/1 0:00 xxx
    # uname -a
    SunOS hal 5.5.1 Generic sun4m sparc SUNW,SPARCstation-5
    # exit
    script done on Wed Oct 11 10:42:27 2000


    The same fork() bomb will kill Linux 2.2.17 dead. We have to do
    something.


    Now, the SunWay(tm) seems to be to limit the number of forks/second
    that can occur, giving the kernel some time to swap. This reduces
    performance when you execute many programs from a shell. However,
    most useful programs take some time to execute if they are truly
    doing something useful. This may be the heuristic that wants to
    be exploited both for forks and mallocs (sbrk / mmap). If a task
    called these functions before some number of jiffy-counts had
    expired, it would have to sleep until the expiration time. This
    gives the kernel time to clean up.

    I note that the directory cache is, for some reason, considered
    so important that swap-space is used before the directory cache
    is touched. There are a lot of things that should be done within
    the kernel before you actually kill tasks, and some things that
    should be done before you swap.

    The whole idea of preventing attacks is to put an unreasonable
    burden on the attacker. If the attacker's process gets slower and
    slower, the more resources it consumes, in principle it could never
    consume all available resources.

    Given that the attacker is not really an attacker, but a Web Daemon,
    if it gets slower as it starts to overload the system, the same
    self-limiting occurs.

    Cheers,
    Dick Johnson

    Penguin : Linux version 2.2.17 on an i686 machine (801.18 BogoMips).

    "Memory is like gasoline. You use it up when you are running. Of
    course you get it all back when you reboot..."; Actual explanation
    obtained from the Micro$oft help desk.


    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 12:39    [W:0.035 / U:0.020 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site