Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752356AbcD2WlT (ORCPT ); Fri, 29 Apr 2016 18:41:19 -0400 Received: from mx1.redhat.com ([209.132.183.28]:46906 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751153AbcD2WlR (ORCPT ); Fri, 29 Apr 2016 18:41:17 -0400 Date: Fri, 29 Apr 2016 17:41:12 -0500 From: Josh Poimboeuf To: Andy Lutomirski Cc: Jessica Yu , Jiri Kosina , Miroslav Benes , Ingo Molnar , Peter Zijlstra , Michael Ellerman , Heiko Carstens , live-patching@vger.kernel.org, "linux-kernel@vger.kernel.org" , X86 ML , linuxppc-dev@lists.ozlabs.org, "linux-s390@vger.kernel.org" , Vojtech Pavlik , Jiri Slaby , Petr Mladek , Chris J Arges , Andy Lutomirski Subject: Re: [RFC PATCH v2 05/18] sched: add task flag for preempt IRQ tracking Message-ID: <20160429224112.kl3jlk7ccvfceg2r@treble> References: <20160429201139.pudoged2yathyo64@treble> <20160429202701.yijrohqdsurdxv2a@treble> <20160429212546.t26mvthtvh7543ff@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, 29 Apr 2016 22:41:16 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1494 Lines: 38 On Fri, Apr 29, 2016 at 02:37:41PM -0700, Andy Lutomirski wrote: > On Fri, Apr 29, 2016 at 2:25 PM, Josh Poimboeuf wrote: > > I think the easiest way to make it work would be to modify the idtentry > > macro to put all the idt entries in a dedicated section. Then the > > unwinder could easily detect any calls from that code. > > That would work. Would it make sense to do the same for the irq entries? Yes, I think so. > >> I suppose we could try to rejigger the code so that rbp points to > >> pt_regs or similar. > > > > I think we should avoid doing something like that because it would break > > gdb and all the other unwinders who don't know about it. > > How so? > > Currently, rbp in the entry code is meaningless. I'm suggesting that, > when we do, for example, 'call \do_sym' in idtentry, we point rbp to > the pt_regs. Currently it points to something stale (which the > dump_stack code might be relying on. Hmm.) But it's probably also > safe to assume that if you unwind to the 'call \do_sym', then pt_regs > is the next thing on the stack, so just doing the section thing would > work. Yes, rbp is meaningless on the entry from user space. But if an in-kernel interrupt occurs (e.g. page fault, preemption) and you have nested entry, rbp keeps its old value, right? So the unwinder can walk past the nested entry frame and keep going until it gets to the original entry. > We should really re-add DWARF some day. Working on it :-) -- Josh