Re: [PATCH 0/5] Slab objects identifiers

[Pavel Emelyanov <xemul@parallels.com>]

On 10/07/2011 09:03 PM, Christoph Lameter wrote:
> On Thu, 6 Oct 2011, Pavel Emelyanov wrote:
> 
>> While doing the checkpoint-restore in the userspace we need to determine
>> whether various kernel objects (like mm_struct-s of file_struct-s) are shared
>> between tasks and restore this state.
>>
>> The 2nd step can for now be solved by using respective CLONE_XXX flags and
>> the unshare syscall, while there's currently no ways for solving the 1st one.
>>
>> One of the ways for checking whether two tasks share e.g. an mm_struct is to
>> provide some mm_struct ID of a task to its proc file. The best from the
>> performance point of view ID is the object address in the kernel, but showing
>> them to the userspace is not good for performance reasons. Thus the ID should
>> not be calculated based on the object address.
> 
> If two tasks share an mm_struct then the mm_struct pointer (task->mm) will
> point to the same address. Objects are already uniquely identified by
> their address.

Yes of course, but ...

> If you store the physical address with the object content
> when transferring then you can verify that they share the mm_struct.

... are we all OK with showing kernel addresses to the userspace? I thought the %pK
format was invented specially to handle such leaks.

If we are, then (as I said in the first letter) we should just show them and forget 
this set. If we're not - we should invent smth more straightforward and this set is 
an attempt for doing this.

Thanks,
Pavel

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>