Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933011AbcLHXPQ (ORCPT ); Thu, 8 Dec 2016 18:15:16 -0500 Received: from mail-vk0-f46.google.com ([209.85.213.46]:35350 "EHLO mail-vk0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932859AbcLHXPP (ORCPT ); Thu, 8 Dec 2016 18:15:15 -0500 MIME-Version: 1.0 In-Reply-To: <20161123181330.10705-1-dsafonov@virtuozzo.com> References: <20161123181330.10705-1-dsafonov@virtuozzo.com> From: Andy Lutomirski Date: Thu, 8 Dec 2016 15:14:53 -0800 Message-ID: Subject: Re: [PATCH] x86/coredump: always use user_regs_struct for compat_elf_gregset_t To: Dmitry Safonov Cc: Thomas Gleixner , Dmitry Safonov <0x7f454c46@gmail.com>, Ingo Molnar , "linux-kernel@vger.kernel.org" , Oleg Nesterov , "linux-mm@kvack.org" , X86 ML , "H. Peter Anvin" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1117 Lines: 22 On Nov 23, 2016 10:16 AM, "Dmitry Safonov" wrote: > > From commit 90954e7b9407 ("x86/coredump: Use pr_reg size, rather that > TIF_IA32 flag") elf coredump file is constructed according to register > set size - and that's good: if binary crashes with 32-bit code selector, > generate 32-bit ELF core, otherwise - 64-bit core. > That was made for restoring 32-bit applications on x86_64: we want > 32-bit application after restore to generate 32-bit ELF dump on crash. > All was quite good and recently I started reworking 32-bit applications > dumping part of CRIU: now it has two parasites (32 and 64) for seizing > compat/native tasks, after rework it'll have one parasite, working in > 64-bit mode, to which 32-bit prologue long-jumps during infection. > > And while it has worked for my work machine, in VM with > !CONFIG_X86_X32_ABI during reworking I faced that segfault in 32-bit > binary, that has long-jumped to 64-bit mode results in dereference > of garbage: Can you point to the actual line that's crashing? I'm wondering if we have code that should be made more robust. --Andy