From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752997AbcHOSZ1 (ORCPT ); Mon, 15 Aug 2016 14:25:27 -0400 Received: from mx1.redhat.com ([209.132.183.28]:45412 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750791AbcHOSZ0 (ORCPT ); Mon, 15 Aug 2016 14:25:26 -0400 Date: Mon, 15 Aug 2016 13:25:22 -0500 From: Josh Poimboeuf To: "H. Peter Anvin" Cc: Andy Lutomirski , Thomas Gleixner , Ingo Molnar , X86 ML , "linux-kernel@vger.kernel.org" , Linus Torvalds , Steven Rostedt , Brian Gerst , Kees Cook , Peter Zijlstra , Frederic Weisbecker , Byungchul Park , Nilay Vaish Subject: Re: [PATCH v3 16/51] x86/32: put real return address on stack in entry code Message-ID: <20160815182522.6vjn6aheuiw65oca@treble> References: <34b62822bb153955ed4ec1ab2e19ea482361c16c.1471011425.git.jpoimboe@redhat.com> <20160815150941.nilwkrkszj5mm5ka@treble> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0.1 (2016-04-01) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Mon, 15 Aug 2016 18:25:25 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Aug 15, 2016 at 11:04:42AM -0700, H. Peter Anvin wrote: > On 08/15/16 08:09, Josh Poimboeuf wrote: > > On Sun, Aug 14, 2016 at 12:31:47AM -0700, Andy Lutomirski wrote: > >> On Fri, Aug 12, 2016 at 7:28 AM, Josh Poimboeuf wrote: > >>> This standardizes the stacks of idle tasks to be consistent with other > >>> tasks on 32-bit. > >> > >> It might be nice to stick a ud2 or 1: hlt; jmp 1b or similar > >> afterwards to make it clear that initial_code can't return. > > > > Yeah, I'll do something like that. > > > > "Standardizing the stack" how? A zero on the stack terminates the stack > trace. Instead of zero, user tasks have a real return address at that spot. This makes idle tasks consistent with that, so we have a well defined "end of stack". Also it makes the stack trace more useful since it shows what entry code was involved in calling into C. -- Josh