linux-kernel - Re: [PATCH 3/3] ACPI: APEI: EINJ: Do not fail einj_init() on faux_device

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]

Message-ID: <684869cc8777b_249110016@dwillia2-xfh.jf.intel.com.notmuch>
Date: Tue, 10 Jun 2025 10:22:20 -0700
From: Dan Williams <dan.j.williams@...el.com>
To: Jonathan Cameron <Jonathan.Cameron@...wei.com>, Greg KH
	<gregkh@...uxfoundation.org>
CC: Dan Williams <dan.j.williams@...el.com>, <rafael.j.wysocki@...el.com>,
	<linux-cxl@...r.kernel.org>, <linux-acpi@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>, "Rafael J. Wysocki" <rafael@...nel.org>,
	Sudeep Holla <sudeep.holla@....com>, Ben Cheatham <Benjamin.Cheatham@....com>
Subject: Re: [PATCH 3/3] ACPI: APEI: EINJ: Do not fail einj_init() on
 faux_device_create() failure

Jonathan Cameron wrote:
[..]
> Hmm. I did some digging. Seems that was debated 10 years ago without
> a huge amount of clarity on the answer beyond all sane people telling
> compiler folk not to use this in optimizations :)
> 
> Comes down to whether any dereference of NULL is UB whether or not
> the compiler can just do a simple offset calculation.
> 
> Anyhow, whilst fine, it's still a little ugly to my eyes :(

I recall we had this conversation with Dan Carpenter on a smatch patch
and resolved that while it looks "interesting" it does no harm.

For this patch I am not motivated to spin it because even if the the
compiler took advantage of the NULL check to drop UB work, that would
only mean dropping the assignment.

Otherwise, this conversion lines up with the intent of both
einj_initialized and faux_device_destroy() whereby faux_device_destroy()
is already prepared for the case where faux_device_create() fails.