The MT6365 PMIC, compatible with MT6359 PMIC, never had its own include
file so the boards that integrates this PMIC used mt6359.dtsi in their
devicetree to enable its support.
So, add the mt6365 include file for the MT6365 definitions and labels.
In order not to duplicate all of them, make it include mt6359.dtsi and
override the compatible strings for the MFD main and sub devices with
the MT6365 ones.
Signed-off-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com>
[Angelo: Fixed regulators node label] Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Derek J. Clark [Sun, 10 May 2026 04:25:39 +0000 (04:25 +0000)]
platform/x86: lenovo-wmi-other: Limit adding attributes to supported devices
Adds lwmi_is_attr_01_supported, and only creates the attribute subfolder
if the attribute is supported by the hardware. Due to some poorly
implemented BIOS this is a multi-step sequence of events. This is
because:
- Some BIOS support getting the capability data from custom mode (0xff),
while others only support it in no-mode (0x00).
- Some BIOS support get/set for the current value from custom mode (0xff),
while others only support it in no-mode (0x00).
- Some BIOS report capability data for a method that is not fully
implemented.
- Some BIOS have methods fully implemented, but no complimentary
capability data.
To ensure we only expose fully implemented methods with corresponding
capability data, we check each outcome before reporting that an
attribute can be supported.
Checking for lwmi_is_attr_01_supported during remove is not done to
ensure that we don't attempt to call cd01 or send WMI events if one of
the interfaces being removed was the cause of the driver unloading.
Fixes: edc4b183b794 ("platform/x86: Add Lenovo Other Mode WMI Driver") Reported-by: Kurt Borja <kuurtb@gmail.com> Closes: https://lore.kernel.org/platform-driver-x86/DG60P3SHXR8H.3NSEHMZ6J7XRC@gmail.com/ Cc: stable@vger.kernel.org Reviewed-by: Rong Zhang <i@rong.moe> Tested-by: Rong Zhang <i@rong.moe> Reviewed-by: Mark Pearson <mpearson-lenovo@squebb.ca> Signed-off-by: Derek J. Clark <derekjohn.clark@gmail.com> Link: https://patch.msgid.link/20260510042546.436874-10-derekjohn.clark@gmail.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Derek J. Clark [Sun, 10 May 2026 04:25:38 +0000 (04:25 +0000)]
platform/x86: lenovo-wmi-other: Add Attribute ID helper functions
Adds lwmi_attr_id() function. In the same vein as LWMI_ATTR_ID_FAN_RPM(),
but as a generic, to de-duplicate attribute_id assignment boilerplate.
Adds tunable_attr_01_id() function that breaks out the members of a
tunable_attr_01 struct and passes them to lwmi_attr_id().
No functional change intended.
Cc: stable@vger.kernel.org Reviewed-by: Rong Zhang <i@rong.moe> Tested-by: Rong Zhang <i@rong.moe> Reviewed-by: Mark Pearson <mpearson-lenovo@squebb.ca> Signed-off-by: Derek J. Clark <derekjohn.clark@gmail.com> Link: https://patch.msgid.link/20260510042546.436874-9-derekjohn.clark@gmail.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Derek J. Clark [Sun, 10 May 2026 04:25:37 +0000 (04:25 +0000)]
platform/x86: lenovo-wmi-helpers: Move gamezone enums to wmi-helpers
In a later patch in the series the thermal mode enum will be accessed
across three separate drivers (wmi-capdata, wmi-gamezonem and wmi-other).
An additional patch in the series will also add a function prototype that
needs to reference this enum in wmi-helpers.h. To avoid having all these
drivers begin to import each others headers, and to avoid declaring an
opaque enum to hande the second case, move the thermal mode enum to
helpers where it can be safely accessed by everything that needs it from
a single import.
While at it, since the gamezone_events_type enum is the only remaining
item in the header, move that as well and remove the gamezone header
entirely.
Cc: stable@vger.kernel.org Reviewed-by: Mark Pearson <mpearson-lenovo@squebb.ca> Reviewed-by: Rong Zhang <i@rong.moe> Tested-by: Rong Zhang <i@rong.moe> Signed-off-by: Derek J. Clark <derekjohn.clark@gmail.com> Link: https://patch.msgid.link/20260510042546.436874-8-derekjohn.clark@gmail.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Rong Zhang [Sun, 10 May 2026 04:25:36 +0000 (04:25 +0000)]
platform/x86: lenovo: Decouple lenovo-wmi-gamezone and lenovo-wmi-other
Currently, lenovo-wmi-gamezone depends on lenovo-wmi-other as the former
imports symbols from the latter. The imported symbols are just used to
register a notifier block. However, there is no runtime dependency
between both drivers, and either of them can run without the other,
which is the major purpose of using the notifier framework.
Such a link-time dependency is non-optimal. A previous attempt to "fix"
it made LENOVO_WMI_GAMEZONE select LENOVO_WMI_TUNING, which was
fundamentally broken and resulted in undefined Kconfig behavior, as
`select' cannot be used on a symbol with potentially unmet dependencies.
Decouple both drivers by moving the thermal mode notifier chain to
lenovo-wmi-helpers. Methods for notifier block (un)registration are
exported for lenovo-wmi-gamezone, while a method for querying the
current thermal mode are exported for lenovo-wmi-other.
This turns the dependency graph from
+------------ lenovo-wmi-gamezone
| |
v |
lenovo-wmi-helpers |
^ |
| V
+------------ lenovo-wmi-other
into
+------------ lenovo-wmi-gamezone
|
v
lenovo-wmi-helpers
^
|
+------------ lenovo-wmi-other
To make it clear, the name of the notifier chain is also renamed from
`om_chain_head' to `tm_chain_head', indicating that it's used to query
the current thermal mode.
No functional change intended.
Reviewed-by: Mark Pearson <mpearson-lenovo@squebb.ca> Fixes: 6e38b9fcbfa3 ("platform/x86: lenovo: gamezone needs "other mode"") Cc: stable@vger.kernel.org Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202603252259.gHvJDyh3-lkp@intel.com/ Closes: https://lore.kernel.org/oe-kbuild-all/202603260302.X0NjQOda-lkp@intel.com/ Signed-off-by: Rong Zhang <i@rong.moe> Signed-off-by: Derek J. Clark <derekjohn.clark@gmail.com> Link: https://patch.msgid.link/20260510042546.436874-7-derekjohn.clark@gmail.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Derek J. Clark [Sun, 10 May 2026 04:25:35 +0000 (04:25 +0000)]
platform/x86: lenovo-wmi-other: Fix tunable_attr_01 struct members
In struct tunable_attr_01 the capdata pointer is unused and the size of
the id members is u32 when it should be u8. Fix these prior to adding
additional members.
No functional change intended.
Reviewed-by: Mark Pearson <mpearson-lenovo@squebb.ca> Cc: stable@vger.kernel.org Reviewed-by: Rong Zhang <i@rong.moe> Tested-by: Rong Zhang <i@rong.moe> Signed-off-by: Derek J. Clark <derekjohn.clark@gmail.com> Link: https://patch.msgid.link/20260510042546.436874-6-derekjohn.clark@gmail.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Derek J. Clark [Sun, 10 May 2026 04:25:34 +0000 (04:25 +0000)]
platform/x86: lenovo-wmi-other: Zero initialize WMI arguments
Adds explicit initialization of wmi_method_args_32 declarations with
zero values to prevent uninitialized data from being sent to the device
BIOS when passed.
No functional change intended.
Reviewed-by: Mark Pearson <mpearson-lenovo@squebb.ca> Fixes: 22024ac5366f ("platform/x86: Add Lenovo Gamezone WMI Driver") Fixes: edc4b183b794 ("platform/x86: Add Lenovo Other Mode WMI Driver") Reported-by: Rong Zhang <i@rong.moe> Closes: https://lore.kernel.org/platform-driver-x86/95c7e7b539dd0af41189c754fcd35cec5b6fe182.camel@rong.moe/ Cc: stable@vger.kernel.org Reviewed-by: Rong Zhang <i@rong.moe> Tested-by: Rong Zhang <i@rong.moe> Signed-off-by: Derek J. Clark <derekjohn.clark@gmail.com> Link: https://patch.msgid.link/20260510042546.436874-5-derekjohn.clark@gmail.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Rong Zhang [Sun, 10 May 2026 04:25:33 +0000 (04:25 +0000)]
platform/x86: lenovo-wmi-other: Balance component bind and unbind
When lwmi_om_master_bind() fails, the master device's components are
left bound, with the aggregate device destroyed due to the failure
(found by sashiko.dev [1]).
Balance calls to component_bind_all() and component_unbind_all() when an
error is propagated to the component framework.
Rong Zhang [Sun, 10 May 2026 04:25:32 +0000 (04:25 +0000)]
platform/x86: lenovo-wmi-other: Balance IDA id allocation and free
Currently, the IDA id is only freed on wmi-other device removal or
failure to create firmware-attributes device, kset, or attributes. It
leaks IDA ids if the wmi-other device is bound multiple times, as the
unbind callback never frees the previously allocated IDA id.
Additionally, if the wmi-other device has failed to create a
firmware-attributes device before it gets removed, the wmi-device
removal callback double frees the same IDA id.
These bugs were found by sashiko.dev [1].
Fix them by moving ida_free() into lwmi_om_fw_attr_remove() so it is
balanced with ida_alloc() in lwmi_om_fw_attr_add(). With them fixed,
properly set and utilize the validity of priv->ida_id to balance
firmware-attributes registration and removal, without relying on
propagating the registration error to the component framework, which is
more reliable and aligns with the hwmon device registration and removal
sequences.
Introduce a structured, size-efficient, per-CPU, CPUID data repository.
Use the x86-cpuid-db auto-generated data types, and custom CPUID leaf
parsers, to build that repository. Given a leaf, subleaf, and index,
provide direct memory access to the parsed and cached per-CPU CPUID output.
** Long-term goal
Remove the need for drivers and other areas in the kernel to invoke direct
CPUID queries. Only one place in the kernel should be allowed to use the
CPUID instruction: the CPUID parser code.
** Implementation
Introduce CPUID_LEAF()/CPUID_LEAF_N() to build a compact CPUID storage
layout in the form:
where each CPUID query stores its output at the designated leaf/subleaf
array and has an associated "CPUID query info" structure.
Embed the CPUID tables inside "struct cpuinfo_x86" to ensure early-boot and
per-CPU access through the CPUs capability structures.
Use an array of CPUID output storage entries for each leaf/subleaf
combination to accommodate leaves which produce the same output format for
a large subleaf range. This is typical for CPUID leaves enumerating
hierarchical objects; e.g. CPUID(0x4) cache topology enumeration,
CPUID(0xd) XSAVE enumeration, and CPUID(0x12) SGX Enclave Page Cache
enumeration.
** New CPUID APIs
Assuming a CPU capability structure 'c', provide macros to access the
parsed and cached CPUID leaf/subleaf output. These macros resolve to a
compile-time tokenization that ensures type-safety:
Fix spelling mistake in comment:
- occured -> occurred
Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Md Shofiqul Islam <shofiqtest@gmail.com> Signed-off-by: Carlos Maiolino <cem@kernel.org>
pmdomain: core: add support for power-domains-child-ids
Currently, PM domains can only support hierarchy for simple
providers (e.g. ones with #power-domain-cells = 0).
Add support for oncell providers as well by adding a new property
`power-domains-child-ids` to describe the parent/child relationship.
For example, an SCMI PM domain provider has multiple domains, each of
which might be a child of diffeent parent domains. In this example,
the parent domains are MAIN_PD and WKUP_PD:
which can be called by pmdomain providers to add/remove child domains
if they support the new property power-domains-child-ids.
The add function is "all or nothing". If it cannot add all of the
child domains in the list, it will unwind any additions already made
and report a failure.
Signed-off-by: Kevin Hilman (TI) <khilman@baylibre.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
firewire: Simplify storing pointers in device id struct
Technically it is fine (on all current Linux architectures) to store a
pointer in an unsigned long variable. However this needs explicit
casting which is an easy source for type mismatches.
By replacing the plain unsigned long .driver_data in struct
ieee1394_device_id by an anonymous union, most of the casting can be
dropped. There is still some implicit casting involved (between a void *
and a driver specific pointer type), but that's better than the approach
to store a pointer in an unsigned long variable as this doesn't lose the
information that the data being pointed to is const.
All users of struct ieee1394_device_id are initialized in a way that is
compatible with the new definition, so no adaptions are needed there.
(The comments addressing to CHERI extension are dropped by the
maintainer.)
Add binding documentation for the new power-domains-child-ids property,
which works in conjunction with the existing power-domains property to
establish parent-child relationships between a multi-domain power domain
provider and external parent domains.
Each element in the uint32 array identifies the child domain
ID (index) within the provider that should be made a child domain of
the corresponding phandle entry in power-domains. The two arrays must
have the same number of elements.
Signed-off-by: Kevin Hilman (TI) <khilman@baylibre.com> Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Merge patch series "selftests/namespaces: Fix test hangs and false failures"
Ricardo B. Marlière <rbm@suse.com> says:
This series addresses three reliability problems in the namespaces selftest
suite that cause tests to hang or report incorrect results.
The first patch fixes a hang in nsid_test where the grandchild process is
not reaped during fixture teardown, leaving it alive and holding the TAP
pipe write-end open so the test runner blocks indefinitely waiting for EOF.
The second and third patches fix two problems in listns_efault_test: a
waitpid(-1) race that can cause the iterator child to be consumed during
namespace cleanup (leading to an indefinite block on the subsequent targeted
waitpid), and a false FAIL verdict on kernels that do not implement listns()
(the EFAULT tests should SKIP in that case, consistent with every other
listns test that already handles ENOSYS correctly).
selftests/namespaces: Skip efault tests when listns() is not available
When listns() is not implemented the iterator child detects ENOSYS and
exits cleanly with status PIDFD_SKIP before the parent has a chance to
signal it. The parent sends SIGKILL (which is a harmless no-op at that
point) and then calls waitpid(), obtaining a normal-exit status. The
subsequent ASSERT_TRUE(WIFSIGNALED(status)) therefore fails, causing the
three EFAULT-focused tests to report FAIL rather than SKIP on kernels that
do not yet carry listns() support.
After collecting the iterator's exit status, check whether it exited with
PIDFD_SKIP and issue a SKIP verdict in that case, consistent with the
behaviour of every other listns test that already handles ENOSYS correctly.
selftests/namespaces: Fix waitpid race in listns_efault_test cleanup
The efault tests spawn two categories of child processes: namespace
children (each in its own mount namespace, for concurrent destruction) and
an iterator child that calls listns() in a tight loop. The cleanup loop
used waitpid(-1), which reaps any child in any order. If the iterator child
exits early (e.g. because listns() returned ENOSYS) before all namespace
children have been reaped, waitpid(-1) may consume it instead. The
subsequent targeted waitpid(iter_pid) would then block indefinitely.
Track the PIDs of the namespace children explicitly and use targeted
waitpid() calls in the cleanup loop so the iterator child cannot be
inadvertently reaped during namespace cleanup.
Merge patch series "uaccess/sockptr: copy_struct_ fixes and more helpers"
Stefan Metzmacher <metze@samba.org> says:
Here are some patches related to
copy_struct_{from,to}_{user,sockptr}()
I collected during my work on an IPPROTO_SMBDIRECT
implementation wrapping the smbdirect code used
by cifs.ko and ksmbd.ko.
The first patch fixes copy_struct_to_user()
to behave like documented.
The 2nd patch fixes the case where
copy_struct_from_user() is called by
copy_struct_from_sockptr().
The 3rd patch introduces
copy_struct_{from,to}_bounce_buffer()
as a result of a discussion about the
IPPROTO_QUIC driver in order to
be future prove when handling msg_control
messages in sendmsg and recvmsg.
But I'll likely also use them in my
IPPROTO_SMBDIRECT driver.
The 4th patch makes copy_struct_from_sockptr()
a trivial wrapper switching between
copy_struct_from_user() and
copy_struct_from_bounce_buffer()
The 5th patch introduces copy_struct_to_sockptr()
which I'll also use in my IPPROTO_SMBDIRECT driver.
* patches from https://patch.msgid.link/cover.1775576651.git.metze@samba.org:
sockptr: introduce copy_struct_to_sockptr()
sockptr: let copy_struct_from_sockptr() use copy_struct_from_bounce_buffer()
uaccess: add copy_struct_{from,to}_bounce_buffer() helpers
sockptr: fix usize check in copy_struct_from_sockptr() for user pointers
uaccess: fix ignored_trailing logic in copy_struct_to_user()
selftests/namespaces: Kill grandchild in nsid fixture teardown
The timens_separate and pidns_separate test cases fork a grandchild that
calls pause(). FIXTURE_TEARDOWN only kills the direct child, which is the
init process of the grandchild's namespace. Once the child (init) exits,
the grandchild is reparented to the host init but remains alive and
continues to hold the inherited write end of the test runner's TAP pipe
open. tap_prefix never receives EOF and blocks indefinitely, hanging the
entire test collection.
Record the grandchild PID in the fixture struct so that teardown can send
SIGKILL and reap it before dealing with the child. The grandchild must be
reaped first because the child acts as its PID namespace init; killing the
child first would kill the grandchild without giving us a chance to
waitpid() it.
We already have copy_struct_from_sockptr() as wrapper to
copy_struct_from_user() or copy_struct_from_bounce_buffer(),
so it's good to have copy_struct_to_sockptr()
as well matching the behavior of copy_struct_to_user()
or copy_struct_to_bounce_buffer().
The world would be better without sockptr_t, but having
copy_struct_to_sockptr() is better than open code it
in various places.
I'll use this in my IPPROTO_SMBDIRECT work,
but maybe it will also be useful for others...
IPPROTO_QUIC will likely also use it.
Cc: Dmitry Safonov <0x7f454c46@gmail.com> Cc: Dmitry Safonov <dima@arista.com> Cc: Francesco Ruggeri <fruggeri@arista.com> Cc: Salam Noureddine <noureddine@arista.com> Cc: David Ahern <dsahern@kernel.org> Cc: David S. Miller <davem@davemloft.net> Cc: Michal Luczaj <mhal@rbox.co> Cc: David Wei <dw@davidwei.uk> Cc: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Cc: Luiz Augusto von Dentz <luiz.dentz@gmail.com> Cc: Marcel Holtmann <marcel@holtmann.org> Cc: Xin Long <lucien.xin@gmail.com> Cc: Eric Dumazet <edumazet@google.com> Cc: Kuniyuki Iwashima <kuniyu@google.com> Cc: Paolo Abeni <pabeni@redhat.com> Cc: Willem de Bruijn <willemb@google.com> Cc: Neal Cardwell <ncardwell@google.com> Cc: Jakub Kicinski <kuba@kernel.org> Cc: Simon Horman <horms@kernel.org> Cc: Aleksa Sarai <cyphar@cyphar.com> Cc: Christian Brauner <brauner@kernel.org> CC: Kees Cook <keescook@chromium.org> Cc: netdev@vger.kernel.org Cc: linux-bluetooth@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Stefan Metzmacher <metze@samba.org> Link: https://patch.msgid.link/c950ee1578cb93b4411c3731010def9c1cd82f0d.1775576651.git.metze@samba.org Signed-off-by: Christian Brauner <brauner@kernel.org>
sockptr: let copy_struct_from_sockptr() use copy_struct_from_bounce_buffer()
The world would be better without sockptr_t, but this at least
simplifies copy_struct_from_sockptr() to be just a dispatcher for
copy_struct_from_user() or copy_struct_from_bounce_buffer() without any
special logic on its own.
Cc: Dmitry Safonov <0x7f454c46@gmail.com> Cc: Dmitry Safonov <dima@arista.com> Cc: Francesco Ruggeri <fruggeri@arista.com> Cc: Salam Noureddine <noureddine@arista.com> Cc: David Ahern <dsahern@kernel.org> Cc: David S. Miller <davem@davemloft.net> Cc: Michal Luczaj <mhal@rbox.co> Cc: David Wei <dw@davidwei.uk> Cc: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Cc: Luiz Augusto von Dentz <luiz.dentz@gmail.com> Cc: Marcel Holtmann <marcel@holtmann.org> Cc: Xin Long <lucien.xin@gmail.com> Cc: Eric Dumazet <edumazet@google.com> Cc: Kuniyuki Iwashima <kuniyu@google.com> Cc: Paolo Abeni <pabeni@redhat.com> Cc: Willem de Bruijn <willemb@google.com> Cc: Neal Cardwell <ncardwell@google.com> Cc: Jakub Kicinski <kuba@kernel.org> Cc: Simon Horman <horms@kernel.org> Cc: Aleksa Sarai <cyphar@cyphar.com> Cc: Christian Brauner <brauner@kernel.org> CC: Kees Cook <keescook@chromium.org> Cc: netdev@vger.kernel.org Cc: linux-bluetooth@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Stefan Metzmacher <metze@samba.org> Link: https://patch.msgid.link/b9b7e22664a53251d7ad099b12aead8b599c1257.1775576651.git.metze@samba.org Signed-off-by: Christian Brauner <brauner@kernel.org>
sockptr: fix usize check in copy_struct_from_sockptr() for user pointers
copy_struct_from_user will never hit the check_zeroed_user() call
and will never return -E2BIG if new userspace passed new bits in a
larger structure than the current kernel structure.
As far as I can there are no critical/related uapi changes in
- include/net/bluetooth/bluetooth.h and net/bluetooth/sco.c
after the use of copy_struct_from_sockptr in v6.13-rc3
- include/uapi/linux/tcp.h and net/ipv4/tcp_ao.c
after the use of copy_struct_from_sockptr in v6.6-rc1
So that new callers will get the correct behavior from the start.
Fixes: 4954f17ddefc ("net/tcp: Introduce TCP_AO setsockopt()s") Fixes: ef84703a911f ("net/tcp: Add TCP-AO getsockopt()s") Fixes: faadfaba5e01 ("net/tcp: Add TCP_AO_REPAIR") Fixes: 3e643e4efa1e ("Bluetooth: Improve setsockopt() handling of malformed user input") Cc: Dmitry Safonov <0x7f454c46@gmail.com> Cc: Dmitry Safonov <dima@arista.com> Cc: Francesco Ruggeri <fruggeri@arista.com> Cc: Salam Noureddine <noureddine@arista.com> Cc: David Ahern <dsahern@kernel.org> Cc: David S. Miller <davem@davemloft.net> Cc: Michal Luczaj <mhal@rbox.co> Cc: David Wei <dw@davidwei.uk> Cc: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Cc: Luiz Augusto von Dentz <luiz.dentz@gmail.com> Cc: Marcel Holtmann <marcel@holtmann.org> Cc: Xin Long <lucien.xin@gmail.com> Cc: Eric Dumazet <edumazet@google.com> Cc: Kuniyuki Iwashima <kuniyu@google.com> Cc: Paolo Abeni <pabeni@redhat.com> Cc: Willem de Bruijn <willemb@google.com> Cc: Neal Cardwell <ncardwell@google.com> Cc: Jakub Kicinski <kuba@kernel.org> Cc: Simon Horman <horms@kernel.org> Cc: Aleksa Sarai <cyphar@cyphar.com> Cc: Christian Brauner <brauner@kernel.org> CC: Kees Cook <keescook@chromium.org> Cc: netdev@vger.kernel.org Cc: linux-bluetooth@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Stefan Metzmacher <metze@samba.org> Link: https://patch.msgid.link/cfaedbc33ae9d36adaabf04fa79424f30ff1efdd.1775576651.git.metze@samba.org Reviewed-by: Aleksa Sarai <aleksa@amutable.com> Signed-off-by: Christian Brauner <brauner@kernel.org>
uaccess: fix ignored_trailing logic in copy_struct_to_user()
Currently all callers pass ignored_trailing=NULL, but I have
code that will make use of.
Now it actually behaves like documented:
* If @usize < @ksize, then the kernel is trying to pass userspace a newer
struct than it supports. Thus we only copy the interoperable portions
(@usize) and ignore the rest (but @ignored_trailing is set to %true if
any of the trailing (@ksize - @usize) bytes are non-zero).
Fixes: 424a55a4a908 ("uaccess: add copy_struct_to_user helper") Cc: Dmitry Safonov <0x7f454c46@gmail.com> Cc: Dmitry Safonov <dima@arista.com> Cc: Francesco Ruggeri <fruggeri@arista.com> Cc: Salam Noureddine <noureddine@arista.com> Cc: David Ahern <dsahern@kernel.org> Cc: David S. Miller <davem@davemloft.net> Cc: Michal Luczaj <mhal@rbox.co> Cc: David Wei <dw@davidwei.uk> Cc: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Cc: Luiz Augusto von Dentz <luiz.dentz@gmail.com> Cc: Marcel Holtmann <marcel@holtmann.org> Cc: Xin Long <lucien.xin@gmail.com> Cc: Eric Dumazet <edumazet@google.com> Cc: Kuniyuki Iwashima <kuniyu@google.com> Cc: Paolo Abeni <pabeni@redhat.com> Cc: Willem de Bruijn <willemb@google.com> Cc: Neal Cardwell <ncardwell@google.com> Cc: Jakub Kicinski <kuba@kernel.org> Cc: Simon Horman <horms@kernel.org> Cc: Aleksa Sarai <cyphar@cyphar.com> Cc: Christian Brauner <brauner@kernel.org> CC: Kees Cook <keescook@chromium.org> Cc: netdev@vger.kernel.org Cc: linux-bluetooth@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Stefan Metzmacher <metze@samba.org> Link: https://patch.msgid.link/71f69442410c1186ed8ce6d5b4b9d4a5a70edbad.1775576651.git.metze@samba.org Reviewed-by: Aleksa Sarai <aleksa@amutable.com> Signed-off-by: Christian Brauner <brauner@kernel.org>
Rosen Penev [Sat, 9 May 2026 00:34:38 +0000 (17:34 -0700)]
gpio: zevio: allow COMPILE_TEST builds
The ZEVIO GPIO driver uses generic platform, MMIO, and gpiolib interfaces.
Allow it to build with COMPILE_TEST so it gets coverage on non-ARM
platforms.
Drop the ARM-specific IOMEM() casts around the register pointer. The
pointer is already __iomem, so readl() and writel() can use it directly.
Tested with:
make LLVM=1 ARCH=loongarch drivers/gpio/gpio-zevio.o
fprobe: Fix unregister_fprobe() to wait for RCU grace period
Commit 4346ba1604093 ("fprobe: Rewrite fprobe on function-graph tracer")
changed fprobe to register struct fprobe to an rcu-hlist, but it forgot
to wait for RCU GP. Thus there can be use-after-free if the fprobe is
released right after unregistering. This can be happened on fprobe
event and sample module code.
To fix this issue, add synchronize_rcu() in unregister_fprobe().
Note that BPF is OK because fprobe is used as a part of
bpf_kprobe_multi_link. This unregisters its fprobe in
bpf_kprobe_multi_link_release() and it is deallocated via
bpf_kprobe_multi_link_dealloc(), which is invoked from
bpf_link_defer_dealloc_rcu_gp() RCU callback.
For BPF, this also introduced unregister_fprobe_async() which does
NOT wait for RCU grace priod.
Matthew Auld [Fri, 8 May 2026 10:26:37 +0000 (11:26 +0100)]
drm/xe/dma-buf: fix UAF with retry loop
Retry doesn't work here, since bo will be freed on error, leading to
UAF. However, now that we do the alloc & init before the attach, we can
now combine this as one unit and have the init do the alloc for us. This
should make the retry safe.
Reported by Sashiko.
v2: Fix up the error unwind (CI)
Closes: https://sashiko.dev/#/patchset/20260506184332.86743-2-matthew.auld%40intel.com Fixes: eb289a5f6cc6 ("drm/xe: Convert xe_dma_buf.c for exhaustive eviction") Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: <stable@vger.kernel.org> # v6.18+ Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Link: https://patch.msgid.link/20260508102635.149172-4-matthew.auld@intel.com
Matthew Auld [Fri, 8 May 2026 10:26:36 +0000 (11:26 +0100)]
drm/xe/dma-buf: handle empty bo and UAF races
There look to be some nasty races here when triggering the
invalidate_mappings hook:
1) We do xe_bo_alloc() followed by the attach, before the actual full bo
init step in xe_dma_buf_init_obj(). However the bo is visible on the
attachments list after the attach. This is bad since exporter driver,
say amdgpu, can at any time call back into our invalidate_mappings hook,
with an empty/bogus bo, leading to potential bugs/crashes.
2) Similar to 1) but here we get a UAF, when the invalidate_mappings
hook is triggered. For example, we get as far as xe_bo_init_locked()
but this fails in some way. But here the bo will be freed on error, but
we still have it attached from dma-buf pov, so if the
invalidate_mappings is now triggered then the bo we access is gone and
we trigger UAF and more bugs/crashes.
To fix this, move the attach step until after we actually have a fully
set up buffer object. Note that the bo is not published to userspace
until later, so not sure what the comment "Don't publish the bo
until we have a valid attachment", is referring to.
We have at least two different customers reporting hitting a NULL ptr
deref in evict_flags when importing something from amdgpu, followed by
triggering the evict flow. Hit rate is also pretty low, which would
hint at some kind of race, so something like 1) or 2) might explain
this.
v2:
- Shuffle the order of the ops slightly (no functional change)
- Improve the comment to better explain the ordering (Matt B)
Fix the pinctrl child node names to adhere to the bindings. The main pin
node is supposed to be named like "something-pins" and the pinmux node
named like "pins-something".
Signed-off-by: David Lechner <dlechner@baylibre.com> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Akari Tsuyukusa [Wed, 25 Mar 2026 14:45:00 +0000 (23:45 +0900)]
arm: dts: mediatek: mt6589: Add Arm Generic Timer node
Add the Arm Generic Timer node to the MT6589 SoC.
"arm,cpu-registers-not-fw-configured;" is required
because the bootloader does not initialize the Arm Generic Timer.
Signed-off-by: Akari Tsuyukusa <akkun11.open@gmail.com> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
thunderbolt: test: add KUnit regression tests for XDomain property parser
Add three KUnit cases that exercise the defects fixed by the sibling
commits in this series by feeding crafted XDomain property blocks to
tb_property_parse_dir():
tb_test_property_parse_u32_wrap - entry->value = 0xffffff00 and
entry->length = 0x100 so their u32 sum 0x100000000 wraps to 0
under the block_len guard; without the fix the subsequent
parse_dwdata() reads attacker-directed OOB memory.
tb_test_property_parse_recursion - two DIRECTORY entries pointing
at each other, driving __tb_property_parse_dir() recursion;
without the fix the kernel stack is exhausted.
tb_test_property_parse_dir_len_underflow - a DIRECTORY entry with
length < 4 placed near the end of the block so the non-root UUID
kmemdup of 4 dwords from dir_offset reads OOB before the later
content_len = dir_len - 4 underflow path is reached.
Each test asserts tb_property_parse_dir() returns NULL on the
crafted input. With CONFIG_KASAN=y, running these on the pre-fix
kernel produces an oops inside __tb_property_parse_dir or its
callees: u32_wrap takes a page fault on the KASAN shadow lookup for
the wild ~16 GiB OOB offset; recursion trips a KASAN out-of-bounds
report in __unwind_start as the per-task kernel stack is consumed;
dir_len_underflow trips a KASAN slab-out-of-bounds report in
kmemdup_noprof reading 16 bytes past the 28-byte block. Post-fix
they pass cleanly.
The crafted blocks are populated by writing u32 dwords directly,
matching the existing root_directory[] style used elsewhere in
this file rather than imposing a private struct overlay.
Run with:
./tools/testing/kunit/kunit.py run --arch=x86_64 \
--kconfig_add CONFIG_PCI=y --kconfig_add CONFIG_NVMEM=y \
--kconfig_add CONFIG_USB4=y --kconfig_add CONFIG_USB4_KUNIT_TEST=y \
--kconfig_add CONFIG_KASAN=y 'thunderbolt.tb_test_property_parse_*'
Assisted-by: Claude:claude-opus-4-7 Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
thunderbolt: property: Cap recursion depth in __tb_property_parse_dir()
A DIRECTORY entry's value field is used as the dir_offset for a
recursive call into __tb_property_parse_dir() with no depth counter.
A crafted peer that chains DIRECTORY entries into a back-reference
loop drives the parser until the kernel stack is exhausted and the
guard page fires. Any untrusted XDomain peer (cable, dock, in-line
inspector, adjacent host) that reaches the PROPERTIES_REQUEST
control-plane exchange can trigger this without authentication.
Thread a depth counter through tb_property_parse() and
__tb_property_parse_dir(), and reject blocks that exceed
TB_PROPERTY_MAX_DEPTH = 8. That is comfortably larger than any
observed legitimate XDomain layout.
Operators who do not need XDomain host-to-host discovery can disable
the path entirely with thunderbolt.xdomain=0 on the kernel command
line.
Fixes: cdae7c07e3e3 ("thunderbolt: Add support for XDomain properties") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-6 Assisted-by: Codex:gpt-5-4 Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
thunderbolt: property: Reject dir_len < 4 to prevent size_t underflow
On the non-root path, __tb_property_parse_dir() takes dir_len from
entry->length (u16 widened to size_t). Two distinct OOB conditions
follow when entry->length < 4:
1. The non-root path begins with kmemdup(&block[dir_offset],
sizeof(*dir->uuid), ...) which always reads 4 dwords from
dir_offset. tb_property_entry_valid() only enforces
dir_offset + entry->length <= block_len, so a crafted entry
with dir_offset close to the end of the property block and
entry->length in 0..3 passes that gate but lets the UUID copy
run off the block (e.g. dir_offset = 497, dir_len = 3 in a
500-dword block reads block[497..501]).
2. After the kmemdup, content_len = dir_len - 4 underflows size_t
to ~SIZE_MAX, nentries becomes SIZE_MAX / 4, and the entry
walk runs OOB on each iteration until an entry fails
validation or the kernel oopses on an unmapped page.
Reject dir_len < 4 on the non-root path *before* the UUID kmemdup,
which closes both holes.
Also move INIT_LIST_HEAD(&dir->properties) up to immediately after
the dir allocation so the new error-return path (and the existing
uuid-alloc failure path) calling tb_property_free_dir() sees a
walkable list rather than the zero-initialized NULL next/prev that
list_for_each_entry_safe() would oops on.
Fixes: cdae7c07e3e3 ("thunderbolt: Add support for XDomain properties") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-6 Assisted-by: Codex:gpt-5-4 Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
thunderbolt: property: Reject u32 wrap in tb_property_entry_valid()
entry->value is u32 and entry->length is u16; the sum is performed in
u32 and wraps. A malicious XDomain peer can pick
value = 0xffffff00, length = 0x100 so the sum 0x100000000 wraps to 0
and passes the > block_len check. tb_property_parse() then passes
entry->value to parse_dwdata() as a dword offset into the property
block, reading attacker-directed memory far past the allocation.
For TEXT-typed entries with the "deviceid" or "vendorid" keys this
lands in xd->device_name / xd->vendor_name and is readable back via
the per-XDomain device_name / vendor_name sysfs attributes; the leak
is NUL-bounded (kstrdup() stops at the first zero byte) and
untargeted (the attacker picks a delta, not an absolute address).
DATA-typed entries are parsed into property->value.data but not
generically surfaced to userspace.
Use check_add_overflow() so a wrapped sum is rejected.
Fixes: cdae7c07e3e3 ("thunderbolt: Add support for XDomain properties") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-6 Assisted-by: Codex:gpt-5-4 Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Matt Bobrowski [Thu, 30 Apr 2026 07:38:36 +0000 (07:38 +0000)]
bpf: fix crash in bpf_[set|remove]_dentry_xattr for negative dentries
bpf_set_dentry_xattr and bpf_remove_dentry_xattr BPF kfuncs attempt to
lock the inode of the supplied dentry without checking if it is
NULL. If a negative dentry is passed (e.g. from
security_inode_create), d_inode(dentry) returns NULL, and
inode_lock(inode) will cause a NULL pointer dereference.
Trivially fix this by adding a NULL check for inode before attempting
to lock it, returning -EINVAL if it is NULL.
Additionally, drop WARN_ON(!inode) in bpf_xattr_read_permission() and
bpf_xattr_write_permission(). These warnings could be triggered by
passing a negative dentry to bpf_get_dentry_xattr() or the _locked
variants of the xattr kfuncs, potentially causing a Denial of Service
on systems with panic_on_warn enabled. Instead, simply return -EINVAL.
Reported-by: Quan Sun <2022090917019@std.uestc.edu.cn> Closes: https://lore.kernel.org/bpf/1587cbf4-1293-4e25-ad24-c970836a1686@std.uestc.edu.cn/ Fixes: 56467292794b ("bpf: fs/xattr: Add BPF kfuncs to set and remove xattrs") Signed-off-by: Matt Bobrowski <mattbobrowski@google.com> Link: https://patch.msgid.link/20260430073836.2894001-1-mattbobrowski@google.com Signed-off-by: Christian Brauner <brauner@kernel.org>
soc: mediatek: mtk-mmsys: Restore MT8167 routing masks lost during merge
The original patch that was sent to the mailing lists included the values
for the route masks, but they got lost during merge: add back the full
register masks where missing.
Fixes: 060f7875bd23 ("soc: mediatek: mmsys: Add support for MT8167 SoC") Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Jason-JH Lin [Wed, 25 Mar 2026 03:57:38 +0000 (11:57 +0800)]
soc: mediatek: Use pkt_write function pointer for subsys ID compatibility
Switch to pkt_write and reg_write_mask function pointers for register
access, enabling compatibility with platforms regardless of subsys ID
support.
Signed-off-by: Jason-JH Lin <jason-jh.lin@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Merge patch series "cleanup block-style layouts exports"
Chuck Lever <cel@kernel.org> says:
This series cleanups the exportfs support for block-style layouts that
provide direct block device access. This is preparation for supporting
exportfs of more than a single device per file system.
* patches from https://patch.msgid.link/20260423181854.743150-1-cel@kernel.org:
exportfs,nfsd: rework checking for layout-based block device access support
exportfs: don't pass struct iattr to ->commit_blocks
exportfs: split out the ops for layout-based block device access
nfsd/blocklayout: always ignore loca_time_modify
exportfs,nfsd: rework checking for layout-based block device access support
Currently NFSD hard codes checking support for block-style layouts.
Lift the checks into a file system-helper and provide a exportfs-level
helper to implement the typical checks.
This prepares for supporting block layout export of multiple devices
per file system.
Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Jeff Layton <jlayton@kernel.org> Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Link: https://patch.msgid.link/20260423181854.743150-5-cel@kernel.org Signed-off-by: Christian Brauner <brauner@kernel.org>
exportfs: don't pass struct iattr to ->commit_blocks
The only thing ->commit_blocks really needs is the new size, with a magic
-1 placeholder 0 for "do not change the size" because it only ever
extends the size.
Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Jeff Layton <jlayton@kernel.org> Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Link: https://patch.msgid.link/20260423181854.743150-4-cel@kernel.org Signed-off-by: Christian Brauner <brauner@kernel.org>
exportfs: split out the ops for layout-based block device access
The support to grant layouts for direct block device access works
at a very different layer than the rest of exports. Split the methods
for it into a separate struct, and move that into a separate header
to better split things out. The pointer to the new operation vector
is kept in export_operations to avoid bloating the super_block.
Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Jeff Layton <jlayton@kernel.org> Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Link: https://patch.msgid.link/20260423181854.743150-3-cel@kernel.org Signed-off-by: Christian Brauner <brauner@kernel.org>
RFC 8881 Section 18.42 makes it clear that the client provided timestamp
is a "may" condition, and clients that want to force a specific timestamp
should send a separate SETATTR in the compound.
Since commit b82f92d5dd1a ("fs: have setattr_copy handle multigrain
timestamps appropriately") the ia_mtime value is ignored by file
systems using multi-grain timestamps like XFS, which is the only
file system supporting blocklayout exports right now, so make that
explicit in NFSD as well.
Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Jeff Layton <jlayton@kernel.org> Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Link: https://patch.msgid.link/20260423181854.743150-2-cel@kernel.org Signed-off-by: Christian Brauner <brauner@kernel.org>
selftests/pid_namespace: compute pid_max test limits dynamically
The pid_max kselftest hardcodes pid_max values of 400 and 500, but the
kernel enforces a minimum of PIDS_PER_CPU_MIN * num_possible_cpus().
On machines with many possible CPUs (e.g. nr_cpu_ids=128 yields a
minimum of 1024), writing 400 or 500 to /proc/sys/kernel/pid_max
returns EINVAL and all three tests fail.
Compute these limits the same way as the kernel does and set outer_limit
and inner_limit dynamically based on the result. Original test semantics
are preserved (outer < inner, nested namespace capped by parent).
Signed-off-by: Bjoern Doebel <doebel@amazon.com> Link: https://patch.msgid.link/20260422201151.3830506-1-doebel@amazon.com Reviewed-by: Pavel Tikhomirov <ptikhomirov@virtuozzo.com> Assisted-by: Kiro:claude-opus-4.6 Signed-off-by: Christian Brauner <brauner@kernel.org>
pinctrl: renesas: rzv2m: Fix type in .pin_config_group_get() callback
On 64-bit platforms, "unsigned long" is 64-bit. Hence checking if all
"unsigned long" configuration values are equal should be done using an
"unsigned long" temporary.
pinctrl: renesas: rzg2l: Fix type in .pin_config_group_get() callback
On 64-bit platforms, "unsigned long" is 64-bit. Hence checking if all
"unsigned long" configuration values are equal should be done using an
"unsigned long" temporary.
Biju Das [Thu, 30 Apr 2026 09:34:12 +0000 (10:34 +0100)]
pinctrl: renesas: rzg2l: Add support for clone channel control
The RZ/G3L SoC has some IP such as I2C ch{2,3},SCIF ch{3,4,5},
RSPI ch{1,2} and RSCI ch{1,2,3} need to control the clone channel for
proper operation. As per the RZ/G3L hardware manual, the clone channel
setting is to be done before the mux setting.
The port and function selectors are evaluated multiple times
in rzg2l_pinctrl_set_mux(). Simplify the function by dropping
dupicate evaluation storing them in local variables.
Biju Das [Thu, 30 Apr 2026 09:34:09 +0000 (10:34 +0100)]
pinctrl: renesas: rzg2l: Update OEN pin validation to use exact match
The RZ/G2L SoC uses pin 0 from a port for OEN while RZ/G3L uses pin 1. The
existing greater-than comparison against oen_max_pin in
rzg2l_pin_to_oen_bit() would incorrectly accept any pin below that value
rather than enforcing the single valid OEN pin for each SoC. Replace the
range check with an exact equality test so that only the designated OEN
pin is accepted.
Biju Das [Thu, 30 Apr 2026 09:34:08 +0000 (10:34 +0100)]
pinctrl: renesas: rzg2l: Add support for selecting power source for {WDT,AWO,ISO}
The RZ/G3L SoC has support for setting power source that are not
controlled by the following voltage control registers:
- SD_CH{0,1,2}_POC, XSPI_POC, ETH{0,1}_POC, I3C_SET.POC
Add support for selecting voltages using OTHER_POC register for
setting I/O domain voltage for WDT, ISO and AWO by extending
rzg2l_caps_to_pwr_reg() with a mask output parameter so that callers
callers can identify which bit(s) within OTHER_POC correspond to the
requested domain. Update rzg2l_get_power_source() to extract the
relevant bit field via field_get() when reading OTHER_POC, and update
rzg2l_set_power_source() to perform a read-modify-write under the
spinlock when writing to OTHER_POC, since multiple domains share the
same register.
Biju Das [Thu, 30 Apr 2026 09:34:07 +0000 (10:34 +0100)]
pinctrl: renesas: rzg2l: Make QSPI register handling conditional
The QSPI register at offset 0x3008 is not present on all SoCs supported by
the RZ/G2L pinctrl driver. Unconditionally reading and writing this
register during suspend/resume on hardware that lacks it can cause
undefined behaviour.
Add a qspi field to rzg2l_register_offsets to allow per-SoC declaration of
the QSPI register offset, and guard the suspend/resume accesses with a
check on that field. Populate the offset only for the RZ/{G2L,G2LC,G2UL,
Five} hardware configuration, which is where the register is known to
exist.
Currently the DP SDP log helpers use spaces for indentation. Switch to
tabs for indentation and use drm_printf_indent to keep the format
strings readable.
drm/dp: Add a helper to get the SDP type as a string
Introduce dp_sdp_type_get_name() to get the SDP type as a string.
Use this to log the SDP type based on the sdp_type fields of the
VSC and AS SDPs instead of the hardcoded strings.
v2: Modify the SDP names to match the DisplayPort Spec. (Ville)
drm/dp: Store coasting vtotal in struct drm_dp_as_sdp
Add new field in struct drm_dp_as_sdp to store coasting vtotal.
This is used by the sinks that support Panel Replay and Asynchronous
timing during PR Active to derive refresh rate, when AS SDP transmission
is stopped by the source.
drm/dp: Add DPCD for configuring AS SDP for PR + VRR
Add additional DPCDs required to be configured to support VRR with Panel
Replay. These DPCDs are specifically required for configuring Adaptive Sync
SDP and are introduced in DP v2.1.
v2:
- Correct the shift for the bits. (Ville)
- Add DP_PR_ prefix for the PR-related fields.
v3:
- Use macro values in their shifted form to match the convention. (Ville)
v4:
- Add macro for the mask. (Ville)
drm/dp: Rename and relocate AS SDP payload field masks
The AS SDP payload field masks were misnamed and placed under the DPRX
feature enumeration list. These are not DPRX capability bits, but are
payload field masks for the Adaptive Sync SDP.
Relocate both masks next to the AS SDP definitions.
Update users to the corrected names. No functional change.
Chen Wandun [Mon, 11 May 2026 08:18:38 +0000 (16:18 +0800)]
cgroup/cpuset: Skip hardwall ancestor scan in cpuset v2 in cpuset_current_node_allowed()
Cgroup v2 doesn't have the concept of memory hardwall, only top_cpuset
has CS_MEM_EXCLUSIVE/CS_MEM_HARDWALL flags, nearest_hardwall_ancestor
always returns top_cpuset with all nodes set, so no need to acquire
callback_lock and scan up cpuset.
Tejun Heo [Mon, 11 May 2026 08:53:08 +0000 (22:53 -1000)]
Merge branch 'for-7.1-fixes' into for-7.2
Pull to receive dde2f938d02f ("cgroup/cpuset: move PF_EXITING check
before __GFP_HARDWALL in cpuset_current_node_allowed()") as a
dependency for an upcoming patch in the same function.
Andrea Righi [Mon, 11 May 2026 08:31:30 +0000 (10:31 +0200)]
sched_ext: Clear ops->priv on scx_alloc_and_add_sched() error paths
scx_alloc_and_add_sched() can fail after @sch has been assigned to
ops->priv. In those cases @sch is torn down (either via kfree() through
the err_free_* chain or via kobject_put() -> scx_kobj_release() -> RCU
work), but @ops->priv is left pointing at the about-to-be-freed pointer.
With the recent -EBUSY gate in scx_root_enable_workfn() and
scx_sub_enable_workfn() that rejects an attach when @ops->priv is still
non-NULL, see commit bbf30b383cf6 ("sched_ext: Fix ops->priv clobber on
concurrent attach/detach"), a dangling @ops->priv permanently locks the
kdata out: every future attach attempt sees a stale binding and returns
-EBUSY even though no scheduler is actually attached.
Clear @ops->priv on the post-assign failure paths so that the kdata
returns to its pre-attach state when the function returns ERR_PTR().
ceph: add ceph_has_realms_with_quotas() check to ceph_quota_update_statfs()
When MDS rejects a session, remove_session_caps() ->
__ceph_remove_cap() -> ceph_change_snap_realm() clears
i_snap_realm for every inode that loses its last cap.
The realm is restored once caps are re-granted after
reconnect. It is not a real error and this patch changes
pr_err_ratelimited_client() on doutc().
Every quota methods ceph_quota_is_max_files_exceeded(),
ceph_quota_is_max_bytes_exceeded(),
ceph_quota_is_max_bytes_approaching() calls
ceph_has_realms_with_quotas() check. This patch adds
the missing ceph_has_realms_with_quotas() call into
ceph_quota_update_statfs().
[ idryomov: add braces around both arms of multiline ifs ]
libceph: Fix potential out-of-bounds access in __ceph_x_decrypt()
In __ceph_x_decrypt(), a part of the buffer p is interpreted as a
ceph_x_encrypt_header, and the magic field of this struct is accessed.
This happens without any guarantee that the buffer is large enough to
hold this struct. The function parameter ciphertext_len represents the
length of the ciphertext to decrypt and is guaranteed to be at most the
remaining size of the allocated buffer p. However, this value is not
necessarily greater than sizeof(ceph_x_encrypt_header). E.g., a message
frame of type FRAME_TAG_AUTH_REPLY_MORE, that is just as long to hold
the ciphertext at its end with a ciphertext_len of 8 or less, can
trigger an out-of-bounds memory access when accessing hdr->magic.
This patch fixes the issue by adding a check to ensure that the
decrypted plaintext in the buffer is large enough to represent at least
the ceph_x_encrypt_header.
Commit d93231a6bc8a ("ceph: prevent a client from exceeding the MDS
maximum xattr size") moved the required_blob_size computation to before
the __build_xattrs() call, introducing a race.
__build_xattrs() releases and reacquires i_ceph_lock during execution.
In that window, handle_cap_grant() may update i_xattrs.blob with a
newer MDS-provided blob and bump i_xattrs.version. When
__build_xattrs() detects that index_version < version, it destroys and
rebuilds the entire xattr rb-tree from the new blob, potentially
increasing count, names_size, and vals_size.
The prealloc_blob size check that follows still uses the stale
required_blob_size computed before the rebuild, so it passes even when
prealloc_blob is too small for the now-larger tree. After __set_xattr()
adds one more xattr on top, __ceph_build_xattrs_blob() is called from
the cap flush path and hits:
Fix this by recomputing required_blob_size after __build_xattrs()
returns, using the current tree state. Also re-validate against
m_max_xattr_size to fall back to the sync path if the rebuilt tree now
exceeds the MDS limit.
Cc: stable@vger.kernel.org Fixes: d93231a6bc8a ("ceph: prevent a client from exceeding the MDS maximum xattr size") Signed-off-by: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com> Reviewed-by: Alex Markuze <amarkuze@redhat.com> Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
The old_blob in __ceph_setxattr() can store
ci->i_xattrs.prealloc_blob value during the retry.
However, it is never called the ceph_buffer_put()
for the old_blob object. This patch fixes the issue of
the buffer leak.
libceph: Fix unnecessarily high ceph_decode_need() for uniform bucket
In crush_decode_uniform_bucket(), the item_weight field of the bucket
is set. This is a single field of type u32 since the uniform bucket uses
the same weight for all items. The value in ceph_decode_need() is set to
(1+b->h.size) * sizeof(u32), which is higher than actually needed.
This patch removes the call to ceph_decode_need() with the unnecessarily
high value and switches the subsequent operation from ceph_decode_32()
to ceph_decode_32_safe(), which already includes the correct bounds
check.
libceph: Fix potential out-of-bounds access in crush_decode()
A message of type CEPH_MSG_OSD_MAP containing a crush map with at least
one bucket has two fields holding the bucket algorithm. If the values
in these two fields differ, an out-of-bounds access can occur. This is
the case because the first algorithm field (alg) is used to allocate
the correct amount of memory for a bucket of this type, while the second
algorithm field inside the bucket (b->alg) is used in the subsequent
processing.
This patch fixes the issue by adding a check that compares alg and
b->alg and aborts the processing in case they differ. Furthermore,
b->alg is set to 0 in this case, because the destruction of the crush
map also uses this field to determine the bucket type, which can again
result in an out-of-bounds access when trying to free the memory pointed
to by the fields of the bucket. To correctly free the memory allocated
for the bucket in such a case, the corresponding call to kfree is moved
from the algorithm-specific crush_destroy_bucket functions to the
generic crush_destroy_bucket().
Tao Cui [Mon, 11 May 2026 06:25:20 +0000 (14:25 +0800)]
selftests/cgroup: fix misleading debug message in test_cgfreezer_time_child
The debug message says "Expect ctime <= ptime" when the test actually
expects ctime > ptime (child's freeze time should exceed parent's,
which is zero). Fix the message to match the actual expectation.
Signed-off-by: Tao Cui <cuitao@kylinos.cn> Signed-off-by: Tejun Heo <tj@kernel.org>
Tao Cui [Mon, 11 May 2026 06:15:08 +0000 (14:15 +0800)]
selftests/cgroup: fix child process escaping to parent cleanup in test_cpucg_nice
In test_cpucg_nice, the forked child process incorrectly jumps to the
parent's cleanup label on cg_write failure. This causes the child to
attempt cg_destroy on cgroups the parent is still using, and then
return to main() to continue executing tests as if it were the parent.
Replace goto cleanup with exit(EXIT_FAILURE) in the child process.
Signed-off-by: Tao Cui <cuitao@kylinos.cn> Signed-off-by: Tejun Heo <tj@kernel.org>
Hongfu Li [Mon, 11 May 2026 06:08:53 +0000 (14:08 +0800)]
selftests/cgroup: Add NULL check after malloc in cgroup_util.c
Add NULL checks after malloc() in three helper functions to prevent
NULL pointer dereference on memory allocation failure.
- cg_name()
- cg_name_indexed()
- cg_control()
These functions allocate memory with malloc() but previously called
snprintf() unconditionally, which would trigger undefined behavior
if allocation fails.
Signed-off-by: Hongfu Li <lihongfu@kylinos.cn> Signed-off-by: Tejun Heo <tj@kernel.org>
staging: rtl8723bs: replace non-standard BITn macros with BIT(n)
Remove the local BIT0-BIT31 macro definitions from osdep_service.h
and replace all usages with the kernel's BIT(n) macro from <linux/bitops.h>.
NOTE: DYNAMIC_BB_DYNAMIC_TXPWR is defined as BIT2 and used
in a bitwise NOT expression. Migrating to BIT(2) causes an
-Werror=overflow warning due to the unsigned long result not
fitting in u32. This instance has been left unconverted.
Zhenzhong Duan [Sat, 9 May 2026 02:43:46 +0000 (10:43 +0800)]
iommu/vt-d: Avoid NULL pointer dereference or refcount corruption
Commit 60f030f7418d ("iommu/vt-d: Avoid use of NULL after WARN_ON_ONCE")
fixed a NULL pointer dereference in an unlikely situation partly.
If dev_pasid is not found in the dev_pasids list, it remains NULL.
However, the teardown operations are executed unconditionally, this lead
to a NULL pointer dereference or refcount corruption.
If the domain was never attached to this IOMMU, info will be NULL, which
would cause an immediate dereference when checking --info->refcnt.
Even if info is not NULL, decrementing the refcount without having removed
a valid PASID might unbalance the count. This could lead to premature
dropping of the refcount to 0, potentially causing a use-after-free for the
remaining active devices sharing the domain.
Fix it by returning early if dev_pasid is NULL, before executing the
teardown operations.
Issue found by AI review and suggested by Kevin Tian.
https://sashiko.dev/#/patchset/20260421031347.1408890-1-zhenzhong.duan%40intel.com
Fixes: 60f030f7418d ("iommu/vt-d: Avoid use of NULL after WARN_ON_ONCE") Cc: stable@vger.kernel.org Suggested-by: Kevin Tian <kevin.tian@intel.com> Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Link: https://lore.kernel.org/r/20260422033538.95000-1-zhenzhong.duan@intel.com Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
The global static blocked domain is a dummy domain without corresponding
dmar_domain structure, accessing beyond iommu_domain structure triggers
oops easily. Fix it by return early in domain_remove_dev_pasid() like
identity domain.
Fixes: 7d0c9da6c150 ("iommu/vt-d: Add set_dev_pasid callback for dma domain") Cc: stable@vger.kernel.org Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Link: https://lore.kernel.org/r/20260421031347.1408890-1-zhenzhong.duan@intel.com Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Naval Alcalá [Sat, 9 May 2026 02:43:44 +0000 (10:43 +0800)]
iommu/vt-d: Disable DMAR for Intel Q35 IGFX
Intel Q35 integrated graphics (8086:29b2) exhibits broken DMAR
behaviour similar to other G4x/GM45 devices for which DMAR is
already disabled via quirks.
When DMAR is enabled, the system may hard lock up during boot or
early device initialization, requiring a reset.
Add the missing PCI ID to the existing quirk list to disable
DMAR for this device.
Guopeng Zhang [Sat, 9 May 2026 10:20:30 +0000 (18:20 +0800)]
cgroup/cpuset: Reset DL migration state on can_attach() failure
cpuset_can_attach() accumulates temporary SCHED_DEADLINE migration
state in the destination cpuset while walking the taskset.
If a later task_can_attach() or security_task_setscheduler() check
fails, cgroup_migrate_execute() treats cpuset as the failing subsystem
and does not call cpuset_cancel_attach() for it. The partially
accumulated state is then left behind and can be consumed by a later
attach, corrupting cpuset DL task accounting and pending DL bandwidth
accounting.
Reset the pending DL migration state from the common error exit when
ret is non-zero. Successful can_attach() keeps the state for
cpuset_attach() or cpuset_cancel_attach().
Fixes: 2ef269ef1ac0 ("cgroup/cpuset: Free DL BW in case can_attach() fails") Cc: stable@vger.kernel.org # v6.10+ Signed-off-by: Guopeng Zhang <zhangguopeng@kylinos.cn> Signed-off-by: Tejun Heo <tj@kernel.org> Reviewed-by: Chen Ridong <chenridong@huaweicloud.com> Reviewed-by: Waiman Long <longman@redhat.com>
projects / thirdparty / kernel / linux.git / log
