All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: paulmck@kernel.org
Cc: LKML <linux-kernel@vger.kernel.org>,
	x86@kernel.org, Paolo Bonzini <pbonzini@redhat.com>,
	KVM <kvm@vger.kernel.org>
Subject: Re: [patch 2/2] x86/kvm: Sanitize kvm_async_pf_task_wait()
Date: Sat, 07 Mar 2020 02:02:25 +0100	[thread overview]
Message-ID: <874kv1asf2.fsf@nanos.tec.linutronix.de> (raw)
In-Reply-To: <20200307002210.GJ2935@paulmck-ThinkPad-P72>

"Paul E. McKenney" <paulmck@kernel.org> writes:
>> In #2c RCU is eventually not watching, but as that state cannot schedule
>> anyway there is no point to worry about it so it has to invoke
>> rcu_irq_enter() before running that code. This can be optimized, but this
>> will be done as an extra step in course of the entry code consolidation
>> work.
>
> In other words, any needed rcu_irq_enter() and rcu_irq_exit() are added
> in one of the entry-code consolidation patches, and patch below depends
> on that patch, correct?

No. The patch itself is already correct when applied to mainline. It has
no dependencies.

It invokes rcu_irq_enter()/exit() for the case (#2c) where it is
relevant. All other case are already RCU safe today.

The fact that the invocation is misplaced is a different story and yes,
that is part of the entry code cleanup along with some optimization
which are possible once the entry voodoo is out of ASM and adjustable
for a particular entry point in C.

Thanks,

        tglx

  reply	other threads:[~2020-03-07  1:02 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-06 23:42 [patch 0/2] x86/kvm: Sanitize async page fault Thomas Gleixner
2020-03-06 23:42 ` [patch 1/2] x86/kvm: Handle async page faults directly through do_page_fault() Thomas Gleixner
2020-03-17  8:47   ` [x86/kvm] aec3011ae9: WARNING:at_arch/x86/kernel/kvm.c:#kvm_guest_init kernel test robot
2020-03-17  8:47     ` kernel test robot
2020-03-06 23:42 ` [patch 2/2] x86/kvm: Sanitize kvm_async_pf_task_wait() Thomas Gleixner
2020-03-07  0:22   ` Paul E. McKenney
2020-03-07  1:02     ` Thomas Gleixner [this message]
2020-03-07  3:48       ` Paul E. McKenney
2020-03-07  2:18   ` Andy Lutomirski
2020-03-07 10:01     ` Thomas Gleixner
2020-03-07 15:10       ` Andy Lutomirski
2020-03-07 15:51         ` Andy Lutomirski
2020-03-07 19:18           ` Thomas Gleixner
2020-03-07 19:30             ` Andy Lutomirski
2020-03-07 15:52         ` Thomas Gleixner
2020-03-07 16:06           ` Andy Lutomirski
2020-03-07 20:08             ` Thomas Gleixner

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=874kv1asf2.fsf@nanos.tec.linutronix.de \
    --to=tglx@linutronix.de \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=paulmck@kernel.org \
    --cc=pbonzini@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.