On Wed, May 11, 2022 at 06:09:28PM +0000, Rik van Riel wrote: > On Tue, 2022-05-10 at 18:12 -0700, Josh Poimboeuf wrote: > > 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. > > Ahhhh, I think I understand. > > Does that mean if the scheduling of the kernel thread originated > from an IRQ, the KLP transition will fail probably? It will fail definitely, unless you have the ORC unwinder. > However, if the call to schedule came from a voluntary preemption, > for example through a cond_resched() or due to the thread going > to sleep a little bit, the stack walk will be reliable, and the > KLP transition may succeed? Right. -- Josh
