linux-kernel - Re: [PATCH] Containment measures for slab objects on scatter gather lists

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:	Thu, 28 Jun 2007 21:39:01 -0700 (PDT)
From:	Christoph Lameter <clameter@....com>
To:	David Miller <davem@...emloft.net>
cc:	hugh@...itas.com, James.Bottomley@...eleye.com,
	rmk+lkml@....linux.org.uk, akpm@...ux-foundation.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Containment measures for slab objects on scatter gather
 lists

On Thu, 28 Jun 2007, David Miller wrote:

> > You can get such a reference and then the slab page will be in limbo if 
> > all objects are freed until that reference is given up. The reference 
> > method is also use by kmem_cache_vacate() (but that is slab internal).
> 
> What about if someone kfree()'s that object meanwhile?

If that is the last object in the slab then the page is deslabified and 
it will stick around as a regular page until its refcount reaches zero.

There is slab functionality in SLUB that uses this trick to insure that 
the slab does not go away.

> Can we bump the SLAB object count just like we can a page?

You can bump the slab page count. But you have to use virt_to_head_page() 
instead of virt_to_page() since slab pages may be compound pages (in both 
SLAB and SLUB). Incrementing the refcount of a tail page will cause an oops on
free.

> That's basically what's happening in the stuff Jens is
> working on, he needs to grab a reference to a SLAB
> object just like one can a page.  Even if there is an
> intervening kfree (like a put_page()) the SLAB object is
> still live until all the references are put, and thus it
> can't get reallocated and given to another client by SLAB.

If you kfree the object then all slab allocators will feel free to 
immediately alloc the object for other purposes.

If you want to prohibit further allocations from a slab then I can likely 
give you a function call that removes a slab from the partial lists so 
that the slab will not be allocated from. But this will only work with 
SLUB.

At some point the slab will then need to be returned to the partial slab 
lists.

Hmmmm... Maybe we are creating more of a mess with this. Isnt there some 
other way to handle these object.

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