From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751913AbcFXSNJ (ORCPT ); Fri, 24 Jun 2016 14:13:09 -0400 Received: from mx1.redhat.com ([209.132.183.28]:48281 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751585AbcFXSNI (ORCPT ); Fri, 24 Jun 2016 14:13:08 -0400 Date: Fri, 24 Jun 2016 13:12:45 -0500 From: Josh Poimboeuf To: Brian Gerst Cc: the arch/x86 maintainers , Linux Kernel Mailing List , Ingo Molnar , "H. Peter Anvin" , Denys Vlasenko , Andy Lutomirski , Borislav Petkov , Thomas Gleixner Subject: Re: [PATCH v2 6/6] x86: Fix thread_saved_pc() Message-ID: <20160624181245.d3uzocmdkabmrdc4@treble> References: <1466283378-17062-1-git-send-email-brgerst@gmail.com> <1466283378-17062-7-git-send-email-brgerst@gmail.com> <20160620160141.ct6ua2qungibffvu@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.39]); Fri, 24 Jun 2016 18:12:47 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jun 22, 2016 at 12:27:43AM -0400, Brian Gerst wrote: > On Mon, Jun 20, 2016 at 12:01 PM, Josh Poimboeuf wrote: > > On Sat, Jun 18, 2016 at 04:56:18PM -0400, Brian Gerst wrote: > >> thread_saved_pc() was using a completely bogus method to get the return > >> address. Since switch_to() was previously inlined, there was no sane way > >> to know where on the stack the return address was stored. Now with the > >> frame of a sleeping thread well defined, this can be implemented correctly. > >> > >> Signed-off-by: Brian Gerst > >> --- > >> arch/x86/include/asm/processor.h | 10 ++-------- > >> arch/x86/kernel/process.c | 10 ++++++++++ > >> arch/x86/kernel/process_32.c | 8 -------- > >> 3 files changed, 12 insertions(+), 16 deletions(-) > >> > >> diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h > >> index 1e7d634..413f4f1 100644 > >> --- a/arch/x86/include/asm/processor.h > >> +++ b/arch/x86/include/asm/processor.h > >> @@ -716,8 +716,6 @@ static inline void spin_lock_prefetch(const void *x) > >> .io_bitmap_ptr = NULL, \ > >> } > >> > >> -extern unsigned long thread_saved_pc(struct task_struct *tsk); > >> - > >> /* > >> * TOP_OF_KERNEL_STACK_PADDING reserves 8 bytes on top of the ring0 stack. > >> * This is necessary to guarantee that the entire "struct pt_regs" > >> @@ -767,17 +765,13 @@ extern unsigned long thread_saved_pc(struct task_struct *tsk); > >> .sp0 = TOP_OF_INIT_STACK \ > >> } > >> > >> -/* > >> - * Return saved PC of a blocked thread. > >> - * What is this good for? it will be always the scheduler or ret_from_fork. > >> - */ > >> -#define thread_saved_pc(t) READ_ONCE_NOCHECK(*(unsigned long *)((t)->thread.sp - 8)) > >> - > >> #define task_pt_regs(tsk) ((struct pt_regs *)(tsk)->thread.sp0 - 1) > >> extern unsigned long KSTK_ESP(struct task_struct *task); > >> > >> #endif /* CONFIG_X86_64 */ > >> > >> +extern unsigned long thread_saved_pc(struct task_struct *tsk); > >> + > >> extern void start_thread(struct pt_regs *regs, unsigned long new_ip, > >> unsigned long new_sp); > >> > >> diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c > >> index 00ebab0..db458c4 100644 > >> --- a/arch/x86/kernel/process.c > >> +++ b/arch/x86/kernel/process.c > >> @@ -513,6 +513,16 @@ unsigned long arch_randomize_brk(struct mm_struct *mm) > >> } > >> > >> /* > >> + * Return saved PC of a blocked thread. > >> + */ > >> +unsigned long thread_saved_pc(struct task_struct *tsk) > >> +{ > >> + struct inactive_task_frame *frame = > >> + (struct inactive_task_frame *) READ_ONCE(tsk->thread.sp); > >> + return READ_ONCE_NOCHECK(frame->ret_addr); > >> +} > >> + > >> +/* > > > > I would agree with the above (removed) comment: > > > > "What is this good for? it will be always the scheduler or ret_from_fork." > > > > And I'd guess the same is true for all the arches which have to > > implement it. Maybe this function (and its single call site in > > sched_show_task()) should just be removed altogether? > > I didn't really want to stray down that path with this series. This > just makes it functional again. the usefulness is still open for > debate. Fair enough. Reviewed-by: Josh Poimboeuf -- Josh