Date: Tue, 12 May 2015 11:45:15 +0200 (CEST)
From: Jiri Kosina <jkosina@suse.cz>
To: Josh Poimboeuf <jpoimboe@redhat.com>
cc: Jiri Slaby <jslaby@suse.cz>, live-patching@vger.kernel.org,
        sjenning@redhat.com, vojtech@suse.cz, mingo@redhat.com,
        linux-kernel@vger.kernel.org
Subject: Re: [RFC kgr on klp 0/9] kGraft on the top of KLP
In-Reply-To: <20150505162444.GA11582@treble.redhat.com>
Message-ID: <alpine.LNX.2.00.1505121139310.8186@pobox.suse.cz>
References: <1430739625-4658-1-git-send-email-jslaby@suse.cz> <1430742009-5895-1-git-send-email-jslaby@suse.cz> <20150504154429.GA21537@treble.redhat.com> <alpine.LNX.2.00.1505050036440.17961@pobox.suse.cz> <20150505034352.GA20128@treble.redhat.com>
 <alpine.LNX.2.00.1505050756570.17961@pobox.suse.cz> <20150505162444.GA11582@treble.redhat.com>
User-Agent: Alpine 2.00 (LNX 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2663
Lines: 58

On Tue, 5 May 2015, Josh Poimboeuf wrote:

> > Agreed ...  under the condition that it can be made really 100% reliable 
> > *and* we'd be reasonably sure that we will be able to realistically 
> > achieve the same goal on other architectures as well. Have you even 
> > started exploring that space, please?
> 
> Yes.  As I postulated before [1], there are two obstacles to achieving
> reliable frame pointer stack traces: 1) missing frame pointer logic and
> 2) exceptions.  If either 1 or 2 was involved in the creation of any of
> the frames on the stack, some frame pointers might be missing, and one
> or more frames could be skipped by the stack walker.
> 
> The first obstacle can be overcome and enforced at compile time using
> stackvalidate [1].
> 
> The second obstacle can be overcome at run time with a future RFC:
> something like a save_stack_trace_tsk_validate() function which does
> some validations while it walks the stack.  It can return an error if it
> detects an exception frame.
> 
>   (It can also do some sanity checks like ensuring that it walks all the
>   way to the bottom of the stack and that each frame has a valid ktext
>   address.  I also would propose a CONFIG_DEBUG_VALIDATE_STACK option
>   which tries to validate the stack on every call to schedule.)
> 
> Then we can have the hybrid consistency model rely on
> save_stack_trace_tsk_validate().  If the stack is deemed unsafe, we can
> fall back to retrying later, or to the kGraft mode of user mode barrier
> patching.
> 
> Eventually I want to try to make *all* stacks reliable, even those with
> exception frames.  That would involve compile and run time validations
> of DWARF data, and ensuring that DWARF and frame pointers are consistent
> with each other.  But those are general improvements which aren't
> prerequisites for the hybrid model.
> 
> [1] http://lkml.kernel.org/r/cover.1430770553.git.jpoimboe@redhat.com

Yup, I understand what is the goal here (and don't get me wrong, I am of 
course all for making frame pointer based stack traces reliable). The 
question I had was -- your patchset is now very x86-centric. If we are 
going to proceed with the hybrid patching model, we'd need to be able to 
extend to other architectures as easily as possible.

I currently haven't yet tried to explore how difficult would it be to 
extend your aproach to other archs. Have you?

Thanks,

-- 
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/