[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20171122053527.eqpuwow3twsl4hc3@gmail.com>
Date: Wed, 22 Nov 2017 06:35:27 +0100
From: Ingo Molnar <mingo@...nel.org>
To: Andy Lutomirski <luto@...nel.org>
Cc: X86 ML <x86@...nel.org>, Borislav Petkov <bpetkov@...e.de>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Brian Gerst <brgerst@...il.com>,
Dave Hansen <dave.hansen@...el.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Josh Poimboeuf <jpoimboe@...hat.com>, stable@...r.kernel.org,
Boris Ostrovsky <boris.ostrovsky@...cle.com>,
Juergen Gross <jgross@...e.com>
Subject: Re: [PATCH v2 01/18] x86/entry/64: Fix
entry_SYSCALL_64_after_hwframe IRQ tracing
* Andy Lutomirski <luto@...nel.org> wrote:
> When I added entry_SYSCALL_64_after_hwframe, I left TRACE_IRQS_OFF
> before it. This means that users of entry_SYSCALL_64_after_hwframe
> were responsible for invoking TRACE_IRQS_OFF, and the one and only
> user (added in the same commit) got it wrong.
>
> I think this would manifest as a warning if a Xen PV guest with
> CONFIG_DEBUG_LOCKDEP=y were used with context tracking. (The
> context tracking bit is to cause lockdep to get invoked before we
> turn IRQs back on.) I haven't tested that for real yet because I
> can't get a kernel configured like that to boot at all on Xen PV.
> I've reported it upstream. The problem seems to be that Xen PV is
> missing early #UD handling, is hitting some WARN, and we rely on
JFYI, seems the changelog got truncated at this point - I simply removed that
partial sentence as I suppose those details will be explained in the Xen fix
anyway.
> Move TRACE_IRQS_OFF below the label.
Thanks,
Ingo
Powered by blists - more mailing lists