[26.04_linux-nvidia-bos] cxl: Backport Type-2 memdev lifetime fixes by nirmoy · Pull Request #483 · NVIDIA/NV-Kernels

nirmoy · 2026-07-06T09:49:10Z

Summary

Backport the complete mainline CXL Type-2 memdev lifetime model to the 7.0 BOS kernel. This replaces the narrow endpoint-pointer guard proposed in #482 with the locking and ownership model used by mainline.

The BOS adaptation migrates both in-tree Type-2 users, SFC and VFIO, to devm_cxl_probe_mem(), removes the callback-based region helper surface, and ties endpoint, memdev, and region teardown to the consumer lifetime.

Patch stack

The first five commits bring in the prerequisite locking and region protection:

bb729bf1d6fd — conditional device_lock() guard support
dc372e5f429c — hold the memdev lock in event tracing
e8069c66d093 — validate the memdev driver in cxl_reset_done() (adapted to the existing BOS guard)
574eda81d0a7 — hold the memdev lock during poison operations
d91feb88692e — block region deletion during region creation (adapted for downstream cxl_create_region())

The first SAUCE commit combines and adapts the remaining accepted mainline lifetime series:

4dd86ca99ffc — resolve region deletion races
bd3a6ff4b84e — pin memdev parents for their full lifetime
2ed519c21bb4 — distinguish class memory devices
d8dcb0b74b04 — introduce devm_cxl_probe_mem()
383f69656359 — support !CONFIG_CXL_REGION

The final SAUCE commit fixes a self-deadlock if devres action allocation fails while the region read lock is held.

Behavior change

After a device is confirmed as CXL.mem, the VFIO path now fails binding when the required topology or firmware-committed region is unavailable instead of leaving a published memdev or silently falling back to partially initialized plain VFIO state. Jiandi should validate this policy on the target hardware.

This stack supersedes #482 after functional validation; the guard PR and this lifetime backport should not both be merged.

Upstream plan

The dependency stack is already accepted in mainline 7.2. The clean upstream version of the new deadlock fix is preserved on codex/cxl-attach-action-deadlock-fix-upstream.

After fault-injection and lockdep validation, post that clean patch to linux-cxl@vger.kernel.org and linux-kernel@vger.kernel.org, then track review on lore. The combined SFC/VFIO migration remains BOS SAUCE because it adapts downstream Type-2 users.

Current validation

git diff --check: pass
Complete code tree matches the independently reviewed prepared backport
CXL core, CXL PCI/mem, SFC CXL, VFIO PCI, and VFIO CXL objects: build pass
Relevant build configuration enabled: CONFIG_CXL_REGION=y, CONFIG_SFC_CXL=y, and CONFIG_VFIO_CXL_CORE=y
Final deadlock fix: strict checkpatch pass
Commit policy audit: no Change-Id, BugLink, or internal bug URL trailers

The target branch's older checkpatch reports inherited ACQUIRE_ERR() assignment-in-condition findings in two accepted upstream backports; no local rewrite was made to those upstream changes.

Pending validation

Fault-inject devres action allocation failure under lockdep
Type-2 VFIO attach, access, reset, repeated bind/unbind, and teardown
SFC CXL probe/remove
BOS package build
Strata/Vera boot with CXL memdev enumeration

Tracking

BugLink: https://bugs.launchpad.net/bugs/2131705 Add ABI documentation for the Performance Limited Register sysfs interface in the cppc_cpufreq driver. Signed-off-by: Sumit Gupta <sumitg@nvidia.com> Reviewed-by: Randy Dunlap <rdunlap@infradead.org> Reviewed-by: Pierre Gondois <pierre.gondois@arm.com> Reviewed-by: Lifeng Zheng <zhenglifeng1@huawei.com> Link: https://patch.msgid.link/20260206142658.72583-8-sumitg@nvidia.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> (cherry picked from commit 856250b) Signed-off-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Nirmoy Das <nirmoyd@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>

BugLink: https://bugs.launchpad.net/bugs/2131705 Currently, the `Reference Performance` register is read every time the CPU frequency is sampled in `cppc_get_perf_ctrs()`. This function is on the hot path of the cppc_cpufreq driver. Reference Performance indicates the performance level that corresponds to the Reference Counter incrementing and is not expected to change dynamically during runtime (unlike the Delivered and Reference counters). Reading this register in the hot path incurs unnecessary overhead, particularly on platforms where CPC registers are located in the PCC (Platform Communication Channel) subspace. This patch moves `reference_perf` from the dynamic feedback counters structure (`cppc_perf_fb_ctrs`) to the static capabilities structure (`cppc_perf_caps`). Signed-off-by: Pengjie Zhang <zhangpengjie2@huawei.com> [ rjw: Changelog adjustment ] Link: https://patch.msgid.link/20260213100935.19111-1-zhangpengjie2@huawei.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> (cherry picked from commit 8505bfb) Signed-off-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Nirmoy Das <nirmoyd@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>

BugLink: https://bugs.launchpad.net/bugs/2131705 Commit 8505bfb ("ACPI: CPPC: Move reference performance to capabilities") introduced a logical error when retrieving the reference performance. On platforms lacking the reference performance register, the fallback logic leaves the local 'ref' variable uninitialized (0). This causes the subsequent sanity check to incorrectly return -EFAULT, breaking amd_pstate initialization. Fix this by assigning 'ref = nom' in the fallback path. Fixes: 8505bfb ("ACPI: CPPC: Move reference performance to capabilities") Reported-by: Nathan Chancellor <nathan@kernel.org> Closes: https://lore.kernel.org/all/20260310003026.GA2639793@ax162/ Tested-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Pengjie Zhang <zhangpengjie2@huawei.com> [ rjw: Subject tweak ] Link: https://patch.msgid.link/20260311071334.1494960-1-zhangpengjie2@huawei.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> (cherry picked from commit be473f0) Signed-off-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Nirmoy Das <nirmoyd@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>

BugLink: https://bugs.launchpad.net/bugs/2131705 Callers of cpc_read() ignore its return value, which can lead to using uninitialized or stale values when the read fails. Fix this by consistently checking cpc_read() return values in cppc_get_perf_caps(), cppc_get_perf_ctrs(), and cppc_get_perf(). Link: https://lore.kernel.org/lkml/48bdf87e-39f1-402f-a7dc-1a0e1e7a819d@nvidia.com/ Suggested-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Sumit Gupta <sumitg@nvidia.com> Link: https://patch.msgid.link/20260318095005.2437960-1-sumitg@nvidia.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> (cherry picked from commit 0cc2497) Signed-off-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Nirmoy Das <nirmoyd@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>

BugLink: https://bugs.launchpad.net/bugs/2131705 policy->max_freq_req QoS constraint represents the maximal allowed frequency than can be requested. It is set by: - writing to policyX/scaling_max sysfs file - toggling the cpufreq/boost sysfs file Upon calling freq_qos_update_request(), a successful update of the max_freq_req value triggers cpufreq_notifier_max(), followed by cpufreq_set_policy() which update the requested frequency for the policy. If the new max_freq_req value is not different from the original value, no frequency update is triggered. In a specific sequence of toggling: - cpufreq/boost sysfs file - CPU hot-plugging a CPU could end up with boost enabled but running at the maximal non-boost frequency, cpufreq_notifier_max() not being triggered. The following fixed that: commit 1608f02 ("cpufreq: Fix re-boost issue after hotplugging a CPU") The following: commit dd016f3 ("cpufreq: Introduce a more generic way to set default per-policy boost flag") also fixed the issue by correctly setting the max_freq_req constraint of a policy that is re-activated. This makes the first fix unnecessary. As the original issue is fixed by another method, this patch reverts: commit 1608f02 ("cpufreq: Fix re-boost issue after hotplugging a CPU") Reviewed-by: Lifeng Zheng <zhenglifeng1@huawei.com> Signed-off-by: Pierre Gondois <pierre.gondois@arm.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Link: https://patch.msgid.link/20260326204404.1401849-2-pierre.gondois@arm.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> (cherry picked from commit 04aa9d0) Signed-off-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Nirmoy Das <nirmoyd@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>

BugLink: https://bugs.launchpad.net/bugs/2131705 The Power Management Quality of Service (PM QoS) allows to aggregate constraints from multiple entities. It is currently used to manage the min/max frequency of a given policy. Frequency constraints can come for instance from: - Thermal framework: acpi_thermal_cpufreq_init() - Firmware: _PPC objects: acpi_processor_ppc_init() - User: by setting policyX/scaling_[min|max]_freq The minimum of the max frequency constraints is used to compute the resulting maximum allowed frequency. When enabling boost frequencies, the same frequency request object (policy->max_freq_req) as to handle requests from users is used. As a result, when setting: - scaling_max_freq - boost The last sysfs file used overwrites the request from the other sysfs file. To avoid this, create a per-policy boost_freq_req to save the boost constraints instead of overwriting the last scaling_max_freq constraint. policy_set_boost() calls the cpufreq set_boost callback. Update the newly added boost_freq_req request from there: - whenever boost is toggled - to cover all possible paths In the existing .set_boost() callbacks: - Don't update policy->max as this is done through the qos notifier cpufreq_notifier_max() which calls cpufreq_set_policy(). - Remove freq_qos_update_request() calls as the qos request is now done in policy_set_boost() and updates the new boost_freq_req $ ## Init state scaling_max_freq:1000000 cpuinfo_max_freq:1000000 $ echo 700000 > scaling_max_freq scaling_max_freq:700000 cpuinfo_max_freq:1000000 $ echo 1 > ../boost scaling_max_freq:1200000 cpuinfo_max_freq:1200000 $ echo 800000 > scaling_max_freq scaling_max_freq:800000 cpuinfo_max_freq:1200000 $ ## Final step: $ ## Without the patches: $ echo 0 > ../boost scaling_max_freq:1000000 cpuinfo_max_freq:1000000 $ ## With the patches: $ echo 0 > ../boost scaling_max_freq:800000 cpuinfo_max_freq:1000000 Note: cpufreq_frequency_table_cpuinfo() updates policy->min and max from: A. cpufreq_boost_set_sw() \-cpufreq_frequency_table_cpuinfo() B. cpufreq_policy_online() \-cpufreq_table_validate_and_sort() \-cpufreq_frequency_table_cpuinfo() Keep these updates as some drivers expect policy->min and max to be set through B. Reviewed-by: Lifeng Zheng <zhenglifeng1@huawei.com> Signed-off-by: Pierre Gondois <pierre.gondois@arm.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Link: https://patch.msgid.link/20260326204404.1401849-3-pierre.gondois@arm.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> (cherry picked from commit 6e39ba4) Signed-off-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Nirmoy Das <nirmoyd@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>

BugLink: https://bugs.launchpad.net/bugs/2131705 A recent change exposed a bug in the error path: if freq_qos_add_request(boost_freq_req) fails, min_freq_req may remain a valid pointer even though it was never successfully added. During policy teardown, this leads to an unconditional call to freq_qos_remove_request(), triggering a WARN. The current design allocates all three freq_req objects together, making the lifetime rules unclear and error handling fragile. Simplify this by allocating the QoS freq_req objects at policy allocation time. The policy itself is dynamically allocated, and two of the three requests are always needed anyway. This ensures consistent lifetime management and eliminates the inconsistent state in failure paths. Reported-by: Zhongqiu Han <zhongqiu.han@oss.qualcomm.com> Fixes: 6e39ba4 ("cpufreq: Add boost_freq_req QoS request") Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Lifeng Zheng <zhenglifeng1@huawei.com> Tested-by: Pierre Gondois <pierre.gondois@arm.com> Reviewed-by: Zhongqiu Han <zhongqiu.han@oss.qualcomm.com> Link: https://patch.msgid.link/a293f29d841b86c51f34699c6e717e01858d8ada.1774933424.git.viresh.kumar@linaro.org Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> (cherry picked from commit 9266b4d) Signed-off-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Nirmoy Das <nirmoyd@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>

BugLink: https://bugs.launchpad.net/bugs/2131705 The value of maximum frequency is fixed and never changes. Doing calculations every time based off of perf is unnecessary. Reviewed-by: Gautham R. Shenoy <gautham.shenoy@amd.com> Link: https://lore.kernel.org/r/20260326193620.649441-1-mario.limonciello@amd.com Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org> (backported from commit 8cdc494) [jamien: minor context-line drift in amd-pstate.c hunks from 3-way auto-merge; +/- content is byte-identical to upstream.] Signed-off-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Nirmoy Das <nirmoyd@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>

BugLink: https://bugs.launchpad.net/bugs/2131705 Extract the QoS related logic from cpufreq_policy_online() to make the function shorter/simpler. The logic is placed in cpufreq_policy_init_qos() and is now executed right after the following calls: - cpufreq_driver->init() - cpufreq_table_validate_and_sort() This helps preparing following patches that will, in cpufreq_policy_init_qos(): - treat the policy->min/max values set by drivers as QoS requests. - set a default policy->min/max value to all policies. No functional change. Signed-off-by: Pierre Gondois <pierre.gondois@arm.com> (backported from https://lore.kernel.org/lkml/20260511135538.522653-1-pierre.gondois@arm.com/) Signed-off-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Nirmoy Das <nirmoyd@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>

…ivers BugLink: https://bugs.launchpad.net/bugs/2131705 Some drivers set policy->min/max in their .init() callback. cpufreq_set_policy() will ultimately override them through: cpufreq_policy_online() \-cpufreq_init_policy() \-cpufreq_set_policy() \-/* Set policy->min/max */ Thus the policy min/max values provided are only temporary. There is an exception if CPUFREQ_NEED_INITIAL_FREQ_CHECK is set and: cpufreq_policy_online() \-__cpufreq_driver_target() \-cpufreq_driver->target() To prepare for a following patch that will remove all policy->min/max initialization in the driver .init() callback if the min/max value is equal to the cpuinfo.min/max_freq, set a default policy->min/max value for all drivers. Signed-off-by: Pierre Gondois <pierre.gondois@arm.com> (backported from https://lore.kernel.org/lkml/20260511135538.522653-1-pierre.gondois@arm.com/) Signed-off-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Nirmoy Das <nirmoyd@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>

BugLink: https://bugs.launchpad.net/bugs/2131705 Prior to [1], drivers were setting policy->min/max and the value was used as a QoS constraint. After that change, the values were only temporarily used: cpufreq_set_policy() ultimately overriding them through: cpufreq_policy_online() \-cpufreq_init_policy() \-cpufreq_set_policy() \-/* Set policy->min/max */ This patch reinstate the initial behaviour. This will allow drivers to request min/max QoS frequencies if desired. For instance, the cppc driver advertises a lowest non-linear frequency, which should be used as a min QoS value. To avoid having drivers setting policy->min/max to default values which are considered as QoS values (i.e. the reason why [1] was introduced), remove the initialization of policy->min/max in .init() callbacks wherever the policy->min/max values are identical to the policy->cpuinfo.min/max_freq. Indeed, the previous patch ("cpufreq: Set default policy->min/max values for all drivers") makes this initialization redundant. The only drivers where these values are different are: - gx-suspmod.c (min) - cppc-cpufreq.c (min) - longrun.c [1] commit 521223d ("cpufreq: Fix initialization of min and max frequency QoS requests") Signed-off-by: Pierre Gondois <pierre.gondois@arm.com> (backported from https://lore.kernel.org/lkml/20260511135538.522653-1-pierre.gondois@arm.com/) [jamien: 3-way auto-merge resolved context drift in amd-pstate.c and intel_pstate.c against this tree; +/- content is byte-identical to v2 3/4.] Signed-off-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Nirmoy Das <nirmoyd@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>

BugLink: https://bugs.launchpad.net/bugs/2131705 Consider policy->min/max being set in the driver .init() callback as a QoS request. Impacted driver are: - gx-suspmod.c (min) - cppc-cpufreq.c (min) - longrun.c (min/max) Update the documentation accordingly. Signed-off-by: Pierre Gondois <pierre.gondois@arm.com> (backported from https://lore.kernel.org/lkml/20260511135538.522653-1-pierre.gondois@arm.com/) Signed-off-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Nirmoy Das <nirmoyd@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>

BugLink: https://bugs.launchpad.net/bugs/2131705 Add a kernel boot parameter 'cppc_cpufreq.auto_sel_mode' to enable CPPC autonomous performance selection on all CPUs at system startup. When autonomous mode is enabled, the hardware automatically adjusts CPU performance based on workload demands using Energy Performance Preference (EPP) hints. When auto_sel_mode=1: - Configure all CPUs for autonomous operation on first init - Set EPP to performance preference (0x0) - Use HW min/max_perf when available; otherwise initialize from caps - Clamp desired_perf to bounds before enabling autonomous mode - Hardware controls frequency instead of the OS governor The boot parameter is applied only during first policy initialization. Skip applying it on CPU hotplug to preserve runtime sysfs configuration. This patch depends on patch [2] ("cpufreq: Set policy->min and max as real QoS constraints") so that the policy->min/max set in cppc_cpufreq_cpu_init() are not overridden by cpufreq_set_policy() during init. Reviewed-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Sumit Gupta <sumitg@nvidia.com> (backported from https://lore.kernel.org/lkml/20260424201814.230071-1-sumitg@nvidia.com/) [jamien: hunk #2 (cppc_set_enable() insertion in cppc_cpufreq_cpu_init) rebased onto Pierre's v2 series, which replaced the local min/max vars with direct policy->min assignment; insertion point and code are unchanged.] Signed-off-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Nirmoy Das <nirmoyd@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>

BugLink: https://bugs.launchpad.net/bugs/2150727 This reverts commit 11d6b22. Signed-off-by: Nirmoy Das <nirmoyd@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>

… NVIDIA GPUs" BugLink: https://bugs.launchpad.net/bugs/2150727 This reverts commit 208b48c. Signed-off-by: Nirmoy Das <nirmoyd@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>

…he capable devices" BugLink: https://bugs.launchpad.net/bugs/2150727 This reverts commit 967f9fe. Signed-off-by: Nirmoy Das <nirmoyd@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>

…le devices BugLink: https://bugs.launchpad.net/bugs/2150727 Controlled by the IOMMU driver, ATS is usually enabled "on demand" when a given PASID on a device is attached to an I/O page table. This is working even when a device has no translation on its RID (i.e., the RID is IOMMU bypassed). However, certain PCIe devices require non-PASID ATS on their RID even when the RID is IOMMU bypassed. Call this "always on". For example, CXL spec r4.0 notes in sec 3.2.5.13 Memory Type on CXL.cache: "To source requests on CXL.cache, devices need to get the Host Physical Address (HPA) from the Host by means of an ATS request on CXL.io." In other words, the CXL.cache capability requires ATS; otherwise, it can't access host physical memory. Introduce a new pci_ats_always_on() helper for the IOMMU driver to scan a PCI device and shift ATS policies between "on demand" and "always on". Add the support for CXL.cache devices first. Pre-CXL devices will be added in quirks.c file. Note that pci_ats_always_on() validates against pci_ats_supported(), so we ensure that untrusted devices (e.g. external ports) will not be always on. This maintains the existing ATS security policy regarding potential side- channel attacks via ATS. Cc: linux-cxl@vger.kernel.org Suggested-by: Vikram Sethi <vsethi@nvidia.com> Suggested-by: Jason Gunthorpe <jgg@nvidia.com> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Tested-by: Nirmoy Das <nirmoyd@nvidia.com> Acked-by: Nirmoy Das <nirmoyd@nvidia.com> Signed-off-by: Nicolin Chen <nicolinc@nvidia.com> Reviewed-by: Dave Jiang <dave.jiang@intel.com> (backported from https://lore.kernel.org/r/f6734b9dad0050138676f11ecd14e9db1cf6b697.1777269009.git.nicolinc@nvidia.com) [Nirmoy: Adapt to already existing PCI_DVSEC_CXL_CACHE_CAPABLE.] Signed-off-by: Nirmoy Das <nirmoyd@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>

BugLink: https://bugs.launchpad.net/bugs/2150727 Some NVIDIA GPU/NIC devices, though they don't implement CXL config space, have many CXL-like properties. Call this kind "pre-CXL". Similar to CXL.cache capability, these pre-CXL devices also require the ATS function even when their RIDs are IOMMU bypassed, i.e. keep ATS "always on" v.s. "on demand" when a non-zero PASID line gets enabled in SVA use cases. Introduce pci_dev_specific_ats_always_on() quirk function to scan a list of IDs for these devices. Then, include it in pci_ats_always_on(). Suggested-by: Jason Gunthorpe <jgg@nvidia.com> Reviewed-by: Nirmoy Das <nirmoyd@nvidia.com> Tested-by: Nirmoy Das <nirmoyd@nvidia.com> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Signed-off-by: Nicolin Chen <nicolinc@nvidia.com> Reviewed-by: Dave Jiang <dave.jiang@intel.com> (backported from https://lore.kernel.org/r/1a8cf5e88051ab5c10417edb94df598ecbc810cf.1777269009.git.nicolinc@nvidia.com) [Nirmoy: Apply after reverting older ATS always-on PCI quirk support.] Signed-off-by: Nirmoy Das <nirmoyd@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>

BugLink: https://bugs.launchpad.net/bugs/2150727 When a device's default substream attaches to an identity domain, the SMMU driver currently sets the device's STE between two modes: Mode 1: Cfg=Translate, S1DSS=Bypass, EATS=1 Mode 2: Cfg=bypass (EATS is ignored by HW) When there is an active PASID (non-default substream), mode 1 is used. And when there is no PASID support or no active PASID, mode 2 is used. The driver will also downgrade an STE from mode 1 to mode 2, when the last active substream becomes inactive. However, there are PCIe devices that demand ATS to be always on. For these devices, their STEs have to use the mode 1 as HW ignores EATS with mode 2. Change the driver accordingly: - always use the mode 1 - never downgrade to mode 2 - allocate and retain a CD table (see note below) Note that these devices might not support PASID, i.e. doing non-PASID ATS. In such a case, the ssid_bits is set to 0. However, s1cdmax must be set to a !0 value in order to keep the S1DSS field effective. Thus, when a master requires ats_always_on, set its s1cdmax to at least 1, meaning that the CD table will have a dummy entry (SSID=1) that will never be used. Now for these devices, arm_smmu_cdtab_allocated() will always return true, v.s. false prior to this change. When its default substream is attached to an IDENTITY domain, its first CD is NULL in the table, which is a totally valid case. Thus, add "!master->ats_always_on" to the condition. Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Tested-by: Nirmoy Das <nirmoyd@nvidia.com> Acked-by: Nirmoy Das <nirmoyd@nvidia.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Signed-off-by: Nicolin Chen <nicolinc@nvidia.com> Reviewed-by: Dave Jiang <dave.jiang@intel.com> (backported from https://lore.kernel.org/r/7403163ebf59380f88c7503b3adf0dae07428df8.1777269009.git.nicolinc@nvidia.com) [Nirmoy: Apply after reverting older ATS always-on arm-smmu-v3 support.] Signed-off-by: Nirmoy Das <nirmoyd@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>

BugLink: https://bugs.launchpad.net/bugs/2150640 ovl_iterate_merged() stores PTR_ERR(cache) in err before checking IS_ERR(cache). On success err holds the truncated cache pointer and can be returned as a bogus non-zero error. The syzbot reproducer reaches this through overlay-on-overlay readdir: getdents64 iterate_dir(outer overlay file) ovl_iterate_merged() ovl_cache_get() ovl_dir_read_merged() ovl_dir_read() iterate_dir(inner overlay file) ovl_iterate_merged() Only compute PTR_ERR(cache) on the error path. Fixes: d25e4b7 ("ovl: refactor ovl_iterate() and port to cred guard") Reported-by: syzbot+a16fb0cce329a320661c@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=a16fb0cce329a320661c Cc: stable@vger.kernel.org Signed-off-by: Nirmoy Das <nirmoyd@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> (backported from https://lore.kernel.org/r/20260514144258.3068715-1-nirmoyd@nvidia.com) Signed-off-by: Brad Figg <bfigg@nvidia.com>

BugLink: https://bugs.launchpad.net/bugs/2153819 In preparation for type2 drivers add function and macro for differentiating CXL memory expanders (type 3) from CXL device accelerators (type 2) helping drivers built from public headers to embed struct cxl_dev_state inside a private struct. Update type3 driver for using this same initialization. Signed-off-by: Alejandro Lucero <alucerop@amd.com> Reviewed-by: Dave Jiang <dave.jiang@intel.com> Reviewed-by: Alison Schofield <alison.schofield@intel.com> Reviewed-by: Gregory Price <gourry@gourry.net> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Link: https://patch.msgid.link/20260306164741.3796372-2-alejandro.lucero-palau@amd.com Signed-off-by: Dave Jiang <dave.jiang@intel.com> (cherry picked from commit 9a775c0) Signed-off-by: Koba Ko <kobak@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>

BugLink: https://bugs.launchpad.net/bugs/2153819 In preparation for type2 support, move structs and functions a type2 driver will need to access to into a new shared header file. Differentiate between public and private data to be preserved by type2 drivers. Signed-off-by: Alejandro Lucero <alucerop@amd.com> Reviewed-by: Dave Jiang <dave.jiang@intel.com> Tested-by: Alison Schofield <alison.schofield@intel.com> Reviewed-by: Gregory Price <gourry@gourry.net> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Link: https://patch.msgid.link/20260306164741.3796372-3-alejandro.lucero-palau@amd.com Signed-off-by: Dave Jiang <dave.jiang@intel.com> (cherry picked from commit 0058698) Signed-off-by: Koba Ko <kobak@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>

BugLink: https://bugs.launchpad.net/bugs/2153819 Inside cxl/core/pci.c there are helpers for CXL PCIe initialization meanwhile cxl/pci_drv.c implements the functionality for a Type3 device initialization. In preparation for type2 support, move helper functions from cxl/pci.c to cxl/core/pci.c in order to be exported and used by type2 drivers. [ dj: Clarified subject. ] Signed-off-by: Alejandro Lucero <alucerop@amd.com> Reviewed-by: Dave Jiang <dave.jiang@intel.com> Reviewed-by: Gregory Price <gourry@gourry.net> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Signed-off-by: Gregory Price <gourry@gourry.net> Link: https://patch.msgid.link/20260306164741.3796372-4-alejandro.lucero-palau@amd.com Signed-off-by: Dave Jiang <dave.jiang@intel.com> (cherry picked from commit 58f2893) Signed-off-by: Koba Ko <kobak@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>

BugLink: https://bugs.launchpad.net/bugs/2153819 Remove the redundant port lookup from cxl_rcrb_get_comp_regs() and use the dport parameter directly. The caller has already validated the port is non-NULL before invoking this function, and dport is given as a param. This is simpler than getting dport in the callee and return the pointer to the caller what would require more changes. Signed-off-by: Gregory Price <gourry@gourry.net> Reviewed-by: Alejandro Lucero <alucerop@amd.com> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Reviewed-by: Davidlohr Bueso <dave@stgolabs.net> Link: https://patch.msgid.link/20260306164741.3796372-5-alejandro.lucero-palau@amd.com Signed-off-by: Dave Jiang <dave.jiang@intel.com> (cherry picked from commit d537d95) Signed-off-by: Koba Ko <kobak@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>

BugLink: https://bugs.launchpad.net/bugs/2153819 Add CXL initialization based on new CXL API for accel drivers and make it dependent on kernel CXL configuration. Signed-off-by: Alejandro Lucero <alucerop@amd.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Acked-by: Edward Cree <ecree.xilinx@gmail.com> Reviewed-by: Alison Schofield <alison.schofield@intel.com> Reviewed-by: Dan Williams <dan.j.williams@intel.com> Reviewed-by: Dave Jiang <dave.jiang@intel.com> Reviewed-by: Ben Cheatham <benjamin.cheatham@amd.com> (cherry picked from https://lore.kernel.org/r/20260423180528.17166-2-alejandro.lucero-palau@amd.com) Signed-off-by: Koba Ko <kobak@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>

BugLink: https://bugs.launchpad.net/bugs/2153819 Export cxl core functions for a Type2 driver being able to discover and map the device registers. Use it in sfc driver cxl initialization. Signed-off-by: Alejandro Lucero <alucerop@amd.com> Reviewed-by: Dan Williams <dan.j.williams@intel.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Dave Jiang <dave.jiang@intel.com> Reviewed-by: Ben Cheatham <benjamin.cheatham@amd.com> (backported from https://lore.kernel.org/r/20260423180528.17166-3-alejandro.lucero-palau@amd.com) [kobak: Kept cxl_pci_setup_regs() in the core/pci provider added by the full Type2 prerequisite series and dropped the duplicate provider hunk from drivers/cxl/pci.c.] Signed-off-by: Koba Ko <kobak@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>

BugLink: https://bugs.launchpad.net/bugs/2153819 Type3 relies on mailbox CXL_MBOX_OP_IDENTIFY command for initializing memdev state params which end up being used for DPA initialization. Allow a Type2 driver to initialize DPA simply by giving the size of its volatile hardware partition. Move related functions to memdev. Add sfc driver as the client. Signed-off-by: Alejandro Lucero <alucerop@amd.com> Reviewed-by: Dan Williams <dan.j.williams@intel.com> Reviewed-by: Dave Jiang <dave.jiang@intel.com> Reviewed-by: Ben Cheatham <benjamin.cheatham@amd.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> (cherry picked from https://lore.kernel.org/r/20260423180528.17166-4-alejandro.lucero-palau@amd.com) Signed-off-by: Koba Ko <kobak@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>

BugLink: https://bugs.launchpad.net/bugs/2153819 Current cxl core is relying on a CXL_DEVTYPE_CLASSMEM type device when creating a memdev leading to problems when obtaining cxl_memdev_state references from a CXL_DEVTYPE_DEVMEM type. Modify check for obtaining cxl_memdev_state adding CXL_DEVTYPE_DEVMEM support. Make devm_cxl_add_memdev accessible from an accel driver. Signed-off-by: Alejandro Lucero <alucerop@amd.com> Reviewed-by: Ben Cheatham <benjamin.cheatham@amd.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Dave Jiang <dave.jiang@intel.com> Reviewed-by: Alison Schofield <alison.schofield@intel.com> Reviewed-by: Dan Williams <dan.j.williams@intel.com> (cherry picked from https://lore.kernel.org/r/20260423180528.17166-5-alejandro.lucero-palau@amd.com) Signed-off-by: Koba Ko <kobak@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>

BugLink: https://bugs.launchpad.net/bugs/2153819 Use cxl API for creating a cxl memory device using the type2 cxl_dev_state struct. Signed-off-by: Alejandro Lucero <alucerop@amd.com> Reviewed-by: Martin Habets <habetsm.xilinx@gmail.com> Reviewed-by: Fan Ni <fan.ni@samsung.com> Acked-by: Edward Cree <ecree.xilinx@gmail.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Dave Jiang <dave.jiang@intel.com> (cherry picked from https://lore.kernel.org/r/20260423180528.17166-6-alejandro.lucero-palau@amd.com) Signed-off-by: Koba Ko <kobak@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>

BugLink: https://bugs.launchpad.net/bugs/2153819 Support an accelerator driver to safely work with an autodiscovered region from a committed HDM decoder through: 1) an accelerator driver cxl_attach_region struct with attach and detach callbacks. 2) a specific function, cxl_memdev_attach_region() keeping the required locks for finding a region linked to the memdev endpoint, and 3) invoking attach callback while keeping the locking allowing to work (ioremap and other internal stuff) with the related physical range by the accelerator driver, and 4) linking a detach callback to the endpoint device removal where the accelerator driver can stop using the region range. This covers the cases of a potential removal of cxl_acpi module or a accelerator memdev unbinding from cxl_mem driver through sysfs. Signed-off-by: Alejandro Lucero <alucerop@amd.com> (backported from https://lore.kernel.org/r/20260423180528.17166-7-alejandro.lucero-palau@amd.com) [kobak: Check cxl_memdev_attach_region() errors and propagate failure so SFC probe does not continue after CXL core tears down the attached region. Set probe_data->cxl before attaching so the attach callback can use it, guard attach attempts before a valid endpoint exists, explicitly unwind attach/autoremove side effects if devres action registration fails, preserve DEVMEM target type for autodiscovered regions, and route delete / construct-failure cleanup through endpoint-owned devres actions.] [kobak: Keep no-detach DEVMEM unregister under the endpoint-device guard so attach cannot install endpoint devres actions for a region being freed.] [kobak: Avoid devres-registration failure cleanup under cxl_rwsem.region read lock: keep endpoint->dev locked, drop the region/DPA read guards before unregister_region(), and use devm_remove_action() so failed detach-action registration does not run cxl_endpoint_region_autoremove() under the read lock.] Signed-off-by: Koba Ko <kobak@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>

BugLink: https://bugs.launchpad.net/bugs/2158813 Properties: no-test-build Signed-off-by: Jacob Martin <jacob.martin@canonical.com>

…rnel-versions (adhoc/d2026.06.30) BugLink: https://bugs.launchpad.net/bugs/1786013 Signed-off-by: Jacob Martin <jacob.martin@canonical.com>

Signed-off-by: Jacob Martin <jacob.martin@canonical.com>

BugLink: https://bugs.launchpad.net/bugs/2158811 Define cpu_smt_mask in case of CONFIG_SCHED_SMT=n as cpumask_of that CPU. With that config, it is expected that kernel treats each CPU as individual core. Using cpumask_of(cpu) reflects that. This would help to get rid of the ifdeffery that is spread across the codebase since cpu_smt_mask is defined only in case of CONFIG_SCHED_SMT=y. Note: There is no arch today which defines cpu_smt_mask unconditionally. So likely defining the cpu_smt_mask shouldn't lead redefinition errors. Signed-off-by: Shrikanth Hegde <sshegde@linux.ibm.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Phil Auld <pauld@redhat.com> Reviewed-by: Valentin Schneider <vschneid@redhat.com> Tested-by: K Prateek Nayak <kprateek.nayak@amd.com> Link: https://patch.msgid.link/20260515172456.542799-2-sshegde@linux.ibm.com (cherry picked from commit 8d3ad4bd922e94834d5a5e1c46df625fd21a4acb) Signed-off-by: Andrea Righi <arighi@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>

… asym-capacity BugLink: https://bugs.launchpad.net/bugs/2158811 select_idle_capacity() scans all logical CPUs also when it is looking for a fully idle SMT core. Two concurrent wakeups can therefore observe the same core as idle, encounter different siblings first, and place one task on each sibling while another core remains unused. Make every logical CPU of a selected idle core resolve to the same stable CPU representative within the scan's existing affinity and scheduling-domain mask. If the first task is enqueued before the next scan examines the core, that scan rejects the now-busy core. If both scans observe the core as idle, they select the same runqueue even if the first enqueue becomes visible before the second scan finishes, exposing the imbalance to the load balancer. The symmetric CPU idle selection path is subject to the same race, but normally returns as soon as select_idle_core() finds a fully idle core, reducing the conflict window. The per-CPU capacity scan can retain an idle-core candidate while evaluating other CPUs, giving concurrent wakeups more opportunity to select different siblings of the same SMT core. Therefore, limit the normalization to the asym-capacity path, where this behavior has a measurable impact. On NVIDIA Vera Rubin (arm64, 176 CPUs/88 cores per NUMA node), a CPU-intensive NVPL SGEMM workload restricted to 88 threads (one per core) showed a consistent 23% increase in mean throughput across multiple runs. For comparison, DCPerf MediaWiki running at system saturation (with all SMT siblings busy) showed neither a benefit nor a regression: throughput and Nginx request latency remained within measurement error. Likewise, schbench under partially idle conditions showed no material change in wakeup latency, request latency, or throughput (within 0.1%). Tail wakeup latency was more consistent across runs with this change applied. Signed-off-by: Andrea Righi <arighi@nvidia.com> [ arighi: adjust context for v7.0 ] (backported from https://lore.kernel.org/all/20260630152747.128746-1-arighi@nvidia.com) Signed-off-by: Andrea Righi <arighi@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>

BugLink: https://bugs.launchpad.net/bugs/2156928 This patch updates the lan743x driver to prevent the use of netdev-based logging APIs (such as netdev_dbg) before the network device has been successfully registered. Using netdev-based logging prior to registration results in log messages referencing "(unnamed net_device) (uninitialized)", which can be confusing and less informative. The driver must use netif_msg_ APIs and device-based logging (e.g. dev_dbg) until netdev registration is complete. This ensures log entries are associated with the correct device context and improves log clarity. After registration, netdev-based logging APIs can be used safely. Signed-off-by: David Thompson <davthompson@nvidia.com> Link: https://patch.msgid.link/20260528165017.421576-1-davthompson@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> (cherry picked from commit e3c6508) Signed-off-by: David Thompson <davthompson@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>

BugLink: https://bugs.launchpad.net/bugs/2156928 VLAN-tagged interfaces on lan743x devices were previously unreachable via SSH and failed to respond to large ping packets (e.g. "ping -s 1469" given MTU=1500). In these scenarios, "ethtool -S" reports non-zero "RX Oversize Frame Errors". According to Microchip AN2948, the MAC_RX FSE (VLAN field size enforcement) bit determines whether frames with VLAN tags exceeding the base MTU plus tag length are discarded. The driver must set the MAC_RX.FSE bit before setting MAC_RX.RXEN to allow VLAN-tagged frames up to the interface MTU, preventing them from being treated as oversized. As a result, both the base and VLAN-tagged interfaces can use the same MTU without receive errors. Fixes: 23f0703 ("lan743x: Add main source files for new lan743x driver") Signed-off-by: David Thompson <davthompson@nvidia.com> Reviewed-by: Thangaraj Samynathan <Thangaraj.s@microchip.com> Reviewed-by: Nicolai Buchwitz <nb@tipi-net.de> Tested-by: Nicolai Buchwitz <nb@tipi-net.de> # lan7430 on arm64 (RevPi Link: https://patch.msgid.link/20260529210300.433135-1-davthompson@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> (cherry picked from commit 8173d22) Signed-off-by: David Thompson <davthompson@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>

nirmoy · 2026-07-06T10:02:05Z

@JiandiAnNVIDIA, could you please review and test this upstream follow-up? This draft also tracks the linux-cxl/LKML submission plan.

nirmoy · 2026-07-06T10:15:18Z

BaseOS Kernel Review

Summary

CXL Type-2 memdev backport has Critical issues: a double put_device causing refcount underflow/UAF and an ABBA deadlock between kill_regions and endpoint_unregister_region over regions_lock. cxl_reset_done() also risks an oops dereferencing an ERR_PTR endpoint.

Findings: Critical: 2, High: 2, Medium: 1, Low: 4

Latest watcher review: open review

Generated test plan: open test plan

Kernel deb build: successful (download debs, 4 files)

Head: b25396b9f8fe

This comment is maintained by nv-pr-bot. It is updated when the GitHub watcher publishes a newer review.

jamieNguyenNVIDIA · 2026-07-06T16:33:49Z

@nirmoy: The change looks okay, but shouldn't this be a "SAUCE" patch?

nirmoy · 2026-07-06T17:35:38Z

@nirmoy: The change looks okay, but shouldn't this be a "SAUCE" patch?

Ack. I missed that. I should also add few other upstream fixes which codex seems to missed while creating the PR

clsotog · 2026-07-06T17:39:22Z

For which kernel is this? 7.0-bos?

nirmoy · 2026-07-06T17:47:46Z

For which kernel is this? 7.0-bos?
Wrong branch, it should 7.0-bos. Thanks

nirmoy · 2026-07-06T18:01:26Z

Scope corrected: PR #483 now targets 7.0 BOS and carries the complete dependent lifetime stack. The BOS-specific combined migration and the not-yet-upstream deadlock fix are marked SAUCE. The clean upstream patch is preserved separately for linux-cxl/LKML submission. @JiandiAnNVIDIA, please review and test this BOS backport.

github-actions · 2026-07-06T18:11:53Z

PR Validation Report

Patchscan ✅ No Missing Fixes

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

PR Lint ✅ All checks passed

Details

Checking 7 commits...

Cherry-pick digest:
┌──────────────┬──────────────────────────────────────────────────────────────────┬────────────┬─────────┬───────────────────────────┐
│ Local        │ Referenced upstream / Patch subject                              │ Patch-ID   │ Subject │ SoB chain                 │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ b25396b9f8fe │ [SAUCE] cxl/region: avoid attach action self-deadlock            │ N/A        │ N/A     │ nirmoyd                   │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ fc371e67ebf8 │ [SAUCE] cxl: backport the mainline type-2 memdev lifetime model  │ N/A        │ N/A     │ nirmoyd                   │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ fdcd17096bd3 │ cxl/region: block region delete during region creation           │ noted      │ found   │ ok, backporter: nirmoyd   │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ ddc5989a3af4 │ 574eda81d0a7 cxl/memdev: Hold memdev lock during memdev poison i │ match      │ match   │ preserved + nirmoyd added │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ f2a0894d5f1e │ cxl/pci: check memdev driver binding status in cxl_reset_done()  │ noted      │ found   │ ok, backporter: nirmoyd   │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ b4bc42f3a440 │ dc372e5f429c cxl/pci: Hold memdev lock in cxl_event_trace_record │ match      │ match   │ preserved + nirmoyd added │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ 994b97bce014 │ bb729bf1d6fd driver core: Add conditional guard support for devi │ match      │ match   │ preserved + nirmoyd added │
└──────────────┴──────────────────────────────────────────────────────────────────┴────────────┴─────────┴───────────────────────────┘

Lint: all checks passed.

Introduce conditional guard version of device_lock() for scenarios that require conditional device lock holding. Suggested-by: Dan Williams <dan.j.williams@intel.com> Reviewed-by: Dan Williams <dan.j.williams@intel.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Li Ming <ming.li@zohomail.com> Link: https://patch.msgid.link/20260310-fix_access_endpoint_without_drv_check-v1-1-94fe919a0b87@zohomail.com Signed-off-by: Danilo Krummrich <dakr@kernel.org> (cherry picked from commit bb729bf) Signed-off-by: Nirmoy Das <nirmoyd@nvidia.com>

cxl_event_config() invokes cxl_mem_get_event_record() to get remain event logs from CXL device during cxl_pci_probe(). If CXL memdev probing failed before that, it is possible to access an invalid endpoint. So adding a cxlmd->driver binding status checking inside cxl_dpa_to_region() to ensure the corresponding endpoint is valid. Besides, cxl_event_trace_record() needs to hold memdev lock to invoke cxl_dpa_to_region() to ensure the memdev probing completed. It is possible that cxl_event_trace_record() is invoked during the CXL memdev probing, especially user or cxl_acpi triggers CXL memdev re-probing. Suggested-by: Dan Williams <dan.j.williams@intel.com> Reviewed-by: Dan Williams <dan.j.williams@intel.com> Reviewed-by: Dave Jiang <dave.jiang@intel.com> Signed-off-by: Li Ming <ming.li@zohomail.com> Link: https://patch.msgid.link/20260314-fix_access_endpoint_without_drv_check-v2-3-4c09edf2e1db@zohomail.com Signed-off-by: Dave Jiang <dave.jiang@intel.com> (cherry picked from commit dc372e5) Signed-off-by: Nirmoy Das <nirmoyd@nvidia.com>

cxl_reset_done() accesses the endpoint of the corresponding CXL memdev without endpoint validity checking. By default, cxlmd->endpoint is initialized to -ENXIO, if cxl_reset_done() is triggered after the corresponding CXL memdev probing failed, this results in access to an invalid endpoint. CXL subsystem can always check CXL memdev driver binding status to confirm its endpoint validity. So adding the CXL memdev driver checking inside cxl_reset_done() to avoid accessing an invalid endpoint. Fixes: 934edcd ("cxl: Add post-reset warning if reset results in loss of previously committed HDM decoders") Reviewed-by: Dan Williams <dan.j.williams@intel.com> Reviewed-by: Dave Jiang <dave.jiang@intel.com> Signed-off-by: Li Ming <ming.li@zohomail.com> Link: https://patch.msgid.link/20260314-fix_access_endpoint_without_drv_check-v2-4-4c09edf2e1db@zohomail.com Signed-off-by: Dave Jiang <dave.jiang@intel.com> (backported from https://lore.kernel.org/r/20260314-fix_access_endpoint_without_drv_check-v2-4-4c09edf2e1db@zohomail.com) [nirmoyd: Adapt to the existing BOS NULL/ERR_PTR endpoint guard.] Signed-off-by: Nirmoy Das <nirmoyd@nvidia.com>

cxl_dpa_to_region() assumes that it is running a context where it is not racing changes to "cxlmd->dev.driver". Acquire the memdev device lock in the debugfs entry points to preclude debugfs usage racing cxl_mem driver detach. Suggested-by: Dan Williams <djbw@kernel.org> Reviewed-by: Dave Jiang <dave.jiang@intel.com> Reviewed-by: Alison Schofield <alison.schofield@intel.com> Reviewed-by: Dan Williams <djbw@kernel.org> Signed-off-by: Li Ming <ming.li@zohomail.com> Link: https://patch.msgid.link/20260423111949.177399-1-ming.li@zohomail.com Signed-off-by: Dave Jiang <dave.jiang@intel.com> (cherry picked from commit 574eda8) Signed-off-by: Nirmoy Das <nirmoyd@nvidia.com>

Expand the range lock, rename it "regions_lock", to disable region deletion in the critical period between construct_region() and attach_target(), as well as the period between device_add() and registering the remove actions. Otherwise, userspace can confuse the kernel. It can violate the assumption the region stays registered through the completion of cxl_add_to_region(). It can violate the assumption that devm_add_action_or_reset() is working with a live 'struct cxl_region'. It is ok for the region to disappear outside of those windows as that mirrors device hotplug flows where the proper locks are held. Fixes: a32320b ("cxl/region: Add region autodiscovery") Signed-off-by: Dan Williams <djbw@kernel.org> Reviewed-by: Alejandro Lucero <alucerop@amd.com> Tested-by: ALejandro Lucero <alucerop@amd.com> Reviewed-by: Dave Jiang <dave.jiang@intel.com> Link: https://patch.msgid.link/20260519210158.1499795-2-djbw@kernel.org Signed-off-by: Dave Jiang <dave.jiang@intel.com> (backported from https://lore.kernel.org/r/20260519210158.1499795-2-djbw@kernel.org) [nirmoyd: Extend regions_lock to the downstream cxl_create_region().] Signed-off-by: Nirmoy Das <nirmoyd@nvidia.com>

…model BOS carries a callback-based Type-2 attach API and exported region helpers that are incompatible with the mainline region lifetime model. Applying the mainline deletion-race fixes separately would leave an unsafe intermediate callback lifecycle. Land the dependent transition as one atomic backport. Combine the upstream changes that resolve region deletion races, pin memdev parents for their full lifetime, distinguish class memory devices, introduce devm_cxl_probe_mem(), and support builds without CONFIG_CXL_REGION. Adapt the transition to BOS by migrating both in-tree Type-2 clients, SFC and VFIO, to devm_cxl_probe_mem(). Remove the obsolete public decoder, DPA, HPA, and region helper surface and the callback-based region teardown. The VFIO path now enforces the single firmware-committed decoder contract that its probe path already requires and propagates confirmed-CXL setup failures instead of exposing partially initialized plain VFIO state. Release the SFC CXL mapping while its manually managed probe state is still live, and reject failed VFIO PCI configuration reads before publishing the CXL memdev. Fold in the upstream !CONFIG_CXL_REGION stub so every published prefix remains buildable. Link: https://patch.msgid.link/20260519210158.1499795-3-djbw@kernel.org Link: https://patch.msgid.link/20260519210158.1499795-4-djbw@kernel.org Link: https://patch.msgid.link/20260519210158.1499795-5-djbw@kernel.org Link: https://patch.msgid.link/20260519210158.1499795-6-djbw@kernel.org Link: https://patch.msgid.link/20260610001324.260268-1-dave.jiang@intel.com Signed-off-by: Nirmoy Das <nirmoyd@nvidia.com>

devm_add_action_or_reset() synchronously invokes endpoint_unregister_region() on allocation failure while cxl_memdev_attach_region() still holds cxl_rwsem.region for read. Region teardown then tries to acquire that lock for write and self-deadlocks. Use devm_add_action() and, on failure, leave the region and DPA read-lock scope before invoking endpoint_unregister_region() directly. Keep the endpoint device locked so the topology remains stable while the failed action registration is unwound. Fixes: fc371e6 ("NVIDIA: VR: SAUCE: cxl: Backport the mainline Type-2 memdev lifetime model") Signed-off-by: Nirmoy Das <nirmoyd@nvidia.com>

clsotog · 2026-07-06T21:40:12Z

This commit fc371e6 is like pulling all those links listed at the commit? we can not do a commit for each link maybe for more clarity where the patch came from?
So then the next commit we can update the Fixes with the more clear commit?

Sumit Gupta and others added 30 commits June 18, 2026 20:13

jacobmartin0 and others added 7 commits July 1, 2026 13:51

UBUNTU: link-to-tracker: update tracking bug

29b2c46

BugLink: https://bugs.launchpad.net/bugs/2158813 Properties: no-test-build Signed-off-by: Jacob Martin <jacob.martin@canonical.com>

UBUNTU: [Packaging] debian.nvidia-bos/dkms-versions -- update from ke…

8919d86

…rnel-versions (adhoc/d2026.06.30) BugLink: https://bugs.launchpad.net/bugs/1786013 Signed-off-by: Jacob Martin <jacob.martin@canonical.com>

UBUNTU: Ubuntu-nvidia-bos-7.0.0-2014.14

5a5e4c2

Signed-off-by: Jacob Martin <jacob.martin@canonical.com>

nirmoy mentioned this pull request Jul 6, 2026

[26.04_linux-nvidia-bos] NVIDIA: VR: SAUCE: cxl: guard unlinked memdev endpoints #482

Closed

nirmoy force-pushed the codex/cxl-attach-action-deadlock-fix branch from 89e2944 to 1fd99fe Compare July 6, 2026 18:00

nirmoy changed the title ~~cxl/region: Avoid self-deadlock on attach action allocation failure~~ [26.04_linux-nvidia-bos] cxl: Backport Type-2 memdev lifetime fixes Jul 6, 2026

nirmoy changed the base branch from linux to 26.04_linux-nvidia-bos July 6, 2026 18:01

liming011 and others added 7 commits July 6, 2026 11:12

nirmoy force-pushed the codex/cxl-attach-action-deadlock-fix branch from 1fd99fe to b25396b Compare July 6, 2026 18:15

nvidia-bfigg force-pushed the 26.04_linux-nvidia-bos branch 2 times, most recently from 568a49b to 265816a Compare July 27, 2026 16:36

Navigation Menu

Uh oh!

[26.04_linux-nvidia-bos] cxl: Backport Type-2 memdev lifetime fixes - #483

[26.04_linux-nvidia-bos] cxl: Backport Type-2 memdev lifetime fixes#483
nirmoy wants to merge 457 commits into
NVIDIA:26.04_linux-nvidia-bosfrom
nirmoy:codex/cxl-attach-action-deadlock-fix

nirmoy commented Jul 6, 2026 •

edited

Loading

Uh oh!

nirmoy commented Jul 6, 2026

Uh oh!

nirmoy commented Jul 6, 2026 •

edited

Loading

Uh oh!

jamieNguyenNVIDIA commented Jul 6, 2026

Uh oh!

nirmoy commented Jul 6, 2026

Uh oh!

clsotog commented Jul 6, 2026

Uh oh!

nirmoy commented Jul 6, 2026

Uh oh!

nirmoy commented Jul 6, 2026

Uh oh!

github-actions Bot commented Jul 6, 2026 •

edited

Loading

Uh oh!

clsotog commented Jul 6, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

20 participants

Uh oh!

Conversation

nirmoy commented Jul 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Patch stack

Behavior change

Upstream plan

Current validation

Pending validation

Tracking

Uh oh!

nirmoy commented Jul 6, 2026

Uh oh!

nirmoy commented Jul 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

BaseOS Kernel Review

Summary

Uh oh!

jamieNguyenNVIDIA commented Jul 6, 2026

Uh oh!

nirmoy commented Jul 6, 2026

Uh oh!

clsotog commented Jul 6, 2026

Uh oh!

nirmoy commented Jul 6, 2026

Uh oh!

nirmoy commented Jul 6, 2026

Uh oh!

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

Uh oh!

PR Validation Report

Patchscan ✅ No Missing Fixes

PR Lint ✅ All checks passed

Uh oh!

clsotog commented Jul 6, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

20 participants

nirmoy commented Jul 6, 2026 •

edited

Loading

nirmoy commented Jul 6, 2026 •

edited

Loading

github-actions Bot commented Jul 6, 2026 •

edited

Loading