On Fri, 2012-07-06 at 14:13 +0400, Glauber Costa wrote:
On 07/05/2012 01:29 PM, Li Zhong wrote:
quoted
On Thu, 2012-07-05 at 12:23 +0400, Glauber Costa wrote:
quoted
On 07/05/2012 05:41 AM, Li Zhong wrote:
quoted
On Wed, 2012-07-04 at 16:40 +0400, Glauber Costa wrote:
quoted
On 07/04/2012 01:00 PM, Li Zhong wrote:
quoted
On Tue, 2012-07-03 at 15:36 -0500, Christoph Lameter wrote:
quoted
quoted
Looking through the emails it seems that there is an issue with alias
strings.
To be more precise, there seems no big issue currently. I just wanted to
make following usage of kmem_cache_create (SLUB) possible:
name = some string kmalloced
kmem_cache_create(name, ...)
kfree(name);
Out of curiosity: Why?
This is not (currently) possible with the other allocators (may change
with christoph's unification patches), so you would be making your code
slub-dependent.
For slub itself, I think it's not good that: in some cases, the name
string could be kfreed ( if it was kmalloced ) immediately after calling
the cache create; in some other case, the name string needs to be kept
valid until some init calls finished.
I agree with you that it would make the code slub-dependent, so I'm now
working on the consistency of the other allocators regarding this name
string duplicating thing.
If you really need to kfree the string, or even if it is easier for you
this way, it can be done. As a matter of fact, this is the case for me.
Just that your patch is not enough. Christoph has a patch that makes
this behavior consistent over all allocators.
Sorry, I didn't know that. Seems I don't need to continue the half-done
work in slab. If possible, would you please give me a link of the patch?
Thank you.
Sorry for the delay. In case you haven't found it out yourself yet:
http://www.spinics.net/lists/linux-mm/msg36149.html
Thank you. I think it is better to have these things in the
slab_common.c.
Please not this posted patch as is has a bug.
I do believe that your take on the aliasing code adds value to it. But
as I've already said once, might have to dig a bit deeper in that to get
to end of the rabbit hole.
With slab_common, I think my slab/slob modifications are not needed any
more. After I understand the common patches, I will check whether the
aliasing problem in slub still exists, and if yes, try to send a patch
based on that.