On Wed, Oct 14, 2015 at 9:40 AM, Cyrill Gorcunov <gorcu...@gmail.com> wrote: > 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 <s...@list.ru> >> Cc: Linus Torvalds <torva...@linux-foundation.org> >> Cc: Cyrill Gorcunov <gorcu...@gmail.com> >> Cc: Pavel Emelyanov <xe...@parallels.com> >> Signed-off-by: Andy Lutomirski <l...@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?
That's the intent. If you write __pad = 0, don't set UC_STRICT_RESTORE_SS, and leave cs set to a 64-bit value, then the kernel will detect that 0 is not a valid SS and will fix it for you. If you do write UC_STRICT_RESTORE_SS (e.g. if you saved on a new kernel and you restore the saved uc_flags), then you'll get a new signal delivered. If you're restoring a 32-bit or 16-bit context, then none of the above applies, but I doubt that CRIU supports that anyway. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
