From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1752145AbdKVFfg (ORCPT <rfc822;w@1wt.eu>);
        Wed, 22 Nov 2017 00:35:36 -0500
Received: from mail-wm0-f68.google.com ([74.125.82.68]:36656 "EHLO
        mail-wm0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1751584AbdKVFfb (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Wed, 22 Nov 2017 00:35:31 -0500
X-Google-Smtp-Source: AGs4zMa15GQp2yQ3SuBTwMq44jKLrRuPFvNua+QorZsW7/PHXQa+DYvMzeQXAIR5Pp7JsGibCO3QNg==
Date: Wed, 22 Nov 2017 06:35:27 +0100
From: Ingo Molnar <mingo@kernel.org>
To: Andy Lutomirski <luto@kernel.org>
Cc: X86 ML <x86@kernel.org>, Borislav Petkov <bpetkov@suse.de>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Brian Gerst <brgerst@gmail.com>, Dave Hansen <dave.hansen@intel.com>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Josh Poimboeuf <jpoimboe@redhat.com>, stable@vger.kernel.org,
        Boris Ostrovsky <boris.ostrovsky@oracle.com>,
        Juergen Gross <jgross@suse.com>
Subject: Re: [PATCH v2 01/18] x86/entry/64: Fix
 entry_SYSCALL_64_after_hwframe IRQ tracing
Message-ID: <20171122053527.eqpuwow3twsl4hc3@gmail.com>
References: <cover.1511325444.git.luto@kernel.org>
 <9150aac013b7b95d62c2336751d5b6e91d2722aa.1511325444.git.luto@kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <9150aac013b7b95d62c2336751d5b6e91d2722aa.1511325444.git.luto@kernel.org>
User-Agent: NeoMutt/20170609 (1.8.3)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


* Andy Lutomirski <luto@kernel.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