public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Josh Poimboeuf <jpoimboe@kernel.org>
To: Rik van Riel <riel@fb.com>
Cc: "song@kernel.org" <song@kernel.org>,
	"joe.lawrence@redhat.com" <joe.lawrence@redhat.com>,
	Song Liu <songliubraving@fb.com>,
	"peterz@infradead.org" <peterz@infradead.org>,
	"mingo@redhat.com" <mingo@redhat.com>,
	"vincent.guittot@linaro.org" <vincent.guittot@linaro.org>,
	"live-patching@vger.kernel.org" <live-patching@vger.kernel.org>,
	"jpoimboe@redhat.com" <jpoimboe@redhat.com>,
	Kernel Team <Kernel-team@fb.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"pmladek@suse.com" <pmladek@suse.com>
Subject: Re: [RFC] sched,livepatch: call klp_try_switch_task in __cond_resched
Date: Tue, 10 May 2022 18:12:35 -0700	[thread overview]
Message-ID: <20220511011235.f7cdkc6xn7redqa3@treble> (raw)
In-Reply-To: <bf682c8874a044a643becbb8704a4dfedadc3321.camel@fb.com>

On Wed, May 11, 2022 at 12:46:32AM +0000, Rik van Riel wrote:
> On Tue, 2022-05-10 at 17:37 -0700, Josh Poimboeuf wrote:
> > On Wed, May 11, 2022 at 12:35:11AM +0000, Rik van Riel wrote:
> > > On Tue, 2022-05-10 at 23:57 +0000, Song Liu wrote:
> > > > 
> > > > So, if we come back to the same question: is this a bug (or a
> > > > suboptimal
> > > > behavior that worth fixing)? If so, we are open to any solution
> > > > that 
> > > > would also help PREEMPT and/or non-x86 arches. 
> > > > 
> > > Using the preempt notifiers during KLP transition should
> > > work equally well for PREEMPT and !PREEMPT. It also does
> > > not insert any additional code into the scheduler while
> > > there is no KLP transition going on.
> > 
> > As I've been saying, this is not going to work for PREEMPT because,
> > without ORC, we can't reliably unwind from an IRQ handler, so the
> > kthread won't get patched.
> > 
> Isn't the sched_out preempt notifier always run in
> process context?
> 
> What am I missing?

Maybe it's technically process context at that point.  But the important
point is that the call to the scheduler via preempt_schedule_irq()
originates from the "return from interrupt" path.

So the state of the interrupted task's stack is unknown.  For example it
could have been interrupted before the frame pointer prologue.  Or in a
leaf function which doesn't use frame pointers.

-- 
Josh

  reply	other threads:[~2022-05-11  1:12 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-07 17:46 [RFC] sched,livepatch: call klp_try_switch_task in __cond_resched Song Liu
2022-05-07 18:26 ` Rik van Riel
2022-05-07 19:04   ` Song Liu
2022-05-07 19:18     ` Rik van Riel
2022-05-08 20:41       ` Peter Zijlstra
2022-05-09  1:07         ` Rik van Riel
2022-05-09  7:04 ` Peter Zijlstra
2022-05-09  8:06   ` Song Liu
2022-05-09  9:38     ` Peter Zijlstra
2022-05-09 14:13       ` Rik van Riel
2022-05-09 15:22         ` Petr Mladek
2022-05-09 15:07 ` Petr Mladek
2022-05-09 16:22   ` Song Liu
2022-05-10  7:56     ` Petr Mladek
2022-05-10 13:33       ` Rik van Riel
2022-05-10 15:44         ` Petr Mladek
2022-05-10 16:07           ` Rik van Riel
2022-05-10 16:52             ` Josh Poimboeuf
2022-05-10 18:07               ` Rik van Riel
2022-05-10 18:42                 ` Josh Poimboeuf
2022-05-10 19:45                   ` Song Liu
2022-05-10 23:04                     ` Josh Poimboeuf
2022-05-10 23:57                       ` Song Liu
2022-05-11  0:33                         ` Josh Poimboeuf
2022-05-11  9:24                           ` Petr Mladek
2022-05-11 16:33                             ` Song Liu
2022-05-12  4:07                               ` Josh Poimboeuf
2022-05-13 12:33                               ` Petr Mladek
2022-05-13 13:34                                 ` Peter Zijlstra
2022-05-11  0:35                         ` Rik van Riel
2022-05-11  0:37                           ` Josh Poimboeuf
2022-05-11  0:46                             ` Rik van Riel
2022-05-11  1:12                               ` Josh Poimboeuf [this message]
2022-05-11 18:09                                 ` Rik van Riel
2022-05-12  3:59                                   ` Josh Poimboeuf
2022-05-09 15:52 ` [RFC] sched,livepatch: call stop_one_cpu in klp_check_and_switch_task Rik van Riel
2022-05-09 16:28   ` Song Liu
2022-05-09 18:00   ` Josh Poimboeuf
2022-05-09 19:10     ` Rik van Riel
2022-05-09 19:17       ` Josh Poimboeuf
2022-05-09 19:49         ` Rik van Riel
2022-05-09 20:09           ` Josh Poimboeuf
2022-05-10  0:32             ` Song Liu
2022-05-10  9:35               ` Peter Zijlstra
2022-05-10  1:48             ` Rik van Riel

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=20220511011235.f7cdkc6xn7redqa3@treble \
    --to=jpoimboe@kernel.org \
    --cc=Kernel-team@fb.com \
    --cc=joe.lawrence@redhat.com \
    --cc=jpoimboe@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=live-patching@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=pmladek@suse.com \
    --cc=riel@fb.com \
    --cc=song@kernel.org \
    --cc=songliubraving@fb.com \
    --cc=vincent.guittot@linaro.org \
    /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