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 21:50:35 -0700
From:   Dan Williams <dan.j.williams@intel.com>
To:     Jane Chu <jane.chu@oracle.com>, <tony.luck@intel.com>,
        <bp@alien8.de>, <tglx@linutronix.de>, <mingo@redhat.com>,
        <dave.hansen@linux.intel.com>, <x86@kernel.org>,
        <linux-edac@vger.kernel.org>, <dan.j.williams@intel.com>,
        <linux-kernel@vger.kernel.org>, <hch@lst.de>,
        <nvdimm@lists.linux.dev>
Subject: RE: [PATCH v2] x86/mce: retrieve poison range from hardware whenever
 supported
Message-ID: <62d2439bbeb43_242d29450@dwillia2-xfh.jf.intel.com.notmuch>
References: <20220716033104.903163-1-jane.chu@oracle.com>
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20220716033104.903163-1-jane.chu@oracle.com>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?UBcNLAevHUKHIK5KOk9uZy0286XN9vJaeIk755piUCGjQtEwM7Whc3H7iFZv?=
 =?us-ascii?Q?ifmZTEVerSWtoJbp/Y8h3bd2169xKcvvFKC+gYvsDKVSsrBGwY6Sq0g8bTZd?=
 =?us-ascii?Q?aEtasYDbYs/e6/EdEZmscbve65oWDyyPjX0gB1kSn+vVAlpMksWw6b7KoUGL?=
 =?us-ascii?Q?9sKDLZWroRn51a5kv7DN2O+/OBgFJWbtDFm9ejaQf78rUMKD9xJglnpDMGUd?=
 =?us-ascii?Q?w34YEW5D8kfOZ2ELBByEmRoX+jBVGjZNxabYzKTXxl3hNSfNn9DzTXGVOv8m?=
 =?us-ascii?Q?nWh0sNMHJqj/qCEzUun1zr7BHGYs55y1pOpxJeGukfS9xdsz96U5Ql5rxq+Y?=
 =?us-ascii?Q?2kW1UquZ3szOlxF79NYl+eOpiiudEhgcFqvMHwXmhjVSmMVkgp8eRmNFhYrh?=
 =?us-ascii?Q?bmYVmnt2Ds/v4o63g/a8r90L3Mb1xz2tIgubQj9zzMU4Q7ILZ4ElzAUfDG/6?=
 =?us-ascii?Q?59Z2UZdfNuA1hrZ2g1vi/Kwpc1QVhcdKmTN6gOLYtqg8PatobnutJGIx9Svb?=
 =?us-ascii?Q?0sIYUGMy4yjhwagVq64eJeRNYlNl63VJ8F3mnbfhWeSq4GtfRabuu7n8UgWw?=
 =?us-ascii?Q?8uOPBqprLeDepBDvbRwszY8ZZNQuVvmIPHpF4FAR4p1wCQm4WNPsbaexl2Bo?=
 =?us-ascii?Q?uWrOj6UyPv6Wc8nKKUVcQMFsaYY+kwLvyN6mcEkcTWxmq5VLgdBrqz/2PHvC?=
 =?us-ascii?Q?WURV7p1LxSSmyOoF5BiYZp/tKjn5YxstCOjuRzQFpBoEwQhirhbtZVOC2J2h?=
 =?us-ascii?Q?4q4OipYC22k8zzXHhG8oDL4Aht56pcDZI/U6vrO7QyY+EOhtsre2IM9jqUuO?=
 =?us-ascii?Q?FialwXi71Lm4xZ1JGN5RfuJqTmZydo6RdKnV0vgLyLwUrKKjt2jm1/xY5VuK?=
 =?us-ascii?Q?E0fO2LFuWNO/m8lraO1tOK0qWY5rVwxpuWwaoLG1iD67xoRpHwI3s+gDFCwM?=
 =?us-ascii?Q?KNb1QkJAZWOrYelsFRxxCmWd9GwbqZWDnJSZ9SXHCzITK2e6wHB9PWDV8Fhu?=
 =?us-ascii?Q?pGVmH2GpFLIjZo22Ufz6Yq0HiHH+No33yy0oIHQG7z7pmN5YtLr1G7nawgVu?=
 =?us-ascii?Q?D+POmvWnEG7T8j5pyGy5PeoxmrWYCtqjtzpFDsnj4Ssy96HNoY4SKHsiaFni?=
 =?us-ascii?Q?frRtIunViREDGtdZORXiZ9cCJaV+e7Q2AQRlsQnjK+5BhdA4xD+QrtBobyDJ?=
 =?us-ascii?Q?EdsCd5obVMiKZ+6A9fsCbKSlaEwg5SXxL8Tgc44P87e2ux0/gx6dQu9e/SKk?=
 =?us-ascii?Q?w/oJqQamo+85TxQL1Bf8MvQeOn4lCIrXp8xwhfwXu769WL9Uk5a5jO9eGxu5?=
 =?us-ascii?Q?QKMQlmMvZC4V7WguvQSE3n9sFdgxEvpdnlURWLybYFEJL6oEfL+j3Bu3eDd1?=
 =?us-ascii?Q?O8mznHUkyvtZ4YS8AfwszKGjABWhTIWTerHT91SMHoki9uNVaPqSrZpsHJ4M?=
 =?us-ascii?Q?k7HywwuOC4AbrbAyV+HwsJF6v3tT0Jt9/8HcXN/XP0tJ/qbj9I0b23tQZWWs?=
 =?us-ascii?Q?31M7yArE/MrJQVgW8QTB4DdMhrSBTe+Iz/BRzf/cJ80TwnEuEV72V2CnRSB2?=
 =?us-ascii?Q?eJkkF8j6+SJarJzerpFSHQIqJUrgQ0a3cw3mAM8g9HR5FF8RkSwQSpBo0JLi?=
 =?us-ascii?Q?5A=3D=3D?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 0275d0ed-3191-443f-6559-08da66e6ba52
X-MS-Exchange-CrossTenant-AuthSource: MWHPR1101MB2126.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Jul 2022 04:50:38.2538
 (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: evesOq5qEcodqAH6QV18j9QJ/poVoBO9leredx38dD+4hJlnc2qrMNpTnqrVXDzD49VyG7UFrIDNaLYoef2PAF28qJ8IHG+McMpRAe7lgpk=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA0PR11MB4621
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,
        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

Jane Chu wrote:
> With Commit 7917f9cdb503 ("acpi/nfit: rely on mce->misc to determine
> 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.
> 
> v1: https://lkml.org/lkml/2022/7/15/1040

This should be "Link:" and it should reference lore.kernel.org by
msg-id. Lore is maintained by LF infrastructure and the message-id can
be used to search lore.kernel.org mirrors even if the LF infra is down.

Link: https://lore.kernel.org/r/7ed50fd8-521e-cade-77b1-738b8bfb8502@oracle.com

> Signed-off-by: Jane Chu <jane.chu@oracle.com>
> ---
>  arch/x86/kernel/cpu/mce/apei.c | 6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/x86/kernel/cpu/mce/apei.c b/arch/x86/kernel/cpu/mce/apei.c
> index 717192915f28..a4d5893632e0 100644
> --- a/arch/x86/kernel/cpu/mce/apei.c
> +++ b/arch/x86/kernel/cpu/mce/apei.c
> @@ -29,6 +29,7 @@
>  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;
> @@ -37,7 +38,10 @@ void apei_mce_report_mem_error(int severity, struct cper_sec_mem_err *mem_err)
>  	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;
> +	lsb = __builtin_ffs(mem_err->physical_addr_mask) - 1;

Just use the kernel's __ffs64() which does not require the substraction
fixup, and you can assume that physical_address_mask is non-zero just
like trace_extlog_mem_event() does.

> +	if (lsb <= 0)
> +		lsb = PAGE_SHIFT;

This fixup can then be removed as well.

After the above comments are addressed you can add:

Reviewed-by: Dan Williams <dan.j.williams@intel.com>