Received: by 2002:a05:6358:a55:b0:ec:fcf4:3ecf with SMTP id 21csp1704659rwb; Thu, 19 Jan 2023 14:24:47 -0800 (PST) X-Google-Smtp-Source: AMrXdXvNDP1uNkARvt1f4bj1AKzzAWDz5EB9S0yyJ/Kjv9y3rNTlYdFs/2Uw4mVxyMaZ40XGBUSy X-Received: by 2002:a17:906:1783:b0:866:6b08:946b with SMTP id t3-20020a170906178300b008666b08946bmr12833541eje.39.1674167087052; Thu, 19 Jan 2023 14:24:47 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1674167087; cv=none; d=google.com; s=arc-20160816; b=P1z41Bh/E6Pl+pExKarcg7MwFLXVQqvEXPKpyd+RRHFyZZoPwg5kFPKxSAYznRf8da wZATAHzwJggTmf68SWegyZuZQE+2pvtlcV7NeW4/6LOQmyt6qS18LroN+itNSffFvX1W 8y69XOkmfwop1Xt0dMTLglhi6AM+MWnXGrrMfP4FIZ46ROqH6WBRZqDqpU3SMi0ftprw djxKZkLLBrN/P7ZvyCAOVyz1FJncG3aulA6MT6Ygc+PzIbgWsoAPEckreEyTezHXhgf8 vSnDe8WCdZRWo1Yt529usjCpdnpwVSyoLExKPQMNOabInHBWVr+ttgzQXh69afdBtFXP v1oA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:date:references :in-reply-to:subject:cc:to:dkim-signature:dkim-signature:from; bh=VsSF7KWIbHynqYrF26mD07CtF4vjiv4FfxR14nRaxz4=; b=bu843Q/4JZD1lpR9zJRZhz/PdYD9R44lDZjJSViFqV5e+x2yGZEKd2rRFXKxYrkQ7+ CAFtGfSeBuvVFUz7Fii7bG7ogC7mo35SZlC/aPl+8D/klQtd7azv0fv2PWCjGGYPreO2 fsagp5/meBQ2VIox6KZi7UcsUMRhaZUZ2E/WddnazKzmMTnuiJ03d4SNXOY/qj5IxmUY 8bbwFyAdxH12nIcLFQtoBIq69zc3my50Rue5AeD5L7bzKc4ZOerrlg1bAumqks3c1p20 /J0zukel9gjYYTvrVIn28CDJTtETdo+SGWpH//cscgBuZxfYxFhVZ9XVb8lSvscSc6xF q6mg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=zFG177w8; dkim=neutral (no key) header.i=@linutronix.de header.s=2020e header.b=v96ZlMum; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id hb6-20020a170907160600b0086e372590a3si20041388ejc.381.2023.01.19.14.24.35; Thu, 19 Jan 2023 14:24:47 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=zFG177w8; dkim=neutral (no key) header.i=@linutronix.de header.s=2020e header.b=v96ZlMum; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229620AbjASWMZ (ORCPT + 48 others); Thu, 19 Jan 2023 17:12:25 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47022 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230076AbjASWLO (ORCPT ); Thu, 19 Jan 2023 17:11:14 -0500 Received: from galois.linutronix.de (Galois.linutronix.de [IPv6:2a0a:51c0:0:12e:550::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4B93CA57AC for ; Thu, 19 Jan 2023 13:48:32 -0800 (PST) From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1674164910; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=VsSF7KWIbHynqYrF26mD07CtF4vjiv4FfxR14nRaxz4=; b=zFG177w86kGq1oQNDqcU1jN1HxoC3tlcpBxcpDiKQJcx4LLrnBcjXqSCfS09S9oC9K8qYl hQIhvv9hxH6ZyyST6OKceUgeffGQmeYyc5bqBgEPzdooUNSvSxj5j7XXo66IKNUNPPZ3RR haWtyfyffSO6mvkzinmtrV60YdUOY/5Fxkoi4aGjxSxiFTXgAzB+fkBmkzO4ABkNkA3EfP yEPWGcmIVyQJGsETuthNC1ffHDTCXic+/IsBFu50X6PMyRPz31YuBpl9b8km/6QQNv3TBZ 3dVc/K6vSKaqC5cnjjlMVBKiqna5aGEO+lfbz/DEaeJ+HysMWFo4ZAoSk8VFMw== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1674164910; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=VsSF7KWIbHynqYrF26mD07CtF4vjiv4FfxR14nRaxz4=; b=v96ZlMumHcq9QNUOU38faR0IqywOVckBTw4bXRH6nT2Gz+/A4gZcn6wlhfmimBddsI7y+I tYZVW3+1zatVKtDQ== To: Ashok Raj , Borislav Petkov Cc: Ashok Raj , Tony Luck , LKML , x86 , Ingo Molnar , Dave Hansen , Alison Schofield , Reinette Chatre , Tom Lendacky , Stefan Talpalaru , David Woodhouse , Benjamin Herrenschmidt , Jonathan Corbet , "Rafael J . Wysocki" , Peter Zilstra , Andy Lutomirski , Andrew Cooper Subject: Re: [PATCH v1 Part2 1/5] x86/microcode: Move late load warning to the same function that taints kernel In-Reply-To: <20230113172920.113612-2-ashok.raj@intel.com> References: <20230113172920.113612-1-ashok.raj@intel.com> <20230113172920.113612-2-ashok.raj@intel.com> Date: Thu, 19 Jan 2023 22:48:30 +0100 Message-ID: <875yd2i4b5.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jan 13 2023 at 09:29, Ashok Raj wrote: > Currently the warning about late loading and tainting are issued from two > different functions. > > Later patches will re-enable microcode late-loading. > > Having both messages in the same function helps issuing warnings only > when required. > > Move the warning from microcode_reload_late() -> reload_store() where the > kernel tainting also happens. > > No functional change. I had to read this more than once to make sense of it. Let me try a translation: Late microcode loading issues a warning and taints the kernel. Tainting the kernel and emitting the warning happens in two different functions. The upcoming support for safe late loading under certain conditions needs to prevent both the warning and the tainting when the safe conditions are met. That would require to hand the result of the safe condition check into the function which emits the warning. To avoid this awkward construct, move the warning into reload_store() next to the taint() invocation as that is also the function which will later contain the safe condition check. No functional change. Did my decoder get that right? Thanks, tglx