linux-kernel - Re: [RFC] [PATCH] cpuset operations causes Badness at mm/slab.c:777 warning

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: <alpine.LFD.0.98.0706011615480.3957@woody.linux-foundation.org>
Date:	Fri, 1 Jun 2007 16:25:13 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Andrew Morton <akpm@...ux-foundation.org>
cc:	Christoph Lameter <clameter@....com>,
	Jeremy Fitzhardinge <jeremy@...p.org>,
	Srinivasa Ds <srinivasa@...ibm.com>,
	linux-kernel@...r.kernel.org,
	Srivatsa Vaddagiri <vatsa@...ibm.com>,
	Dinakar Guniguntala <dino@...ibm.com>, pj@....com,
	simon.derr@...l.net, clameter@...ulhu.engr.sgi.com,
	rientjes@...gle.com
Subject: Re: [RFC] [PATCH] cpuset operations causes Badness at mm/slab.c:777
 warning

On Fri, 1 Jun 2007, Andrew Morton wrote:
> 
> We could store the size of the allocation in the allocated object?  Just
> add four bytes to the user's request, then pick the appropriate cache based
> on that, then put the user's `size' at the tail of the resulting allocation?

It should be easy enough to do it for _most_ allocations by just doing it 
when there is already "enough slack" to do it (which is likely true most 
of the time).

IOW, if you ask for a 42-byte allocation, and we allocate from a 64-byte 
slab, you get the slab allocation at address X, you don't actually have to 
return "X" at all. Just return "X+8", and then you do:

 - at 32-bit word at X+0 you put the "real length"
 - at 32-bit word at X+4 you put some good redzone marker
 - at 32-bit word at "X + reallen + 8" you put the endzone marker.

And then you say: if the real length was within 12 bytes of the allocation 
length, we just don't do this.

So you wouldn't get any redzoning for those allocations that are exactly 
sized (or close enough) to fit in an allocation block, but I bet *most* 
allocations would get this for free.

And then, if you actually turn on redzoning, you just always add the 12 
byte to the allocation size (assuming the alignment rules allow you to).

The nice thing about this is that the freeing path already knows where the 
object is *supposed* to start (because it sees the allocation size in the 
slub/slab data structures), so the kfree() path can actually figure out on 
its own whether it is given a "X" or an "X+8" kind of address.

So you don't actually need any extra information. You literally just need 
enough slop in the allocation that you can do this in the first place, so 
there is no cost (except for the cost of checking itself, of course).

Hmm?

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