linux-kernel - Re: [PATCH] slab: prevent warnings when allocating with __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: <0000013f33c83e5f-946866ad-d2d3-48e6-8035-6eaf1ac37fbe-000000@email.amazonses.com>
Date:	Tue, 11 Jun 2013 15:08:48 +0000
From:	Christoph Lameter <cl@...two.org>
To:	Sasha Levin <sasha.levin@...cle.com>
cc:	Pekka Enberg <penberg@...nel.org>,
	"linux-mm@...ck.org" <linux-mm@...ck.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] slab: prevent warnings when allocating with
 __GFP_NOWARN

On Mon, 10 Jun 2013, Sasha Levin wrote:

> > There must be another reason. Lets fix this.
>
> My, I feel silly now.
>
> I was the one who added __GFP_NOFAIL in the first place in
> 2ccd4f4d ("pipe: fail cleanly when root tries F_SETPIPE_SZ
> with big size").
>
> What happens is that root can go ahead and specify any size
> it wants to be used as buffer size - and the kernel will
> attempt to comply by allocation that buffer. Which fails
> if the size is too big.

Could you check that against a boundary? Use vmalloc if larger than a
couple of pages? Maybe PAGE_COSTLY_ORDER or so?

THe higher the order the more likely it is that the allocation will fail.
The PAGE_ORDER_COSTLY (or so) is a reasonable limit as to what size of a
linear contiguous allocation that can be expected to be successful.


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