[linux-nvidia-6.17-next] Set LED_HW_PLUGGABLE for NPEM and fix class init ordering issue of CXL/fwctl by nvax-r · Pull Request #355 · NVIDIA/NV-Kernels

nvax-r · 2026-04-13T03:14:09Z

Description

This backport adds fixes for issue encountered when doing CXL device hotplug.

Set LED_HW_PLUGGABLE for NPEM - Add the flag LED_HW_PLUGGABLE since NPEM LEDs are on
hot-pluggable hardware by nature.
Fix class init ordering on CXL device removal - Use subsys_initcall() to correct the initialization ordering of CXL and fwctl subsystem.

Source

Patch Breakdown (2 patches):

#	Category	Count	Source
1	Richard Cheng's PCI/NPEM: Set LED_HW_PLUGGABLE for hotplug-capable ports	1	LKML (v1, merged and applied to v7.1
2	Richard Cheng's fwctl: Fix class init ordering to avoid NULL pointer dereference on device removal	1	LKML (v1, merged and applied to v7.1 )

Lore Links:

Richard Cheng's PCI/NPEM: Set LED_HW_PLUGGABLE for hotplug-capable ports (v1, applied to v7.1): https://lore.kernel.org/all/20260402093850.23075-1-icheng@nvidia.com/
Richard Cheng's fwctl: Fix class init ordering to avoid NULL pointer dereference on device removal (v1, applied to v7.1): https://lore.kernel.org/all/20260409051902.40218-1-icheng@nvidia.com/

Upstream Status

Series	Status
Richard NPEM v1	Applied to v7.1 and merged
Richard fwctl v1	Applied to v7.1 and merged

Testing

Build Validation:

Built successfully for ARM 64 4k page size kernel
Built successfully for ARM 64 64k page size kernel

Config Verification:

CXL-related configs enabled as expected:

CONFIG_ACPI_APEI_EINJ_CXL=y
CONFIG_PCI_CXL=y
CONFIG_CXL_BUS=y
CONFIG_CXL_PCI=y
CONFIG_CXL_MEM_RAW_COMMANDS=y
CONFIG_CXL_ACPI=m
CONFIG_CXL_PMEM=m
CONFIG_CXL_MEM=y
CONFIG_CXL_FEATURES=y
# CONFIG_CXL_EDAC_MEM_FEATURES is not set
CONFIG_CXL_PORT=y
CONFIG_CXL_SUSPEND=y
CONFIG_CXL_REGION=y
# CONFIG_CXL_REGION_INVALIDATION_TEST is not set
CONFIG_CXL_RAS=y
# CONFIG_CACHEMAINT_FOR_HOTPLUG is not set
# CONFIG_SFC_CXL is not set
CONFIG_CXL_PMU=m
CONFIG_DEV_DAX=y
CONFIG_DEV_DAX_PMEM=m
CONFIG_DEV_DAX_HMEM=m
CONFIG_DEV_DAX_CXL=y
CONFIG_DEV_DAX_HMEM_DEVICES=y
CONFIG_DEV_DAX_KMEM=y
CONFIG_ARCH_HAS_CPU_CACHE_INVALIDATE_MEMREGION=y
CONFIG_GENERIC_CPU_CACHE_MAINTENANCE=y

fwctl config needs to be enabled ,too

CONFIG_FWCTL=y

Runtime Testing:

Boot test on ARM64 system
CXL device enumeration test (ls /sys/bus/cxl/devices/)
CXL interleaving testing
CXL reset test (echo 1 > /sys/bus/pci/devices//cxl_reset)
CXL hotplug test

Notes

If you need a full CXL type 2-capable kernel, Jiandi's backport should be added as well.
Since these 2 patches are bug fixes and independent of them, we can backport them seperately.

LP: https://bugs.launchpad.net/ubuntu/+source/linux-nvidia-6.17/+bug/2149918

nvmochs · 2026-04-13T15:32:19Z

@nvax-r Since these are both expected in v7.1 and that merge window just opened, let's wait until these are merged into Linus' tree (sometime in the next 13 days) so we can just pick from there instead of carrying these are SAUCE patches.

nvax-r · 2026-04-14T01:38:11Z

@nvmochs -
Sure, I'll keep track of them then.

[ Upstream commit 77603ab ] Shin'ichiro reported sporadic hangs when running generic/013 in our CI system. When enabling lockdep, there is a lockdep splat when calling btrfs_get_dev_zone_info_all_devices() in the mount path that can be triggered by i.e. generic/013: ====================================================== WARNING: possible circular locking dependency detected 7.0.0-rc1+ #355 Not tainted ------------------------------------------------------ mount/1043 is trying to acquire lock: ffff8881020b5470 (&vblk->vdev_mutex){+.+.}-{4:4}, at: virtblk_report_zones+0xda/0x430 but task is already holding lock: ffff888102a738e0 (&fs_devs->device_list_mutex){+.+.}-{4:4}, at: btrfs_get_dev_zone_info_all_devices+0x45/0x90 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #4 (&fs_devs->device_list_mutex){+.+.}-{4:4}: __mutex_lock+0xa3/0x1360 btrfs_create_pending_block_groups+0x1f4/0x9d0 __btrfs_end_transaction+0x3e/0x2e0 btrfs_zoned_reserve_data_reloc_bg+0x2f8/0x390 open_ctree+0x1934/0x23db btrfs_get_tree.cold+0x105/0x26c vfs_get_tree+0x28/0xb0 __do_sys_fsconfig+0x324/0x680 do_syscall_64+0x92/0x4f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #3 (btrfs_trans_num_extwriters){++++}-{0:0}: join_transaction+0xc2/0x5c0 start_transaction+0x17c/0xbc0 btrfs_zoned_reserve_data_reloc_bg+0x2b4/0x390 open_ctree+0x1934/0x23db btrfs_get_tree.cold+0x105/0x26c vfs_get_tree+0x28/0xb0 __do_sys_fsconfig+0x324/0x680 do_syscall_64+0x92/0x4f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #2 (btrfs_trans_num_writers){++++}-{0:0}: lock_release+0x163/0x4b0 __btrfs_end_transaction+0x1c7/0x2e0 btrfs_dirty_inode+0x6f/0xd0 touch_atime+0xe5/0x2c0 btrfs_file_mmap_prepare+0x65/0x90 __mmap_region+0x4b9/0xf00 mmap_region+0xf7/0x120 do_mmap+0x43d/0x610 vm_mmap_pgoff+0xd6/0x190 ksys_mmap_pgoff+0x7e/0xc0 do_syscall_64+0x92/0x4f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #1 (&mm->mmap_lock){++++}-{4:4}: __might_fault+0x68/0xa0 _copy_to_user+0x22/0x70 blkdev_copy_zone_to_user+0x22/0x40 virtblk_report_zones+0x282/0x430 blkdev_report_zones_ioctl+0xfd/0x130 blkdev_ioctl+0x20f/0x2c0 __x64_sys_ioctl+0x86/0xd0 do_syscall_64+0x92/0x4f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #0 (&vblk->vdev_mutex){+.+.}-{4:4}: __lock_acquire+0x1522/0x2680 lock_acquire+0xd5/0x2f0 __mutex_lock+0xa3/0x1360 virtblk_report_zones+0xda/0x430 blkdev_report_zones_cached+0x162/0x190 btrfs_get_dev_zones+0xdc/0x2e0 btrfs_get_dev_zone_info+0x219/0xe80 btrfs_get_dev_zone_info_all_devices+0x62/0x90 open_ctree+0x1200/0x23db btrfs_get_tree.cold+0x105/0x26c vfs_get_tree+0x28/0xb0 __do_sys_fsconfig+0x324/0x680 do_syscall_64+0x92/0x4f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e other info that might help us debug this: Chain exists of: &vblk->vdev_mutex --> btrfs_trans_num_extwriters --> &fs_devs->device_list_mutex Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&fs_devs->device_list_mutex); lock(btrfs_trans_num_extwriters); lock(&fs_devs->device_list_mutex); lock(&vblk->vdev_mutex); *** DEADLOCK *** 3 locks held by mount/1043: #0: ffff88811063e878 (&fc->uapi_mutex){+.+.}-{4:4}, at: __do_sys_fsconfig+0x2ae/0x680 #1: ffff88810cb9f0e8 (&type->s_umount_key#31/1){+.+.}-{4:4}, at: alloc_super+0xc0/0x3e0 #2: ffff888102a738e0 (&fs_devs->device_list_mutex){+.+.}-{4:4}, at: btrfs_get_dev_zone_info_all_devices+0x45/0x90 stack backtrace: CPU: 2 UID: 0 PID: 1043 Comm: mount Not tainted 7.0.0-rc1+ #355 PREEMPT(full) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-9.fc43 06/10/2025 Call Trace: <TASK> dump_stack_lvl+0x5b/0x80 print_circular_bug.cold+0x18d/0x1d8 check_noncircular+0x10d/0x130 __lock_acquire+0x1522/0x2680 ? vmap_small_pages_range_noflush+0x3ef/0x820 lock_acquire+0xd5/0x2f0 ? virtblk_report_zones+0xda/0x430 ? lock_is_held_type+0xcd/0x130 __mutex_lock+0xa3/0x1360 ? virtblk_report_zones+0xda/0x430 ? virtblk_report_zones+0xda/0x430 ? __pfx_copy_zone_info_cb+0x10/0x10 ? virtblk_report_zones+0xda/0x430 virtblk_report_zones+0xda/0x430 ? __pfx_copy_zone_info_cb+0x10/0x10 blkdev_report_zones_cached+0x162/0x190 ? __pfx_copy_zone_info_cb+0x10/0x10 btrfs_get_dev_zones+0xdc/0x2e0 btrfs_get_dev_zone_info+0x219/0xe80 btrfs_get_dev_zone_info_all_devices+0x62/0x90 open_ctree+0x1200/0x23db btrfs_get_tree.cold+0x105/0x26c ? rcu_is_watching+0x18/0x50 vfs_get_tree+0x28/0xb0 __do_sys_fsconfig+0x324/0x680 do_syscall_64+0x92/0x4f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f615e27a40e RSP: 002b:00007fff11b18fb8 EFLAGS: 00000246 ORIG_RAX: 00000000000001af RAX: ffffffffffffffda RBX: 000055572e92ab10 RCX: 00007f615e27a40e RDX: 0000000000000000 RSI: 0000000000000006 RDI: 0000000000000003 RBP: 00007fff11b19100 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 000055572e92bc40 R14: 00007f615e3faa60 R15: 000055572e92bd08 </TASK> Don't hold the device_list_mutex while calling into btrfs_get_dev_zone_info() in btrfs_get_dev_zone_info_all_devices() to mitigate the issue. This is safe, as no other thread can touch the device list at the moment of execution. Reported-by: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com> Reviewed-by: Damien Le Moal <dlemoal@kernel.org> Signed-off-by: Johannes Thumshirn <johannes.thumshirn@wdc.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com> Signed-off-by: Sasha Levin <sashal@kernel.org>

nvmochs · 2026-04-21T01:08:20Z

@nvax-r I believe these are both merged now, so you can refresh this PR. We will also need these backported to 26.04_linux-nvidia-bos.

github-actions · 2026-04-21T02:30:06Z

✅ Patchscan: No Missing Fixes

All cherry-picked commits have been checked — no missing upstream fixes found.

nvax-r · 2026-04-21T02:58:25Z

@nvax-r I believe these are both merged now, so you can refresh this PR. We will also need these backported to 26.04_linux-nvidia-bos.

No problem, I've picked them up from upstream kernel.
I'll handle for 26.04 nvidia kernel later.

nvmochs · 2026-04-21T14:26:50Z

@nvax-r I believe these are both merged now, so you can refresh this PR. We will also need these backported to 26.04_linux-nvidia-bos.

No problem, I've picked them up from upstream kernel. I'll handle for 26.04 nvidia kernel later.

Sounds good. I opened a Jira and assigned to you so we don't forget about 26.04. =)

nvmochs

Verified these are clean picks that match upstream.

Acked-by: Matthew R. Ochs <mochs@nvidia.com>

clsotog · 2026-04-21T15:39:49Z

I think this needs a rebase and then I can ack the PR. thanks

NPEM registers LED classdevs on PCI endpoint that may be behind hotplug-capable ports. During hot-removal, led_classdev_unregister() calls led_set_brightness(LED_OFF) which leads to a PCI config read to a disconnected device, which fails and returns -ENODEV (topology details in msgid.link below): leds 0003:01:00.0:enclosure:ok: Setting an LED's brightness failed (-19) The LED core already suppresses this for devices with LED_HW_PLUGGABLE set, but NPEM never sets it. Add the flag since NPEM LEDs are on hot-pluggable hardware by nature. Fixes: 4e89354 ("PCI/NPEM: Add Native PCIe Enclosure Management support") Signed-off-by: Richard Cheng <icheng@nvidia.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Lukas Wunner <lukas@wunner.de> Acked-by: Kai-Heng Feng <kaihengf@nvidia.com> Link: https://patch.msgid.link/20260402093850.23075-1-icheng@nvidia.com (cherry picked from commit 16d021c) Signed-off-by: Richard Cheng <icheng@nvidia.com>

…evice removal CXL is linked before fwctl in drivers/Makefile. Both use `module_init, so `cxl_pci_driver_init()` runs first. When `cxl_pci_probe()` calls `fwctl_register()` and then `device_add()`, fwctl_class is not yet registered because fwctl_init() hasn't run, causing `class_to_subsys()` to return NULL and skip knode_class initialization. On device removal, `class_to_subsys()` returns non-NULL, and `device_del()` calls `klist_del()` on the uninitialized knode, triggering a NULL pointer dereference. Fixes: 858ce2f ("cxl: Add FWCTL support to CXL") Link: https://patch.msgid.link/r/20260409051902.40218-1-icheng@nvidia.com Signed-off-by: Richard Cheng <icheng@nvidia.com> Reviewed-by: Kai-Heng Feng <kaihengf@nvidia.com> Reviewed-by: Dave Jiang <dave.jiang@intel.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> (cherry picked from commit a55f802) Signed-off-by: Richard Cheng <icheng@nvidia.com>

jamieNguyenNVIDIA · 2026-04-22T01:29:09Z

Acked-by: Jamie Nguyen <jamien@nvidia.com>

nvax-r · 2026-04-22T02:49:09Z

I think this needs a rebase and then I can ack the PR. thanks

I've rebased it again, please review while you are available, thanks.

clsotog

Acked-by: Carol L Soto <csoto@nvidia.com>

nvmochs · 2026-04-22T14:27:43Z

Merged, closing PR.

b5c046256379 (nnoble/nvidia-6.17-next) fwctl: Fix class init ordering to avoid NULL pointer dereference on device removal
f7d28252cc3c PCI/NPEM: Set LED_HW_PLUGGABLE for hotplug-capable ports

nvax-r force-pushed the cxl_2026-04-13 branch from 550131b to e56ab40 Compare April 21, 2026 02:19

nvidia-bfigg force-pushed the 24.04_linux-nvidia-6.17-next branch from 8b07926 to 80bac29 Compare April 21, 2026 12:02

nvmochs requested review from clsotog, nirmoy and nvmochs April 21, 2026 14:26

nvmochs approved these changes Apr 21, 2026

View reviewed changes

nvax-r added 2 commits April 22, 2026 00:12

nvax-r force-pushed the cxl_2026-04-13 branch from e56ab40 to f794381 Compare April 22, 2026 00:17

clsotog approved these changes Apr 22, 2026

View reviewed changes

nvmochs closed this Apr 22, 2026

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[linux-nvidia-6.17-next] Set LED_HW_PLUGGABLE for NPEM and fix class init ordering issue of CXL/fwctl#355

[linux-nvidia-6.17-next] Set LED_HW_PLUGGABLE for NPEM and fix class init ordering issue of CXL/fwctl#355
nvax-r wants to merge 2 commits into
NVIDIA:24.04_linux-nvidia-6.17-nextfrom
nvax-r:cxl_2026-04-13

nvax-r commented Apr 13, 2026 •

edited by nvmochs

Loading

Uh oh!

nvmochs commented Apr 13, 2026

Uh oh!

nvax-r commented Apr 14, 2026

Uh oh!

nvmochs commented Apr 21, 2026

Uh oh!

github-actions Bot commented Apr 21, 2026 •

edited

Loading

Uh oh!

nvax-r commented Apr 21, 2026

Uh oh!

nvmochs commented Apr 21, 2026

Uh oh!

nvmochs left a comment

Uh oh!

clsotog commented Apr 21, 2026

Uh oh!

jamieNguyenNVIDIA commented Apr 22, 2026 •

edited

Loading

Uh oh!

nvax-r commented Apr 22, 2026

Uh oh!

clsotog left a comment

Uh oh!

nvmochs commented Apr 22, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Conversation

nvax-r commented Apr 13, 2026 • edited by nvmochs Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Source

Lore Links:

Upstream Status

Testing

Build Validation:

Config Verification:

Runtime Testing:

Notes

Uh oh!

nvmochs commented Apr 13, 2026

Uh oh!

nvax-r commented Apr 14, 2026

Uh oh!

nvmochs commented Apr 21, 2026

Uh oh!

github-actions Bot commented Apr 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

✅ Patchscan: No Missing Fixes

Uh oh!

nvax-r commented Apr 21, 2026

Uh oh!

nvmochs commented Apr 21, 2026

Uh oh!

nvmochs left a comment

Choose a reason for hiding this comment

Uh oh!

clsotog commented Apr 21, 2026

Uh oh!

jamieNguyenNVIDIA commented Apr 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

nvax-r commented Apr 22, 2026

Uh oh!

clsotog left a comment

Choose a reason for hiding this comment

Uh oh!

nvmochs commented Apr 22, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

nvax-r commented Apr 13, 2026 •

edited by nvmochs

Loading

github-actions Bot commented Apr 21, 2026 •

edited

Loading

jamieNguyenNVIDIA commented Apr 22, 2026 •

edited

Loading