From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id C4F6EC3F6B0 for ; Fri, 29 Jul 2022 18:02:34 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238471AbiG2SCd (ORCPT ); Fri, 29 Jul 2022 14:02:33 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41060 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238452AbiG2SCc (ORCPT ); Fri, 29 Jul 2022 14:02:32 -0400 Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 39D7087C20; Fri, 29 Jul 2022 11:02:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1659117752; x=1690653752; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=Y0+P/vHWqaRgVIxlZZfHJ7Fd2MGWeehyke55xUiYtkk=; b=g1PMCXTHGQsqulMzRFcaEjcHlrqECD0YqkVB5ouyhCqdfz8yLSE87EoV sLcSEUoy4vsWoAWdWZjGDXMcfxUHPIUL3hLqg0RsHrJy22kHt5xm4s7a6 rMZlvt0eOOl+lNhFfRAOfINluqOW8aM08MtxFejgk9RLj170rsBg6vpj1 TeUPl5RBMDUi/JJaZTltRiLd5xyU+XroIImcO8hJkv2hpNuB2uNJy/ieA bUfk2shhaRGcf8+36QQrHP6qyiVNecsFEEm+WJlH1jLpqpQMq4u/kce5X WeSXdxHZThOjN0WaRoN5aiWGPRILWeQTIYMe2Ga/O0tNJGMfUK8G9gZWp g==; X-IronPort-AV: E=McAfee;i="6400,9594,10423"; a="314624637" X-IronPort-AV: E=Sophos;i="5.93,201,1654585200"; d="scan'208";a="314624637" Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Jul 2022 11:02:31 -0700 X-IronPort-AV: E=Sophos;i="5.93,201,1654585200"; d="scan'208";a="669348643" Received: from svdas-mobl.amr.corp.intel.com (HELO [10.209.20.175]) ([10.209.20.175]) by fmsmga004-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Jul 2022 11:02:30 -0700 Message-ID: Date: Fri, 29 Jul 2022 11:02:30 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Subject: Re: [RESEND RFC PATCH] x86/bugs: Add "unknown" reporting for MMIO Stale Data Content-Language: en-US To: Pawan Gupta Cc: Jonathan Corbet , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org, tony.luck@intel.com, antonio.gomez.iglesias@linux.intel.com, Daniel Sneddon , andrew.cooper3@citrix.com, Josh Poimboeuf References: <20220729175959.w7gd5z7dsbxrnydn@desk> From: Dave Hansen In-Reply-To: <20220729175959.w7gd5z7dsbxrnydn@desk> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org On 7/29/22 10:59, Pawan Gupta wrote: >> + if (!boot_cpu_unknown_bug(bug)) >> + return sprintf(buf, "Unknown\n"); >> >> Thoughts? > Sounds good. Similar to this Borislav suggested to add > X86_BUG_MMIO_UNKNOWN. I will see if I can combine both approaches. I'd say Borislav's is better if there is going to be a small number of "unknown" things in total. Mine might be better if we expect a *bunch* of them. In other words, I'm rooting for Borislav's.