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: <20080522043410.GA4050@linux-sh.org>
Date:	Thu, 22 May 2008 13:34:10 +0900
From:	Paul Mundt <lethal@...ux-sh.org>
To:	Pekka Enberg <penberg@...helsinki.fi>
Cc:	Christoph Lameter <clameter@....com>, linux-kernel@...r.kernel.org,
	mpm@...enic.com, dhowells@...hat.com
Subject: Re: [RFC/PATCH 1/3] SLAB: Add PageSlab checking to ksize()

On Thu, May 22, 2008 at 07:21:48AM +0300, Pekka Enberg wrote:
> Christoph Lameter wrote:
> >>That's probably due to the fact that we use PageSlab for all pages with 
> >>SLUB
> >>and for bigblock pages in SLOB with this patch. Christoph, Matt, any
> >>suggestions how to fix the PageSlab check in nommu btw?
> >
> >I already posted a patch and commented numerous times. What else needs 
> >to be said? SLUB only uses PageSlab for kmalloc <=4kb.
> 
> (I missed your patch, btw.)
> 
> For SLOB, we will never use ksize() as it doesn't set PageSlab. Is that 
> not a problem?
> 
That means that kobjsize() will hand back PAGE_SIZE for non-compound
pages, which is what it's presently doing anyways. In the case of SLOB
bigblock pages allocated on pass-through to the page allocator, these are
compound pages anyways, so compound_page() should do the right thing
there? That only handles the kmalloc() path though, and not the
kmem_cache_alloc() cases.

Shouldn't SLOB's PageSlab usage should mimic that of SLUB in this case
instead? PG_slab doesn't buy us much if we can already sort out the size
through compound_order(), it's the kmem_cache_alloc() and <= PAGE_SIZE
kmalloc()'s where __GFP_COMP isn't true and where PG_slab should be set.
--
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