From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753430AbbJNQ5O (ORCPT ); Wed, 14 Oct 2015 12:57:14 -0400 Received: from smtp24.mail.ru ([94.100.181.179]:58795 "EHLO smtp24.mail.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751919AbbJNQ5N (ORCPT ); Wed, 14 Oct 2015 12:57:13 -0400 Subject: Re: [RFC 3/4] x86/signal/64: Re-add support for SS in the 64-bit signal context To: Cyrill Gorcunov , Andy Lutomirski References: <6e14e2f7ce1c38fc1996bd4d5d3d9dc70b8bd94d.1444697927.git.luto@kernel.org> <20151014164021.GS2048@uranus> Cc: x86@kernel.org, linux-kernel@vger.kernel.org, Brian Gerst , Denys Vlasenko , Linus Torvalds , Borislav Petkov , Pavel Emelyanov From: Stas Sergeev X-Enigmail-Draft-Status: N1110 Message-ID: <561E895E.7050905@list.ru> Date: Wed, 14 Oct 2015 19:57:02 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20151014164021.GS2048@uranus> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Mras: Ok Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 >> Cc: Linus Torvalds >> Cc: Cyrill Gorcunov >> Cc: Pavel Emelyanov >> Signed-off-by: Andy Lutomirski > > 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.