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
Date: Tue, 12 May 2015 11:45:15 +0200 (CEST) [thread overview]
Message-ID: <alpine.LNX.2.00.1505121139310.8186@pobox.suse.cz> (raw)
In-Reply-To: <20150505162444.GA11582@treble.redhat.com>
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
next prev parent reply other threads:[~2015-05-12 9:45 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-04 11:40 [RFC kgr on klp 1/9] livepatch: make kobject in klp_object statically allocated Jiri Slaby
2015-05-04 11:40 ` [RFC kgr on klp 2/9] livepatch: introduce patch/func-walking helpers Jiri Slaby
2015-05-04 11:40 ` [RFC kgr on klp 3/9] livepatch: add klp_*_to_patch helpers Jiri Slaby
2015-05-04 11:40 ` [RFC kgr on klp 4/9] livepatch: add kgr infrastructure Jiri Slaby
2015-05-04 12:23 ` Martin Schwidefsky
2015-05-05 13:27 ` Jiri Slaby
2015-05-05 14:34 ` Martin Schwidefsky
2015-05-04 11:40 ` [RFC kgr on klp 5/9] livepatch: teach klp about consistency models Jiri Slaby
2015-05-04 11:40 ` [RFC kgr on klp 6/9] livepatch: do not allow failure while really patching Jiri Slaby
2015-05-04 11:40 ` [RFC kgr on klp 7/9] livepatch: propagate the patch status to functions Jiri Slaby
2015-05-04 11:40 ` [RFC kgr on klp 8/9] livepatch: add kgraft-like patching Jiri Slaby
2015-05-04 11:40 ` [RFC kgr on klp 9/9] livepatch: send a fake signal to all tasks Jiri Slaby
2015-05-04 14:34 ` Oleg Nesterov
2015-05-06 12:58 ` Miroslav Benes
2015-05-04 12:20 ` [RFC kgr on klp 0/9] kGraft on the top of KLP Jiri Slaby
2015-05-04 15:44 ` Josh Poimboeuf
2015-05-04 22:48 ` Jiri Kosina
2015-05-05 3:43 ` Josh Poimboeuf
2015-05-05 6:14 ` Jiri Kosina
2015-05-05 16:24 ` Josh Poimboeuf
2015-05-12 9:45 ` Jiri Kosina [this message]
2015-05-12 15:20 ` Josh Poimboeuf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.LNX.2.00.1505121139310.8186@pobox.suse.cz \
--to=jkosina@suse.cz \
--cc=jpoimboe@redhat.com \
--cc=jslaby@suse.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=live-patching@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=sjenning@redhat.com \
--cc=vojtech@suse.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).