On Thu, Oct 13, 2011 at 2:25 PM, Pavel Emelyanov <xemul@xxxxxxxxxxxxx> wrote:
>>> ... are we all OK with showing kernel addresses to the userspace? I thought the %pK
>>> format was invented specially to handle such leaks.
>>
>> I don't think it's worth it to try to hide kernel addresses for
>> checkpoint/restart.
>
> We don't need to know anything about kernel internals for checkpoint-restart, that's
> why I said, that abstract identifiers are just fine.
OK.
>>> 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.
>>
>> Does this ID thing need to happen in the slab layer?
>
> Not necessarily, of course, but if we're going to show some identifier of an object
> we have 2 choices - either we generate this ID independently (with e.g. IDA), but
> this is slow, or we use some knowledge of an object as a bunch of bytes in memory.
> These slab IDs thing is an attempt to implement the 2nd approach.
Why is the first approach slow? I fully agree that unique IDs are probably the
way to go here but why don't you just add a new member to struct mm_struct and
initialize it in mm_alloc() and mm_dup()?
> The question I'm trying to answer with this is - do task A and task B have their mm
> shared or not? Showing an ID answers one. Maybe there exists another way, but I haven't
> invented it yet and decided to send this set out for discussion (the "release early"
> idiom). If slab maintainers say "no, we don't accept this at all ever", then of course
> I'll have to think further, but if the concept is suitable, but needs some refinement -
> let's do it.
Oh, I much appreciate that you sent this early. I'm not completely against doing
this in the slab layer but I need much more convincing. I expect most distros to
enable checkpoint/restart so this ID mechanism is going to be default
on for slab.
Pekka
--
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>