linux-kernel - Re: [PATCH v11 1/3] ACPI: APEI: send SIGBUS to current task if synchronous memory error not recovered

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Sat, 24 Feb 2024 11:42:13 -0800
From: Dan Williams <dan.j.williams@...el.com>
To: Jonathan Cameron <Jonathan.Cameron@...wei.com>, Dan Williams
	<dan.j.williams@...el.com>
CC: Shuai Xue <xueshuai@...ux.alibaba.com>, Borislav Petkov <bp@...en8.de>,
	Ira Weiny <ira.weiny@...el.com>, "Luck, Tony" <tony.luck@...el.com>,
	"james.morse@....com" <james.morse@....com>, <rafael@...nel.org>,
	<wangkefeng.wang@...wei.com>, <tanxiaofei@...wei.com>,
	<mawupeng1@...wei.com>, <linmiaohe@...wei.com>, <naoya.horiguchi@....com>,
	<gregkh@...uxfoundation.org>, <will@...nel.org>, <jarkko@...nel.org>,
	<linux-acpi@...r.kernel.org>, <linux-mm@...ck.org>,
	<linux-kernel@...r.kernel.org>, <akpm@...ux-foundation.org>,
	<linux-edac@...r.kernel.org>, <x86@...nel.org>, <justin.he@....com>,
	<ardb@...nel.org>, <ying.huang@...el.com>, <ashish.kalra@....com>,
	<baolin.wang@...ux.alibaba.com>, <tglx@...utronix.de>, <mingo@...hat.com>,
	<dave.hansen@...ux.intel.com>, <lenb@...nel.org>, <hpa@...or.com>,
	<robert.moore@...el.com>, <lvying6@...wei.com>, <xiexiuqi@...wei.com>,
	<zhuo.song@...ux.alibaba.com>
Subject: Re: [PATCH v11 1/3] ACPI: APEI: send SIGBUS to current task if
 synchronous memory error not recovered

Jonathan Cameron wrote:
[..]
> > > None of the CXL component errors should be handled as synchronous
> > > events. They are either asynchronous protocol errors, or effectively
> > > equivalent to CPER_SEC_PLATFORM_MEM notifications.  
> > 
> > Not a good example, CPER_SEC_PLATFORM_MEM is sometimes signaled via SEA.
> > 
> 
> Premature send.:(
> 
> One example I can point at is how we do signaling of memory
> errors detected by the host into a VM on arm64.
> https://elixir.bootlin.com/qemu/latest/source/hw/acpi/ghes.c#L391
> CPER_SEC_PLATFORM_MEM via ARM Synchronous External Abort (SEA).
> 
> Right now we've only used async in QEMU for proposed CXL error
> CPER records signalling but your reference to them being similar
> to CPER_SEC_PLATFORM_MEM is valid so 'maybe' they will be
> synchronous in some physical systems as it's one viable way to
> provide rich information for synchronous reception of poison.
> For the VM case my assumption today is we don't care about providing the
> VM with rich data, so CPER_SEC_PLATFORM_MEM is fine as a path for
> errors whether from CXL CPER records or not.

Makes sense... and I was not precise when I mentioned the equivalency, I
was only considering x86.