On 06/09, Andy Lutomirski wrote:
>
> On Jun 6, 2016 3:21 PM, "Oleg Nesterov" <o...@redhat.com> wrote:
> >
> > On 06/01, Dmitry Safonov wrote:
> > >
> > > Note, that this will work only if application has changed it's CS.
> >
> > So, suppose it changes it's CS and crashes,
> >
> > > If the application does 32-bit syscall with __USER_CS, ptrace
> > > @@ -1355,7 +1355,7 @@ void update_regset_xstate_info(unsigned int size,
> > > u64 xstate_mask)
> > > const struct user_regset_view *task_user_regset_view(struct task_struct
> > > *task)
> > > {
> > > #ifdef CONFIG_IA32_EMULATION
> > > - if (test_tsk_thread_flag(task, TIF_IA32))
> > > + if (!user_64bit_mode(task_pt_regs(task)))
> > > #endif
> >
> > then coredump will do fill_elf_header(view->e_machine) and use EM_X86_64
> > instead of EM_386, or vice versa...
> >
> > I simply can't understand is this better or worse, I guess gdb or any
> > other tool which looks at this coredump will be confused anyway.
> >
>
> I think it's better.
and I tend to agree, I didn't try to argue with this change, but
> CRIU will change CS and someone will make the
> restored process crash afterwards.
I don't understand what do you mean... could you explain?
IIRC, CRIU can't c/r the 32-bit applications, or this is no longer true?
Oleg.
