From: Blaisorblade <bla...@ya...> - 2005-05-05 17:03:30
|
I understand the purpose of the patch; however, without any mention about the effects (which would be IMHO bad) we no more copy LDT segments on fork/clone, which is bad. The patch moves that to the call of modify_ldt, but that's an hack, since currently it's perfectly legitimate that a child uses the father's LDT, though maybe uncommon. It would be better to move LDT copying to an arch-specific helper, defaulting to null (i.e. an empty inline) and defined only for i386 and x86-64 (even the same def. is ok, probably). -- Paolo Giarrusso, aka Blaisorblade Skype user "PaoloGiarrusso" Linux registered user n. 292729 http://www.user-mode-linux.org/~blaisorblade |
From: Bodo S. <bst...@fu...> - 2005-05-06 11:04:54
|
Blaisorblade wrote: > I understand the purpose of the patch; however, without any mention about the > effects (which would be IMHO bad) we no more copy LDT segments on fork/clone, > which is bad. No. The patch shifts code only, but AFAICS it doesn't alter the bahavior of UML/i386. If it does, that would be a bug in the patch! > > The patch moves that to the call of modify_ldt, but that's an hack, since > currently it's perfectly legitimate that a child uses the father's LDT, > though maybe uncommon. No. Let's read the code before and after the change: Before the change, father's LDT is copied in new_mm() using MM_COPY_SEGMENTS. new_mm() only has one caller, which is init_new_context_skas(). After the change, father's LDT is copied in init_new_ldt(), again using MM_COPY_SEGMENTS. init_new_ldt() also has exactly one caller, which again is init_new_context_skas(). In both cases, copying is done only, if /proc/mm is available. So, nothing in the behavior is changed, but the code is shifted to arch-specific files. > > It would be better to move LDT copying to an arch-specific helper, defaulting > to null (i.e. an empty inline) and defined only for i386 and x86-64 (even the > same def. is ok, probably). Yeah. init_new_ldt() exactly *is* such a arch-specific helper. In UML/s390, this is a NOOP. BTW: my UML/i386 uses a libc, that depends on modify_ldt() to manage the TLS. If UML doesn't copy the LDT, this system crashes. And it works fine with the changes! Regards, Bodo |
From: Blaisorblade <bla...@ya...> - 2005-05-07 15:34:38
|
On Friday 06 May 2005 13:04, Bodo Stroesser wrote: > Blaisorblade wrote: > > I understand the purpose of the patch; however, without any mention about > > the effects (which would be IMHO bad) we no more copy LDT segments on > > fork/clone, which is bad. > > No. The patch shifts code only, but AFAICS it doesn't alter the bahavior of > UML/i386. If it does, that would be a bug in the patch! > > > The patch moves that to the call of modify_ldt, but that's an hack, since > > currently it's perfectly legitimate that a child uses the father's LDT, > > though maybe uncommon. > > No. Let's read the code before and after the change: > > Before the change, father's LDT is copied in new_mm() using > MM_COPY_SEGMENTS. new_mm() only has one caller, which is > init_new_context_skas(). > After the change, father's LDT is copied in init_new_ldt(), again > using MM_COPY_SEGMENTS. Ok, it turns out that I was simply misreading the patch (I didn't apply the patch, since I don't have the time to work on Jeff's tree too, beyond the release tree). -- Paolo Giarrusso, aka Blaisorblade Skype user "PaoloGiarrusso" Linux registered user n. 292729 http://www.user-mode-linux.org/~blaisorblade |