Received: by 2002:a05:6a10:6006:0:0:0:0 with SMTP id w6csp237767pxa; Wed, 26 Aug 2020 09:15:54 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx8mSb+6LgKBAGOV/Nn1OTF/I0q9vdGe+9AYUchDE2U64G7gKP6ECXbqF2dJG1EwBCSDDmT X-Received: by 2002:a17:906:82ca:: with SMTP id a10mr15995799ejy.169.1598458553787; Wed, 26 Aug 2020 09:15:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1598458553; cv=none; d=google.com; s=arc-20160816; b=tFcDObne9Ji/P7yUoVBiVOHscz1mDHASnLxNDFqUZGhdkR0elXJ7hXCHrMvWf/zVdB Kup5ttWWm1WiwDAWF7WkWy4iZ4gSNje6sCC+ArLlOi1iZoy/tFWo6qC4dDYEJyHGzrDW i4VT3l15gLuqoktH7bVRNF+D+QUCCE5kZf5oomIkJXipvYj9agYM4jUVVkWyiBHO9tli Rx9XCOpyQVhb7dxxn6jv6IXj5QsjlrydfNNCV2P/wqonl7hGCLHIUW91c3FCMehoiJa5 6ADTwpXKMWEmuw/kX+q8EDbgutK2eMofzDkCQIvwlZuKvYLqyXwyxRJE4i0cfMKI5tV8 a9Zw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=w9mhzKFS/Jew5jvFB5T4SOyPhByVvGbaL12fFJs64+I=; b=lVaGg2QJT9kSKQn1gsoLIhkJ6GiFFoz9hpiwcGYU6ufEjJ5dSUDY1ysbbIA/cfldEX KykaoHuwEWOxzeGr4NZ3Ci0qUNhiQMJkd0vTCR85Zgr+hkI5lll6MX9sSgHkUZcRfzKr DphvSQbpZpROm8tUHRO+OZiJvW1p8m0bmftIWBnIcXmL27zbyM/C7PZ360HBxuuIkmMD Rvndm8GRtSBwTM0ptB2utwh/ZiHOBc6EopyY5ABKM/HyFHGct1DVpNC/cYU0ZPDRsuWU 4psJrYXksKKWbUXy2AHyZpukoDU7zLru1Ljr0Wn+W4cIg+z2j1m/VCSr8vr315R999Fr r3RA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=WYmronn5; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id bd20si682666edb.90.2020.08.26.09.15.29; Wed, 26 Aug 2020 09:15:53 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=WYmronn5; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727879AbgHZQOW (ORCPT + 99 others); Wed, 26 Aug 2020 12:14:22 -0400 Received: from mail.kernel.org ([198.145.29.99]:44582 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726803AbgHZQOE (ORCPT ); Wed, 26 Aug 2020 12:14:04 -0400 Received: from mail-wr1-f48.google.com (mail-wr1-f48.google.com [209.85.221.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 5ADD522BED for ; Wed, 26 Aug 2020 16:14:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1598458443; bh=oKZFw6OKcCRaJR4UDthOfPIs8jXcSZfT0W9tTH84ZMU=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=WYmronn5y6+3WxA+3lGOdD6xi9OvCfnQzq+xGa2yW2+XvVTlhh2B+67ZAgdDA3K3M lRG0f8EVz/NKFcb5ip097k+vC59HLFTD8KHnLFvC45htahMSk8D1h1cOqpMV7V000/ 2XITd34xZZCXHKCGDTQUbhYaEc+IWfZWckm7SF0c= Received: by mail-wr1-f48.google.com with SMTP id y3so2386865wrl.4 for ; Wed, 26 Aug 2020 09:14:03 -0700 (PDT) X-Gm-Message-State: AOAM531/IYul2ZKOyqWpaTYteaafpaa4BFDwy4BaIP7SeUUBZYgjWMpH YfegCoXHMo22WBDgF/wA943MjnisA4fTs4W5rppAgQ== X-Received: by 2002:adf:f442:: with SMTP id f2mr5729898wrp.184.1598458441777; Wed, 26 Aug 2020 09:14:01 -0700 (PDT) MIME-Version: 1.0 References: <20200826115357.3049-1-graf@amazon.com> <87k0xlv5w5.fsf@nanos.tec.linutronix.de> In-Reply-To: <87k0xlv5w5.fsf@nanos.tec.linutronix.de> From: Andy Lutomirski Date: Wed, 26 Aug 2020 09:13:49 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] x86/irq: Preserve vector in orig_ax for APIC code To: Thomas Gleixner Cc: Alexander Graf , X86 ML , Andy Lutomirski , LKML , Andrew Cooper , "Paul E. McKenney" , Alexandre Chartre , Frederic Weisbecker , Paolo Bonzini , Sean Christopherson , Masami Hiramatsu , Petr Mladek , Steven Rostedt , Joel Fernandes , Boris Ostrovsky , Juergen Gross , Mathieu Desnoyers , Josh Poimboeuf , Will Deacon , Tom Lendacky , Wei Liu , Michael Kelley , Jason Chen CJ , Zhao Yakui , "Peter Zijlstra (Intel)" , Avi Kivity , "Herrenschmidt, Benjamin" , robketr@amazon.de, Amos Kong , Brian Gerst , stable Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Aug 26, 2020 at 7:27 AM Thomas Gleixner wrote: > > On Wed, Aug 26 2020 at 13:53, Alexander Graf wrote: > > Commit 633260fa143 ("x86/irq: Convey vector as argument and not in ptregs") > > changed the handover logic of the vector identifier from ~vector in orig_ax > > to purely register based. Unfortunately, this field has another consumer > > in the APIC code which the commit did not touch. The net result was that > > IRQ balancing did not work and instead resulted in interrupt storms, slowing > > down the system. > > The net result is an observationof the symptom but that does not explain > what the underlying technical issue is. > > > This patch restores the original semantics that orig_ax contains the vector. > > When we receive an interrupt now, the actual vector number stays stored in > > the orig_ax field which then gets consumed by the APIC code. > > > > To ensure that nobody else trips over this in the future, the patch also adds > > comments at strategic places to warn anyone who would refactor the code that > > there is another consumer of the field. > > > > With this patch in place, IRQ balancing works as expected and performance > > levels are restored to previous levels. > > There's a lot of 'This patch and we' in that changelog. Care to grep > for 'This patch' in Documentation/process/ ? > > > diff --git a/arch/x86/entry/entry_32.S b/arch/x86/entry/entry_32.S > > index df8c017..22e829c 100644 > > --- a/arch/x86/entry/entry_32.S > > +++ b/arch/x86/entry/entry_32.S > > @@ -727,7 +727,7 @@ SYM_CODE_START_LOCAL(asm_\cfunc) > > ENCODE_FRAME_POINTER > > movl %esp, %eax > > movl PT_ORIG_EAX(%esp), %edx /* get the vector from stack */ > > - movl $-1, PT_ORIG_EAX(%esp) /* no syscall to restart */ > > + /* keep vector on stack for APIC's irq_complete_move() */ > > Yes that's fixing your observed wreckage, but it introduces a worse one. > > user space > -> interrupt > push vector into orig_ax (values are in the ranges of 0-127 and -128 - 255 > except for the system vectors which do > not go through this code) > handle() > ... > exit_to_user_mode_loop() > arch_do_signal() > /* Did we come from a system call? */ > if (syscall_get_nr(current, regs) >= 0) { > > ---> BOOM for any vector 0-127 because syscall_get_nr() > resolves to regs->orig_ax > > Going to be fun to debug. > > The below nasty hack cures it, but I hate it with a passion. I'll look > deeper for a sane variant. > Fundamentally, the way we overload orig_ax is problematic. I have a half-written series to improve it, but my series is broken. I think it's fixable, though. First is this patch to use some __csh bits to indicate the entry type. As far as I know, this patch is correct: https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/commit/?h=x86/entry&id=dfff54208072a27909ae97ebce644c251a233ff2 Then I wrote this incorrect patch: https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/commit/?h=x86/entry&id=3a5087acb8a2cc1e88b1a55fa36c2f8bef370572 That one is wrong because the orig_ax wreckage seems to have leaked into user ABI -- user programs think that orig_ax has certain semantics on user-visible entries. But I think that the problem in this thread could be fixed quite nicely by the first patch, plus a new CS_ENTRY_IRQ and allocating eight bits of __csh to store the vector. Then we could read out the vector. --Andy