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;
Date:   Mon, 8 Aug 2022 16:30:22 -0700
From:   Dan Williams <dan.j.williams@intel.com>
To:     Jane Chu <jane.chu@oracle.com>, Ingo Molnar <mingo@kernel.org>
CC:     "tony.luck@intel.com" <tony.luck@intel.com>,
        "bp@alien8.de" <bp@alien8.de>,
        "tglx@linutronix.de" <tglx@linutronix.de>,
        "mingo@redhat.com" <mingo@redhat.com>,
        "dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>,
        "x86@kernel.org" <x86@kernel.org>,
        "linux-edac@vger.kernel.org" <linux-edac@vger.kernel.org>,
        "dan.j.williams@intel.com" <dan.j.williams@intel.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "hch@lst.de" <hch@lst.de>,
        "nvdimm@lists.linux.dev" <nvdimm@lists.linux.dev>
Subject: Re: [PATCH v7] x86/mce: retrieve poison range from hardware
Message-ID: <62f19c8e795d1_1b3c29448@dwillia2-xfh.jf.intel.com.notmuch>
References: <20220802195053.3882368-1-jane.chu@oracle.com>
 <Yuo3dioqb9mDAOcT@gmail.com>
 <833288b3-4838-63b8-b22b-f22538877957@oracle.com>
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <833288b3-4838-63b8-b22b-f22538877957@oracle.com>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?mRMA/e11//UTebNIwqBXqXVmx4iYOXFZldTyf9FYKp6Y2elnGa1fMKCvF4MM?=
 =?us-ascii?Q?jEPz3620zbgDW2eT42bEL43tpl4h+j45FDlJguR1SmlUx+5W+NpWRmO0ojgC?=
 =?us-ascii?Q?iS79zzQIMiAjHTzyg6GLW2gItjNP5LW7tiIIzZf8PIV/Lg3BpDV7GlEOjj+d?=
 =?us-ascii?Q?IxPSqOHQmV1AM7nmlY2u5hPd085zrA/0v+Z4/q3T1vk1XuzzICoXi56QQ61a?=
 =?us-ascii?Q?2zL8B7kLkVTe7jbor8vbV2cDtRtLWhntcolA9H9NnSEBCQBeL9FBBDAdx0QC?=
 =?us-ascii?Q?JrLZb+hL4B7zpf9lhXdEQZ+nZBfSABydsrn6q5KJQ2ghu9DidxiBdtRcsRKF?=
 =?us-ascii?Q?xt/vXOtqgcXJdac0LFZj3fe+enhut1KA7Ut91KlXXXwMLyBDPT/KKnkUCKbE?=
 =?us-ascii?Q?sCDs0mYrbd7+dLQ39M7MuICark5kCiVfnfxH9BEk6wX73X5Apr9ApUAWT9PF?=
 =?us-ascii?Q?kirloUMyNhQ8sC9A44OHu2qf1U4nbE0ddd/vklFasoJBLWuYcVVE8a0H8EeJ?=
 =?us-ascii?Q?CpuaYsuumZEWSlH0bxp/jIvY8CkoC5YvnL2hmRxL3FX8TFea3UlezBG4Infv?=
 =?us-ascii?Q?pkqmmcoB7CpKgW2fxVaxREZTP826yGRNEOArQGlHw7EtaOvQeP3OVe31w0Ku?=
 =?us-ascii?Q?iHMqE9qyYRbQOCSh0QN7RuYlEPqnf8hoUDTF1+cxs4UIew0UA++kL3zA29yN?=
 =?us-ascii?Q?5ww7SUEGAswMjRIJ8X+mYomxuV692r4GpDYkaQ2SJG/pvASsdKETM25y9zzp?=
 =?us-ascii?Q?rmJ1YL/leYeUcXaGBcYOdxpQvxZwE3MJqrRZojAvCxz4vef8V0MxbqxJ1pVl?=
 =?us-ascii?Q?b07MVEq5fkRjvPtlX1wpAtQTRtLaZOJ3m4/MbPgPIH+lhE3jFz+dCz63eeZm?=
 =?us-ascii?Q?en5nW8X0/1WrSfPkJ+Ju5B/TBXiEjpu+5y0sQozUZO1EJTN1uh+jWKM0NTHJ?=
 =?us-ascii?Q?TcmVx02Mo2wkf0Ot42MSEQ4RnYEO5qtmgc62YNyTUSJks/e2HFyBi61fGp5c?=
 =?us-ascii?Q?pNMZ0DshRdH8xHBX79aN2KgHa+L5+jjzjXoMksion09sx7Im9t9gb8yMA95H?=
 =?us-ascii?Q?3HFiEKdddQ1oAIwOVyUfHOx7VqgWFGxZuNUdLVghmklUSJvodKKy2nL6I+3i?=
 =?us-ascii?Q?h1JAxkNYMcEmcdrvWwoTQDGYOoRCvtKK3kECuJA1mOwGxDXYUu85eDZ/lZSy?=
 =?us-ascii?Q?Vw6IdIHheJq5kF8UXCv56SNPZ28lsenoQAXRsBdojPfQe9okuV8UzbP1krmN?=
 =?us-ascii?Q?boEmqIompaPYD5QjdZaWb4GVJRwHGFrIRf044RnVqtM+CFfxT5ZbfaVNMgZ2?=
 =?us-ascii?Q?ZN6ed+TStMj/O4aZz/yHnnXhc0CKK1YzZpA74DX59a8g4ax3fjHJpYK1GJCK?=
 =?us-ascii?Q?3aIiEn4X09/+MH2sK7zbDZWpf7/0FLyhXn+njP4nFCO+oyRKMIYRlGf8F9Xb?=
 =?us-ascii?Q?ht8OHYwtFSL/oUvJ5FE4NHsPv340NsbL96oJEMmystiVjs1hvQ7sDhQhGQQU?=
 =?us-ascii?Q?2kgLja5mWaYOiXKZv19ZO6hcM02DRU35jkCcDi3pSUQ8dNzU5RNsTRvpIurx?=
 =?us-ascii?Q?AVxzeRiXld+jp/hdEhS8qPi+9hZ3+HhtzXkADsiMMRbA99ec4q/7PDKKzX25?=
 =?us-ascii?Q?9g=3D=3D?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 510444e2-7504-473f-7f03-08da7995f88c
X-MS-Exchange-CrossTenant-AuthSource: MWHPR1101MB2126.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Aug 2022 23:30:25.5735
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: oQOb2MczMTnEjLGtpmHat5WWMbvID6OjlKWxsEwAE5O0NmJc08PdwBgvqLqGwh88GeQCsaNVjU38eZNXHS+SE7Ky+4pfq8aKv3nYXzwBEUI=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW3PR11MB4572
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-7.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI,
        RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,
        T_SCC_BODY_TEXT_LINE 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: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Jane Chu wrote:
> On 8/3/2022 1:53 AM, Ingo Molnar wrote:
> > 
> > * Jane Chu <jane.chu@oracle.com> wrote:
> > 
> >> With Commit 7917f9cdb503 ("acpi/nfit: rely on mce->misc to determine
> > 
> > s/Commit/commit
> 
> Maintainers,
> Would you prefer a v8, or take care the comment upon accepting the patch?
> 
> > 
> >> poison granularity") that changed nfit_handle_mce() callback to report
> >> badrange according to 1ULL << MCI_MISC_ADDR_LSB(mce->misc), it's been
> >> discovered that the mce->misc LSB field is 0x1000 bytes, hence injecting
> >> 2 back-to-back poisons and the driver ends up logging 8 badblocks,
> >> because 0x1000 bytes is 8 512-byte.
> >>
> >> Dan Williams noticed that apei_mce_report_mem_error() hardcode
> >> the LSB field to PAGE_SHIFT instead of consulting the input
> >> struct cper_sec_mem_err record.  So change to rely on hardware whenever
> >> support is available.
> >>
> >> Link: https://lore.kernel.org/r/7ed50fd8-521e-cade-77b1-738b8bfb8502@oracle.com
> >>
> >> Reviewed-by: Dan Williams <dan.j.williams@intel.com>
> >> Reviewed-by: Ingo Molnar <mingo@kernel.org>
> >> Signed-off-by: Jane Chu <jane.chu@oracle.com>
> >> ---
> >>   arch/x86/kernel/cpu/mce/apei.c | 13 ++++++++++++-
> >>   1 file changed, 12 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/arch/x86/kernel/cpu/mce/apei.c b/arch/x86/kernel/cpu/mce/apei.c
> >> index 717192915f28..8ed341714686 100644
> >> --- a/arch/x86/kernel/cpu/mce/apei.c
> >> +++ b/arch/x86/kernel/cpu/mce/apei.c
> >> @@ -29,15 +29,26 @@
> >>   void apei_mce_report_mem_error(int severity, struct cper_sec_mem_err *mem_err)
> >>   {
> >>   	struct mce m;
> >> +	int lsb;
> >>   
> >>   	if (!(mem_err->validation_bits & CPER_MEM_VALID_PA))
> >>   		return;
> >>   
> >> +	/*
> >> +	 * Even if the ->validation_bits are set for address mask,
> >> +	 * to be extra safe, check and reject an error radius '0',
> >> +	 * and fall back to the default page size.
> >> +	 */
> >> +	if (mem_err->validation_bits & CPER_MEM_VALID_PA_MASK)
> >> +		lsb = find_first_bit((void *)&mem_err->physical_addr_mask, PAGE_SHIFT);
> >> +	else
> >> +		lsb = PAGE_SHIFT;
> >> +
> >>   	mce_setup(&m);
> >>   	m.bank = -1;
> >>   	/* Fake a memory read error with unknown channel */
> >>   	m.status = MCI_STATUS_VAL | MCI_STATUS_EN | MCI_STATUS_ADDRV | MCI_STATUS_MISCV | 0x9f;
> >> -	m.misc = (MCI_MISC_ADDR_PHYS << 6) | PAGE_SHIFT;
> >> +	m.misc = (MCI_MISC_ADDR_PHYS << 6) | lsb;
> > 
> > LGTM.
> > 
> > I suppose this wants to go upstream via the tree the bug came from (NVDIMM
> > tree? ACPI tree?), or should we pick it up into the x86 tree?
> 
> No idea.  Maintainers?

There's no real NVDIMM dependency here, just a general cleanup of how
APEI error granularities are managed. So I think it is appropriate for
this to go through the x86 tree via the typical path for mce related
topics.