In preparation for making the kmalloc family of allocators type aware,
we need to make sure that the returned type from the allocation matches
the type of the variable being assigned. (Before, the allocator would
always return "void *", which can be implicitly cast to any pointer type.)
This was allocating many sizeof(struct hlist_head *) when it actually
wanted sizeof(struct hlist_head). Luckily these are the same size.
Adjust the allocation type to match the assignment.
Signed-off-by: Kees Cook <kees@kernel.org>
Reviewed-by: Simon Horman <horms@kernel.org>
Reviewed-by: David Ahern <dsahern@kernel.org>
Reviewed-by: Kuniyuki Iwashima <kuniyu@amazon.com>
Link: https://patch.msgid.link/20250426060529.work.873-kees@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Recently as a side-effect of
commit ac053946f5 ("compiler.h: introduce TYPEOF_UNQUAL() macro")
issues were observed in deduplication between modules and kernel BTF
such that a large number of kernel types were not deduplicated so
were found in module BTF (task_struct, bpf_prog etc). The root cause
appeared to be a failure to dedup struct types, specifically those
with members that were pointers with __percpu annotations.
The issue in dedup is at the point that we are deduplicating structures,
we have not yet deduplicated reference types like pointers. If multiple
copies of a pointer point at the same (deduplicated) integer as in this
case, we do not see them as identical. Special handling already exists
to deal with structures and arrays, so add pointer handling here too.
Reported-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Alan Maguire <alan.maguire@oracle.com>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/bpf/20250429161042.2069678-1-alan.maguire@oracle.com
Restructure L1TF to use select/apply functions to create consistent
vulnerability handling.
Define new AUTO mitigation for L1TF.
Signed-off-by: David Kaplan <david.kaplan@amd.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Reviewed-by: Josh Poimboeuf <jpoimboe@kernel.org>
Link: https://lore.kernel.org/20250418161721.1855190-16-david.kaplan@amd.com
Restructure SSB to use select/apply functions to create consistent
vulnerability handling.
Remove __ssb_select_mitigation() and split the functionality between the
select/apply functions.
Signed-off-by: David Kaplan <david.kaplan@amd.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Reviewed-by: Josh Poimboeuf <jpoimboe@kernel.org>
Link: https://lore.kernel.org/20250418161721.1855190-15-david.kaplan@amd.com
Restructure spectre_v2 to use select/update/apply functions to create
consistent vulnerability handling.
The spectre_v2 mitigation may be updated based on the selected retbleed
mitigation.
Signed-off-by: David Kaplan <david.kaplan@amd.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Reviewed-by: Josh Poimboeuf <jpoimboe@kernel.org>
Link: https://lore.kernel.org/20250418161721.1855190-14-david.kaplan@amd.com
Restructure BHI mitigation to use select/update/apply functions to create
consistent vulnerability handling. BHI mitigation was previously selected
from within spectre_v2_select_mitigation() and now is selected from
cpu_select_mitigation() like with all others.
Define new AUTO mitigation for BHI.
Signed-off-by: David Kaplan <david.kaplan@amd.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Reviewed-by: Josh Poimboeuf <jpoimboe@kernel.org>
Link: https://lore.kernel.org/20250418161721.1855190-13-david.kaplan@amd.com
Restructure spectre_v2_user to use select/update/apply functions to
create consistent vulnerability handling.
The IBPB/STIBP choices are first decided based on the spectre_v2_user
command line but can be modified by the spectre_v2 command line option
as well.
Signed-off-by: David Kaplan <david.kaplan@amd.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Reviewed-by: Josh Poimboeuf <jpoimboe@kernel.org>
Link: https://lore.kernel.org/20250418161721.1855190-12-david.kaplan@amd.com
In mtk_pmic_keys_probe, the regs parameter is only set if the button is
parsed in the device tree. However, on hardware where the button is left
floating, that node will most likely be removed not to enable that
input. In that case the code will try to dereference a null pointer.
Let's use the regs struct instead as it is defined for all supported
platforms. Note that it is ok setting the key reg even if that latter is
disabled as the interrupt won't be enabled anyway.
Fixes: b581acb49a ("Input: mtk-pmic-keys - transfer per-key bit in mtk_pmic_keys_regs")
Signed-off-by: Gary Bisson <bisson.gary@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Adjust the size of 8kB GIC regions to 128kB so that each 4kB is mapped 16
times over a 64kB region.
The offset is then adjusted in the irq-gic driver.
see commit 12e14066f4 ("irqchip/GIC: Add workaround for aliased GIC400")
Fixes: e9b03ef213 ("arm64: dts: st: introduce stm32mp23 SoCs family")
Suggested-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Christian Bruel <christian.bruel@foss.st.com>
Link: https://lore.kernel.org/r/20250415111654.2103767-7-christian.bruel@foss.st.com
Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Adjust the size of 8kB GIC regions to 128kB so that each 4kB is mapped
16 times over a 64kB region.
The offset is then adjusted in the irq-gic driver.
see commit 12e14066f4 ("irqchip/GIC: Add workaround for aliased GIC400")
Fixes: 7a57b1bb1a ("arm64: dts: st: introduce stm32mp21 SoCs family")
Suggested-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Christian Bruel <christian.bruel@foss.st.com>
Link: https://lore.kernel.org/r/20250415111654.2103767-5-christian.bruel@foss.st.com
Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Adjust the size of 8kB GIC regions to 128kB so that each 4kB is mapped 16
times over a 64kB region.
The offset is then adjusted in the irq-gic driver.
see commit 12e14066f4 ("irqchip/GIC: Add workaround for aliased GIC400")
Fixes: 5d30d03aaf ("arm64: dts: st: introduce stm32mp25 SoCs family")
Suggested-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Christian Bruel <christian.bruel@foss.st.com>
Acked-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20250415111654.2103767-3-christian.bruel@foss.st.com
Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
- An i.MX8MP change from Ahmad Fatoum to fix the broken nominal device
tree caused by commit 9f7595b3e5 ("arm64: dts: imx8mp: configure
GPU and NPU clocks to overdrive rate")
- A MAINTAINERS update from Michael Riesch to exclude Sony IMX image
sensor drivers from i.MX entry
- A i.MX95 device tree change from Richard Zhu to correct the range of
PCIe app-reg region
- An opos6ul device tree change from Sébastien Szymanski to fix
an Ethernet regression caused by commit c7e73b5051 ("ARM: imx:
mach-imx6ul: remove 14x14 EVK specific PHY fixup")
- An imx8mm-verdin device tree change from Wojciech Dubowik to fix
a SD card regression caused by commit f5aab0438e ("regulator:
pca9450: Fix enable register for LDO5")
-----BEGIN PGP SIGNATURE-----
iQFIBAABCgAyFiEEFmJXigPl4LoGSz08UFdYWoewfM4FAmgPPxkUHHNoYXduZ3Vv
QGtlcm5lbC5vcmcACgkQUFdYWoewfM50Twf9Eyj8zsNr7RPTPxJmo/tfWPHKGyRF
9l3oKgCYtdO8E0zck/aR/XgYkRY3Y3JdP7Mh4SKmw7mCb6+PHL9UnN72bxPKUuIj
FrvguIjuf8d9iYdQvfncGUv0IZE95M0BBcP9TjKELf4l4N7floZAc32YVItzCQx1
ZKGLnSAD133YR4j1CbAenxBogoiczN628iuklYqTzJm2B7sJBvwrXSa5BKZruFdC
jjtpKamPPb6I1aMqTkgz2Ofbk4KuauAcK1ixgvIAelJXrXngmPcIf+L2rOU0gCZv
XsyVUT2FwFIeHo9aQmQxxZr5v+xFmrRrbTxXZqvmcWMrUWruHm82A2wN9Q==
=YGnN
-----END PGP SIGNATURE-----
Merge tag 'imx-fixes-6.15' of https://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into arm/fixes
i.MX fixes for 6.15:
- An i.MX8MP change from Ahmad Fatoum to fix the broken nominal device
tree caused by commit 9f7595b3e5 ("arm64: dts: imx8mp: configure
GPU and NPU clocks to overdrive rate")
- A MAINTAINERS update from Michael Riesch to exclude Sony IMX image
sensor drivers from i.MX entry
- A i.MX95 device tree change from Richard Zhu to correct the range of
PCIe app-reg region
- An opos6ul device tree change from Sébastien Szymanski to fix
an Ethernet regression caused by commit c7e73b5051 ("ARM: imx:
mach-imx6ul: remove 14x14 EVK specific PHY fixup")
- An imx8mm-verdin device tree change from Wojciech Dubowik to fix
a SD card regression caused by commit f5aab0438e ("regulator:
pca9450: Fix enable register for LDO5")
* tag 'imx-fixes-6.15' of https://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux:
arm64: dts: imx8mm-verdin: Link reg_usdhc2_vqmmc to usdhc2
MAINTAINERS: add exclude for dt-bindings to imx entry
ARM: dts: opos6ul: add ksz8081 phy properties
arm64: dts: imx95: Correct the range of PCIe app-reg region
arm64: dts: imx8mp: configure GPU and NPU clocks in nominal DTSI
Just a single fix addressing the cache node inconsistencies. It removed
unnecessary CPU number from L2 cache node names since they are local to
CPU nodes and should simply be named "l2-cache" and relocates the shared
L3 cache node from under cpu@0/l2-cache to the /cpus node, which is the
standard location for shared caches.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEunHlEgbzHrJD3ZPhAEG6vDF+4pgFAmf3wzcACgkQAEG6vDF+
4piBUA/9GkJ4bwDnROaiucfVCK63xArxLEDpC9GE2TccLBS/uSCp9cSmJzPrsiXN
gKUOSaBMH8RbhQt0YJl06/MJTdhrI3yu64gGfvLDf0zPMyEXmbRSeU2ZSwVxVHLM
vzUwKQW2nw2yx/6DGm7GWL5iH8s+ib23H/2T5oTkKJEhpZ/ZdmLUV1OdL4Xx7euR
ZKlFZ4oNFPfDEknv+n1TXQPgne6OappM6Pn5ZQ/CUU5jjPmOChL2oFjKTdNrXUzA
xdKBWDZeiobrHf7jt7603pQWQX1ae/0wNpQVWkqxo4HbWRShwIeKgvAkvUy2hfx3
DAxJxtoAJX+xdNR0+2K49TG94Bwaj10q/Ft94TDL7cdhYfAT8NnJ+N0CVrP8zQ6/
s9s5ejTD5ntBWriKLJobx9CW/p+W4o3eNmxDNQQK0n4HY2ZPf9DI1V/r/p+hUc3R
EhsUe5dv+5o6qmdZidxm5KJsgBJDmNoGzf/GZawcIOgoQYIh64yXxb2FRTKd90hf
1irElg1QByWWNkhnsQ179qaLb8TMsIDkDHNVClrTGxs/YkURtJE8UcxHoWCg40/u
Soa31RIGPoftgDxqMxMMut4WuEOcohLhEk3KWmgF7U/wsH+FL9yeZuWi+FgB2n2T
H5EV02VhlGg7z40b4xa0muvuEXw7VgbQ3O/Bs1qlZQQlM283sUQ=
=QUJb
-----END PGP SIGNATURE-----
Merge tag 'juno-fix-6.15' of https://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into arm/fixes
Armv8 Morello fix for v6.15
Just a single fix addressing the cache node inconsistencies. It removed
unnecessary CPU number from L2 cache node names since they are local to
CPU nodes and should simply be named "l2-cache" and relocates the shared
L3 cache node from under cpu@0/l2-cache to the /cpus node, which is the
standard location for shared caches.
* tag 'juno-fix-6.15' of https://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux:
arm64: dts: morello: Fix-up cache nodes
A fix that addresses incorrect release of Rx buffer ownership in the
driver. The fix specificially avoids releasing Rx buffer ownership with
FFA_RX_RELEASE if it wasn’t acquired during a FFA_PARTITION_INFO_GET call
that only requested the partition count. This prevents unnecessary errors
like FFA_RET_DENIED from firmware when buffers are not actually owned by
the driver.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEunHlEgbzHrJD3ZPhAEG6vDF+4pgFAmf3xDIACgkQAEG6vDF+
4ph+YRAAu+EXYDSopYHSjmFQ+pY7KUncSE4sG2MPJL06jPO6ldaQ71amQkxm7bW3
KyqXaMBX1mlyHH6RSIY1/cIM3D0a3ubfbS6pjVpz9z5ZteNyYob5MGtE7eho6Swa
pVa/OuNEfF6lXKb8O1eY1xHWGTs/573bVnvqfqKtZnIjNiYAo+pHJzEv+m53U9oF
l0HoaSC6BNgPnVtFdd0z6fCOcCjw9DCluo5j9cvdMGsG6pG+F3mn4iT+7P6uvcFl
XFhuO15+uItbRbZ1QZynZklCa1u99wMCo/+N0FpZiStqC22X6IpAs8FiaqaGpiBY
27znwncqyW3U2lwl0ZYWdMKjlvzUoaZroM7pwu9Kcjtlvb4gF0MzJWSfWTRAMSbK
tAeqQb5zvkiogoDLp3HfQTf+xpqvU6Qn90jpzkawhmyFgcAzR3xHuHX1t2VHY6ye
SfydmOvcz48sS+BxHl3/T2p6zGximT3oZ8gO9uSe0IvRgw2ZJE1RZzoSCJrZTDF0
+ktjDJtMembjSzuNpmOXdGjk2PCWQT/7bmjKe1tg2v2qvD+MEXMiryahQoeovgME
FJR9VvOlL4JVN3ouE5wppqey6ViZmt+bu6Pg3Y6/oNQNt9gJvB7yqODGPHwfEo8r
Z4y9EoDr6qy7r03ihLEa84KMh/LBBCj3dF4SJRWxT/GVJm5K2q4=
=e5sa
-----END PGP SIGNATURE-----
Merge tag 'ffa-fix-6.15' of https://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into arm/fixes
Arm FF-A fix for v6.15
A fix that addresses incorrect release of Rx buffer ownership in the
driver. The fix specificially avoids releasing Rx buffer ownership with
FFA_RX_RELEASE if it wasn’t acquired during a FFA_PARTITION_INFO_GET call
that only requested the partition count. This prevents unnecessary errors
like FFA_RET_DENIED from firmware when buffers are not actually owned by
the driver.
* tag 'ffa-fix-6.15' of https://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux:
firmware: arm_ffa: Skip Rx buffer ownership release if not acquired
Couple of fixes addressing issues with timeout in the polling path
and device reference count imbalance detected by kmemleak.
1. The change fixes a timeout issue in the polling path of SCMI transactions
where false positives could occur if the polling thread was pre-empted,
causing it to appear as though a timeout occurred when it hadn't. The fix
ensures that the polling result is verified before reporting a timeout,
accounting for potential pre-emption or out-of-order replies.
2. It also corrects a device reference count imbalance caused by
device_find_child() during device destruction, which prevented proper
cleanup and triggered memory leaks detected by KMemleak.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEunHlEgbzHrJD3ZPhAEG6vDF+4pgFAmf3xWIACgkQAEG6vDF+
4pjBlQ/9GMfp/FSSVLoUOqUypjkV0U6if1hLHWmqS0EaSi+2eA1oeFms91/KJm5x
s3KHH/YOcdwn7Xej+CJNugTdvp44nUAkkgq0FNoIkSliHznpWJutIH9C0uDe1pLI
wdIHrwXbsvtW4jK0uSL8ZOZWVDpMV3fFjJX+HZqlP7mQTUIo0lh7oIn02X0vrmYE
tNZGYBH2SOv0SPqcI1rcRj5VzroRk6eOK81MJMqWRzkfjDRkTRRaigPojZKHlHaL
jHGYBualK7Qz8rExVtrJ1EaraBQsxXBixYQct0pck7bDQrUlUwZjLr75Jc1aCHnI
fXmkS8nvuLnuXOJ/BWxdqS5cLlP8vycBYfOcOd0Say6VVrhBp38lpbunZWKsq9rX
LgnBWqEUouOvYM+p923xsISj1r0SZu0y+jfummDGandHFzH9zEi+mwEnylQuFROz
1MPtZ6qSstxRXBdqaszoNlTiXIb26LPA5ywomLDln/SLgsYgTIQErqTH7w8yauQq
zPW0I1NQL/+goIa9q12Qc4lu2hQotYpoPBJK2oTgTf7fKlCgjukrFX7Q+vIstNfd
IEOSskgDeCJ8Rc81ZBPb7fhxKY4RzIsgtoplFRNjAIUOE4dZvYD47k7e2+jMVemT
YUWSP3ILSSBBGjJNv6TRIaMj11e2SsR4wc9eF4giHxRTrrTEXTA=
=JEKv
-----END PGP SIGNATURE-----
Merge tag 'scmi-fixes-6.15' of https://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into arm/fixes
Arm SCMI fixes for v6.15
Couple of fixes addressing issues with timeout in the polling path
and device reference count imbalance detected by kmemleak.
1. The change fixes a timeout issue in the polling path of SCMI transactions
where false positives could occur if the polling thread was pre-empted,
causing it to appear as though a timeout occurred when it hadn't. The fix
ensures that the polling result is verified before reporting a timeout,
accounting for potential pre-emption or out-of-order replies.
2. It also corrects a device reference count imbalance caused by
device_find_child() during device destruction, which prevented proper
cleanup and triggered memory leaks detected by KMemleak.
* tag 'scmi-fixes-6.15' of https://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux:
firmware: arm_scmi: Fix timeout checks on polling path
firmware: arm_scmi: Balance device refcount when destroying devices
Commit a3707f53eb ("drm/panthor: show device-wide list of DRM GEM
objects over DebugFS") causes a build warning and linking error when
built without support for DebugFS, because of a non-inline non-static
function declaration in a header file.
On top of that, the function is only being used inside a single
compilation unit, so there is no point in exposing it as a global
symbol.
This is a follow-up from Arnd Bergmann's first fix.
Also move panthor_gem_debugfs_set_usage_flags() into panthor_gem.c and
declare it static.
Fixes: a3707f53eb ("drm/panthor: show device-wide list of DRM GEM objects over DebugFS")
Reported-by: Arnd Bergmann <arnd@arndb.de>
Closes: https://lore.kernel.org/dri-devel/20250424142419.47b9d457@collabora.com/T/#t
Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com>
Reviewed-by: Steven Price <steven.price@arm.com>
Reviewed-by: Liviu Dudau <liviu.dudau@arm.com>
Link: https://lore.kernel.org/r/20250424184041.356191-1-adrian.larumbe@collabora.com
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Both SVM and VMX have similar implementation for executing an IBPB
between running different vCPUs on the same CPU to create separate
prediction domains for different vCPUs.
For VMX, when the currently loaded VMCS is changed in
vmx_vcpu_load_vmcs(), an IBPB is executed if there is no 'buddy', which
is the case on vCPU load. The intention is to execute an IBPB when
switching vCPUs, but not when switching the VMCS within the same vCPU.
Executing an IBPB on nested transitions within the same vCPU is handled
separately and conditionally in nested_vmx_vmexit().
For SVM, the current VMCB is tracked on vCPU load and an IBPB is
executed when it is changed. The intention is also to execute an IBPB
when switching vCPUs, although it is possible that in some cases an IBBP
is executed when switching VMCBs for the same vCPU. Executing an IBPB on
nested transitions should be handled separately, and is proposed at [1].
Unify the logic by tracking the last loaded vCPU and execuintg the IBPB
on vCPU change in kvm_arch_vcpu_load() instead. When a vCPU is
destroyed, make sure all references to it are removed from any CPU. This
is similar to how SVM clears the current_vmcb tracking on vCPU
destruction. Remove the current VMCB tracking in SVM as it is no longer
required, as well as the 'buddy' parameter to vmx_vcpu_load_vmcs().
[1] https://lore.kernel.org/lkml/20250221163352.3818347-4-yosry.ahmed@linux.dev
Link: https://lore.kernel.org/all/20250320013759.3965869-1-yosry.ahmed@linux.dev
Signed-off-by: Yosry Ahmed <yosry.ahmed@linux.dev>
[sean: tweak comment to stay at/under 80 columns]
Signed-off-by: Sean Christopherson <seanjc@google.com>
When freeing a vCPU and thus its VMCB, clear current_vmcb for all possible
CPUs, not just online CPUs, as it's theoretically possible a CPU could go
offline and come back online in conjunction with KVM reusing the page for
a new VMCB.
Link: https://lore.kernel.org/all/20250320013759.3965869-1-yosry.ahmed@linux.dev
Fixes: fd65d3142f ("kvm: svm: Ensure an IBPB on all affected CPUs when freeing a vmcb")
Cc: stable@vger.kernel.org
Cc: Jim Mattson <jmattson@google.com>
Signed-off-by: Yosry Ahmed <yosry.ahmed@linux.dev>
[sean: split to separate patch, write changelog]
Signed-off-by: Sean Christopherson <seanjc@google.com>
On r6x2b6x2g6x2 displays not enough blank data is sent to blank the
entire screen. When support for these displays was added, the dirty
function was updated to handle the different amount of data, but
blanking was not, and remained hardcoded as 2 bytes per pixel.
This change applies almost the same algorithm used in the dirty function
to the blank function, but there is no fb available at that point, and
no concern about having to transform any data, so the dbidev pixel
format is always used for calculating the length.
Fixes: 4aebb79021 ("drm/mipi-dbi: Add support for DRM_FORMAT_RGB888")
Signed-off-by: Russell Cloran <rcloran@gmail.com>
Link: https://lore.kernel.org/r/20250415053259.79572-1-rcloran@gmail.com
Signed-off-by: Maxime Ripard <mripard@kernel.org>
The drm_gem_shmem_test_get_pages_sgt() gets a scatter-gather table using
the drm_gem_shmem_get_sg_table() function and rightfully calls
sg_free_table() on it. However, it's also supposed to kfree() the
returned sg_table, but doesn't.
This leads to a memory leak, reported by kmemleak. Fix it by adding a
kunit action to kfree the sgt when the test ends.
Reported-by: Philipp Stanner <phasta@mailbox.org>
Closes: https://lore.kernel.org/dri-devel/a7655158a6367ac46194d57f4b7433ef0772a73e.camel@mailbox.org/
Fixes: 93032ae634 ("drm/test: add a test suite for GEM objects backed by shmem")
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://lore.kernel.org/r/20250408140758.1831333-1-mripard@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
In some cases when calling function add_probe_vfs_getname, line number
can't be detected by 'perf probe -L getname_flags':
78 atomic_set(&result->refcnt, 1);
// one of the following lines should have line number
// but sometimes it does not because of optimization
result->uptr = filename;
result->aname = NULL;
81 audit_getname(result);
To prevent false failures, skip the affected tests if no suitable line
numbers can be detected.
Signed-off-by: Jakub Brnak <jbrnak@redhat.com>
Acked-by: Namhyung Kim <namhyung@kernel.org>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Ian Rogers <irogers@google.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Kan Liang <kan.liang@linux.intel.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Michael Petlan <mpetlan@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Tomas Glozar <tglozar@redhat.com>
Link: https://lore.kernel.org/r/20250324144523.597557-1-jbrnak@redhat.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
arm64 uses apply_to_page_range to change permissions for kernel vmalloc mappings,
which does not support changing permissions for block mappings. This function
will change permissions until it encounters a block mapping, and will bail
out with a warning. Since there are no reports of this triggering, it
implies that there are currently no cases of code doing a vmalloc_huge()
followed by partial permission change. But this is a footgun waiting to
go off, so let's detect it early and avoid the possibility of permissions
in an intermediate state. So, explicitly disallow changing permissions
for VM_ALLOW_HUGE_VMAP mappings.
Reviewed-by: Ryan Roberts <ryan.roberts@arm.com>
Reviewed-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
Signed-off-by: Dev Jain <dev.jain@arm.com>
Acked-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Gavin Shan <gshan@redhat.com>
Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
Link: https://lore.kernel.org/r/20250403052844.61818-1-dev.jain@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
Log size in addition to physical and virtual addresses. It has potential
to be helpful when DTB exceeds the 2 MB limit.
Initialize size to 0 to print out sane value if fixmap_remap_fdt fails
without setting the size.
Signed-off-by: Bartosz Szczepanek <bsz@amazon.de>
Link: https://lore.kernel.org/r/20250423084851.26449-1-bsz@amazon.de
Signed-off-by: Will Deacon <will@kernel.org>
The struct zone is embedded in struct pglist_data which can be allocated
for each NUMA node early in the boot process. As it's not a slab object
nor a global lock, this was not symbolized.
Since the zone->lock is often contended, it'd be nice if we can
symbolize it. On NUMA systems, node_data array will have pointers for
struct pglist_data. By following the pointer, it can calculate the
address of each zone and its lock using BTF. On UMA, it can just use
contig_page_data and its zones.
The following example shows the zone lock contention at the end.
$ sudo ./perf lock con -abl -E 5 -- ./perf bench sched messaging
# Running 'sched/messaging' benchmark:
# 20 sender and receiver processes per group
# 10 groups == 400 processes run
Total time: 0.038 [sec]
contended total wait max wait avg wait address symbol
5167 18.17 ms 10.27 us 3.52 us ffff953340052d00 &kmem_cache_node (spinlock)
38 11.75 ms 465.49 us 309.13 us ffff95334060c480 &sock_inode_cache (spinlock)
3916 10.13 ms 10.43 us 2.59 us ffff953342aecb40 &kmem_cache_node (spinlock)
2963 10.02 ms 13.75 us 3.38 us ffff9533d2344098 &kmalloc-rnd-08-2k (spinlock)
216 5.05 ms 99.49 us 23.39 us ffff9542bf7d65d0 zone_lock (spinlock)
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Ian Rogers <irogers@google.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Kan Liang <kan.liang@linux.intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Song Liu <song@kernel.org>
Cc: Stephane Eranian <eranian@google.com>
Cc: bpf@vger.kernel.org
Cc: linux-mm@kvack.org
Link: https://lore.kernel.org/r/20250401063055.7431-1-namhyung@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
The selection of CRC32 by ARM64 was added by commit 7481cddf29
("arm64/lib: add accelerated crc32 routines") as a workaround for the
fact that, at the time, the CRC32 library functions used weak symbols to
allow architecture-specific overrides. That only worked when CRC32 was
built-in, and thus ARM64 was made to just force CRC32 to built-in.
Now that the CRC32 library no longer uses weak symbols, that no longer
applies. And the selection does not fulfill a user dependency either;
those all have their own selections from other options. Therefore, the
selection of CRC32 by ARM64 is no longer necessary. Remove it.
Note that this does not necessarily result in CRC32 no longer being set
to y, as it still tends to get selected by something else anyway.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Link: https://lore.kernel.org/r/20250414174018.6359-1-ebiggers@kernel.org
Signed-off-by: Will Deacon <will@kernel.org>
Doing:
#include <linux/mem_encrypt.h>
Causes a bunch of compiler failures due to missing implicit includes that
don't happen on x86:
../arch/arm64/include/asm/rsi_cmds.h:117:2: error: call to undeclared library function 'memcpy' with type 'void *(void *, const void *, unsigned long)'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
117 | memcpy(®s.a1, challenge, size);
../arch/arm64/include/asm/mem_encrypt.h:19:49: warning: declaration of 'struct device' will not be visible outside of this function [-Wvisibility]
19 | static inline bool force_dma_unencrypted(struct device *dev)
../arch/arm64/include/asm/rsi_cmds.h:44:38: error: call to undeclared function 'virt_to_phys'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
44 | arm_smccc_smc(SMC_RSI_REALM_CONFIG, virt_to_phys(cfg),
Add the missing includes to the arch/arm headers to avoid this.
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Link: https://lore.kernel.org/r/0-v1-47aadfbd64cd+25795-arm_memenc_h_jgg@nvidia.com
Signed-off-by: Will Deacon <will@kernel.org>
When the 52-bit virtual addressing was introduced the select like
ARCH_MMAP_RND_BITS_MAX logic was never updated to account for it.
Because of that the rnd max bits knob is set to the default value of 18
when ARM64_VA_BITS=52.
Fix this by setting ARCH_MMAP_RND_BITS_MAX to the same value that would
be used if 48-bit addressing was used. Higher values can't used here
because 52-bit addressing is used only if the caller provides a hint to
mmap, with a fallback to 48-bit. The knob in question is an upper bound
for what the user can set in /proc/sys/vm/mmap_rnd_bits, which in turn
is used to determine how many random bits can be inserted into the base
address used for mmap allocations. Since 48-bit allocations are legal
with ARM64_VA_BITS=52, we need to make sure that the base address is
small enough to facilitate this.
Fixes: b6d00d47e8 ("arm64: mm: Introduce 52-bit Kernel VAs")
Signed-off-by: Kornel Dulęba <korneld@google.com>
Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
Link: https://lore.kernel.org/r/20250417114754.3238273-1-korneld@google.com
Signed-off-by: Will Deacon <will@kernel.org>
amd_hsmp and hsmp_acpi are intended to be mutually exclusive drivers and
amd_hsmp is for legacy platforms. To achieve this, it is essential to
check for the presence of the ACPI device in plat.c. If the hsmp ACPI
device entry is found, allow the hsmp_acpi driver to manage the hsmp
and return an error from plat.c.
Additionally, rename the driver from amd_hsmp to hsmp_acpi to prevent
"Driver 'amd_hsmp' is already registered, aborting..." error in case
both drivers are loaded simultaneously.
Also, support both platform device based and ACPI based probing for
family 0x1A models 0x00 to 0x0F, implement only ACPI based probing
for family 0x1A, models 0x10 to 0x1F. Return false from
legacy_hsmp_support() for this platform.
This aligns with the condition check in is_f1a_m0h().
Link: https://lore.kernel.org/platform-driver-x86/aALZxvHWmphNL1wa@gourry-fedora-PF4VCD3F/
Fixes: 7d3135d163 ("platform/x86/amd/hsmp: Create separate ACPI, plat and common drivers")
Reviewed-by: Naveen Krishna Chatradhi <naveenkrishna.chatradhi@amd.com>
Co-developed-by: Gregory Price <gourry@gourry.net>
Signed-off-by: Gregory Price <gourry@gourry.net>
Signed-off-by: Suma Hegde <suma.hegde@amd.com>
Link: https://lore.kernel.org/r/20250425102357.266790-1-suma.hegde@amd.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
commit 376a8c2a14 ("platform/x86/amd/pmf: Update PMF Driver for
Compatibility with new PMF-TA") added support for platforms that support
an updated TA, however it also exposed a number of platforms that although
they have support for the updated TA don't actually populate a policy
binary.
Add an explicit check that the policy binary isn't empty before
initializing the TA.
Reported-by: Christian Heusel <christian@heusel.eu>
Closes: https://lore.kernel.org/platform-driver-x86/ae644428-5bf2-4b30-81ba-0b259ed3449b@heusel.eu/
Fixes: 376a8c2a14 ("platform/x86/amd/pmf: Update PMF Driver for Compatibility with new PMF-TA")
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Tested-by: Christian Heusel <christian@heusel.eu>
Link: https://lore.kernel.org/r/20250423132002.3984997-3-superm1@kernel.org
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
If a policy is passed into amd_pmf_get_pb_data() that causes the engine
to fail to start there is a memory leak. Free the memory in this failure
path.
Fixes: 10817f28e5 ("platform/x86/amd/pmf: Add capability to sideload of policy binary")
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Link: https://lore.kernel.org/r/20250423132002.3984997-2-superm1@kernel.org
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Willem de Bruijn says:
====================
ip: improve tcp sock multipath routing
From: Willem de Bruijn <willemb@google.com>
Improve layer 4 multipath hash policy for local tcp connections:
patch 1: Select a source address that matches the nexthop device.
Due to tcp_v4_connect making separate route lookups for saddr
and route, the two can currently be inconsistent.
patch 2: Use all paths when opening multiple local tcp connections to
the same ip address and port.
patch 3: Test the behavior. Extend the fib_tests.sh testsuite with one
opening many connections, and count SYNs on both egress
devices, for packets matching the source address of the dev.
Changelog in the individual patches
====================
Link: https://patch.msgid.link/20250424143549.669426-1-willemdebruijn.kernel@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Verify that TCP connections use both routes when connecting multiple
times to a remote service over a two nexthop multipath route.
Use socat to create the connections. Use tc prio + tc filter to
count routes taken, counting SYN packets across the two egress
devices. Also verify that the saddr matches that of the device.
To avoid flaky tests when testing inherently randomized behavior,
set a low bar and pass if even a single SYN is observed on each
device.
Signed-off-by: Willem de Bruijn <willemb@google.com>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Tested-by: Ido Schimmel <idosch@nvidia.com>
Link: https://patch.msgid.link/20250424143549.669426-4-willemdebruijn.kernel@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Load balance new TCP connections across nexthops also when they
connect to the same service at a single remote address and port.
This affects only port-based multipath hashing:
fib_multipath_hash_policy 1 or 3.
Local connections must choose both a source address and port when
connecting to a remote service, in ip_route_connect. This
"chicken-and-egg problem" (commit 2d7192d6cb ("ipv4: Sanitize and
simplify ip_route_{connect,newports}()")) is resolved by first
selecting a source address, by looking up a route using the zero
wildcard source port and address.
As a result multiple connections to the same destination address and
port have no entropy in fib_multipath_hash.
This is not a problem when forwarding, as skb-based hashing has a
4-tuple. Nor when establishing UDP connections, as autobind there
selects a port before reaching ip_route_connect.
Load balance also TCP, by using a random port in fib_multipath_hash.
Port assignment in inet_hash_connect is not atomic with
ip_route_connect. Thus ports are unpredictable, effectively random.
Implementation details:
Do not actually pass a random fl4_sport, as that affects not only
hashing, but routing more broadly, and can match a source port based
policy route, which existing wildcard port 0 will not. Instead,
define a new wildcard flowi flag that is used only for hashing.
Selecting a random source is equivalent to just selecting a random
hash entirely. But for code clarity, follow the normal 4-tuple hash
process and only update this field.
fib_multipath_hash can be reached with zero sport from other code
paths, so explicitly pass this flowi flag, rather than trying to infer
this case in the function itself.
Signed-off-by: Willem de Bruijn <willemb@google.com>
Reviewed-by: David Ahern <dsahern@kernel.org>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Link: https://patch.msgid.link/20250424143549.669426-3-willemdebruijn.kernel@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
With multipath routes, try to ensure that packets leave on the device
that is associated with the source address.
Avoid the following tcpdump example:
veth0 Out IP 10.1.0.2.38640 > 10.2.0.3.8000: Flags [S]
veth1 Out IP 10.1.0.2.38648 > 10.2.0.3.8000: Flags [S]
Which can happen easily with the most straightforward setup:
ip addr add 10.0.0.1/24 dev veth0
ip addr add 10.1.0.1/24 dev veth1
ip route add 10.2.0.3 nexthop via 10.0.0.2 dev veth0 \
nexthop via 10.1.0.2 dev veth1
This is apparently considered WAI, based on the comment in
ip_route_output_key_hash_rcu:
* 2. Moreover, we are allowed to send packets with saddr
* of another iface. --ANK
It may be ok for some uses of multipath, but not all. For instance,
when using two ISPs, a router may drop packets with unknown source.
The behavior occurs because tcp_v4_connect makes three route
lookups when establishing a connection:
1. ip_route_connect calls to select a source address, with saddr zero.
2. ip_route_connect calls again now that saddr and daddr are known.
3. ip_route_newports calls again after a source port is also chosen.
With a route with multiple nexthops, each lookup may make a different
choice depending on available entropy to fib_select_multipath. So it
is possible for 1 to select the saddr from the first entry, but 3 to
select the second entry. Leading to the above situation.
Address this by preferring a match that matches the flowi4 saddr. This
will make 2 and 3 make the same choice as 1. Continue to update the
backup choice until a choice that matches saddr is found.
Do this in fib_select_multipath itself, rather than passing an fl4_oif
constraint, to avoid changing non-multipath route selection. Commit
e6b45241c5 ("ipv4: reset flowi parameters on route connect") shows
how that may cause regressions.
Also read ipv4.sysctl_fib_multipath_use_neigh only once. No need to
refresh in the loop.
This does not happen in IPv6, which performs only one lookup.
Signed-off-by: Willem de Bruijn <willemb@google.com>
Reviewed-by: David Ahern <dsahern@kernel.org>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Link: https://patch.msgid.link/20250424143549.669426-2-willemdebruijn.kernel@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Following the convention, convert intel_hdmi.c to use an intel_connector
pointer everywhere, calling this pointer connector. If the intel
connector must be casted from a drm_connector, call this pointer
_connector and use this pointer only for the casting.
v2: Use for_each_new_intel_connector_in_state(). (Jani)
Cc: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://lore.kernel.org/r/20250428134716.3396802-3-imre.deak@intel.com
Following the convention, convert intel_dp.c to use an intel_connector
pointer everywhere, calling this pointer connector. If the intel
connector must be casted from a drm_connector, call this pointer
_connector and use this pointer only for the casting.
v2: Use for_each_intel_connector_iter(). (Jani)
Cc: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://lore.kernel.org/r/20250428134716.3396802-2-imre.deak@intel.com
Add a new section for all of the time stuff to MAINTAINERS file, with
the existing hrtimer entry fold.
Acked-by: John Stultz <jstultz@google.com>
Reviewed-by: Boqun Feng <boqun.feng@gmail.com>
Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org>
Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com>
Link: https://lore.kernel.org/r/20250423192857.199712-7-fujita.tomonori@gmail.com
[ Changed T: entry branch to `timekeeping-next` - Andreas ]
Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
Introduce a type representing a specific point in time. We could use
the Ktime type but C's ktime_t is used for both timestamp and
timedelta. To avoid confusion, introduce a new Instant type for
timestamp.
Rename Ktime to Instant and modify their methods for timestamp.
Implement the subtraction operator for Instant:
Delta = Instant A - Instant B
Reviewed-by: Boqun Feng <boqun.feng@gmail.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Fiona Behrens <me@kloenk.dev>
Tested-by: Daniel Almeida <daniel.almeida@collabora.com>
Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org>
Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com>
Link: https://lore.kernel.org/r/20250423192857.199712-5-fujita.tomonori@gmail.com
Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
Introduce a type representing a span of time. Define our own type
because `core::time::Duration` is large and could panic during
creation.
time::Ktime could be also used for time duration but timestamp and
timedelta are different so better to use a new type.
i64 is used instead of u64 to represent a span of time; some C drivers
uses negative Deltas and i64 is more compatible with Ktime using i64
too (e.g., ktime_[us|ms]_delta() APIs return i64 so we create Delta
object without type conversion.
i64 is used instead of bindings::ktime_t because when the ktime_t
type is used as timestamp, it represents values from 0 to
KTIME_MAX, which is different from Delta.
as_millis() method isn't used in this patchset. It's planned to be
used in Binder driver.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Fiona Behrens <me@kloenk.dev>
Tested-by: Daniel Almeida <daniel.almeida@collabora.com>
Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org>
Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com>
Link: https://lore.kernel.org/r/20250423192857.199712-4-fujita.tomonori@gmail.com
Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
Add PartialEq/Eq/PartialOrd/Ord trait to Ktime so two Ktime instances
can be compared to determine whether a timeout is met or not.
Use the derive implements; we directly touch C's ktime_t rather than
using the C's accessors because it is more efficient and we already do
in the existing code (Ktime::sub).
Reviewed-by: Trevor Gross <tmgross@umich.edu>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Fiona Behrens <me@kloenk.dev>
Tested-by: Daniel Almeida <daniel.almeida@collabora.com>
Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org>
Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com>
Link: https://lore.kernel.org/r/20250423192857.199712-3-fujita.tomonori@gmail.com
Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
Add Ktime temporarily until hrtimer is refactored to use Instant and
Delta types.
Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org>
Reviewed-by: Boqun Feng <boqun.feng@gmail.com>
Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com>
Link: https://lore.kernel.org/r/20250423192857.199712-2-fujita.tomonori@gmail.com
Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
The appletbdrm driver is exclusively for Touch Bars on x86 Intel Macs.
The M1 Macs have a separate driver. So, lets avoid compiling it for
other architectures.
Signed-off-by: Aditya Garg <gargaditya08@live.com>
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Link: https://lore.kernel.org/r/PN3PR01MB95970778982F28E4A3751392B8B72@PN3PR01MB9597.INDPRD01.PROD.OUTLOOK.COM
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
The generic FourCC format always prints the data using the big endian
order. It is generic because it allows to read the data using a custom
ordering.
The current code uses "n" for reading data in the reverse host ordering.
It makes the 4 variants [hnbl] consistent with the generic printing
of IPv4 addresses.
Unfortunately, it creates confusion on big endian systems. For example,
it shows the data &(u32)0x67503030 as
%p4cn 00Pg (0x30305067)
But people expect that the ordering stays the same. The network ordering
is a big-endian ordering.
The problem is that the semantic is not the same. The modifiers affect
the output ordering of IPv4 addresses while they affect the reading order
in case of FourCC code.
Avoid the confusion by replacing the "n" modifier with "hR", aka
reverse host ordering. It is inspired by the existing %p[mM]R printf
format.
Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Closes: https://lore.kernel.org/r/CAMuHMdV9tX=TG7E_CrSF=2PY206tXf+_yYRuacG48EWEtJLo-Q@mail.gmail.com
Signed-off-by: Petr Mladek <pmladek@suse.com>
Acked-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Aditya Garg <gargaditya08@live.com>
Link: https://lore.kernel.org/r/20250428123132.578771-1-pmladek@suse.com
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Add two quirks for the WDC Blue SN550 (PCI ID 15b7:5009) based on user
reports and hardware analysis:
- NVME_QUIRK_NO_DEEPEST_PS:
liaozw talked to me the problem and solved with
nvme_core.default_ps_max_latency_us=0, so add the quirk.
I also found some reports in the following link.
- NVME_QUIRK_BROKEN_MSI:
after get the lspci from Jack Rio.
I think that the disk also have NVME_QUIRK_BROKEN_MSI.
described in commit d5887dc6b6 ("nvme-pci: Add quirk for broken MSIs")
as sean said in link which match the MSI 1/32 and MSI-X 17.
Log:
lspci -nn | grep -i memory
03:00.0 Non-Volatile memory controller [0108]: Sandisk Corp SanDisk Ultra 3D / WD PC SN530, IX SN530, Blue SN550 NVMe SSD (DRAM-less) [15b7:5009] (rev 01)
lspci -v -d 15b7:5009
03:00.0 Non-Volatile memory controller: Sandisk Corp SanDisk Ultra 3D / WD PC SN530, IX SN530, Blue SN550 NVMe SSD (DRAM-less) (rev 01) (prog-if 02 [NVM Express])
Subsystem: Sandisk Corp WD Blue SN550 NVMe SSD
Flags: bus master, fast devsel, latency 0, IRQ 35, IOMMU group 10
Memory at fe800000 (64-bit, non-prefetchable) [size=16K]
Memory at fe804000 (64-bit, non-prefetchable) [size=256]
Capabilities: [80] Power Management version 3
Capabilities: [90] MSI: Enable- Count=1/32 Maskable- 64bit+
Capabilities: [b0] MSI-X: Enable+ Count=17 Masked-
Capabilities: [c0] Express Endpoint, MSI 00
Capabilities: [100] Advanced Error Reporting
Capabilities: [150] Device Serial Number 00-00-00-00-00-00-00-00
Capabilities: [1b8] Latency Tolerance Reporting
Capabilities: [300] Secondary PCI Express
Capabilities: [900] L1 PM Substates
Kernel driver in use: nvme
dmesg | grep nvme
[ 0.000000] Command line: BOOT_IMAGE=/vmlinuz-6.12.20-amd64-desktop-rolling root=UUID= ro splash quiet nvme_core.default_ps_max_latency_us=0 DEEPIN_GFXMODE=
[ 0.059301] Kernel command line: BOOT_IMAGE=/vmlinuz-6.12.20-amd64-desktop-rolling root=UUID= ro splash quiet nvme_core.default_ps_max_latency_us=0 DEEPIN_GFXMODE=
[ 0.542430] nvme nvme0: pci function 0000:03:00.0
[ 0.560426] nvme nvme0: allocated 32 MiB host memory buffer.
[ 0.562491] nvme nvme0: 16/0/0 default/read/poll queues
[ 0.567764] nvme0n1: p1 p2 p3 p4 p5 p6 p7 p8 p9
[ 6.388726] EXT4-fs (nvme0n1p7): mounted filesystem ro with ordered data mode. Quota mode: none.
[ 6.893421] EXT4-fs (nvme0n1p7): re-mounted r/w. Quota mode: none.
[ 7.125419] Adding 16777212k swap on /dev/nvme0n1p8. Priority:-2 extents:1 across:16777212k SS
[ 7.157588] EXT4-fs (nvme0n1p6): mounted filesystem r/w with ordered data mode. Quota mode: none.
[ 7.165021] EXT4-fs (nvme0n1p9): mounted filesystem r/w with ordered data mode. Quota mode: none.
[ 8.036932] nvme nvme0: using unchecked data buffer
[ 8.096023] block nvme0n1: No UUID available providing old NGUID
Link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d5887dc6b6c054d0da3cd053afc15b7be1f45ff6
Link: https://lore.kernel.org/all/20240422162822.3539156-1-sean.anderson@linux.dev/
Reported-by: liaozw <hedgehog-002@163.com>
Closes: https://bbs.deepin.org.cn/post/286300
Reported-by: rugk <rugk+github@posteo.de>
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=208123
Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
