From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754266AbbCQPJf (ORCPT ); Tue, 17 Mar 2015 11:09:35 -0400 Received: from mx1.redhat.com ([209.132.183.28]:48355 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753608AbbCQPJd (ORCPT ); Tue, 17 Mar 2015 11:09:33 -0400 Message-ID: <55084390.90008@redhat.com> Date: Tue, 17 Mar 2015 16:09:04 +0100 From: Denys Vlasenko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Ingo Molnar CC: Linus Torvalds , Steven Rostedt , Borislav Petkov , "H. Peter Anvin" , Andy Lutomirski , Oleg Nesterov , Frederic Weisbecker , Alexei Starovoitov , Will Drewry , Kees Cook , x86@kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/2 v2] x86/asm/entry/64: Enable interrupts *after* we fetch PER_CPU_VAR(old_rsp) References: <1426600344-8254-1-git-send-email-dvlasenk@redhat.com> <20150317143614.GA18462@gmail.com> In-Reply-To: <20150317143614.GA18462@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 03/17/2015 03:36 PM, Ingo Molnar wrote: > > * Denys Vlasenko wrote: > >> Without this change, it is still not possible to get rid of >> PER_CPU_VAR(old_rsp) usage in switch_to: if preemption happens >> while we did not fetch PER_CPU_VAR(old_rsp) and stored it in pt_regs->sp, >> PER_CPU_VAR(old_rsp) gets corrupted by other task's user sp. > > Well, wouldn't this be a much clearer explanation: > > "We want to use PER_CPU_VAR(old_rsp) as a simple temporary register, > to shuffle user-space RSP into (and from) when we set up the system > call stack frame. At that point we cannot shuffle values into general > purpose registers, because we have not saved them yet. > > To be able to do this shuffling into a memory location, we must be > atomic and must not be preempted while we do the shuffling, otherwise > the 'temporary' register gets overwritten by some other task's > temporary register contents ..." > > Agreed? Sounds good to me.