Received: by 2002:a25:868d:0:0:0:0:0 with SMTP id z13csp535820ybk; Fri, 15 May 2020 07:14:00 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzSIVsRXM69c2kaKV9gRqIW4yAdx+cPwHSeIkoXCRNKs9ur1pdHV2HE8Zww5xLEF1TKAj3M X-Received: by 2002:a05:6402:129a:: with SMTP id w26mr2897738edv.254.1589552040823; Fri, 15 May 2020 07:14:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1589552040; cv=none; d=google.com; s=arc-20160816; b=k+2awMDh7IhGYr+Fxw/SQpy7Zi66UwfanNtVJQKaJKWPjIUNMqGahuH0RtfbMJbYK8 EZaupO3u6uimYxr3+vloEN0qUOECrGzQJLgt/aTnBgAkafItGRSKZkPidCRJocjkHk/l lJfcf3WpsonOT3LXN1K6rtm5Av2QEHFcn6Nj57l/NHR1N0iyK6gKlL3nzN57b9HBL63r 0iUzcqox7kke6xveb/tLcQayMY/omMiZjzJBKygo/Cn3VVFMw6QCoH07vnci4hd2P6EW vcaDyQ5lf9r1JH5LCWgd3jLGMFSq/8S+zB9thmO7Y5pzL/2irOQii351NklIP9QXx3eU zCFQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:in-reply-to :subject:cc:to:from; bh=fFaLyDNN/SVvvvXGPSLTlFkAfyDzG47lk6e1mqZzbVY=; b=h7CMNblwC9c5G8Qc6NxK3urJlVJ32ofzxrNocepXxPx32GqXUpNLHfNjrQ3LF3w1OE P06loDWXXJp2oVD1koopcC1kNEVbAfaxJSNMi4AhTH02xsq4ZwaQLfh0bM2fhuez0tKC qADOv5R/XGK/1SQ2wjWFxPE/MfhmTvpIxEbQu4tzXQ4viLbW5445Ix6v3KLua4Q0GKYu C13L71kZcZs8CKPTWY0llAG5/iweIp/fvry8mC2KycjqF9ETy3fasNrprCDAWRVKVS9T z4hdE69IGTMI5EAqFr+Nw5vDA54d9etfHDntClGmzK5o0GSjKTIYQPfcQdN8aq4wDqYr t71g== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id q3si1285217ejc.214.2020.05.15.07.13.38; Fri, 15 May 2020 07:14:00 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726237AbgEOOMF (ORCPT + 99 others); Fri, 15 May 2020 10:12:05 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59884 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1726144AbgEOOME (ORCPT ); Fri, 15 May 2020 10:12:04 -0400 Received: from Galois.linutronix.de (Galois.linutronix.de [IPv6:2a0a:51c0:0:12e:550::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A7B2CC061A0C for ; Fri, 15 May 2020 07:12:04 -0700 (PDT) Received: from p5de0bf0b.dip0.t-ipconnect.de ([93.224.191.11] helo=nanos.tec.linutronix.de) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1jZb3P-0001eg-Nd; Fri, 15 May 2020 16:11:12 +0200 Received: by nanos.tec.linutronix.de (Postfix, from userid 1000) id 96BF2100606; Fri, 15 May 2020 16:11:10 +0200 (CEST) From: Thomas Gleixner To: Andy Lutomirski Cc: LKML , X86 ML , "Paul E. McKenney" , Andy Lutomirski , Alexandre Chartre , Frederic Weisbecker , Paolo Bonzini , Sean Christopherson , Masami Hiramatsu , Petr Mladek , Steven Rostedt , Joel Fernandes , Boris Ostrovsky , Juergen Gross , Brian Gerst , Mathieu Desnoyers , Josh Poimboeuf , Will Deacon Subject: Re: [patch V4 part 3 29/29] x86/entry/32: Convert IRET exception to IDTENTRY_SW In-Reply-To: Date: Fri, 15 May 2020 16:11:10 +0200 Message-ID: <87imgxe1a9.fsf@nanos.tec.linutronix.de> MIME-Version: 1.0 Content-Type: text/plain X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Andy Lutomirski writes: > On Tue, May 5, 2020 at 7:15 AM Thomas Gleixner wrote: >> >> From: Thomas Gleixner >> >> Convert the IRET exception handler to IDTENTRY_SW. This is slightly >> different than the conversions of hardware exceptions as the IRET exception >> is invoked via an exception table when IRET faults. So it just uses the >> IDTENTRY_SW mechanism for consistency. It does not emit ASM code as it does >> not fit the other idtentry exceptions. > > Blech. I should redo the 32-bit code to handle this the way the > 64-bit code does and this can all be deleted. But, for now: > > Acked-by: Andy Lutomirski > > However, maybe rename asm_exc_iret_error to avoid confusion? It's not > really an exception entry. True. Removed the 'exc_' from all instances.