[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20161210171707.cpupmxyuhob4tc3i@treble>
Date: Sat, 10 Dec 2016 11:17:07 -0600
From: Josh Poimboeuf <jpoimboe@...hat.com>
To: Balbir Singh <bsingharora@...il.com>
Cc: Jessica Yu <jeyu@...hat.com>, Jiri Kosina <jikos@...nel.org>,
Miroslav Benes <mbenes@...e.cz>,
Petr Mladek <pmladek@...e.com>, linux-s390@...r.kernel.org,
Vojtech Pavlik <vojtech@...e.com>,
Peter Zijlstra <peterz@...radead.org>, x86@...nel.org,
Heiko Carstens <heiko.carstens@...ibm.com>,
linux-kernel@...r.kernel.org, Andy Lutomirski <luto@...nel.org>,
live-patching@...r.kernel.org, Jiri Slaby <jslaby@...e.cz>,
linuxppc-dev@...ts.ozlabs.org, Ingo Molnar <mingo@...nel.org>,
Chris J Arges <chris.j.arges@...onical.com>
Subject: Re: [PATCH v3 00/15] livepatch: hybrid consistency model
On Sat, Dec 10, 2016 at 04:46:17PM +1100, Balbir Singh wrote:
> On Thu, 2016-12-08 at 12:08 -0600, Josh Poimboeuf wrote:
> > Dusting the cobwebs off the consistency model again. This is based on
> > linux-next/master.
> >
> > v1 was posted on 2015-02-09:
> >
> > https://lkml.kernel.org/r/cover.1423499826.git.jpoimboe@redhat.com
> >
> > v2 was posted on 2016-04-28:
> >
> > https://lkml.kernel.org/r/cover.1461875890.git.jpoimboe@redhat.com
> >
> > The biggest issue from v2 was finding a decent way to detect preemption
> > and page faults on the stack of a sleeping task.
>
> Could you please elaborate on this? Preemption of a sleeping task and
> faults as in the future (time) preemption and faults?
The normal way for a task to go to sleep is to call schedule(). objtool
ensures the stack trace is reliable in that case, by making sure that
all functions save the frame pointer on the stack before calling out to
another function.
But a task can also go to sleep in a few other ways. One way is by
preemption, where an interrupt handler interrupts the task and calls
preempt_schedule_irq(). Another way is by a page fault exception. In
both cases, there's no guarantee that the interrupted function saved the
frame pointer on the stack beforehand. So the stack trace might be
unreliable. Fortunately, interrupts and exceptions leave evidence
behind on the stack. So when walking the stack of a sleeping task, we
can detect when an IRQ or exception occurred, and consider such a stack
unreliable.
--
Josh
Powered by blists - more mailing lists