All of lore.kernel.org
 help / color / mirror / Atom feed
From: bugzilla-daemon@kernel.org
To: platform-driver-x86@vger.kernel.org
Subject: [Bug 221759] New: amd_pmc: failed probe leaks LPS0 handler registration; subsequent probe hits list_add BUG in acpi_register_lps0_dev
Date: Thu, 16 Jul 2026 20:35:53 +0000	[thread overview]
Message-ID: <bug-221759-215701@https.bugzilla.kernel.org/> (raw)

https://bugzilla.kernel.org/show_bug.cgi?id=221759

            Bug ID: 221759
           Summary: amd_pmc: failed probe leaks LPS0 handler registration;
                    subsequent probe hits list_add BUG in
                    acpi_register_lps0_dev
           Product: Drivers
           Version: 2.5
          Hardware: AMD
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P3
         Component: Platform_x86
          Assignee: drivers_platform_x86@kernel-bugs.osdl.org
          Reporter: francisdb@gmail.com
        Regression: No

Found while debugging an unrelated s2idle issue on a Framework Desktop (AMD
Ryzen AI Max 300 Series, FRANMFCP06, BIOS 03.05). Kernel: vanilla 7.1.3 (plus
an unrelated amdgpu device-link test patch; drivers/platform/x86/amd/pmc is
pristine).

if amd_pmc_probe() fails after acpi_register_lps0_dev() has succeeded (e.g.
amd_stb_s2d_init() returning -ENOMEM), the error path does not call
acpi_unregister_lps0_dev(), leaving amd_pmc_s2idle_dev_ops on the lps0 handler
list. The debugfs dir from amd_pmc_dbgfs_register() leaks the same way. After
the module is unloaded and loaded again, the next acpi_register_lps0_dev()
walks the corrupted list and hits the list_add BUG below. Even without a
reload, a failed probe leaves the LPS0 ops registered while the devm-managed
driver resources have been torn down, so the next s2idle transition would call
into stale state.

In 7.1.3 drivers/platform/x86/amd/pmc/pmc.c, amd_pmc_probe():

        if (IS_ENABLED(CONFIG_SUSPEND)) {
                err = acpi_register_lps0_dev(&amd_pmc_s2idle_dev_ops);
                ...
        }

        amd_pmc_dbgfs_register(dev);
        err = amd_stb_s2d_init(dev);
        if (err)
                goto err_pci_dev_put;      <- only does pci_dev_put(rdev)

acpi_unregister_lps0_dev() is only called in the remove path.

Reproduction (as observed; any amd_stb_s2d_init failure should do):

1. modprobe amd_pmc enable_stb=1 dump_custom_stb=1 on a long-running system.
The 16 MB S2D dump ioremap failed here (WARN at arch/x86/mm/ioremap.c:216,
devm_ioremap returned NULL), so amd_stb_s2d_init returned -ENOMEM:

   WARNING: arch/x86/mm/ioremap.c:216 at __ioremap_caller+0xfc/0x3b0
   Call Trace:
    devm_ioremap+0x5a/0xb0
    amd_stb_s2d_init+0x1c5/0x260 [amd_pmc]
    amd_pmc_probe+0x2d1/0x380 [amd_pmc]
   amd_pmc AMDI000B:00: probe with driver amd_pmc failed with error -12

2. modprobe -r amd_pmc; modprobe amd_pmc

   list_add corruption. next->prev should be prev (ffffffffb31269e0), but was
0000000000000000. (next=ffffffffc06db340).
   kernel BUG at lib/list_debug.c:29!
   Oops: invalid opcode: 0000 [#1] SMP NOPTI
   CPU: 0 UID: 0 PID: 55224 Comm: modprobe Tainted: G        W          
7.1.3-usbdep4 #4
   Hardware name: Framework Desktop (AMD Ryzen AI Max 300 Series)/FRANMFCP06,
BIOS 03.05 01/21/2026
   RIP: 0010:__list_add_valid_or_report+0x78/0xb0
   Call Trace:
    acpi_register_lps0_dev+0x44/0x80
    amd_pmc_probe+0x224/0x380 [amd_pmc]
    platform_probe+0x67/0x90
    ...

Expected fix: unwind acpi_register_lps0_dev() (and the debugfs dir / quirks) on
the amd_stb_s2d_init() failure path, or move the LPS0 registration after the
last fallible step.

Addendum: on this platform the failure is not an unlucky corner case. The SMU
firmware rejects the S2D init command outright (amd_pmc AMDI000B:00: SMU cmd
failed. err: 0xff), so amd_pmc_probe() fails with -ENOMEM on EVERY boot where
enable_stb=1 is set, silently breaking s2idle support and arming the reload
BUG. Two consequences worth considering beyond the missing unwind: (1) an
unsupported/refused S2D setup should probably not be fatal to the whole PMC
probe, and (2) the error code for an SMU refusal surfacing as -ENOMEM is
misleading.

Happy to test a patch; this machine reproduces both the probe failure (every
boot with enable_stb=1) and the reload BUG on demand.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

             reply	other threads:[~2026-07-16 20:35 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-16 20:35 bugzilla-daemon [this message]
2026-07-16 21:47 ` [Bug 221759] amd_pmc: failed probe leaks LPS0 handler registration; subsequent probe hits list_add BUG in acpi_register_lps0_dev bugzilla-daemon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-221759-215701@https.bugzilla.kernel.org/ \
    --to=bugzilla-daemon@kernel.org \
    --cc=platform-driver-x86@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.