linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Borislav Petkov <bp@alien8.de>, ira.weiny@intel.com
Cc: Rik van Riel <riel@surriel.com>,
	Dave Hansen <dave.hansen@intel.com>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	x86@kernel.org, linux-kernel@vger.kernel.org, kernel-team@fb.com,
	Frederic Weisbecker <frederic@kernel.org>,
	Juergen Gross <jgross@suse.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>
Subject: Re: [RFC PATCH 1/5] entry: Pass pt_regs to irqentry_exit_cond_resched()
Date: Wed, 10 Aug 2022 01:18:30 +0200	[thread overview]
Message-ID: <87fsi5qa49.ffs@tglx> (raw)
In-Reply-To: <YvDnkALyHl77R/Ug@zn.tnic>

On Mon, Aug 08 2022 at 12:38, Borislav Petkov wrote:
> On Fri, Aug 05, 2022 at 10:30:05AM -0700, ira.weiny@intel.com wrote:
>> ---
>>  arch/arm64/include/asm/preempt.h |  2 +-
>>  arch/arm64/kernel/entry-common.c |  4 ++--
>>  arch/x86/entry/common.c          |  2 +-
>>  include/linux/entry-common.h     | 17 ++++++++------
>>  kernel/entry/common.c            | 13 +++++++----
>>  kernel/sched/core.c              | 40 ++++++++++++++++----------------
>>  6 files changed, 43 insertions(+), 35 deletions(-)
>
> Why all this churn?
>
> Why can't you add a parameter to irqentry_exit():
>
>   noinstr void irqentry_exit(struct pt_regs *regs, irqentry_state_t state, bool cond_resched);
>
> and then have all callers except xen_pv_evtchn_do_upcall() pass in false
> and this way have all exit paths end up in irqentry_exit()?
>
> And, ofc, move the true case which is the body of
> raw_irqentry_exit_cond_resched() to irqentry_exit() and then get rid of
> former.
>
> xen_pv_evtchn_do_upcall() will, ofc, do:
>
>         if (inhcall && !WARN_ON_ONCE(state.exit_rcu)) {
>                 irqentry_exit(regs, state, true);
>                 instrumentation_end();
>                 restore_inhcall(inhcall);
>         } else {
>                 instrumentation_end();
>                 irqentry_exit(regs, state, false);
>

How is that less churn? Care to do:

    git grep 'irqentry_exit(' arch/

The real question is:

    Why is it required that irqentry_exit_cond_resched() handles any of
    the auxiliary pt regs space?
    
That's completely unanswered by the changelog and absolutely irrelevant
for the problem at hand, i.e. storing the CPU number on irq/exception
entry.

    So why is this patch in this series at all?

But even for future purposes it is more than questionable. Why?

Contrary to the claim of the changelog xen_pv_evtchn_do_upcall() is not
really a bypass of irqentry_exit(). The point is:

The hypercall is issued by the kernel from privcmd_ioctl_hypercall()
which does:

      xen_preemptible_hcall_begin();
      hypercall();
      xen_preemptible_hcall_end();

So any upcall from the hypervisor to the guest will semantically hit
regular interrupt enabled guest kernel space which means that if that
code would call irqentry_exit() then it would run through the kernel
exit code path:

	} else if (!regs_irqs_disabled(regs)) {

		instrumentation_begin();
		if (IS_ENABLED(CONFIG_PREEMPTION))
			irqentry_exit_cond_resched();

		/* Covers both tracing and lockdep */
		trace_hardirqs_on();
		instrumentation_end();
       } ....

Which would fail to invoke irqentry_exit_cond_resched() if
CONFIG_PREEMPTION=n.  But the whole point of this exercise is to allow
preemption from the upcall even when the kernel has CONFIG_PREEMPTION=n.

Staring at this XENPV code there are two issues:

  1) That code lacks a trace_hardirqs_on() after the call to
     irqentry_exit_cond_resched(). My bad.

  2) CONFIG_PREEMPT_DYNAMIC broke this mechanism.

     If the static call/key is disabled then the call becomes a NOP.

     Frederic?

Both clearly demonstrate how well tested this XEN_PV muck is which means
we should just delete it.

Anyway. This wants the fix below.

If there is still a need to do anything about this XEN cond_resched()
muck for the PREEMPTION=n case for future auxregs usage then this can be
simply hidden in this new XEN helper and does not need any change to the
rest of the code.

I doubt that this is required, but if so then there needs to be a very
concise explanation and not just uncomprehensible hand waving word
salad.

Thanks,

        tglx
---
--- a/arch/x86/entry/common.c
+++ b/arch/x86/entry/common.c
@@ -283,9 +283,18 @@ static __always_inline void restore_inhc
 {
 	__this_cpu_write(xen_in_preemptible_hcall, inhcall);
 }
+
+static __always_inline void xenpv_irqentry_exit_cond_resched(void)
+{
+	instrumentation_begin();
+	raw_irqentry_exit_cond_resched();
+	trace_hardirqs_on();
+	instrumentation_end();
+}
 #else
 static __always_inline bool get_and_clear_inhcall(void) { return false; }
 static __always_inline void restore_inhcall(bool inhcall) { }
+static __always_inline void xenpv_irqentry_exit_cond_resched(void) { }
 #endif
 
 static void __xen_pv_evtchn_do_upcall(struct pt_regs *regs)
@@ -306,11 +315,11 @@ static void __xen_pv_evtchn_do_upcall(st
 
 	instrumentation_begin();
 	run_sysvec_on_irqstack_cond(__xen_pv_evtchn_do_upcall, regs);
+	instrumentation_end();
 
 	inhcall = get_and_clear_inhcall();
 	if (inhcall && !WARN_ON_ONCE(state.exit_rcu)) {
-		irqentry_exit_cond_resched();
-		instrumentation_end();
+		xenpv_irqentry_exit_cond_resched();
 		restore_inhcall(inhcall);
 	} else {
 		instrumentation_end();

  parent reply	other threads:[~2022-08-09 23:18 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-05 17:30 [RFC PATCH 0/5] Print CPU at segfault time ira.weiny
2022-08-05 17:30 ` [RFC PATCH 1/5] entry: Pass pt_regs to irqentry_exit_cond_resched() ira.weiny
2022-08-05 18:33   ` Rik van Riel
2022-08-08 10:38   ` Borislav Petkov
2022-08-08 17:34     ` Ira Weiny
2022-08-08 17:38       ` Borislav Petkov
2022-08-08 17:43         ` Dave Hansen
2022-08-08 17:52           ` Borislav Petkov
2022-08-09 23:18     ` Thomas Gleixner [this message]
2022-08-10  7:25       ` Thomas Gleixner
2022-08-05 17:30 ` [RFC PATCH 2/5] entry: Add calls for save/restore auxiliary pt_regs ira.weiny
2022-08-05 18:34   ` Rik van Riel
2022-08-09 12:05   ` Borislav Petkov
2022-08-09 18:38     ` Ira Weiny
2022-08-09 18:49       ` Borislav Petkov
2022-08-09 21:14         ` Thomas Gleixner
2022-08-09 21:38           ` Borislav Petkov
2022-08-09 22:33             ` Ira Weiny
2022-08-09 21:49         ` Ira Weiny
2022-08-09 23:53           ` Thomas Gleixner
2022-08-05 17:30 ` [RFC PATCH 3/5] x86/entry: Add auxiliary pt_regs space ira.weiny
2022-08-05 18:45   ` Rik van Riel
2022-08-05 17:30 ` [RFC PATCH 4/5] x86,mm: print likely CPU at segfault time ira.weiny
2022-08-05 17:30 ` [RFC PATCH 5/5] x86/entry: Store CPU info on exception entry ira.weiny
2022-08-05 18:46   ` Rik van Riel
2022-08-05 18:47   ` Dave Hansen
2022-08-06  9:01     ` Ingo Molnar
2022-08-06  9:11       ` Borislav Petkov
2022-08-07 10:02         ` Ingo Molnar
2022-08-07 10:35           ` Borislav Petkov
2022-08-07 20:02             ` Ira Weiny
2022-08-08 11:03               ` Ingo Molnar
2022-08-08 12:01                 ` Borislav Petkov
2022-08-09 20:06                   ` Thomas Gleixner
2022-08-08 16:16                 ` Dave Hansen
2022-08-08 17:24                   ` Rik van Riel
2022-08-09 21:19                   ` Andy Lutomirski

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=87fsi5qa49.ffs@tglx \
    --to=tglx@linutronix.de \
    --cc=andrew.cooper3@citrix.com \
    --cc=bp@alien8.de \
    --cc=dave.hansen@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=frederic@kernel.org \
    --cc=ira.weiny@intel.com \
    --cc=jgross@suse.com \
    --cc=kernel-team@fb.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=riel@surriel.com \
    --cc=x86@kernel.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;
as well as URLs for NNTP newsgroup(s).