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-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.64.0709101238510.24941@schroedinger.engr.sgi.com>
Date:	Mon, 10 Sep 2007 12:41:45 -0700 (PDT)
From:	Christoph Lameter <clameter@....com>
To:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
cc:	Nick Piggin <npiggin@...e.de>,
	Daniel Phillips <phillips@...nq.net>, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
	dkegel@...gle.com, David Miller <davem@...emloft.net>
Subject: Re: [RFC 0/3] Recursive reclaim (on __PF_MEMALLOC)

On Mon, 10 Sep 2007, Peter Zijlstra wrote:

> >  Peter's approach establishes the 
> > limit by failing PF_MEMALLOC allocations. 
> 
> I'm not failing PF_MEMALLOC allocations. I'm more stringent in failing !
> PF_MEMALLOC allocations.

Right you are failing other allocations.

> > If that occurs then other 
> > subsystems (like the disk, or even fork/exec or memory management 
> > allocation) will no longer operate since their allocations no longer 
> > succeed which will make the system even more fragile and may lead to 
> > subsequent failures.
> 
> Failing allocations should never be a stability problem, we have the
> fault-injection framework which allows allocations to fail randomly -
> this should never crash the kernel - if it does its a BUG.

Allright maybe you can get the kernel to be stable in the face of having 
no memory and debug all the fallback paths in the kernel when an OOM 
condition occurs.

But system calls will fail? Like fork/exec? etc? There may be daemons 
running that are essential for the system to survive and that cannot 
easily take an OOM condition? Various reclaim paths also need memory and 
if the allocation fails then reclaim cannot continue.

-
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