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@xxxxxxxxx. 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@xxxxxxxxx";> email@xxxxxxxxx </a>