All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: "Jürgen Groß" <jgross@suse.com>
Cc: syzbot <syzbot+8db9e1ecde74e590a657@syzkaller.appspotmail.com>,
	fenghua.yu@intel.com, Marco Elver <elver@google.com>,
	"Luck, Tony" <tony.luck@intel.com>,
	"Paul E. McKenney" <paulmck@kernel.org>,
	yu-cheng.yu@intel.com, Dave Hansen <dave.hansen@linux.intel.com>,
	syzkaller-bugs <syzkaller-bugs@googlegroups.com>,
	LKML <linux-kernel@vger.kernel.org>,
	kasan-dev <kasan-dev@googlegroups.com>,
	virtualization@lists.linux-foundation.org,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Wei Liu <wei.liu@kernel.org>,
	the arch/x86 maintainers <x86@kernel.org>
Subject: Re: [PATCH] x86/paravirt: Add missing noinstr to arch_local*() helpers
Date: Tue, 11 Aug 2020 10:12:05 +0200	[thread overview]
Message-ID: <20200811081205.GV3982@worktop.programming.kicks-ass.net> (raw)
In-Reply-To: <a2dffeeb-04f0-8042-b39a-b839c4800d6f@suse.com>

On Tue, Aug 11, 2020 at 09:57:55AM +0200, Jürgen Groß wrote:
> On 11.08.20 09:41, Peter Zijlstra wrote:
> > On Fri, Aug 07, 2020 at 05:19:03PM +0200, Marco Elver wrote:
> > 
> > > My hypothesis here is simply that kvm_wait() may be called in a place
> > > where we get the same case I mentioned to Peter,
> > > 
> > > 	raw_local_irq_save(); /* or other IRQs off without tracing */
> > > 	...
> > > 	kvm_wait() /* IRQ state tracing gets confused */
> > > 	...
> > > 	raw_local_irq_restore();
> > > 
> > > and therefore, using raw variants in kvm_wait() works. It's also safe
> > > because it doesn't call any other libraries that would result in corrupt
> > 
> > Yes, this is definitely an issue.
> > 
> > Tracing, we also musn't call into tracing when using raw_local_irq_*().
> > Because then we re-intoduce this same issue all over again.
> > 
> > Both halt() and safe_halt() are more paravirt calls, but given we're in
> > a KVM paravirt call already, I suppose we can directly use native_*()
> > here.
> > 
> > Something like so then... I suppose, but then the Xen variants need TLC
> > too.
> 
> Just to be sure I understand you correct:
> 
> You mean that xen_qlock_kick() and xen_qlock_wait() and all functions
> called by those should gain the "notrace" attribute, right?
> 
> I am not sure why the kick variants need it, though. IMO those are
> called only after the lock has been released, so they should be fine
> without notrace.

The issue happens when someone uses arch_spinlock_t under
raw_local_irq_*().

> And again: we shouldn't forget the Hyper-V variants.

Bah, my grep failed :/ Also *groan*, that's calling apic->send_IPI().


_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

WARNING: multiple messages have this Message-ID (diff)
From: Peter Zijlstra <peterz@infradead.org>
To: "Jürgen Groß" <jgross@suse.com>
Cc: Marco Elver <elver@google.com>, Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	fenghua.yu@intel.com, "H. Peter Anvin" <hpa@zytor.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Ingo Molnar <mingo@redhat.com>,
	syzkaller-bugs <syzkaller-bugs@googlegroups.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	"Luck, Tony" <tony.luck@intel.com>,
	the arch/x86 maintainers <x86@kernel.org>,
	yu-cheng.yu@intel.com, sdeep@vmware.com,
	virtualization@lists.linux-foundation.org,
	kasan-dev <kasan-dev@googlegroups.com>,
	syzbot <syzbot+8db9e1ecde74e590a657@syzkaller.appspotmail.com>,
	"Paul E. McKenney" <paulmck@kernel.org>,
	Wei Liu <wei.liu@kernel.org>
Subject: Re: [PATCH] x86/paravirt: Add missing noinstr to arch_local*() helpers
Date: Tue, 11 Aug 2020 10:12:05 +0200	[thread overview]
Message-ID: <20200811081205.GV3982@worktop.programming.kicks-ass.net> (raw)
In-Reply-To: <a2dffeeb-04f0-8042-b39a-b839c4800d6f@suse.com>

On Tue, Aug 11, 2020 at 09:57:55AM +0200, Jürgen Groß wrote:
> On 11.08.20 09:41, Peter Zijlstra wrote:
> > On Fri, Aug 07, 2020 at 05:19:03PM +0200, Marco Elver wrote:
> > 
> > > My hypothesis here is simply that kvm_wait() may be called in a place
> > > where we get the same case I mentioned to Peter,
> > > 
> > > 	raw_local_irq_save(); /* or other IRQs off without tracing */
> > > 	...
> > > 	kvm_wait() /* IRQ state tracing gets confused */
> > > 	...
> > > 	raw_local_irq_restore();
> > > 
> > > and therefore, using raw variants in kvm_wait() works. It's also safe
> > > because it doesn't call any other libraries that would result in corrupt
> > 
> > Yes, this is definitely an issue.
> > 
> > Tracing, we also musn't call into tracing when using raw_local_irq_*().
> > Because then we re-intoduce this same issue all over again.
> > 
> > Both halt() and safe_halt() are more paravirt calls, but given we're in
> > a KVM paravirt call already, I suppose we can directly use native_*()
> > here.
> > 
> > Something like so then... I suppose, but then the Xen variants need TLC
> > too.
> 
> Just to be sure I understand you correct:
> 
> You mean that xen_qlock_kick() and xen_qlock_wait() and all functions
> called by those should gain the "notrace" attribute, right?
> 
> I am not sure why the kick variants need it, though. IMO those are
> called only after the lock has been released, so they should be fine
> without notrace.

The issue happens when someone uses arch_spinlock_t under
raw_local_irq_*().

> And again: we shouldn't forget the Hyper-V variants.

Bah, my grep failed :/ Also *groan*, that's calling apic->send_IPI().



  reply	other threads:[~2020-08-11  8:12 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-05  7:19 upstream test error: WARNING in __local_bh_enable_ip syzbot
2020-08-05 13:26 ` [PATCH] x86/paravirt: Add missing noinstr to arch_local*() helpers Marco Elver
2020-08-05 13:42   ` peterz
2020-08-05 13:42     ` peterz
2020-08-05 13:59     ` Marco Elver
2020-08-05 14:12       ` peterz
2020-08-05 14:12         ` peterz
2020-08-05 14:17         ` Jürgen Groß
2020-08-05 14:17           ` Jürgen Groß
2020-08-05 14:17         ` peterz
2020-08-05 14:17           ` peterz
2020-08-05 14:36           ` Marco Elver
2020-08-05 17:31             ` Marco Elver
2020-08-06  7:47               ` Marco Elver
2020-08-06 11:32                 ` peterz
2020-08-06 11:32                   ` peterz
2020-08-06 13:17                   ` Marco Elver
2020-08-06 16:06                     ` Marco Elver
2020-08-07  9:01                       ` Marco Elver
2020-08-07  9:24                         ` Jürgen Groß
2020-08-07  9:24                           ` Jürgen Groß
2020-08-07  9:50                           ` Marco Elver
2020-08-07 10:35                             ` Jürgen Groß
2020-08-07 10:35                               ` Jürgen Groß
2020-08-07 11:38                               ` Marco Elver
2020-08-07 12:04                                 ` Jürgen Groß
2020-08-07 12:04                                   ` Jürgen Groß
2020-08-07 12:08                                   ` Marco Elver
2020-08-07 15:19                                     ` Marco Elver
2020-08-11  7:00                                       ` Marco Elver
2020-08-11  7:04                                         ` Jürgen Groß
2020-08-11  7:04                                           ` Jürgen Groß
2020-08-11  7:41                                       ` Peter Zijlstra
2020-08-11  7:41                                         ` Peter Zijlstra
2020-08-11  7:57                                         ` Jürgen Groß
2020-08-11  7:57                                           ` Jürgen Groß
2020-08-11  8:12                                           ` Peter Zijlstra [this message]
2020-08-11  8:12                                             ` Peter Zijlstra
2020-08-11  8:18                                             ` Jürgen Groß
2020-08-11  8:18                                               ` Jürgen Groß
2020-08-11  8:38                                             ` Jürgen Groß
2020-08-11  8:38                                               ` Jürgen Groß
2020-08-11  9:20                                               ` peterz
2020-08-11  9:20                                                 ` peterz
2020-08-11  9:46                                                 ` peterz
2020-08-11  9:46                                                   ` peterz
2020-08-11 20:17                                                   ` peterz
2020-08-11 20:17                                                     ` peterz
2020-08-12  8:06                                                     ` Marco Elver
2020-08-12  8:18                                                       ` peterz
2020-08-12  8:18                                                         ` peterz
2020-08-12  8:57                                                         ` peterz
2020-08-12  8:57                                                           ` peterz
2020-08-06 21:02   ` kernel test robot
2020-08-06 21:02     ` kernel test robot

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=20200811081205.GV3982@worktop.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=elver@google.com \
    --cc=fenghua.yu@intel.com \
    --cc=hpa@zytor.com \
    --cc=jgross@suse.com \
    --cc=kasan-dev@googlegroups.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=paulmck@kernel.org \
    --cc=syzbot+8db9e1ecde74e590a657@syzkaller.appspotmail.com \
    --cc=syzkaller-bugs@googlegroups.com \
    --cc=tglx@linutronix.de \
    --cc=tony.luck@intel.com \
    --cc=virtualization@lists.linux-foundation.org \
    --cc=wei.liu@kernel.org \
    --cc=x86@kernel.org \
    --cc=yu-cheng.yu@intel.com \
    /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.