similar to: [PATCH] x86/paravirt: Add missing noinstr to arch_local*() helpers

And some more information ... Am 2014-10-13 12:04, schrieb Jonas Meurer: > Am 2014-08-19 12:26, schrieb Jonas Meurer: >> I encounter kernel crashes on an up-to-date Debian/Wheezy Xen domU >> with the >> stock kernel. The dom0 runs the same linux kernel and >> xen/4.1.4-3+deb7u1. > > the bug is still reproducible with the latest kernel and Xen packages >

On 07.08.20 11:01, Marco Elver wrote: > On Thu, 6 Aug 2020 at 18:06, Marco Elver <elver at google.com> wrote: >> On Thu, 6 Aug 2020 at 15:17, Marco Elver <elver at google.com> wrote: >>> On Thu, Aug 06, 2020 at 01:32PM +0200, peterz at infradead.org wrote: >>>> On Thu, Aug 06, 2020 at 09:47:23AM +0200, Marco Elver wrote: >>>>> Testing my

On 07.08.20 11:50, Marco Elver wrote: > On Fri, Aug 07, 2020 at 11:24AM +0200, J?rgen Gro? wrote: >> On 07.08.20 11:01, Marco Elver wrote: >>> On Thu, 6 Aug 2020 at 18:06, Marco Elver <elver at google.com> wrote: >>>> On Thu, 6 Aug 2020 at 15:17, Marco Elver <elver at google.com> wrote: >>>>> On Thu, Aug 06, 2020 at 01:32PM +0200, peterz at

On 07.08.20 13:38, Marco Elver wrote: > On Fri, Aug 07, 2020 at 12:35PM +0200, J?rgen Gro? wrote: >> On 07.08.20 11:50, Marco Elver wrote: >>> On Fri, Aug 07, 2020 at 11:24AM +0200, J?rgen Gro? wrote: >>>> On 07.08.20 11:01, Marco Elver wrote: >>>>> On Thu, 6 Aug 2020 at 18:06, Marco Elver <elver at google.com> wrote: >>>>>> On

Hey again, Am 2014-08-19 12:26, schrieb Jonas Meurer: > I encounter kernel crashes on an up-to-date Debian/Wheezy Xen domU with > the > stock kernel. The dom0 runs the same linux kernel and > xen/4.1.4-3+deb7u1. the bug is still reproducible with the latest kernel and Xen packages from Debian Wheezy. Unfortunately it seems like a corner case, somehow related to the hardware

On Wed, Aug 05, 2020 at 03:59:40PM +0200, Marco Elver wrote: > On Wed, Aug 05, 2020 at 03:42PM +0200, peterz at infradead.org wrote: > > Shouldn't we __always_inline those? They're going to be really small. > > I can send a v2, and you can choose. For reference, though: > > ffffffff86271ee0 <arch_local_save_flags>: > ffffffff86271ee0: 0f 1f 44 00 00

On Wed, Aug 05, 2020 at 03:59:40PM +0200, Marco Elver wrote: > On Wed, Aug 05, 2020 at 03:42PM +0200, peterz at infradead.org wrote: > > Shouldn't we __always_inline those? They're going to be really small. > > I can send a v2, and you can choose. For reference, though: > > ffffffff86271ee0 <arch_local_save_flags>: > ffffffff86271ee0: 0f 1f 44 00 00

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

On Tue, Aug 11, 2020 at 10:38:50AM +0200, J?rgen Gro? wrote: > In case you don't want to do it I can send the patch for the Xen > variants. I might've opened a whole new can of worms here. I'm not sure we can/want to fix the entire fallout this release :/ Let me ponder this a little, because the more I look at things, the more problems I keep finding... bah bah bah.

On 11.08.20 09:00, Marco Elver wrote: > On Fri, 7 Aug 2020 at 17:19, Marco Elver <elver at google.com> wrote: >> On Fri, Aug 07, 2020 at 02:08PM +0200, Marco Elver wrote: >>> On Fri, 7 Aug 2020 at 14:04, J?rgen Gro? <jgross at suse.com> wrote: >>>> >>>> On 07.08.20 13:38, Marco Elver wrote: >>>>> On Fri, Aug 07, 2020 at 12:35PM

On Thu, Aug 06, 2020 at 09:47:23AM +0200, Marco Elver wrote: > Testing my hypothesis that raw then nested non-raw > local_irq_save/restore() breaks IRQ state tracking -- see the reproducer > below. This is at least 1 case I can think of that we're bound to hit. Aaargh! > diff --git a/init/main.c b/init/main.c > index 15bd0efff3df..0873319dcff4 100644 > --- a/init/main.c

On 11.08.20 10:12, Peter Zijlstra wrote: > 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,

On 11.08.20 10:12, Peter Zijlstra wrote: > 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,

On Wed, Aug 12, 2020 at 10:06:50AM +0200, Marco Elver wrote: > On Tue, Aug 11, 2020 at 10:17PM +0200, peterz at infradead.org wrote: > > On Tue, Aug 11, 2020 at 11:46:51AM +0200, peterz at infradead.org wrote: > > > > > So let me once again see if I can't find a better solution for this all. > > > Clearly it needs one :/ > > > > So the below boots

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,

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

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

On Tue, Aug 11, 2020 at 11:20:54AM +0200, peterz at infradead.org wrote: > On Tue, Aug 11, 2020 at 10:38:50AM +0200, J?rgen Gro? wrote: > > In case you don't want to do it I can send the patch for the Xen > > variants. > > I might've opened a whole new can of worms here. I'm not sure we > can/want to fix the entire fallout this release :/ > > Let me

On Tue, Aug 11, 2020 at 11:20:54AM +0200, peterz at infradead.org wrote: > On Tue, Aug 11, 2020 at 10:38:50AM +0200, J?rgen Gro? wrote: > > In case you don't want to do it I can send the patch for the Xen > > variants. > > I might've opened a whole new can of worms here. I'm not sure we > can/want to fix the entire fallout this release :/ > > Let me

Package: xen-hypervisor-4.1-amd64 Version: 4.1.4-3+deb7u1 Severity: normal Hello, I was running Xen for a few years and after a PSU failure I never got the system working stable again. I suspected damage to the board so I replaced everything in the system piece by piece but Xen enabled kernel always crashes even with only Dom0 running when moderate amount of IO happens on the box. kvm seems