lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4532273.UPlyArG6xL@fdefranc-mobl3>
Date: Tue, 04 Nov 2025 17:53:18 +0100
From: "Fabio M. De Francesco" <fabio.m.de.francesco@...ux.intel.com>
To: Jonathan Cameron <jonathan.cameron@...wei.com>
Cc: linux-cxl@...r.kernel.org, "Rafael J . Wysocki" <rafael@...nel.org>,
 Len Brown <lenb@...nel.org>, Tony Luck <tony.luck@...el.com>,
 Borislav Petkov <bp@...en8.de>, Hanjun Guo <guohanjun@...wei.com>,
 Mauro Carvalho Chehab <mchehab@...nel.org>,
 Shuai Xue <xueshuai@...ux.alibaba.com>, Davidlohr Bueso <dave@...olabs.net>,
 Dave Jiang <dave.jiang@...el.com>,
 Alison Schofield <alison.schofield@...el.com>,
 Vishal Verma <vishal.l.verma@...el.com>, Ira Weiny <ira.weiny@...el.com>,
 Dan Williams <dan.j.williams@...el.com>,
 Mahesh J Salgaonkar <mahesh@...ux.ibm.com>,
 Oliver O'Halloran <oohall@...il.com>, Bjorn Helgaas <bhelgaas@...gle.com>,
 Sunil V L <sunilvl@...tanamicro.com>, Xiaofei Tan <tanxiaofei@...wei.com>,
 Mario Limonciello <mario.limonciello@....com>,
 Huacai Chen <chenhuacai@...nel.org>,
 Heinrich Schuchardt <heinrich.schuchardt@...onical.com>,
 Arnd Bergmann <arnd@...db.de>, Peter Zijlstra <peterz@...radead.org>,
 Ingo Molnar <mingo@...nel.org>, Guo Weikang <guoweikang.kernel@...il.com>,
 Xin Li <xin@...or.com>, Will Deacon <will@...nel.org>,
 Huang Yiwei <quic_hyiwei@...cinc.com>, Gavin Shan <gshan@...hat.com>,
 Smita Koralahalli <Smita.KoralahalliChannabasappa@....com>,
 Uwe Kleine-König <u.kleine-koenig@...libre.com>,
 Li Ming <ming.li@...omail.com>,
 Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>,
 Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@...ux.intel.com>,
 Karolina Stolarek <karolina.stolarek@...cle.com>,
 Jon Pan-Doh <pandoh@...gle.com>, Lukas Wunner <lukas@...ner.de>,
 Shiju Jose <shiju.jose@...wei.com>, linux-kernel@...r.kernel.org,
 linux-acpi@...r.kernel.org, linuxppc-dev@...ts.ozlabs.org,
 linux-pci@...r.kernel.org
Subject:
 Re: [PATCH 6/6 v6] ACPI: extlog: Trace CPER CXL Protocol Error Section

On Tuesday, October 28, 2025 4:06:09 PM Central European Standard Time Jonathan Cameron wrote:
> On Thu, 23 Oct 2025 14:25:41 +0200
> "Fabio M. De Francesco" <fabio.m.de.francesco@...ux.intel.com> wrote:
> 
> > When Firmware First is enabled, BIOS handles errors first and then it makes
> > them available to the kernel via the Common Platform Error Record (CPER)
> > sections (UEFI 2.10 Appendix N). Linux parses the CPER sections via one of
> > two similar paths, either ELOG or GHES. The errors managed by ELOG are
> > signaled to the BIOS by the I/O Machine Check Architecture (I/O MCA).
> > 
> > Currently, ELOG and GHES show some inconsistencies in how they report to
> > userspace via trace events.
> > 
> > Therefore, make the two mentioned paths act similarly by tracing the CPER
> > CXL Protocol Error Section (UEFI v2.10, Appendix N.2.13).
> > 
> > Cc: Dan Williams <dan.j.williams@...el.com>
> > Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@...ux.intel.com>
> > Signed-off-by: Fabio M. De Francesco <fabio.m.de.francesco@...ux.intel.com>
> 
> Just one small question.   With that addressed, 
> Reviewed-by: Jonathan Cameron <jonathan.cameron@...wei.com>
> 
> > diff --git a/drivers/cxl/core/ras.c b/drivers/cxl/core/ras.c
> > index 2731ba3a0799..3f527b0c6509 100644
> > --- a/drivers/cxl/core/ras.c
> > +++ b/drivers/cxl/core/ras.c
> > @@ -105,6 +105,12 @@ static void cxl_cper_handle_prot_err(struct cxl_cper_prot_err_work_data *data)
> >  		cxl_cper_trace_uncorr_prot_err(cxlmd, data->ras_cap);
> >  }
> >  
> > +void cxl_cper_ras_handle_prot_err(struct cxl_cper_prot_err_work_data *wd)
> 
> Why do we need this wrapper?  The name is a bit more general, so if you
> do need it, then why not instead just rename cxl_cper_handle_prot_err()
> 
Actually, on a second thought I believe that we don't need either this
wrapper or renaming cxl_cper_handle_prot_err(). I'll export the latter
as it is.

Fabio
> > +{
> > +	cxl_cper_handle_prot_err(wd);
> > +}
> > +EXPORT_SYMBOL_GPL(cxl_cper_ras_handle_prot_err);
> > +
> >  static void cxl_cper_prot_err_work_fn(struct work_struct *work)
> >  {
> >  	struct cxl_cper_prot_err_work_data wd;
> > diff --git a/include/cxl/event.h b/include/cxl/event.h
> > index 94081aec597a..a37eef112411 100644
> > --- a/include/cxl/event.h
> > +++ b/include/cxl/event.h
> > @@ -340,4 +340,6 @@ cxl_cper_setup_prot_err_work_data(struct cxl_cper_prot_err_work_data *wd,
> >  }
> >  #endif
> >  
> > +void cxl_cper_ras_handle_prot_err(struct cxl_cper_prot_err_work_data *wd);
> > +
> >  #endif /* _LINUX_CXL_EVENT_H */
> 
> 





Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ