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:   Fri, 15 Jul 2022 12:17:40 -0700
From:   Dan Williams <dan.j.williams@intel.com>
To:     Jane Chu <jane.chu@oracle.com>,
        Dan Williams <dan.j.williams@intel.com>,
        "hch@infradead.org" <hch@infradead.org>,
        "vishal.l.verma@intel.com" <vishal.l.verma@intel.com>,
        "dave.jiang@intel.com" <dave.jiang@intel.com>,
        "ira.weiny@intel.com" <ira.weiny@intel.com>,
        "nvdimm@lists.linux.dev" <nvdimm@lists.linux.dev>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] acpi/nfit: badrange report spill over to clean range
Message-ID: <62d1bd546fce2_242d29499@dwillia2-xfh.jf.intel.com.notmuch>
References: <20220711232658.536064-1-jane.chu@oracle.com>
 <62ce16518e7d3_6070c29447@dwillia2-xfh.jf.intel.com.notmuch>
 <09df842d-d8e4-0594-56b0-b4bb9ea37b67@oracle.com>
 <62cf622a32e1_16b52e294ea@dwillia2-xfh.jf.intel.com.notmuch>
 <8b13446a-65ac-0cbd-6c17-0f9e1cfbb048@oracle.com>
 <62d0c0947c3e6_1643dc2944a@dwillia2-xfh.jf.intel.com.notmuch>
 <82641e64-1003-d11a-df9c-73f3b61d6b8a@oracle.com>
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <82641e64-1003-d11a-df9c-73f3b61d6b8a@oracle.com>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?9PuY4Wh3i3Dmu4gnDYMe58t7UxbJezK1zbo49FNAMLs64UI2xt2/m3RkdpKG?=
 =?us-ascii?Q?GuIes2ZqRWrKk/udXLmo4ciTa5wccDeYNyGuYF9ApK0lbPZZSxvdIlyD3kIv?=
 =?us-ascii?Q?EZ51L61torJBJz98V9S38biHVhXl8J13s3U+xWKtGVqrVi/IMM0GD9ws4KFF?=
 =?us-ascii?Q?pROiFmfOvvxNtUUYES32DIQt5VGz/dI4064WRnV5nkXOwlGbCLMokK/qauX4?=
 =?us-ascii?Q?a9giCOhTzYY+E42QhegYMbHJDCCKN3c4zh20WXSuDJUnme2RU3GRObbaXGid?=
 =?us-ascii?Q?6vpcVeRmP6ffSSfI6zhZI9gbpFDyzlVwD5hbP9mcHxKBftWmE5g2el0tL3QS?=
 =?us-ascii?Q?05a4Q+A4dNl+VOE/5gNDbTU5ftjk0h0+uA0MKrsP2VheDq1wD7+slP13D/tw?=
 =?us-ascii?Q?ZT2s5CxQfpQc/EVSKfukTT1pnOWtYzwCfaco2iS5pnC4KfXS9NUjIl9aPBxF?=
 =?us-ascii?Q?oi7J/AR4FFouStx4r2X8neDOOz+SdgFCusY9rcOpJPOcpKrOkje1dbh8FyCT?=
 =?us-ascii?Q?tTevk4TR0KZ1x5znyywgYRv/zr0zgWsHGEHvauoZOurrDuM8HdFlM8TNFiID?=
 =?us-ascii?Q?2woCitqnTJLzBzM9kI98HBM82FoyL2qrXZwDMgwpF8Lo+ZnVvd/GZkAzdic1?=
 =?us-ascii?Q?E6tix3ot7uTITz262fWgFlpUwBD07Cq/UPk6V0D73GOyPEWmqZ12+kvat1Xz?=
 =?us-ascii?Q?YAhay6OdARCrvA66BzYsS5Xc/6CVdTYYYtWPtGRR5JpwvCa1MR3Eo70LyYGM?=
 =?us-ascii?Q?eIiHFFp/p/yyObloJuSS4vspvFR8kuEOBMYfmQhjLmRHg1GJvjTgdhZBO10l?=
 =?us-ascii?Q?tPXtpuQjs/YNcQYboIZSqZxo12Y/hcynf2cce7IXP2CAQy9nCOEnqp3d3+4E?=
 =?us-ascii?Q?PXIk7Nn5O6PaKnaIM3yFOOPoO0OFxXCBVTN3RR/CpQev24PsbD6ZyalBiMCb?=
 =?us-ascii?Q?KAAMT0WftbQZFSej3KA0ARKrTX1ACQl4twPlQh+lXQb6/Hp4eixMailgO2M9?=
 =?us-ascii?Q?2ecdBz/sDe2g/owqHOnAq/rJzzE8DKR1G0e9AIouiOcJwUJ30CuHNbY6jpnQ?=
 =?us-ascii?Q?35HWk8AmOtEZTfclwDtjVAN2MRnz6GJxPmSEQ1O1xRfCiGGliX/jwOIL7HIt?=
 =?us-ascii?Q?DFTChJQLkHxMzRL+vD7HtLwjpR1ZVGsm/yXtfmlkb5yqNRdaychNsobNKVwz?=
 =?us-ascii?Q?dAKN+9iXN+HL+lGzwUVOqmoeirwiWBdf+h+soOQ/M9oRkt2oqxVfhsDIayTk?=
 =?us-ascii?Q?jc8oaZw4fdQAOAACzsWpfzb/7CB7GP59tHVREYyg5jeEMvdmUaTiV8pt0NIU?=
 =?us-ascii?Q?NTFYtyo6rMBsF0paE8uZbIrHbOh8sn0WClUU+dVMz9Aie7gvIoa4qqGacqiB?=
 =?us-ascii?Q?Uc2alLTFjx3GZxD3EXcoGom6+VJdGi1tpXNBF/aNqc65ggkEjLHMLOeJB33d?=
 =?us-ascii?Q?5ic+7bDqYqVXAzw3qHWzEigdmZWtcnlXewuTFRxoasa3r6bicXjGxCFXW8BJ?=
 =?us-ascii?Q?HvOG3TGoHDQNtncZV3LCauqgYDoinSDDGF9nnh2BHobf0HsK0btBRLSx9+Z0?=
 =?us-ascii?Q?zGqFqEydvoNsVBU6a8/3h1/I2bhmoPg71qZ6t+O7Eid3lZQTrYY1Csw2Azfh?=
 =?us-ascii?Q?3A=3D=3D?=
X-MS-Exchange-CrossTenant-Network-Message-Id: a63f5760-2b6b-4747-1575-08da6696b122
X-MS-Exchange-CrossTenant-AuthSource: MWHPR1101MB2126.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Jul 2022 19:17:43.1306
 (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: 80H5j9NTOOznG/NYbZlpRgFYXq6VPIUKpyJO7qzHFOLj3j6GWqWPmiUUZ6EX1Xe9DGp003YODKkczQrawyyR4eXHK1d0wiTqI2HAMYSNoXI=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3559
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-5.0 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,
        RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE
        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

[ add Tony ]

Jane Chu wrote:
> On 7/14/2022 6:19 PM, Dan Williams wrote:
> > Jane Chu wrote:
> >> I meant to say there would be 8 calls to the nfit_handle_mce() callback,
> >> one call for each poison with accurate address.
> >>
> >> Also, short ARS would find 2 poisons.
> >>
> >> I attached the console output, my annotation is prefixed with "<==".
> > 
> > [29078.634817] {4}[Hardware Error]:   physical_address: 0x00000040a0602600		<== 2nd poison @ 0x600
> > [29078.642200] {4}[Hardware Error]:   physical_address_mask: 0xffffffffffffff00
> > 
> > Why is nfit_handle_mce() seeing a 4K address mask when the CPER record
> > is seeing a 256-byte address mask?
> 
> Good question!  One would think both GHES reporting and 
> nfit_handle_mce() are consuming the same mce record...
> Who might know?

Did some grepping...

Have a look at: apei_mce_report_mem_error()

"The call is coming from inside the house!"

Luckily we do not need to contact a BIOS engineer to get this fixed.

> > Sigh, is this "firmware-first" causing the kernel to get bad information
> > via the native mechanisms >
> > I would expect that if this test was truly worried about minimizing BIOS
> > latency it would disable firmware-first error reporting. I wonder if
> > that fixes the observed problem?
> 
> Could you elaborate on firmware-first error please?  What are the 
> possible consequences disabling it? and how to disable it?

With my Linux kernel developer hat on, firmware-first error handling is
really only useful for supporting legacy operating systems that do not
have native machine check handling, or for platforms that have bugs that
would otherwise cause OS native error handling to fail. Otherwise, for
modern Linux, firmware-first error handling is pure overhead and a
source of bugs.

In this case the bug is in the Linux code that translates the ACPI event
back into an MCE record.