From: Armin Wolf W_Armin@gmx.de
[ Upstream commit 94a370fc8def6038dbc02199db9584b0b3690f1a ]
The ACPI sysfs code will fail to initialize if acpi_kobj is NULL, together with some ACPI drivers.
Follow the other firmware subsystems and bail out if the kobject cannot be registered.
Signed-off-by: Armin Wolf W_Armin@gmx.de Link: https://patch.msgid.link/20250518185111.3560-2-W_Armin@gmx.de Signed-off-by: Rafael J. Wysocki rafael.j.wysocki@intel.com Signed-off-by: Sasha Levin sashal@kernel.org ---
**YES** This commit should be backported to stable kernel trees. Here's my extensive analysis: ## Code Change Analysis The commit changes the behavior in `acpi_init()` when `kobject_create_and_add("acpi", firmware_kobj)` fails: **Before:** - If `acpi_kobj` creation fails, only prints a debug message and continues execution - The function proceeds to initialize ACPI subsystems with a NULL `acpi_kobj` - This leads to potential crashes/failures in other ACPI components **After:** - If `acpi_kobj` creation fails, prints an error message and returns `-ENOMEM` - Prevents initialization of ACPI subsystems with a NULL `acpi_kobj` - Follows proper error handling patterns ## Evidence from Kernel Code Investigation From examining the kernel repository, I found multiple critical usages of `acpi_kobj` that would fail catastrophically if it's NULL: 1. **drivers/acpi/sysfs.c:514**: `kobject_create_and_add("tables", acpi_kobj)` - NULL parent causes undefined behavior 2. **drivers/acpi/sysfs.c:924**: `sysfs_create_group(acpi_kobj, &interrupt_stats_attr_group)` - NULL kobject crashes 3. **drivers/acpi/platform_profile.c**: Multiple `sysfs_notify(acpi_kobj, ...)` calls that would crash with NULL 4. **drivers/acpi/platform_profile.c**: `sysfs_create_group(acpi_kobj, &platform_profile_group)` would fail ## Backport Criteria Assessment ✅ **Fixes a real bug**: Yes - prevents crashes when kobject creation fails ✅ **Small and contained**: Yes - only 4 lines changed in one function ✅ **Clear side effects**: Yes - prevents ACPI initialization on memory allocation failure ✅ **No architectural changes**: Yes - just proper error handling ✅ **Critical subsystem**: Yes - ACPI is core kernel infrastructure ✅ **Minimal regression risk**: Yes - only affects rare failure path ✅ **Follows stable rules**: Yes - important bugfix with minimal risk ## Comparison with Historical Examples This commit closely matches **Similar Commit #1** (Status: YES) which also: - Fixed error handling in ACPI initialization code - Added proper cleanup/error handling when kobject operations fail - Was considered suitable for backporting The commit differs significantly from the "NO" examples which were: - Code cleanup/style changes (Similar Commits #2, #3, #4) - Refactoring without fixing actual bugs (Similar Commit #4) ## Risk Assessment **Low Risk**: The change only affects the extremely rare case where `kobject_create_and_add()` fails due to memory allocation failure. In such cases: - **Current behavior**: System continues with broken ACPI, leading to crashes - **New behavior**: ACPI initialization fails cleanly, system may still boot without ACPI ## Conclusion This is a critical bug fix that prevents crashes in ACPI subsystems when memory allocation fails during boot. It transforms undefined behavior/crashes into clean failure handling, making it an ideal candidate for stable backporting.
drivers/acpi/bus.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c index 9bc5bc5bc359b..ea63b8f272892 100644 --- a/drivers/acpi/bus.c +++ b/drivers/acpi/bus.c @@ -1335,8 +1335,10 @@ static int __init acpi_init(void) }
acpi_kobj = kobject_create_and_add("acpi", firmware_kobj); - if (!acpi_kobj) - pr_debug("%s: kset create error\n", __func__); + if (!acpi_kobj) { + pr_err("Failed to register kobject\n"); + return -ENOMEM; + }
init_prmt(); result = acpi_bus_init();