linux-kernel - Re: [PATCH] 2.6.26-rc: x86: pci-dma.c: use __GFP_NO_OOM instead of __GFP

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: <20080528024727.GB20824@one.firstfloor.org>
Date:	Wed, 28 May 2008 04:47:27 +0200
From:	Andi Kleen <andi@...stfloor.org>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Miquel van Smoorenburg <mikevs@...all.net>,
	Andi Kleen <andi@...stfloor.org>,
	Glauber Costa <gcosta@...hat.com>,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org,
	Ingo Molnar <mingo@...e.hu>
Subject: Re: [PATCH] 2.6.26-rc: x86: pci-dma.c: use __GFP_NO_OOM instead of __GFP_NORETRY

> So...  why not just remove the setting of __GFP_NORETRY?  Why is it
> wrong to oom-kill things in this case?

When the 16MB zone overflows (which can be common in some workloads)
calling the OOM killer is pretty useless because it has barely any 
real user data [only exception would be the "only 16MB" case Alan
mentioned]. Killing random processes in this case is bad. 

I think for 16MB __GFP_NORETRY is ok because there should be 
nothing freeable in there so looping is useless. Only exception would be the 
"only 16MB total" case again but I'm not sure 2.6 supports that at all
on x86.

On the other hand d_a_c() does more allocations than just 16MB, especially
on 64bit and the other zones need different strategies.

> But this change increases the chances of a caller getting stuck in the
> page allocator for ever, unable to make progress?

At least for much longer, yes I am somewhat worried about this too.

Sometimes a OOM regression test suite would be really nice.

-Andi
--
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/