linux-kernel - Re: [PATCH -next] slub: set PG

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]

Date:	Mon, 5 Mar 2012 08:48:33 -0600 (CST)
From:	Christoph Lameter <cl@...ux.com>
To:	Minchan Kim <minchan@...nel.org>
cc:	Namhyung Kim <namhyung.kim@....com>,
	Pekka Enberg <penberg@...nel.org>,
	Matt Mackall <mpm@...enic.com>,
	Namhyung Kim <namhyung@...il.com>, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH -next] slub: set PG_slab on all of slab pages

On Sun, 4 Mar 2012, Minchan Kim wrote:

> I read this thread and I feel the we don't reach right point.
> I think it's not a compound page problem.
> We can face above problem where we allocates big order page without __GFP_COMP
> and free middle page of it.

Yes we can do that and doing such a thing seems to be more legitimate
since one could argue that the user did not request an atomic allocation
unit from the page allocator and therefore the freeing of individual
pages in that group is permissible. If memory serves me right we do that
sometimes.

However if compound pages are requested then such an atomic allocation
unit *was* requested and the page allocator should not allow to free
individual pages.
--
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/