Re: [RFC 3/4] x86/signal/64: Re-add support for SS in the 64-bit signal context

[Stas Sergeev <stsp@list.ru>]

14.10.2015 19:40, Cyrill Gorcunov пишет:
> On Mon, Oct 12, 2015 at 06:04:07PM -0700, Andy Lutomirski wrote:
> ...
>>
>> For the benefit of new 64-bit software that uses segmentation (new
>> versions of DOSEMU might), the new behavior can be detected with a
>> new ucontext flag UC_SIGCONTEXT_SS.
>>
>> To avoid compilation issues, __pad0 is left as an alias for ss in
>> ucontext.
>>
>> The nitty-gritty details are documented in the header file.
>>
>> Cc: Stas Sergeev <stsp@list.ru>
>> Cc: Linus Torvalds <torvalds@linux-foundation.org>
>> Cc: Cyrill Gorcunov <gorcunov@gmail.com>
>> Cc: Pavel Emelyanov <xemul@parallels.com>
>> Signed-off-by: Andy Lutomirski <luto@kernel.org>
> 
> Andy, so for old criu versions (prior the 1.5.1 which is Mar 2015,
> in next versions we already write proper ss into the images)
> we've been providing __pad = 0, which is ss in a new meaning,
> and the kernel will overwrite it with @user-ds after this series,
> correct? This should work for us. Stas, mind to refresh my memory,
> which ss value doesmu setups here?
Nothing.
Older dosemus didn't care about touching __pad0, so
whatever kernel saves there, is still there, even when
dosemu needs another value.
The problem starts to happen IIRC when dosemu invalidates
the LDT entry that was previously saved by the kernel as an SS.
IIRC this was causing the SIGSEGV right from sigreturn().
It is actually a bit annoying to have such bad code in kernel
only for the sake of the older dosemu.