lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <f36b08ee0611230430k9b2b625qc8d1b93031e09d14@mail.gmail.com>
Date:	Thu, 23 Nov 2006 14:30:14 +0200
From:	"Yakov Lerner" <iler.ml@...il.com>
To:	Kernel <linux-kernel@...r.kernel.org>
Subject: coping with swap-exhaustion in 2.4.33-4

    Where can I read anything about how kernel is supposed to
react to the 'swap-full' condition ? We have troubles on the
production machine which routinely arrives to the swap-full state
no matter how I increase the swap, because user proceses multi-fork
and then want to allocate a lot of virtual memory.

   I made a small test (below) and I run it as root and as non-root, having
two ssh sessions to the target machine (I run it as
as while true; do memstress; done ).

   Is the right solution in the kernel, or in the ulimiting the processes ?
I'm not sure what to do with forking, they fork many children ...
Is looking for kernel patches the right direction ? I want kernel not
to kill root-owned processes when non-root process is memory hog, but
that's not what I see.

Running my memstress, I see two things:
  1) if memory-hog process is non-root, then it is never killed
but hangs, and other pprocesses (which are root processes) are
killed instead of the mem-hog process.
  2) if memory-hog process is run as root, it is promptly
killed when swap is exhausted. Sometimes other processes
are killed, too (sshd server happen to be killed).

The (1) does not sound right for me. Is there a patch for it ?
Is there a redhat patch for this maybe ? Where can I find such
patches ?

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ