On 10/10/2011 07:24 PM, Christoph Lameter wrote: > On Mon, 10 Oct 2011, Pavel Emelyanov wrote: > >>> 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. > > Not in general but I think for process migration we are fine with the > handling of the addresses. Doesnt process migration require rooot anyways? Well, currently the most strict requirement for checkpoint part is the ptrace_may_access() one, which is not necessarily root. And I'd prefer not restricting it further without need. > Adding additional metadata to each slab or object is certainly not > acceptable because it slows down operations for everyone. Please note, that this ID generation thing is not required for EVERY kmem cache in the system, only for a couple of them. For 64 bits kernel this ID is stored on the struct page itself doesn't making object density worse, on 32 bits the caches I require to mark with this flag already have gaps between objects and thus do not make density worse either. Besides, the slab ID generation is a single percpu counter and is called in the places where percpu areas are already hot in caches, thus no noticeable penalty should be seen. Besides, in OpenVZ we modify slub code to store on the page with objects an array of pointers (size == number of objects) and no performance tests show any degradation due to this. If I misunderstood your concern, please elaborate. >> 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. > > Well one solution is to show the addresses only to members of a specific > group or only to root. I agree with that. Need to sort out the issues above. 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>