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
| ||
|
Date: Thu, 12 Sep 2013 15:51:38 +0900 From: Joonsoo Kim <iamjoonsoo.kim@....com> To: Christoph Lameter <cl@...ux.com> Cc: Pekka Enberg <penberg@...nel.org>, Andrew Morton <akpm@...ux-foundation.org>, David Rientjes <rientjes@...gle.com>, linux-mm@...ck.org, linux-kernel@...r.kernel.org, Mel Gorman <mgorman@...e.de> Subject: Re: [PATCH 01/16] slab: correct pfmemalloc check On Wed, Sep 11, 2013 at 02:30:03PM +0000, Christoph Lameter wrote: > On Thu, 22 Aug 2013, Joonsoo Kim wrote: > > > And, therefore we should check pfmemalloc in page flag of first page, > > but current implementation don't do that. virt_to_head_page(obj) just > > return 'struct page' of that object, not one of first page, since the SLAB > > don't use __GFP_COMP when CONFIG_MMU. To get 'struct page' of first page, > > we first get a slab and try to get it via virt_to_head_page(slab->s_mem). > > Maybe using __GFP_COMP would make it consistent across all allocators and > avoid the issue? We then do only have to set the flags on the first page. Yes, you are right. It can be solved by using __GFP_COMP. But I made this patch to clarify the problem in current code and to be merged seperately. If I solve the problem with __GFP_COMP which is implemented in [09/16] of this patchset, it would also weaken the purpose of that patch. Thanks. -- 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