On Tue, 24 Apr 2007, Neil Brown wrote: > On Monday April 23, [email protected] wrote: > > Would this work? Contains a solution somewhat along the lines of your > > thoughts on the subject. > > > > Concept seems sound. > Code needs a kfree of the name returned by create_unique_id, and I > think ID_STR_LENGTH needs to be at least 34. Sysfs copies the string? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
- Follow-Ups:
- Re: SLUB: kmem_cache_destroy doesn't - version 2.
- From: Neil Brown <[email protected]>
- Re: SLUB: kmem_cache_destroy doesn't - version 2.
- References:
- SLUB: kmem_cache_destroy doesn't - version 2.
- From: Neil Brown <[email protected]>
- Re: SLUB: kmem_cache_destroy doesn't - version 2.
- From: Christoph Lameter <[email protected]>
- Re: SLUB: kmem_cache_destroy doesn't - version 2.
- From: Neil Brown <[email protected]>
- Re: SLUB: kmem_cache_destroy doesn't - version 2.
- From: Christoph Lameter <[email protected]>
- Re: SLUB: kmem_cache_destroy doesn't - version 2.
- From: Neil Brown <[email protected]>
- Re: SLUB: kmem_cache_destroy doesn't - version 2.
- From: Christoph Lameter <[email protected]>
- Re: SLUB: kmem_cache_destroy doesn't - version 2.
- From: Neil Brown <[email protected]>
- SLUB: kmem_cache_destroy doesn't - version 2.
- Prev by Date: Re: [PATCH] Return EPERM not ECHILD on security_task_wait failure
- Next by Date: Re: SLUB: kmem_cache_destroy doesn't - version 2.
- Previous by thread: Re: SLUB: kmem_cache_destroy doesn't - version 2.
- Next by thread: Re: SLUB: kmem_cache_destroy doesn't - version 2.
- Index(es):
 |