From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A23CB2522A2; Mon, 9 Jun 2025 10:18:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.176.79.56 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1749464287; cv=none; b=J7vSih2pMJO2XEG6gHeBa3Nm3C/QAF+SvCdfqzpWme5SXR7BT6Rtk9q5DfZ1Z4e0QgS3OnIq1f5R3pmwhJaS4ax976WLbCSPieT3k9LtUJRhxAkt6IN3JmRfCNCvYAUWfAUvKFeLrhU0QgyGrU6UuvG3Kk051ErdnoANWni1spM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1749464287; c=relaxed/simple; bh=f+5PnMziq+6s9kssIcPM7wytiBpCtOd4FLLaGGt+BEw=; h=Date:From:To:CC:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=KnmutVKWJkAmEGEz2o1jKPXJlPtoBtfevqLoFYZNRs+cdhL1dRtyGeO1RfociRlgoRTCzFTniICGaMdh/+x3VLBPIqvRTDd2hoikfdTWQ3tCr+zqvA9DBj0n+ehBCP/R6cRPtVB2zYbYGAHDD1BLh7u9Jbl3l3esnfE3JIrWC/Y= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; arc=none smtp.client-ip=185.176.79.56 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Received: from mail.maildlp.com (unknown [172.18.186.231]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4bG79p2Jp4z6L4sF; Mon, 9 Jun 2025 18:16:14 +0800 (CST) Received: from frapeml500008.china.huawei.com (unknown [7.182.85.71]) by mail.maildlp.com (Postfix) with ESMTPS id E613A1404C5; Mon, 9 Jun 2025 18:18:00 +0800 (CST) Received: from localhost (10.203.177.66) by frapeml500008.china.huawei.com (7.182.85.71) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.39; Mon, 9 Jun 2025 12:18:00 +0200 Date: Mon, 9 Jun 2025 11:17:58 +0100 From: Jonathan Cameron To: Dan Williams CC: , , , , , "Rafael J. Wysocki" , Sudeep Holla , Ben Cheatham Subject: Re: [PATCH 3/3] ACPI: APEI: EINJ: Do not fail einj_init() on faux_device_create() failure Message-ID: <20250609111758.0000258d@huawei.com> In-Reply-To: <20250607033228.1475625-4-dan.j.williams@intel.com> References: <20250607033228.1475625-1-dan.j.williams@intel.com> <20250607033228.1475625-4-dan.j.williams@intel.com> X-Mailer: Claws Mail 4.3.0 (GTK 3.24.42; x86_64-w64-mingw32) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-ClientProxiedBy: lhrpeml100001.china.huawei.com (7.191.160.183) To frapeml500008.china.huawei.com (7.182.85.71) On Fri, 6 Jun 2025 20:32:28 -0700 Dan Williams wrote: > CXL has a symbol dependency on einj_core.ko, so if einj_init() fails then > cxl_core.ko fails to load. Prior to the faux_device_create() conversion, > einj_probe() failures were tracked by the einj_initialized flag without > failing einj_init(). > > Revert to that behavior and always succeed einj_init() given there is no > way, and no pressing need, to discern faux device-create vs device-probe > failures. > > This situation arose because CXL knows proper kernel named objects to > trigger errors against, but acpi-einj knows how to perform the error > injection. The injection mechanism is shared with non-CXL use cases. The > result is CXL now has a module dependency on einj-core.ko, and init/probe > failures are handled at runtime. > > Fixes: 6cb9441bfe8d ("ACPI: APEI: EINJ: Transition to the faux device interface") > Cc: Greg Kroah-Hartman > Cc: "Rafael J. Wysocki" > Cc: Sudeep Holla > Cc: Ben Cheatham > Signed-off-by: Dan Williams > --- > drivers/acpi/apei/einj-core.c | 9 +++------ > 1 file changed, 3 insertions(+), 6 deletions(-) > > diff --git a/drivers/acpi/apei/einj-core.c b/drivers/acpi/apei/einj-core.c > index fea11a35eea3..9b041415a9d0 100644 > --- a/drivers/acpi/apei/einj-core.c > +++ b/drivers/acpi/apei/einj-core.c > @@ -883,19 +883,16 @@ static int __init einj_init(void) > } > > einj_dev = faux_device_create("acpi-einj", NULL, &einj_device_ops); > - if (!einj_dev) > - return -ENODEV; > > - einj_initialized = true; > + if (einj_dev) > + einj_initialized = true; > > return 0; > } > > static void __exit einj_exit(void) > { > - if (einj_initialized) > - faux_device_destroy(einj_dev); > - > + faux_device_destroy(einj_dev); Hi Dan, Thi bit is sort of fine though not really related, because faux_device_destroy() checks void faux_device_destroy(struct faux_device *faux_dev) { struct device *dev = &faux_dev->dev; if (!faux_dev) return; Though that check is after a dereference of faux_dev which doesn't look right to me. Might be fine because of how the kernel is built (I can't remember where we ended up on topic of compilers making undefined behavior based optimizations). Still not that nice from a logical point of view! > } > > module_init(einj_init);