io.latency is documented only in terms of average latency and the avg_lat
stat, which matches rotational devices. On non-rotational devices a group
misses its target once enough of the IOs in the window individually exceed
it, and io.stat reports missed/total rather than avg_lat/win.
Describe both cases: how a miss is detected, note that the avg_lat tuning
guidance is rotational-only, and update the io.stat field list (mark
avg_lat/win as rotational-only, document missed/total).
Acked-by: Michal Koutný <mkoutny@suse.com>
Signed-off-by: Tao Cui <cuitao@kylinos.cn>
Signed-off-by: Tejun Heo <tj@kernel.org>
- Fix swiotlb initialization on systems where DRAM is located above
4GiB (such as the Tenstorrent Blackhole cards)
- Fix an out-of-bounds access in the memory hot-remove code that can
occur on Sv39 and Sv48 systems
- Avoid oopsing during boot if the SBI component of the unaligned
access performance checking code loses a race against __init
function freeing
- Avoid attempting to install the debug-enabled vDSO when it shouldn't
be built due to !CONFIG_MMU
- Avoid some sparse warnings by adding missing __iomem notations
in get_cycles{,_hi}()
- Drop an unnecessary runtime warning in the SiFive errata handler
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEElRDoIDdEz9/svf2Kx4+xDQu9KksFAmpvhjgACgkQx4+xDQu9
KkvxVRAAsKDraTKUCihar+rgSSy3MZaCIo3u3Xg7FExhF7oCNvxdeHXcjgUOFVHl
P3YwbMCm43ztnNC7jXTQyd8OZ+EqneqRNRK0Hvj+dbXLmIV/P0byIbG2VAZPmbal
vYZ7L52M2a25A30ZGSGPknc2kthLyuhM2XOxOFhd8HjJcuyF+76YQbx+Lbw6255/
s4zVAwzlmztfVKV0y8Gark32CnZfJOeytYmIixOL7daDmb1iY70oJv4828wWfVaD
FP2dQkQXfH4VPnces4h5g/0vuhYf3LL76jbXIWgYE+UMEvv2dR2IcgnfBzKLSAcH
xzQpTKr0LIywd/wdVxng1vRk9MM+ltvdNRMF1nhIAS3FvBZYbogSKP6E8vSM2YDR
NL7Qoh+lDf9tAGk2rlGr34wTR3DvX3z0LH4pNcBwQveLjqk9gQ9g+BwPYHFnqjLy
j94Nch5hA2jnWypWCgmL3d7PP96joZsogPHYT8GbXdSXCTf9nTyV7EYCtERV6nJh
CtJI595pUurT5jQx+qxSXj/PyvL4o4z5hib4Vmc6qh1fucJgsyr9/5VSMPDHzeqd
FjcLlBBMRfRAZwiGey+1+Ini0pCBSaV5HNEmKEaLsTH/wua/XFm9gOkUGl5WKyTe
yUhYppZErSmPMSXhRFEC5IkeOV8TcxHBs3+KESMMYZVbq4H5BRs=
=gw8o
-----END PGP SIGNATURE-----
Merge tag 'riscv-for-linus-7.2-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux
Pull RISC-V fixes from Paul Walmsley:
- Fix swiotlb initialization on systems where DRAM is located above
4GiB (such as the Tenstorrent Blackhole cards)
- Fix an out-of-bounds access in the memory hot-remove code that can
occur on Sv39 and Sv48 systems
- Avoid oopsing during boot if the SBI component of the unaligned
access performance checking code loses a race against __init function
freeing
- Avoid attempting to install the debug-enabled vDSO when it shouldn't
be built due to !CONFIG_MMU
- Avoid some sparse warnings by adding missing __iomem notations in
get_cycles{,_hi}()
- Drop an unnecessary runtime warning in the SiFive errata handler
* tag 'riscv-for-linus-7.2-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux:
riscv: vdso: Only try to install vDSO when present
riscv: mm: Fix out-of-bounds page-table walk during memory hot-remove
riscv: drop __init from vec_check_unaligned_access_speed_all_cpus
riscv: mm: fix SWIOTLB initialization for systems with DRAM above 4GB
riscv/sifive: remove warning in errata
riscv: time: Add missing __iomem in get_cycles() and get_cycles_hi()
LincStation E1 is an entry-level NAS device powered by the RK3568B2 SoC
with two 3.5" HDD slots (behind a SATA port multiplier) and two m.2 2280
slots for SSDs (each PCIe 3.0 x1). Other major features include:
- 4 GiB DRAM / 64 GB eMMC
- RTL8125 2.5 Gb Ethernet
- Fn-Link 6222B-SRC Wi-Fi 5 / Bluetooth module
- 1 USB 5 Gbps + 2 USB high speed ports
- HDMI output
Each HDD slot provides a GPIO input for disk presence detection and an
output for power control. Since the disks are behind a port multiplier,
there is no way to describe them in the devicetree, so the disk power
is enabled at all times by GPIO hogs, and the detection inputs are used
only as LED triggers.
The board contains several pairs of amber/white LEDs for power, disk,
m.2 slot, and network status. These are configured to use triggers when
possible. The PWM fan uses a relatively aggressive fan curve to keep
the hard disks within a safe temperature range. It may benefit from
further tuning.
The pinhole reset button is multiplexed between the SoC reset pin and
an ADC input. The mux is configured here to drive the SoC reset pin, as
this works reliably without polling by software. The adc-keys
description is included for use by a devicetree overlay if desired.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Link: https://patch.msgid.link/20260711192842.845048-5-samuel@sholland.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
LincStation E1 is an entry-level NAS device powered by the RK3568B2 SoC
with two 3.5" HDD slots and two m.2 2280 slots for SSDs. It is marketed
under the LincPlus[1] brand, but the OEM appears to be Techvision
Intelligent Technology Co., Ltd[2]. The OEM model number is TVD8322R,
which is referenced by the vendor devicetree, a sticker on the board,
and a design patent (CN309443154S) matching the system chassis.
Link: https://www.lincplustech.com/products/lincstation-e1-network-attached-storage.html [1]
Link: https://cn.techvision.com.cn [2]
Signed-off-by: Samuel Holland <samuel@sholland.org>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://patch.msgid.link/20260711192842.845048-4-samuel@sholland.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
- Fix PCI MMIO write syscall falsely reporting success for mappings not
valid for MMIO when MIO is unavailable by returning -EFAULT
- Fix CPRB parameter buffer overflows in zcrypt CCA AES cipher and ECC
private key conversion by rejecting oversized key tokens
- Fix buffer overreads and length underflow in pkey and zcrypt CCA token
validation by checking length fields against actual buffer sizes
- Fix out of bounds permission bitmap access in zcrypt EP11 admin CPRB
filtering on custom device nodes by using AP_DOMAINS as the limit
- Fix speculative permission bitmap reads in zcrypt CCA and EP11 admin
CPRB handling by sanitizing user controlled domain indexes
- Fix sensitive key material left in zcrypt CCA clear key import buffers
by scrubbing CPRB and temporary buffers after use
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEE3QHqV+H2a8xAv27vjYWKoQLXFBgFAmpvT7gACgkQjYWKoQLX
FBg7qAf/eDHPqcayM4/Rasf3P+KVoIquyl0BjBI41Lf348em9ffLdvGI+PmSgo3s
CVOPmsQY1zn4UvWrU3Wn0/Kmgo7U4xv6ODDUbvuTbjr7gUigMOYPoH3zShQJW8dY
bJ5UnbtYC5ZMpnkEFQi4F1xNd3IoOFQLnbUPaFd+5S+slUJygGNh4XjEBEUfo3yS
dyly7GWgml2obf2R4IfRG1ItP4hY8OWo0K9XrDJomh+s5WfkFy5QMlL6uEsuXzcR
iqEPTaHblvz5FhEozZmmFppM3GVclyLouxZTHYHP32OaoLOIgF9NNW4WUmXodyF/
efMV21LmtCjMcLrM4LQ1PohTtXgG+A==
=U3To
-----END PGP SIGNATURE-----
Merge tag 's390-7.2-6' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux
Pull s390 updates from Vasily Gorbik:
- Fix PCI MMIO write syscall falsely reporting success for mappings not
valid for MMIO when MIO is unavailable by returning -EFAULT
- Fix CPRB parameter buffer overflows in zcrypt CCA AES cipher and ECC
private key conversion by rejecting oversized key tokens
- Fix buffer overreads and length underflow in pkey and zcrypt CCA
token validation by checking length fields against actual buffer
sizes
- Fix out of bounds permission bitmap access in zcrypt EP11 admin CPRB
filtering on custom device nodes by using AP_DOMAINS as the limit
- Fix speculative permission bitmap reads in zcrypt CCA and EP11 admin
CPRB handling by sanitizing user controlled domain indexes
- Fix sensitive key material left in zcrypt CCA clear key import
buffers by scrubbing CPRB and temporary buffers after use
* tag 's390-7.2-6' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux:
s390/zcrypt: Fix missing mem scrub at clear key import in cca_clr2cipherkey()
s390/zcrypt: Close speculative mem read possibility
s390/zcrypt: Fix wrong domain value verification with EP11 CPRBs
s390/zcrypt: Fix buffer over-read in cca_cipher2protkey
s390/zcrypt: Validate length for CCA ECC private key requests
s390/zcrypt: Validate length for CCA AES cipher key requests
s390/pci: Fix s390_pci_mmio_write syscall error return without MIO
- Fix the boot-time memcmp() asm implementation's constraints
and optimization properties (Mauricio Faria de Oliveira)
- Move the 0xd0...0xd7 AMD Zen5 model range from the Zen6
range where it mistakenly ended up (Pratik Vishwakarma)
Signed-off-by: Ingo Molnar <mingo@kernel.org>
-----BEGIN PGP SIGNATURE-----
iQJFBAABCgAvFiEEBpT5eoXrXCwVQwEKEnMQ0APhK1gFAmpu9+0RHG1pbmdvQGtl
cm5lbC5vcmcACgkQEnMQ0APhK1j8Ig//WBoOGw9bbFkDJFUdIS59EdJS+4l7KTJh
eRxiExnwQluOpo1x4/mKAMmgqz7IoFCc0PjLXIBC3+rN+AvM5+L/qkBGtHmcaHEu
uXdU5zAYk6a7QfvK9C6k1C/v4HQKb3FLvUliJShKfLAv7ekLLvVHWxExmJYoBsrn
VxPIW3+rpnBJn4v5bLUVs/Z6h99aB4nicA4i6p7WKiy+Vr1qOSIu5T4piff27FJE
btT61yOfTKFoKgum5dI4ZYJTX29edXcJUMPidN/egJAxMQnUdI38fO/joYMreYsx
rJ3zuv3mdV+LiusPO7ZHcNVZtc09PPMM2krLrOyjSEHzhE/WGqLXNn6FKK5H+j86
xKyawqhD+2ANktj+09bFfu3cpZEz5bdifyKx6BtvgYkSEVaX055E1zzqYXZCIaVs
DqdAs3aSKNWAbJkfMONJMZ4P28ZGikppeefihG6hcAnBjAyQC9SaTOA37fHT6WQ/
bDf3NU5c+TX0TrWd696E9jy5cLjXL60jbVPL7SF7C3d8/QPPWCbOU14Dw3s4bWh+
WfptSuB9Iuk+aalRnAVWpUBI9DDUcomC3oDLLHttztXojdZPvP1zdUhDzjaJ0Im8
N8xC30PBMGIrFGJpXN4XRM3BlSxXBVGrmS/WAqE/KE51RcA5WzQBFMGBe4V3gRbO
OV3slKkCD9k=
=EHql
-----END PGP SIGNATURE-----
Merge tag 'x86-urgent-2026-08-02' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull misc x86 fixes from Ingo Molnar:
- Fix the boot-time memcmp() asm implementation's constraints
and optimization properties (Mauricio Faria de Oliveira)
- Move the 0xd0...0xd7 AMD Zen5 model range from the Zen6
range where it mistakenly ended up (Pratik Vishwakarma)
* tag 'x86-urgent-2026-08-02' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86/CPU/AMD: Carve out a Zen5 models range
x86/boot: Add volatile, clobbers and zero-length test in memcmp()
Add the Invensense ICM42607P IMU for the Anbernic RG-DS. Mount-matrix
was tested with iio-sensor-proxy and reports correct orientation.
Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
Link: https://patch.msgid.link/20260728225542.174825-10-macroalpha82@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Correct a few white-space issues, like missing space before bracket '{'
character or spurious space, which will be flagged by dt-check-style
("redundant-whitespace" warning). No functional changes.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://patch.msgid.link/20260801210247.383632-4-krzysztof.kozlowski@oss.qualcomm.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Correct a few white-space issues, like missing space before bracket '{'
character or spurious space, which will be flagged by dt-check-style
("redundant-whitespace" warning). No functional changes.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://patch.msgid.link/20260801210247.383632-3-krzysztof.kozlowski@oss.qualcomm.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Please consider pulling these changes from the signed vfs-7.2-rc6.fixes tag.
Thanks!
Christian
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQRAhzRXHqcMeLMyaSiRxhvAZXjcogUCam8K1wAKCRCRxhvAZXjc
oicvAP9SaD+BOfpqRkICUIrZ/Lz+x3bIn1a0/yjgDQlPE1xJmQD+JCqIVnvUDN2U
m89mFy/4Mq9FYnuHZ6LWMAeYYIx3OQM=
=+294
-----END PGP SIGNATURE-----
Merge tag 'vfs-7.2-rc6.fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs
Pull vfs fixes from Christian Brauner:
"binfmt_misc:
- Don't let an 'F' entry pin its own instance.
An entry registered with 'F' opens its interpreter at registration
time and holds that file until the entry is freed, so an entry
nobody removes by hand is only closed once the binfmt_misc
superblock is shut down.
If the interpreter lives on a mount that keeps that superblock
alive the two pin each other and the file is never closed. That's
reachable by pointing the interpreter at the instance itself or by
using the instance as an overlayfs lower layer, and once the mount
namespace is gone there's nothing left to unregister through
either.
- Restore write access when removing an entry.
Registering with the MISC_FMT_OPEN_FILE flag opens the interpreter
via open_exec() which denies write access for as long as the entry
exists, but removal only did filp_close() and never restored it.
The inode's i_writecount stayed permanently negative and opening
the interpreter for writing kept failing with ETXTBSY long after
the entry was gone.
- Use exe_file_deny_write_access() for the interpreter clone so both
sides base their decision on the same mode.
- Reject a flag character as the field delimiter. create_entry() pads
the buffer with the delimiter so the field parsers terminate even
on a truncated string, but check_special_flags() consumes flag
characters instead of scanning for the delimiter.
If the delimiter is itself a flag character the padding stops
acting as a terminator and the scan keeps reading past the end of
the allocation. Such a registration was always rejected, just only
after the out of bounds read has already happened.
- Don't leak the user namespace when the mount fails.
bm_get_tree() hands its reference to get_tree_keyed() and sget_fc()
moves it into sb->s_fs_info, but generic_shutdown_super() only
calls ->put_super() from inside the if (sb->s_root) branch and
bm_fill_super() can fail before either s_root or s_op is in place.
Drop the reference in ->kill_sb() instead, which runs
unconditionally.
netfs:
- Clear PG_private_2 on a copy-to-cache append failure.
- Handle a rolling buffer allocation failure in single-object
writeback and drop the extra folio reference
netfs_write_folio_single() took before the append.
- Release the previously batched readahead folios when
rolling_buffer_load_from_ra() fails in
netfs_prepare_read_iterator()
- Fix the folio_queue ENOMEM in writeback by adding a mempool and
passing gfp flags into the rolling buffer helpers.
iomap:
- Add a separate bio_set for iomap_split_ioend(). It can split bios
that already come from iomap_ioend_bioset and deadlock once that
bioset is exhausted.
afs:
- Set call->async for an asynchronous afs_fs_fetch_data() the way
afs_fs_fetch_data64() already does.
- Subtract subreq->transferred from subreq->len in
afs_fs_fetch_data() rather than adding it.
- Fix a UAF when sending a message"
* tag 'vfs-7.2-rc6.fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs:
iomap: add a separate bio_set for iomap_split_ioend
binfmt_misc: don't leak the user namespace when the mount fails
binfmt_misc: reject a flag character as the field delimiter
binfmt_misc: use exe_file_deny_write_access() for the interpreter clone
binfmt_misc: restore write access when removing an entry
binfmt_misc: don't let an 'F' entry pin its own instance
netfs: Fix folio_queue ENOMEM in writeback by adding a mempool
netfs: release readahead folios on iterator preparation failure
netfs: handle single writeback rolling buffer allocation failure
netfs: clear PG_private_2 on copy-to-cache append failure
afs: Fix UAF when sending a message
afs: Fix afs_fs_fetch_data() to subtract transferred from len
afs: Fix afs_fs_fetch_data() to set call->async
No core changes. The largest driver fix is the reversion of threaded
interrupt handlers in UFS and the next is the resume deadlock fix in
hisi_sas which extends into libsas.
Signed-off-by: James E.J. Bottomley <James.Bottomley@HansenPartnership.com>
-----BEGIN PGP SIGNATURE-----
iLgEABMIAGAWIQTnYEDbdso9F2cI+arnQslM7pishQUCam86+xsUgAAAAAAEAA5t
YW51MiwyLjUrMS4xMiwyLDImHGphbWVzLmJvdHRvbWxleUBoYW5zZW5wYXJ0bmVy
c2hpcC5jb20ACgkQ50LJTO6YrIVcnwD/QWD/DCvLd533SY0vE2fZYVYnUVi3uzAy
OGkbmxKtCSABAO/djRxNN1CTDtVXnhUhp/VLn0niXfy4jLmCkoWpnD2N
=ERuj
-----END PGP SIGNATURE-----
Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi
Pull SCSI fixes from James Bottomley"
"No core changes. The largest driver fix is the reversion of threaded
interrupt handlers in UFS and the next is the resume deadlock fix in
hisi_sas which extends into libsas"
* tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
scsi: ufs: core: Initialize hba->rpmbs list in ufshcd
scsi: mpi3mr: Fix potential deadlock in mpi3mr_fault_uevent_emit
scsi: target: Clear cmd_cnt when initial counter enrollment fails
scsi: zfcp: Fix memory leak during adapter release by destroying gid_pn_req
scsi: ufs: core: Revert "Delegate the interrupt service routine to a threaded IRQ handler"
scsi: ufs: core: Cancel RTC work in active-active suspend
scsi: scsi_debug: Fix REPORT ZONES alloc_len underflow OOB write
scsi: target: iblock: Fix wrong PR ops NULL check for PREEMPT/RELEASE
scsi: ufs: dt-bindings: Add missing mcq reg for qcom,sa8255p-ufshc
scsi: libsas: Fix HA resume deadlock and hisi_sas disk-wake race
scsi: libiscsi_tcp: Bound SCSI Response data segment to the connection buffer
scsi: libiscsi: Fix stale-data leak into the SCSI sense buffer
mchp_tc_probe() reads the devicetree "reg" cell - a u32, per the API
contract of of_property_read_u32_index() - into a signed int, so the
bounds check "channel > 2" fails to reject cell values at or above
0x80000000: reinterpreted as a negative int, they compare below 2 and
pass validation.
A malformed devicetree can therefore drive a negative channel into the
ATMEL_TC_REG() offset arithmetic, making the driver access syscon
regmap offsets outside the TC block's register window, and into the
"t%d_clk" clock-name formatting, where it truncates clk_name (sized
for "t0_clk".."t2_clk").
Declare channel as u32, matching the API contract; the unsigned
comparison then rejects everything except channels 0..2. Adjust the
format specifier to %u accordingly, which also resolves the W=1
warning that exposed the gap:
microchip-tcb-capture.c:520:56: warning: '%d' directive output may
be truncated writing between 1 and 11 bytes into a region of size
6 [-Wformat-truncation=]
note: directive argument in the range [-2147483648, 2]
No behavior change for well-formed devicetrees: channels 0..2 take
identical paths before and after.
Fixes: 106b104137 ("counter: Add microchip TCB capture counter")
Assisted-by: Claude:claude-fable-5 [gcc W=1]
Signed-off-by: Babanpreet Singh <bbnpreetsingh@gmail.com>
Reviewed-by: Joshua Crofts <joshua.crofts1@gmail.com>
Link: https://lore.kernel.org/r/20260714042910.7-1-bbnpreetsingh@gmail.com
Signed-off-by: William Breathitt Gray <wbg@kernel.org>
The ACPI spec bizarrely indicates that the PMU interrupt can be
edge-triggered, which contradicts the very basics of the PMU
architecture (SW is required to clear the interrupt condition for
the level to drop).
Remove the code parsing this flag and always flag the interrupt
as level triggered, no matter what firmware says.
Signed-off-by: Marc Zyngier <maz@kernel.org>
Reviewed-by: Zenghui Yu <yuzenghui@huawei.com>
Signed-off-by: Will Deacon <will@kernel.org>
If we have 64-bit counters, we can reasonably assume we'll never have to
handle an overflow before the end of the universe (since we're a system
PMU with no sampling). Thus even if firmware does specify an IRQ, we can
still continue in the event of being unable to request it. This can help
systems where IRQs cannot be claimed exclusively, or are broken in other
ways.
Reviewed-by: Ilkka Koskinen <ilkka@os.amperecomputing.com>
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Will Deacon <will@kernel.org>
When waiting for a sub-module to register, we return a bare
-EPROBE_DEFER that ends up showing the end user:
platform arm-cs-arch-pmu.1: deferred probe pending (no reason)
wherein it's not necessarily clear that they might need to take some
action to ensure the appropriate module is available to load. Let's use
dev_err_probe() here so we can show exactly what we're waiting for.
Similarly, in the case where something's gone horribly wrong with an
already-registered module, we can use dev_WARN() to standardise the
device/driver attribution rather than just open-coding "arm_cspmu".
Reviewed-by: Ilkka Koskinen <ilkka@os.amperecomputing.com>
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Will Deacon <will@kernel.org>
On ACPI systems, it has not actually been possible for userspace to
reliably tell which PMU corresponds to which APMT entry for types
other than "ACPI device" - the evidence trail only leads from the
arbitrarily-numbered PMU device to its arbitrarily-numbered parent
platform device that has no distinguishing features either.
While we've now improved the platform device creation to associate the
actual APMT unique ID, we may as well also tweak the PMU devices to
substitute the arbitrary number with a different arbitrary number that
might be more directly meaningful based on the APMT definitions.
We don't have an equivalent for Devicetree, but in that case the
platform devices are at least identifiable via their sysfs-visible
of_node.
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Reviewed-by: Ilkka Koskinen <ilkka@os.amperecomputing.com>
[will: Remove unneeded semicolon reported by coccinelle]
Signed-off-by: Will Deacon <will@kernel.org>
The APMT node format includes a unique identifier, so we can use this as
the platform device ID to give userspace stable and identifiable device
names, rather than auto numbering dependent on how the table is parsed.
Cc: Lorenzo Pieralisi <lpieralisi@kernel.org>
Cc: Hanjun Guo <guohanjun@huawei.com>
Cc: Sudeep Holla <sudeep.holla@kernel.org>
Reviewed-by: Ilkka Koskinen <ilkka@os.amperecomputing.com>
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Reviewed-by: Hanjun Guo <guohanjun@huawei.com>
Signed-off-by: Will Deacon <will@kernel.org>
Implement CRB filtering per CXL 4.0 8.2.7.2.2, and extend the
current filtering support beyond HDM. CRB filtering is only
permitted for the DDR Interface, Queue Occupancy, Queue Residency
and Retry event groups (CXL 4.0 Table 13-5), and only when counting
a single event (a single mask bit). Because these group IDs are
scoped by the CXL vendor ID, events from other vendors are also
rejected. For example, to count DDR activates on channel 2 only:
perf stat -a -e cxl_pmu_mem0.0/ddr_act,crb_filter_en=1,crb=0x02FFFFFF/
Placing the 32-bit CRB value at config2:32-63 leaves the
existing HDM value at config2:0-15 untouched and avoids needing
a new config3.
Signed-off-by: Harshal Thakkar <harshal.t@samsung.com>
[davidlohr: multiple fixes]
Signed-off-by: Davidlohr Bueso <dave@stgolabs.net>
Reviewed-by: Richard Cheng <icheng@nvidia.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Will Deacon <will@kernel.org>
Add support for CXL 4.0 events that are exposed by the CPMU hardware
but not present in the driver. Such events are defined in Table 13-5
of the spec.
Signed-off-by: Harshal Thakkar <harshal.t@samsung.com>
[davidlohr: add missing throttle and queue occupancy events]
Signed-off-by: Davidlohr Bueso <dave@stgolabs.net>
Reviewed-by: Richard Cheng <icheng@nvidia.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Will Deacon <will@kernel.org>
The HDM decoder filter configuration register is 32 bits wide, but the
driver programs it with a 64-bit writeq(). The filter value never
exceeds 32 bits, so the upper half of the write is always zero and
lands in the adjacent Filter ID 1 (Channel/Rank/Bank) configuration
register at offset+4.
Fixes: 5d7107c727 ("perf: CXL Performance Monitoring Unit driver")
Signed-off-by: Davidlohr Bueso <dave@stgolabs.net>
Reviewed-by: Richard Cheng <icheng@nvidia.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Will Deacon <will@kernel.org>
Commit 3e360ef0c0 ("kselftest/arm64: Corrupt P0 in the irritator when
testing SSVE") added corruption of P0 to the sve-test case in order to
ensure that the predicate registers were covered as part of the
corruption. On SME only systems this results in an illegal instruction
since signal handlers are run out of streaming mode and the predicate
registers do not exist out of streaming mode without SVE. Switch to
entering and exiting streaming mode in the irritator, this will reset
all relevant registers to 0 if they somehow weren't already by the
signal entry.
Fixes: 3e360ef0c0 ("kselftest/arm64: Corrupt P0 in the irritator when testing SSVE")
Reported-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Will Deacon <will@kernel.org>
syscall_get_arguments() returns 'regs->orig_x0' for the first system
call argument so as to avoid aliasing with the syscall return value in
'regs->regs[0]' on the return path, however the actual syscall
invocation passes 'regs->regs[0]' as the first parameter.
Although the two registers should be kept in sync during syscall entry
for native tasks, pass 'regs->orig_x0' as the first syscall parameter
for consistency with the syscall argument APIs. Compat tasks continue to
use 'regs->regs[0]' for compatibility with the behaviour of the 32-bit
kernel.
Suggested-by: Jinjie Ruan <ruanjinjie@huawei.com>
Signed-off-by: Will Deacon <will@kernel.org>
Commit e057b94772 ("arm64: syscall: Ensure saved x0 is kept in-sync
with tracer updates") attempted to resolve a long-standing issue with
syscall entry tracing, where a tracer is able to manipulate the first
syscall argument without being subjected to seccomp or audit checking.
Unfortunately, that fix was incomplete [1], as it failed to update
'orig_x0' between a tracer updating x0 during a seccomp ptrace exit
(SECCOMP_RET_TRACE) and the seccomp filter being re-evaluated.
Rather than add hooks to the core seccomp code, instead move the
synchronisation code into the ptrace GPR and syscall setting code so
that 'orig_x0' is kept up to date with x0 whenever we're stopped on the
syscall entry path.
Cc: Kees Cook <kees@kernel.org>
Cc: Jinjie Ruan <ruanjinjie@huawei.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Link: https://sashiko.dev/#/patchset/20260716120640.6590-1-will@kernel.org [1]
Reported-by: Yiqi Sun <sunyiqixm@gmail.com>
Link: https://lore.kernel.org/all/20260529065444.1336608-1-sunyiqixm@gmail.com/
Fixes: e057b94772 ("arm64: syscall: Ensure saved x0 is kept in-sync with tracer updates")
Fixes: a5cd110cb8 ("arm64/ptrace: run seccomp after ptrace")
Tested-by: Jinjie Ruan <ruanjinjie@huawei.com>
Signed-off-by: Will Deacon <will@kernel.org>
Add a selftest that verifies the kernel re-evaluates a seccomp filter
with the correct (ptrace-modified) first argument after
a SECCOMP_RET_TRACE stop. On arm64, syscall_get_arguments() reads
the first argument from orig_x0, which may be stale if the tracer modified
regs->regs[0] but orig_x0 was not synced. This can cause the filter to
see an old argument and incorrectly allow a syscall that it should
have rejected.
The child installs a filter that:
- TRACEs write() when fd == 2
- returns ERRNO(EPERM) when fd == 1
The parent catches the SECCOMP event, changes x0 (fd) from 2 to 1,
and resumes the child.
If the seccomp re-evaluation sees the stale orig_x0 (fd=2) the filter
returns TRACE again and the kernel (with recheck_after_trace=true)
allows the syscall to proceed – write succeeds and the child exits 0.
If the seccomp re-evaluation sees the new value (fd=1) the filter
returns ERRNO(EPERM), write fails and the child exits non-zero.
The test passes only when the write fails (child exit != 0).
Before the fix:
# ./seccomp_ret_trace_x0_bypass
TAP version 13
1..1
not ok 1 write succeeded, orig_x0 bypass likely
# Totals: pass:0 fail:1 xfail:0 xpass:0 skip:0 error:0
After the fix:
# ./seccomp_ret_trace_x0_bypass
TAP version 13
1..1
ok 1 seccomp correctly denied modified syscall
# Totals: pass:1 fail:0 xfail:0 xpass:0 skip:0 error:0
Cc: Kees Cook <kees@kernel.org>
Cc: Will Deacon <will@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Link: https://lore.kernel.org/all/20260717182758.17111-1-will@kernel.org/
Link: https://lore.kernel.org/all/20260716120640.6590-1-will@kernel.org/
Link: https://lore.kernel.org/all/202607152004.DEA95D63@keescook/
Suggested-by: Kees Cook <kees@kernel.org>
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
Signed-off-by: Will Deacon <will@kernel.org>
As Kees suggested, add a test that verifies that seccomp observes the
correct first argument after a ptracer modifies x0 at a syscall-enter-stop
on arm64.
The first syscall argument and the return value share register x0.
The original value is saved in orig_x0 on entry and used by
syscall_get_arguments(), but ptrace changes to x0 were not
automatically reflected there. This test checks the kernel re-syncs
orig_x0 after a ptrace stop so that seccomp sees the modified
argument.
A seccomp filter allows write(2,...) and kills the task for any other
fd. The tracer changes fd from 2 to 1 at entry. If orig_x0 remains
stale, the child exits normally (bypass, test fails). If orig_x0 is
correctly updated, the child is killed by SIGSYS (test passes).
Before the fix:
./seccomp_ptrace_x0_bypass
TAP version 13
1..1
not ok 1 seccomp_ptrace_x0_bypass
# Totals: pass:0 fail:1 xfail:0 xpass:0 skip:0 error:0
After the fix:
# ./seccomp_ptrace_x0_bypass
TAP version 13
1..1
[ 19.475951] audit: type=1326 audit(1784254846.284:2): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=227 comm="seccomp_ptrace_" exe="/mnt/seccomp0
[ 19.477852] audit: type=1701 audit(1784254846.284:3): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=227 comm="seccomp_ptrace_" exe="/mnt/seccomp1
ok 1 seccomp_ptrace_x0_bypass
# Totals: pass:1 fail:0 xfail:0 xpass:0 skip:0 error:0
Cc: Kees Cook <kees@kernel.org>
Cc: Will Deacon <will@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Link: https://lore.kernel.org/all/20260716120640.6590-1-will@kernel.org/
Link: https://lore.kernel.org/all/202607152004.DEA95D63@keescook/
Suggested-by: Kees Cook <kees@kernel.org>
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
Signed-off-by: Will Deacon <will@kernel.org>
The checks on the header size reported for the inactive regset of the
NT_ARM_SVE/NT_ARM_SSVE pair compare it against sizeof(sve), but sve is
a struct user_sve_header *, so this is 8 rather than the intended 16.
The kernel carried the identical typo when filling in the header, so
kernel and test agreed on the wrong value and the test passed.
Compare against sizeof(*sve), stop after the header checks for an
inactive regset since it has no payload to compare, and prefill the
buffer with a sentinel to verify that reading an inactive regset
leaves everything after the header untouched. This also covers the
getter's return value, which determines how many bytes ptrace copies
back to userspace.
Fixes: 864f3ddcd7 ("kselftest/arm64: fp-ptrace: Adjust to new inactive mode behaviour")
Assisted-by: Claude:claude-opus-5
Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
Signed-off-by: Will Deacon <will@kernel.org>
sve_init_header_from_task() takes header as a pointer, so for the
inactive mode
header->size = sizeof(header);
stores 8 rather than sizeof(struct user_sve_header), which is 16.
Userspace sees an impossible size smaller than the header it
describes.
The inactive-mode check in sve_get_common() compares header.size
against sizeof(header) as well, but there header is a struct, so the
check can never fire. Reads of NT_ARM_SVE and NT_ARM_SSVE for the
inactive mode therefore still return the other mode's FPSIMD data,
exactly the situation the check was added to prevent.
Fix the size, and make the check return the remaining membuf space
instead of 0, which regset_get() would interpret as the entire
(zero-filled) buffer having been populated.
Fixes: b93e685ecf ("arm64/fpsimd: ptrace: Do not present register data for inactive mode")
Assisted-by: Claude:claude-opus-5
Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
Signed-off-by: Will Deacon <will@kernel.org>
T241-MPAM-6 causes all MBWU counter formats to count 64-byte
requests instead of bytes. Commit dc48eb1ff2 excluded the 63-bit
MSMON_MBWU_LWD format while scaling the shorter counters. Systems
selecting the preferred 63-bit counter consequently report bandwidth
values that are 64 times too small.
Apply the scale to both the sampled value and overflow correction for
the 63-bit format. Unsigned arithmetic retains modulo-u64 behavior
when the scaled counter range exceeds u64.
Fixes: dc48eb1ff2 ("arm_mpam: Add workaround for T241-MPAM-6")
Link: https://lore.kernel.org/lkml/20240816131432.993859-1-sdonthineni@nvidia.com/
Signed-off-by: Shanker Donthineni <sdonthineni@nvidia.com>
Reviewed-by: Fenghua Yu <fenghuay@nvidia.com>
Tested-by: Fenghua Yu <fenghuay@nvidia.com>
Reviewed-by: Ben Horgan <ben.horgan@arm.com>
Signed-off-by: Ben Horgan <ben.horgan@arm.com>
Signed-off-by: Will Deacon <will@kernel.org>
Memory bandwidth monitoring make uses of MBWU monitors and is now exposed
to the user via resctrl. Add some documentation so the user knows what to
expect.
Co-developed-by: James Morse <james.morse@arm.com>
Signed-off-by: James Morse <james.morse@arm.com>
Signed-off-by: Ben Horgan <ben.horgan@arm.com>
Reviewed-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com>
Reviewed-by: Fenghua Yu <fenghuay@nvidia.com>
Reviewed-by: Gavin Shan <gshan@redhat.com>
Signed-off-by: Will Deacon <will@kernel.org>
ABMC, mbm_event mode, has a helper resctrl_arch_config_cntr() for changing
the mapping between 'cntr_id' and a CLOSID/RMID pair.
Add the helper.
For MPAM this is done by updating the mon->mbwu_idx_to_mon[] array, and as
usual CDP means it needs doing in three different ways.
Signed-off-by: James Morse <james.morse@arm.com>
Signed-off-by: Ben Horgan <ben.horgan@arm.com>
Tested-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com>
Tested-by: Fenghua Yu <fenghuay@nvidia.com>
Tested-by: Gavin Shan <gshan@redhat.com>
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Reviewed-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com>
Reviewed-by: Fenghua Yu <fenghuay@nvidia.com>
Reviewed-by: Gavin Shan <gshan@redhat.com>
Signed-off-by: Will Deacon <will@kernel.org>
MPAM is able to emulate ABMC, i.e. mbm_event mode, by making memory
bandwidth monitors assignable. Rather than supporting the 'default'
mbm_assign_mode always use 'mbm_event' mode even if there are sufficient
memory bandwidth monitors. The per monitor event configuration is only
provided by resctrl when in 'mbm_event' mode and so only allowing
'mbm_event' mode will make it easier to support per-monitor event
configuration for MPAM. For the moment, the only event supported is
mbm_total_event with no bandwidth type configuration. The 'mbm_assign_mode'
file will still show 'default' when there is no support for memory
bandwidth monitoring.
The monitors need to be allocated from the driver, and mapped to whichever
control/monitor group resctrl wants to use them with.
Add a second array to hold the monitor values indexed by resctrl's cntr_id.
When CDP is in use, two monitors are needed so the available number of
counters halves. Platforms with one monitor will have zero monitors when
CDP is in use.
Co-developed-by: James Morse <james.morse@arm.com>
Signed-off-by: James Morse <james.morse@arm.com>
Signed-off-by: Ben Horgan <ben.horgan@arm.com>
Tested-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com>
Tested-by: Fenghua Yu <fenghuay@nvidia.com>
Tested-by: Gavin Shan <gshan@redhat.com>
Reviewed-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com>
Reviewed-by: Fenghua Yu <fenghuay@nvidia.com>
Reviewed-by: Gavin Shan <gshan@redhat.com>
Signed-off-by: Will Deacon <will@kernel.org>
resctrl has two types of bandwidth counters, NUMA-local and global. MPAM
can only count globally; either using MSC at the L3 cache or in the memory
controllers. When global and local equate to the same thing continue just
to call it global.
Pick the corresponding MPAM classes to back the MBM counters. As resctrl
requires all monitors to be at the L3 cache, we can only use the counters
at the memory controllers when they have the same topology as the L3 cache
and the traffic they see if the same. In particular, for the bandwidth
counters at the memory controllers to be exposed to resctrl it is required
there is a single L3 cache and a single NUMA node as otherwise cross NUMA
traffic will be counted at the wrong instance.
Signed-off-by: James Morse <james.morse@arm.com>
Signed-off-by: Ben Horgan <ben.horgan@arm.com>
Tested-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com>
Tested-by: Zeng Heng <zengheng4@huawei.com>
Tested-by: Fenghua Yu <fenghuay@nvidia.com>
Tested-by: Gavin Shan <gshan@redhat.com>
Reviewed-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com>
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Reviewed-by: Fenghua Yu <fenghuay@nvidia.com>
Reviewed-by: Gavin Shan <gshan@redhat.com>
Signed-off-by: Will Deacon <will@kernel.org>
Sashiko reported that during CPU offlining, __cpu_disable() is
executed by the stopper thread via take_cpu_down() with local
interrupts disabled. __cpu_disable() calls ipi_teardown(), which
invokes ipi_lpi_disable(). For the GICv5 flow, this eventually calls
the sleepable disable_irq().
This can be reproduced easily with CONFIG_DEBUG_ATOMIC_SLEEP=y by
offlining a CPU:
BUG: sleeping function called from invalid context at kernel/irq/manage.c:702
in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 20, name: migration/1
preempt_count: 1, expected: 0
no locks held by migration/1/20.
irq event stamp: 186
hardirqs last enabled at (185): [<ffff800080b084c8>] _raw_spin_unlock_irq+0x38/0x68
hardirqs last disabled at (186): [<ffff8000801f8e08>] multi_cpu_stop+0xc8/0x190
softirqs last enabled at (80): [<ffff8000800c48b8>] handle_softirqs+0x410/0x468
softirqs last disabled at (75): [<ffff8000800102f4>] __do_softirq+0x1c/0x28
Fix this by using disable_irq_nosync() instead, which is safe in this
atomic context.
Fixes: ba1004f861 ("arm64: smp: Support non-SGIs for IPIs")
Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
Signed-off-by: Will Deacon <will@kernel.org>
A CPU wedged with interrupts masked ignores the stop IPI, and without
pseudo-NMI there is no NMI IPI to escalate to: a reboot proceeds with
the CPU still running, and a kdump misses its registers.
Add a third rung to smp_send_stop(): once the IPI (and pseudo-NMI IPI,
if enabled) rungs have run, signal SDEI event 0 at whatever stayed
online. Firmware delivers it regardless of the target's DAIF, so it
reaches a CPU a plain IPI cannot; the target acks by going offline,
which the caller already polls for.
Fold the stop bookkeeping into one arm64_nmi_cpu_stop(regs,
die_on_crash), shared by the stop IPI handlers, panic_smp_self_stop()
and the SDEI handler, replacing the near-duplicate local_cpu_stop() and
ipi_cpu_crash_stop(). @die_on_crash is the only difference: the IPI
handlers pass true and PSCI CPU_OFF the CPU on a crash stop so a capture
kernel can reclaim it; the SDEI handler and self-stop pass false and
park. The SDEI park is required, not conservative -- its handler runs
inside an SDEI event that is never completed (completing it resumes the
wedged context), and a CPU_OFF from that unfinished-event context wedges
EL3 on some firmware (left as a follow-up). The dump is unaffected; only
re-onlining the CPU in an SMP capture kernel is lost.
Suggested-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Kiryl Shutsemau (Meta) <kas@kernel.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Tested-by: Yin Fengwei <fengwei_yin@linux.alibaba.com>
Signed-off-by: Will Deacon <will@kernel.org>
Deliver an NMI-like event to an interrupt-masked arm64 CPU via the
standard SDEI software-signalled event (event 0), without the pseudo-NMI
hot-path cost: register a handler for event 0 and poke a target with
sdei_event_signal(0, mpidr).
First user is arch_trigger_cpumask_backtrace() (sysrq-l, RCU stalls,
hung-task/soft-lockup dumps), which otherwise rides an IPI that can't
reach a masked CPU. Falls back to the IPI path when SDEI is absent; no
watchdog backend yet, so the stock detector is untouched.
Signed-off-by: Kiryl Shutsemau (Meta) <kas@kernel.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Tested-by: Yin Fengwei <fengwei_yin@linux.alibaba.com>
Signed-off-by: Will Deacon <will@kernel.org>
Add sdei_event_signal(), a thin wrapper over the SDEI_EVENT_SIGNAL call
(DEN0054) that makes the software-signalled event (event 0) pending on a
target PE -- delivered NMI-like even when that PE has interrupts masked.
It takes no locks, so it is safe to call from NMI / crash context.
Signed-off-by: Kiryl Shutsemau (Meta) <kas@kernel.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Tested-by: Yin Fengwei <fengwei_yin@linux.alibaba.com>
Signed-off-by: Will Deacon <will@kernel.org>
invoke_sdei_fn() returns -EIO when no SDEI conduit was probed, and the
core warns ("Failed to create event ...") on any registration that hits
that. An optional consumer that registers an event from an unconditional
initcall would therefore make every boot on a non-SDEI system emit that
warning for what is simply absent firmware.
Expose whether SDEI firmware is present so such a consumer can skip
registration -- and the warning -- when there is nothing to talk to.
Signed-off-by: Kiryl Shutsemau (Meta) <kas@kernel.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Tested-by: Yin Fengwei <fengwei_yin@linux.alibaba.com>
Signed-off-by: Will Deacon <will@kernel.org>
There is no functional requirement to keep the entries in arm64's
tools/cpucaps file sorted alphabetically and, in fact, they have fallen
out of order over time. Given that only the arm64 tree touches this file
and the perceived benefit of sorting was to help with conflicts, just
remove the stale comment and accept that we're collectively not very
good at the alphabet.
In the limited cases where a specific ordering is important, we enforce
it through build-time assertions (e.g. in can_use_gic_priorities()).
Cc: Catalin Marinas <catalin.marinas@arm.com>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Reviewed-by: Fuad Tabba <fuad.tabba@linux.dev>
Reported-by: Marc Zyngier <maz@kernel.org>
Acked-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Will Deacon <will@kernel.org>
On systems where CLIDR_EL1.LoC == 0, no cache maintenance is required
when cleaning or invalidating to the Point of Coherency and therefore
all DMA agents can be treated as coherent.
Extend arch_setup_dma_ops() to take CLIDR_EL1.LoC into account when
setting the DMA ops for a device, emitting a warning message if the
firmware advertises a non-coherent device on a fully coherent system.
Cc: Steffen Eiden <seiden@linux.ibm.com>
Cc: Andreas Grapentin <gra@linux.ibm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Marc Zyngier <maz@kernel.org>
Signed-off-by: Will Deacon <will@kernel.org>
A robust futex unlock stores 0 over the whole futex value - wiping
FUTEX_WAITERS - and wakes a single waiter. That wakeup is a one-shot
notification: the protocol relies on its recipient to either acquire the
futex (and eventually unlock while aware of the remaining contention) or
re-arm FUTEX_WAITERS before sleeping again. If the woken waiter is killed
before it can do either, the kernel must jump in and wake the next task
down the line.
This is a known complication of the futex protocol with a previous
partial fix in commit ca16d5bee5 ("futex: Prevent robust futex exit
race"). Unfortunately, that fix is insufficient.
If a third task re-acquired the futex through the uncontended fast
path in the meantime, the notification is lost: robust exit processing
sees that it is owned by another task and does nothing, while the new
owner sees no FUTEX_WAITERS when it unlocks and wakes nobody.
The remaining waiters sleep forever behind a free futex:
A owns the futex, B and C sleep in FUTEX_WAIT
uval == A | FUTEX_WAITERS
A robust unlock: store 0, FUTEX_WAKE(1) wakes B
uval == 0
D fast path acquire: cmpxchg(0 -> D)
uval == D, no FUTEX_WAITERS
B killed before acting on the wakeup
B exit walk, pending op: owner D != B -> no action
D unlock: no FUTEX_WAITERS -> no wake
C sleeps forever
This is clearly a shortcoming in the implementation, which fails to keep
the FUTEX_WAITERS bit consistent.
Work around this by augmenting the robust list exit processing to also
perform the extra wakeup if the futex word is owned by another thread but
FUTEX_WAITERS is not set.
This does not fix the problem of a non-contended take over/release and free
sequence, which has been discussed for years and has been addressed by
commit 3ca9595d9f ("futex: Add support for unlocking robust futexes") and
subsequent changes, but failed to take the problem described above into
account.
A more complete solution which is based on the in kernel unlock of
contended robust futexes has been discussed in the context of this change
and should show up in mainline sooner than later.
[ tglx: Amend change log slightly and fixup coding style ]
Fixes: ca16d5bee5 ("futex: Prevent robust futex exit race")
Signed-off-by: Keno Fischer <keno@juliahub.com>
Signed-off-by: Thomas Gleixner <tglx@kernel.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Assisted-by: ClaudeCode:claude-fable-5 tla+
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260730194705.38981-1-keno@juliacomputing.com
Janne Grunau <j@jannau.net> says:
This series adds device trees for Apple silicon devices with M3 Pro, Max
and Ultra SoCs. The M3 generation has fewer devices than their M1 and M2
predecessors. The only non-laptop device is the M3 Ultra Mac Studio. The
Laptops are the known 14 and 16-inch Macbook Pros now with M3 Pro and
M3 Max SoCs. The M3 Max variant with fewer CPU and GPU cores has
additionally only a 384-bit wide memory bus instead of 512-bit of the
full M3 Max. It has a separate identifier (T6034) and so there are six
laptop device trees.
Another difference to M1 and M2 Pro/Max/Ultra is that the M3 Pro is
distinct SoC design and not a smaller M3 Max. For this reason both M3
Max variants and the M3 Ultra will use "apple,t6030" as compatible
prefix. In the M1 and M2 generations Pro, Max and Ultra SoCs shared
"apple,t6000" / "apple,t6020" as common prefix. There is currently no
known difference but M3 Pro and M3 Max are not as closely related as
previously.
This series adds the same level of hardware as the base M3 (T8122) has
in v7.2-rc1. This includes CPU cores, interrupt controller, power
states, watchdog, serial, pin controller, i2c and the boot framebuffer.
This is intended as base so that support for additional hardware can be
added to all M3 based devices at the same time.
Link: https://patch.msgid.link/20260724-apple-t603x-initial-devices-v3-0-bbeba0420603@jannau.net
Signed-off-by: Sven Peter <sven@kernel.org>
Minimal device trees for the M3 Pro based 14-inch and 16-inch MacBook
Pro released in November 2023. The M3 Pro is a distinct SoC design and
not a cut down version of the Max variant like for M1 and M2 Pro.
The M3 Pro has only a single cluster with up to 6 performance cores and
one cluster with 6 efficiency cores.
While it no longer shares a common SoC .dtsi the devices itself are
still similar to the ones with M3 Max. It is still useful to share the
basic device composition in t603x-j514-j516.dtsi. For the M3 Pro based
devices additional overrides for diverging pin and irq numbers are
expected.
The device trees have devices nodes for CPU cores, timer, interrupt
controller, power states, watchdog, serial, pin controller, i2c,
PWM based keyboard LED illumination and the boot framebuffer.
Reviewed-by: Sven Peter <sven@kernel.org>
Signed-off-by: Janne Grunau <j@jannau.net>
Signed-off-by: Sven Peter <sven@kernel.org>
