[lkml]   [2000]   [Sep]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: the new VMt

    On Mon, Sep 25, 2000 at 02:04:19PM -0600, wrote:

    > > Right, but if the alternative is spurious ENOMEM when we can satisfy
    > An ENOMEM is not spurious if there is not enough memory. UNIX does not ask the
    > OS to do impossible tricks.

    Yes, but the ENOMEM _is_ spurious if you actually meant EAGAIN, and if
    the OS was perfectly capable of doing the retry itself.

    > > all of the pending requests just as long as they are serialised, is
    > > this a problem?
    > I think you are solving the wrong problem. On a small memory machine, the kernel,
    > utilities, and applications should be configured to use little memory.
    > BusyBox is better than BeanCount.

    Any box is a small memory machine if you get the wrong workload on it,
    and the DoS attacks which are possible without beancounting let any
    user bring even a large system to its knees right now. If solving
    that problem also means that small memory machines do the right thing
    on their own rather than requiring specific manual configuration, then
    it sounds like a good aim.

    > > However, you just can't escape from the fact that on low memory
    > > machinnes, we *need* beancounter-style accounting of pinned pages or
    > > we'll be in Deep Trouble (TM). We already have nasty DoS situations
    > What we need is simple kernel code that does not hold resources
    > into a possible deadlock situation.


    > On general principles, I don't see any substitute for clean code in the kernel and
    > my prediction is that if you show me an example of
    > DoS vulnerability, I can show you fix that does not require bean counting.
    > Am I wrong?

    If you have a user forking multiple processes and exhausting some
    resource, then at some point you have to do something about it. Let's
    say it's page tables, just for argument's sake, because those are
    currently non-swappable, but even if you make those swappable there
    are plenty of other resources it might be (eg. data shoved down unix
    domain sockets if you want another example).

    So you have run out of physical memory --- what do you do about it?
    The important observation here is that in a multi-user environment,
    simply denying further allocations isn't good enough --- unless you
    revoke those existing allocations you have DoS. And you can't fairly
    revoke existing allocations without knowing WHICH user has exhausted
    the memory (which requires beancounter-style resource tracking), AND
    having mechanisms in place to revoke all of the possible resources
    which might be involved (eg unix domain socket datagrams). kill -9
    might solve that latter problem but it doesn't help in identifying who
    to kill.

    > --
    > ---------------------------------------------------------
    > Victor Yodaiken
    > Finite State Machine Labs: The RTLinux Company.
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 12:38    [W:0.034 / U:1.684 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site