mirror of
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/
synced 2026-11-13 07:31:07 +00:00
1,485,420 commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
Xin Chen
|
f5afdff569 |
Bluetooth: hci_core: use skb_get() instead of skb_clone() for req_skb
BT enable fails intermittently with -ETIMEDOUT (-110). The kernel log
shows the HCI Read Local Version command was sent and the firmware
replied with status 0x00 (logged by hci_req_cmd_complete() BT_DBG),
but the waiter in __hci_cmd_sync_sk() never woke up and timed out
after 10 s:
bluetooth hci0: Opcode 0xfc00 // __hci_cmd_sync_sk
bluetooth hci0: opcode 0xfc00 plen 1 // hci_cmd_sync_add
bluetooth hci0: skb len 4 // hci_cmd_sync_alloc
bluetooth hci0: length 1 // hci_req_sync_run
Bluetooth: hci0 cmd_cnt 1 cmd queued 1 // hci_cmd_work
Bluetooth: hci0 type 1 len 4 // hci_send_frame
Bluetooth: opcode 0xfc00 status 0x00 // hci_req_cmd_complete
<-- req_skb NULL: req_complete_skb not set,
hci_cmd_sync_complete() never called,
req_status stays HCI_REQ_PEND -->
<-- 10 s later: wait_event_interruptible_timeout expires -->
bluetooth hci0: end: err -110 // __hci_cmd_sync_sk
The root cause is that hci_send_cmd_sync() clones the sent command
into hdev->req_skb so that hci_req_cmd_complete() can locate the
registered completion callback. Under memory pressure this
skb_clone() fails, leaving hdev->req_skb NULL. The firmware reply
is received and processed, but hci_req_cmd_complete() finds NULL
req_skb, so hci_cmd_sync_complete() is never called, req_status
stays HCI_REQ_PEND, and the waiter times out with -ETIMEDOUT.
req_skb is only used to read bt_cb(skb)->hci callbacks and opcode --
it is never modified. Replace skb_clone() with skb_get(), which
simply increments the reference count of hdev->sent_cmd without
allocating new memory and therefore cannot fail.
This issue was first observed as a use-after-free in ttyport_close()
when ttyport_open() failed, which was investigated in an earlier
patch series [1]. That investigation led to the discovery of the
true root cause described above.
[1] https://lore.kernel.org/all/20250430111617.1151390-1-quic_cxin@quicinc.com/
Fixes:
|
||
Valentin Kindschi
|
941929abe5 |
Bluetooth: hci_event: clear HCI_LE_ADV only on a created connection
le_conn_complete_evt() clears HCI_LE_ADV before looking at the event
status, on the premise stated in its comment that all controllers stop
advertising when a connection is created.
That premise only holds when a connection was actually created. On a
non-zero status none was, and the controller is still advertising: after
the host issues LE Create Connection Cancel the event arrives with
Unknown Connection Identifier (0x02), and a connection timeout behaves
the same way. Clearing the flag there leaves the host believing
advertising is off while the controller has it on.
It is also wrong for extended advertising, where several sets can be
advertising at once. hci_cc_le_set_ext_adv_enable() is careful about
this - on disabling one set it walks hdev->adv_instances and only clears
HCI_LE_ADV once no instance is still enabled. The unconditional clear
here discards that bookkeeping, so one set connecting drops the flag
while the others keep advertising.
The direction of the error matters. A flag left set is self-correcting:
hci_disable_advertising_sync() sends LE Set Advertising Enable(0) and
the command complete puts the state back. A flag left clear is not,
because that same function returns early without sending anything while
the flag is clear:
- LE Set Advertising Parameters is then sent to a controller that is
still advertising, and is correctly rejected with Command Disallowed
(0x0c);
- hci_enable_advertising_sync() returns at that point, before the
LE Set Advertising Enable that would set HCI_LE_ADV again.
On a controller without LE Extended Advertising that is reachable from
here: hci_schedule_adv_instance_sync() re-arms adv_instance_expire every
HCI_DEFAULT_ADV_DURATION (2 s) and its "already advertising" shortcut
tests HCI_LE_ADV, which can no longer become true, so the parameter
write is retried for as long as advertising is configured:
Bluetooth: hci0: Opcode 0x2006 failed: -16
Only clear the flag when a connection was established.
Note this is not on its own sufficient to stop that retry loop - the
redundant enable queued by hci_le_conn_failed() clears HCI_LE_ADV itself
and recreates the same mismatch, which patch 1 addresses. This patch
fixes the event handler reporting a state the controller is not in.
Verified on the affected device (BCM43455, legacy advertising only) with
this patch and patch 1 applied. A 221 s btmon capture with an out-of-range
peer at -90 dBm contains two outgoing connection attempts that the host
cancelled, each producing exactly the event this patch changes:
< LE Set Advertising Parameters 0x2006 Success
< LE Set Advertising Enable 0x200a Success
< LE Create Connection Cancel 0x200e Success
> LE Connection Complete Unknown Connection Identifier (0x02), central
Nothing follows either one; the next command is an unrelated scan restart
70 ms later. Over the whole capture: 7 LE Set Advertising Parameters sent,
all Success; 10 LE Set Advertising Enable, all Success; no Command
Disallowed of any opcode, and no 2 s cadence anywhere. Two central
connections to other peers completed normally afterwards, with feature
exchange and a connection parameter update, so advertising was still live
across the cancelled attempts.
The extended advertising case above is a code argument, not a measurement:
this controller has no LE Extended Advertising, so that path is not
exercised by the capture.
Fixes:
|
||
|
Valentin Kindschi
|
ed5fb41d3b |
Bluetooth: hci_conn: re-enable advertising only for peripheral role
hci_le_conn_failed() unconditionally calls hci_enable_advertising(), although its own comment states advertising should be re-enabled only when the failed attempt was made as a peripheral. hci_le_conn_failed() is reached from hci_conn_failed() for every failed LE connection, including outgoing central connections. For a central attempt this enable is redundant: hci_le_create_conn_sync() already restores advertising via hci_resume_advertising_sync() in its done: block. Because hci_enable_advertising() only queues the work on cmd_sync_work, it runs *after* that resume has already succeeded and set HCI_LE_ADV. The resulting HCI sequence, captured on a BCM43455 (no LE Extended Advertising, so legacy advertising is used): LE Create Connection Status Success ... 13.8 s, peer never answers ... LE Set Advertising Parameters (0x2006) Success <- done: resume, LE Set Advertising Enable (0x200a) Success HCI_LE_ADV set LE Create Connection Cancel (0x200e) Success LE Connection Complete Unknown Conn Id LE Set Advertising Parameters (0x2006) Command Disallowed (0x0c) The last command is the queued enable from hci_le_conn_failed() running as a second hci_enable_advertising_sync() pass. It clears HCI_LE_ADV (hci_sync.c, "Clear the HCI_LE_ADV bit temporarily"), then sends LE Set Advertising Parameters while the controller is still advertising, which the controller correctly rejects with Command Disallowed. The disable-first call at the top of hci_enable_advertising_sync() cannot prevent this: hci_disable_advertising_sync() returns early without sending anything when HCI_LE_ADV is clear, so it is a no-op exactly when the flag is wrong. hci_enable_advertising_sync() then returns without sending LE Set Advertising Enable, so HCI_LE_ADV is never set again. The legacy software rotation loop re-arms hci_schedule_adv_instance_sync() every HCI_DEFAULT_ADV_DURATION (2 s), and its "already advertising" shortcut tests HCI_LE_ADV, which can no longer become true. The command is therefore retried every 2 s indefinitely: Bluetooth: hci0: Opcode 0x2006 failed: -16 Observed on a gateway as 5326 occurrences over 3 hours, ending only when bluetoothd was restarted. Connection attempts that succeed do not call hci_le_conn_failed() and never trigger this. Add the role test the comment already describes. Both other hci_enable_advertising() call sites reached from a failed/closed LE connection (hci_cs_disconnect() and hci_disconn_complete_evt()) already guard on conn->role == HCI_ROLE_SLAVE; this one was missed. Reproducing needs legacy advertising (ext_adv_capable() false, so the software rotation loop is used), simultaneous peripheral advertising and outgoing central connects, and a central connect that times out rather than failing fast. The Fixes tag points at the commit that introduced the advertising restart into this path for the directed-advertising (peripheral) case; the role test that the later commit |
||
Lorenzo Stoakes (ARM)
|
aec6a8d80e |
Bluetooth: hci_bcm4377: Ignore reserved PHY in ext adv reports on BCM4378
Commit |
||
HyeongJun An
|
4beb198bc5 |
Bluetooth: eir: Fix OOB read in eir_get_service_data()
eir_get_service_data() walks the advertising data for a Service Data
field with a matching UUID. On a mismatch it advances:
eir += dlen;
eir_len -= dlen;
eir_get_data() reports dlen as the field's data length, but the field
spans dlen + 2 bytes once its length and type bytes count, and more
when non-Service-Data fields were skipped to reach it. The pointer
lands correctly on the next field. eir_len does not, and the shortfall
compounds across fields until eir_get_data() reads the length and type
bytes of a "field" past the end of the buffer.
For an ISO broadcast sink that buffer is hcon->le_per_adv_data[], filled
from the periodic advertising reports of a remote broadcaster. A PA
payload packed with mismatching Service Data fields walks off the array
into the rest of struct hci_conn. A drifted field that matches the BAA
UUID puts those bytes in iso_pi(sk)->base, where user space reads them
back with getsockopt(BT_ISO_BASE).
Recompute eir_len from the end of the buffer each iteration.
Fixes:
|
||
Ali Ahmet Memis
|
060fa7592b |
Bluetooth: btnxpuart: Validate the FW dump header length
nxp_process_fw_dump() pulls the ACL header off the frame and then reads
seq_num and buf_len from a struct nxp_fw_dump_hdr placed at skb->data,
without checking that the ACL payload is long enough to contain it.
h4_recv_buf() collects HCI_ACL_HDR_SIZE bytes of header followed by the
number of payload bytes named in that header, so skb->len is 4 + dlen
with dlen supplied by the controller and possibly smaller than the 8
byte dump header, or zero. A short frame with connection handle 0xfff
therefore reads both fields from beyond the received data.
Beyond the read itself, buf_len is what terminates a dump: a value of
zero makes the driver call hci_devcd_complete() and reset the
controller, so a truncated frame can end a dump early.
Use skb_pull_data() to validate and pull the FW dump header before
accessing its fields. Warn and reject the chunk if the header is
truncated.
Fixes:
|
||
Randy Dunlap
|
e5bbf81def |
docs: kernel-parameters: add CPU_FREQ, CPU_IDLE build options
CPU_FREQ and CPU_IDLE are used in descriptions of some kernel parameters so add their descriptions to the build options list. Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Acked-by: Rafael J. Wysocki (Intel) <rafael@kernel.org> Signed-off-by: Jonathan Corbet <corbet@lwn.net> Message-ID: <20260815172934.3604009-1-rdunlap@infradead.org> |
||
Pauli Virtanen
|
5b9b68abb5 |
Bluetooth: hci_sync: add conditional locking annotations
Add context analysis annotations to functions doing conditional locking,
to suppress analysis warnings.
Fixes:
|
||
Sherry Sun
|
3b8f8d6323 |
Bluetooth: btnxpuart: Check remote M.2 connector availability before pwrseq
The current code uses of_graph_is_present() to decide whether to enter
the pwrseq path. However, of_graph_is_present() only checks for the
structural presence of a port/ports sub-node and does not check the
status property. This causes problems when a DT overlay disables the
remote M.2 connector node (e.g., switching from PCIe WiFi to SDIO WiFi):
the port node still exists, so of_graph_is_present() returns true, but
the pwrseq provider never registers because the connector is disabled,
leading to an infinite -EPROBE_DEFER loop.
Replace of_graph_is_present() with a new helper that traverses the OF
graph to the remote port parent (the M.2 connector node) and checks
of_device_is_available(). When the remote connector is disabled, the
pwrseq path is skipped, allowing the BT driver to fall through to the
direct bluetooth child node path.
Fixes:
|
||
Chris Lu
|
fa0ad2d277 |
Bluetooth: btmtksdio: Fix out-of-bounds DMA read in the TX path
btmtksdio_tx_packet() rounds the transfer size up to the SDIO block size
of 256 bytes, but hands the host controller the SKB buffer as is:
err = sdio_writesb(bdev->func, MTK_REG_CTDR, skb->data,
round_up(skb->len, MTK_SDIO_BLOCK_SIZE));
Only skb->len bytes hold packet data, so the controller reads up to 255
bytes of uninitialised memory and sends it to the device over the SDIO
bus. Depending on how much tailroom slack the SKB allocation happens to
carry, that read can also extend past the end of the buffer.
Compute the padded length up front, ensure the SKB has tailroom for it,
and zero-fill the padding with skb_put_zero(). skb->len then covers the
padding, so sdio_writesb() no longer needs to round up. byte_tx keeps
counting the header and the payload only, and the error path restores the
SKB so that the caller can requeue it.
Writing behind skb->tail is only safe because the driver owns the buffer,
which "Bluetooth: btmtksdio: Take exclusive ownership of the SKB before
TX" ensures.
Fixes:
|
||
|
Chris Lu
|
155e3003d1 |
Bluetooth: btmtksdio: Take exclusive ownership of the SKB before TX
btmtksdio_tx_packet() prepends the MediaTek SDIO header with skb_push()
and writes into that space after only checking the headroom size. On a
cloned SKB that headroom belongs to a buffer shared with the other owner,
which the driver has no right to write to.
Cloned SKBs do reach this path: hci_send_cmd_sync() keeps a clone of every
HCI command in hdev->sent_cmd before handing the SKB to the driver, and
l2cap_ertm_send() clones SKBs for retransmission.
Replace the open-coded headroom check with skb_cow_head(), which both
guarantees the headroom and reallocates a private buffer when the SKB is
cloned. The cost is one reallocation and copy per cloned packet, the usual
price of this pattern in network drivers.
This has no observable effect on its own, as the driver only writes in
front of skb->data where no other owner looks. It is a prerequisite for
"Bluetooth: btmtksdio: Fix out-of-bounds DMA read in the TX path", which
writes padding behind skb->tail, and carries the same Fixes: tag so that
both are backported together.
Fixes:
|
||
Ismail Tarim
|
21b50c2484 |
Bluetooth: btmtk: Do not discard the subsystem reset timeout
When the MTK_BT_RST_DONE poll times out, btmtk_usb_subsys_reset() logs "Reset timeout" and keeps the error in err, but err is then overwritten by the return value of the following btmtk_usb_id_get() call, so the timeout is never reported to the caller. Commit |
||
|
Ismail Tarim
|
59c3ee19ca |
Bluetooth: btmtk: Do not report success when subsys reset fails
btmtk_usb_subsys_reset() validates the subsystem reset by reading the
chip id back. When that read succeeds at the bus level but yields an id
of zero, the reset has demonstrably not taken effect: the function logs
"Can't get device id, subsys reset fail." and then returns the return
value of btmtk_usb_id_get(), which in that case is zero, i.e. success.
btusb_mtk_reset() returns that value unchanged, so its caller cannot
tell a completed reset from a failed one.
Return -ENODEV when the chip id reads back as zero, leaving the existing
MT6639 exemption intact.
Observed on an MT7902 [13d3:3579]. The path can be reached on demand by
asking the controller for a coredump, since btmtk requests a reset once
the dump completes:
# echo 1 > /sys/class/bluetooth/hci0/device/coredump
Bluetooth: hci0: Mediatek coredump end
Bluetooth: hci0: Can't get device id, subsys reset fail.
usb 3-10: reset high-speed USB device number 5 using xhci_hcd
usb 3-10: device descriptor read/64, error -110
usb usb3-port10: attempt power cycle
usb usb3-port10: unable to enumerate USB device
The same sequence occurs unprompted when the controller firmware asserts
on its own.
Note that this corrects the error reporting only; it does not by itself
make the controller recoverable in the case above.
Fixes:
|
||
|
Pauli Virtanen
|
66d6ef1854 |
Bluetooth: L2CAP: fix race l2cap_sock_cleanup_listen() vs. put_chan
For L2CAP sockets without owning sk->sk_socket, reading
l2cap_pi(sk)->chan may race against concurrent l2cap_sock_kill() ->
l2cap_sock_put_chan(). This excludes simultaneous proto_ops callbacks,
but access in l2cap_sock_cleanup_listen() has unsafe lockless read.
[Task 1] [Task 2 (hdev->workqueue)]
l2cap_sock_release(parent) l2cap_disconn_cfm
l2cap_sock_cleanup_listen l2cap_conn_del
bt_accept_dequeue l2cap_chan_del
lock_sock(sk) l2cap_sock_teardown_cb
bt_accept_unlink
bt_sk(sk)->parent = NULL
release_sock(sk) ----------------> lock_sock(sk)
parent = /* NULL */
lock_sock(sk) <--------------------- release_sock(sk)
sock_set_flag(sk, SOCK_ZAPPED)
l2cap_sock_close_cb
l2cap_sock_kill(sk)
l2cap_sock_put_chan
chan = READ l2cap_pi(sk)->chan l2cap_pi(sk)->chan = NULL
l2cap_chan_hold_unless_zero l2cap_put_chan(chan)
kref_get_unless_zero(&chan->ref)
Task 1 may observe NULL which causes null-ptr-deref.
Fix the race by taking lock_sock() in l2cap_sock_kill() to
synchronize with l2cap_sock_cleanup_listen(). hold_unless_zero() is not
needed here, l2cap_pi(sk)->chan owns reference if it is non-NULL.
Clarify code comments vs. locking.
Fixes:
|
||
Pavel Shpakovskiy
|
59eecbe2f2 |
Bluetooth: mgmt: fix 'hdev->discovery.uuids' NULL dereference
'uuid_count' member of struct 'discovery_state' is assigned and read
without any locks, so there is a chance of situation when
uuid_count != 0, but uuids is NULL and there will be NULL pointer
dereference.
Possible race:
'hci_update_passive_scan_sync'
'hci_discovery_filter_clear'
hdev->discovery.uuid_count = 0;
<----------------------preempted----------------------------->
'start_service_discovery'
// Set uuid_count to value != 0
hdev->discovery.uuid_count = uuid_count;
hdev->discovery.uuids = kmemdup(...);
<----------------------preempted----------------------------->
spin_lock(&hdev->discovery.lock);
kfree(hdev->discovery.uuids);
hdev->discovery.uuids = NULL;
spin_unlock(&hdev->discovery.lock);
Now uuids == NULL and uuid_count != 0.
So 'mgmt_device_found' -> 'is_filter_match' -> 'eir_has_uuids' receives
non consistent discovery state, where NULL dereference of uuids happens.
To fix it let's add discovery.lock around every read/write of uuid_count,
uuids pair of struct members. It is also important to assign uuid_count
value only after success kmemdup() allocation in
start_service_discovery(), otherwise uuids is NULL, because kmemdup failed,
but uuid_count is already assigned to non zero value.
The following panic happens:
[ ] ------------[ cut here ]------------
[ ] Unable to handle kernel NULL pointer dereference at virtual
address 0000000000000000
[ ] Internal error: Oops: 0000000096000006 [#1] PREEMPT SMP
[ ] CPU: 0 PID: 15056 Comm: kworker/u9:2
[ ] Workqueue: hci0 hci_rx_work
[ ] pstate: 10400009 (nzcV daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ ] pc : eir_has_uuids+0x2d8/0x590
[ ] lr : is_filter_match+0x258/0x320
...
[ ] Call trace:
[ ] eir_has_uuids+0x2d8/0x590
[ ] is_filter_match+0x258/0x320
[ ] mgmt_device_found+0x5b0/0xafc
[ ] process_adv_report.part.0+0x8c8/0xf14
[ ] hci_le_adv_report_evt+0x338/0x3f0
[ ] hci_le_meta_evt+0x1f0/0x4c8
[ ] hci_event_packet+0x440/0xc9c
[ ] hci_rx_work+0x44c/0xaf8
[ ] process_one_work+0x54c/0x103c
[ ] worker_thread+0x6c4/0x10c4
[ ] kthread+0x274/0x2ec
[ ] ret_from_fork+0x10/0x20
[ ] Code: 14000004 91004021 eb14003f 54000180 (f9400024)
[ ] ---[ end trace 0000000000000000 ]---
Fixes:
|
||
Tao Cui
|
6586705bc2 |
docs/sched_ext: document that cgroup CPU knobs are scheduler-dependent
The scheduler core communicates the initial cpu controller settings to the BPF scheduler through ops.cgroup_init() and reports subsequent changes through the corresponding ops.cgroup_set_*() callbacks. Whether and how a knob takes effect is up to the loaded scheduler: it may implement the corresponding callback partially or not at all, so cpu.max, cpu.weight and friends can silently have no effect. Document this in the basics section of sched-ext.rst. Signed-off-by: Tao Cui <cuitao@kylinos.cn> Reviewed-by: Andrea Righi <arighi@nvidia.com> Signed-off-by: Tejun Heo <tj@kernel.org> |
||
|
Pauli Virtanen
|
d4bfa78fd6 |
Bluetooth: L2CAP: reject accept queue add unless BT_LISTEN
New sk should not be added to parent socket accept queue after last
l2cap_sock_cleanup_listen() has run in l2cap_sock_teardown_cb() and
state set to BT_CLOSED, as that can result to UAF on dereferencing the
dangling parent reference.
l2cap_sock_new_connection_cb() may race with parent l2cap_chan teardown,
due to chan->state accessed without consistent locking:
[Task 1] [Task 2]
l2cap_sock_release(parent) l2cap_connect
l2cap_sock_shutdown pchan = l2cap_global_chan_by_psm
l2cap_chan_lock(pchan)
l2cap_chan_close
l2cap_sock_teardown_cb
pchan->state = BT_CLOSED
l2cap_chan_unlock(pchan) ------> l2cap_chan_lock(pchan)
l2cap_new_connection
l2cap_sock_new_connection_cb
l2cap_chan_lock(pchan) <-------- l2cap_chan_unlock(pchan)
l2cap_sock_kill(parent) /* bt_sk(sk)->parent dangling */
Fix by adding check for sk_state == BT_LISTEN after acquiring sk lock in
l2cap_sock_new_connection_cb(). Add lock_sock() around sk_state writes
where missing, to avoid data races.
Although the data races on pchan->state should be fixed too, this
defensive sk_state check probably makes sense in any case.
Fixes:
|
||
|
Pauli Virtanen
|
ca2c4c2649 |
Bluetooth: L2CAP: access chan->conn safely in get/setsockopt
Since commit |
||
Guangshuo Li
|
c7e9a8cb69 |
Bluetooth: hci_intel: fix usage_count leak when autosuspend_delay is negative
intel_set_power() calls pm_runtime_use_autosuspend() when powering on
the device, but the power-off path does not call the matching
pm_runtime_dont_use_autosuspend() before disabling runtime PM.
If the autosuspend delay is set to a negative value while autosuspend
is enabled, the runtime PM core increments usage_count to prevent
runtime suspend. Without calling pm_runtime_dont_use_autosuspend()
during teardown, this reference is not dropped and usage_count remains
unbalanced.
Add the missing pm_runtime_dont_use_autosuspend() call before disabling
runtime PM.
This issue was found by manual code inspection.
Fixes:
|
||
|
Guangshuo Li
|
853a92b97c |
Bluetooth: hci_h5: fix usage_count leak when autosuspend_delay is negative
h5_btrtl_open() calls pm_runtime_use_autosuspend(), but
h5_btrtl_close() does not call the matching
pm_runtime_dont_use_autosuspend() when tearing down runtime PM.
If the autosuspend delay is set to a negative value while autosuspend
is enabled, the runtime PM core increments usage_count to prevent
runtime suspend. Without calling pm_runtime_dont_use_autosuspend()
during driver teardown, this reference is not dropped and usage_count
remains unbalanced.
Add the missing pm_runtime_dont_use_autosuspend() call before disabling
runtime PM.
This issue was found by manual code inspection.
Fixes:
|
||
|
Guangshuo Li
|
dc6b7c771a |
Bluetooth: hci_bcm: fix usage_count leak when autosuspend_delay is negative
bcm_request_irq() calls pm_runtime_use_autosuspend(), but bcm_close()
does not call the matching pm_runtime_dont_use_autosuspend() when
tearing down runtime PM.
If the autosuspend delay is set to a negative value while autosuspend
is enabled, the runtime PM core increments usage_count to prevent
runtime suspend. Without calling pm_runtime_dont_use_autosuspend()
during driver teardown, this reference is not dropped and usage_count
remains unbalanced.
Add the missing pm_runtime_dont_use_autosuspend() call before disabling
runtime PM.
This issue was found by manual code inspection.
Fixes:
|
||
Linus Torvalds
|
8bfab832ad |
mailbox: updates for v7.3
- mhuv2: convert channel translation to fw_xlate() and use generic device
property APIs
- axiado: add AX3005 mailbox controller driver and DT bindings
- bcm2835: use platform_get_irq() and simplify probe error handling
- cix: fix DT property string typo and use dev_err_probe()
- exynos: add Exynos850 mailbox driver support and DT bindings
- microchip: add null check for devm_kasprintf()
- pcc: fix missed-interrupt command timeout, verify shared memory signature,
and notify clients on polled completion
- qcom: fix CPUCP PREEMPT_RT deadlock and NULL data crash, fix IPCC duplicate
channel allocation across holes, and add IPQ5210 APCS and Nord IPCC bindings
- riscv: validate RPMI notification buffer lengths and event payload bounds
- rockchip: manage peripheral clock with devm helper and drop unused struct field
- ti-msgmgr: convert bindings to DT schema
- misc: remove redundant dev_err()/dev_err_probe() on IRQ request failures
across drivers
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEE6EwehDt/SOnwFyTyf9lkf8eYP5UFAmqLoQ8ACgkQf9lkf8eY
P5X5Yg//fV6vjCgnuCPSfL0z8RbGrE8WlY9XWmQnp5boKa7rjNVKedwkiPxNFMAw
ro/ERpyfxLSQziws/nonAr7bJ5yxrz6wHFU6++5rT9w5m4e0Y7meoKT6GEj+1bEy
1kQ/4xmaZSLkUUTJkndU6wGBWxt0GJHObUNzVJxx28E0f1OAQa4MojT96gcgx8tm
uPzaL6acBigsLRtlCUYgtTR5/CLi9ArJmzRYrWVNG07fxr4sSKuMWTp5Fu+te5/w
jLJXyEgdzIzbjKrysyQPt0Di3iR2raTlw/86bFQtqdk4GNBMjPcQQtc7qWhUsst8
XhjXm0OB8yHtJ0cn59yLeChWZ/2Cc+nPqWtYdtadWghuqnTGfdpjkS2sngPsNVRy
txEvyqgzszQcpAqemKVnVlKHBgq0D3VwMR3KQ/tUIWLgpxw5YcG4oczum/Cf+YOR
i3VVbxFKkzHjopzh8Gh7pgAuwY4uJnVEgOtFnQLGe6goLcs6nNmBAMe6wi2Ge5mQ
0ZxoAj1z7pylQPiAQViPYM1uJcgRWJx+B6dzfBJKKBSTsHmHPhjXVYqbs/5/RrU+
0iHNFVs2dQuKkyjgOQ/qX7Oas3uasc87nuTM7yyHfhFjgt3G+7XaDPETgVuBK/BX
/3vlpkQEjQFL5CJVcxCZ0/ZSQnwhx0Kr84qXEttq2LMl1Qlzq5w=
=rp2p
-----END PGP SIGNATURE-----
Merge tag 'mailbox-v7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/jassibrar/mailbox
Pull mailbox updates from Jassi Brar:
- mhuv2:
- convert channel translation to fw_xlate()
- use generic device property APIs
- axiado:
- add AX3005 mailbox controller driver and DT bindings
- bcm2835:
- use platform_get_irq()
- simplify probe error handling
- cix:
- fix DT property string typo
- use dev_err_probe()
- exynos:
- add Exynos850 mailbox driver support and DT bindings
- microchip:
- add null check for devm_kasprintf()
- pcc:
- fix missed-interrupt command timeout
- verify shared memory signature
- notify clients on polled completion
- qcom:
- fix CPUCP PREEMPT_RT deadlock and NULL data crash
- fix IPCC duplicate channel allocation across holes
- add IPQ5210 APCS and Nord IPCC bindings
- riscv:
- validate RPMI notification buffer lengths and event payload bounds
- rockchip:
- manage peripheral clock with devm helper
- drop unused struct field
- ti-msgmgr:
- convert bindings to DT schema
- remove redundant dev_err()/dev_err_probe() on IRQ request failures
across drivers
* tag 'mailbox-v7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/jassibrar/mailbox: (22 commits)
mailbox: add Axiado AX3005 mailbox driver
dt-bindings: mailbox: add Axiado AX3005 mailbox
dt-bindings: mailbox: Convert TI Message Manager to DT schema
mailbox: cix: fix DT property name string typo and use dev_err_probe()
mailbox: riscv-sbi-mpxy: validate RPMI notification lengths
mailbox: bcm2835: use platform_get_irq and simplify probe
mailbox: qcom-ipcc: fix duplicate channel allocation across holes
mailbox: mchp-ipc-sbi: Add null check for devm_kasprintf()
mailbox: Remove redundant dev_err()/dev_err_probe()
dt-bindings: mailbox: qcom: Add IPQ5210 APCS compatible
dt-bindings: mailbox: qcom-ipcc: Document Nord IPCC
mailbox: exynos: Add support for Exynos850 mailbox
dt-bindings: mailbox: google,gs101-mbox: Add samsung,exynos850-mbox
mailbox: pcc: Fix command timeout due to missed interrupt
mailbox: pcc: Check shared memory signature on request
mailbox: pcc: Notify clients on polled completion
mailbox: rockchip: drop unneeded runtime pointer (pclk)
mailbox: rockchip: disable pclk on probe failure and unbind
mailbox: qcom-cpucp: handle NULL data in send_data callback
mailbox: qcom-cpucp: fix PREEMPT_RT self-deadlock in IRQ handler
...
|
||
Federico Vaga
|
f7f11bddda |
doc:it_IT: align Italian documentation in process
This commit updates the Italian translation in `process/` following these changes: commit |
||
Guopeng Zhang
|
87d347a8c8 |
selftests/cgroup: Add test for preserving boot-isolated CPUs
Put a CPU isolated at boot into an isolated partition, change the partition back to member and check that the CPU remains isolated. Signed-off-by: Guopeng Zhang <zhangguopeng@kylinos.cn> Reviewed-by: Waiman Long <longman@redhat.com> Signed-off-by: Tejun Heo <tj@kernel.org> |
||
Johan Hovold
|
60763c2f83 |
docs: threat-model: fix /dev/kmsg reference
Fix a '/dev/kmsg' reference which got replaced with '/proc/kmsg' (which
is not accessible to regular users).
Fixes:
|
||
|
Guopeng Zhang
|
6c37d7e074 |
cgroup/cpuset: Preserve boot-isolated CPUs on partition release
isolated_cpus tracks CPUs isolated with isolcpus= as well as CPUs in
isolated cpuset partitions. When an isolated partition is released,
isolated_cpus_update() removes its whole CPU mask. This also clears CPUs
which were already isolated at boot.
This can be reproduced on a cgroup v2 system booted with
isolcpus=domain,15:
cd /sys/fs/cgroup
echo +cpuset > cgroup.subtree_control
mkdir cpuset-repro
echo 15 > cpuset-repro/cpuset.cpus
echo isolated > cpuset-repro/cpuset.cpus.partition
echo member > cpuset-repro/cpuset.cpus.partition
cat cpuset.cpus.isolated
CPU 15 is absent before the change. It must remain in
cpuset.cpus.isolated after the partition is released.
Update isolated_cpus one CPU at a time and keep CPUs outside the
boot-time domain housekeeping mask isolated.
Fixes:
|
||
|
Guopeng Zhang
|
2bf404b1bd |
selftests/cgroup: Drop invalid boot isolation comparison
check_isolcpus() clears ISOLCPUS before rebuilding it from sched domain
data. Comparing that empty value with
/sys/devices/system/cpu/isolated makes the test fail whenever
isolcpus=domain is present.
That sysfs file is generated from HK_TYPE_DOMAIN_BOOT and does not change
when cpuset updates HK_TYPE_DOMAIN. Re-reading it cannot validate dynamic
housekeeping updates. The cpuset.cpus.isolated and sched domain checks
already cover the two dynamic interfaces, so remove the invalid comparison.
This can be reproduced on a kernel booted with isolcpus=domain,15:
# tools/testing/selftests/cgroup/test_cpuset_prs.sh
The test fails its first state-matrix isolation check before the change and
continues past that check afterward.
Fixes:
|
||
Jenson Johnathon Reggentin
|
b40a680ea4 |
docs: block: fix dead http link in blk-mq.rst
The current link http://kernel.dk/blk-mq.pdf leads to a 404 error page. https://www.kernel.dk/blk-mq.pdf leads to the correct document. v2 to add the missing www. prefix in the actual file change. Signed-off-by: Jenson Johnathon Reggentin <mail@jregg.de> Acked-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Jonathan Corbet <corbet@lwn.net> Message-ID: <20260819192422.42189-1-mail@jregg.de> |
||
Akiyoshi Kurita
|
bbc2de7fa5 |
docs/ja_JP: translate submitting-patches.rst (tag usage)
Translate the Acked-by:, Cc:, and Co-developed-by: section into Japanese. Signed-off-by: Akiyoshi Kurita <weibu@redadmin.org> Acked-by: Akira Yokosawa <akiyks@gmail.com> Signed-off-by: Jonathan Corbet <corbet@lwn.net> Message-ID: <20260730130030.1078990-1-weibu@redadmin.org> |
||
Cheng Lingfei
|
909a3f0e9d |
docs: cgroup-v2: fix misc.events key format description
In misc cgroup, misc.events does not output a simple "max" key. Instead, each registered misc resource outputs a separate key suffixed with ".max" (i.e., "<res>.max"). Update the documentation to clarify that the entry key is "<res>.max". Suggested-by: Michal Koutný <mkoutny@suse.com> Signed-off-by: Cheng Lingfei <chenglingfei@foxmail.com> Signed-off-by: Tejun Heo <tj@kernel.org> |
||
Ibrahim Abdelkader
|
cb19774faa |
Bluetooth: hci_sync: Clear HCI_CMD_PENDING when dropping the last request
A synchronous HCI command that never receives a response leaves
HCI_CMD_PENDING set: hci_req_cmd_complete() is the only place that clears
it, and it only runs when a response matching the last command sent
arrives.
hci_send_cmd_sync() populates hdev->req_skb only when the flag transitions
from clear to set, while hci_dev_open_sync() and hci_dev_close_sync() drop
req_skb without clearing the flag. After a timeout followed by either, the
two disagree: the flag claims a request is outstanding while req_skb is
NULL. Subsequent synchronous commands are then sent with no req_skb, so
hci_event_packet() has nothing to match an arriving event against, and the
caller times out even though the controller answered.
Commands answered by Command Complete recover on their own, since
hci_req_cmd_complete() clears the flag as a side effect. Drivers using
__hci_cmd_sync_ev() with a custom event do not, because a vendor event
never reaches that path. On a WCN3988 (hci_qca over UART) this makes a
controller firmware hang unrecoverable: the driver injects a hardware
error and re-runs qca_setup(), qca_read_soc_version() waits for
HCI_EV_VENDOR, the reply arrives within 4 ms and is discarded, and every
retry fails the same way. The adapter is left down until the driver is
unbound and rebound, or power is removed.
Clear the flag wherever the last request is dropped, restoring the
invariant that req_skb is non-NULL exactly when HCI_CMD_PENDING is set.
Verified on hardware by forcing a command timeout: without this change
setup fails on every attempt, with it setup succeeds on the first.
Fixes:
|
||
Paolo Bonzini
|
76671054f9 |
KVM/arm64 changes for 7.3
- Add support for 'slot' based PMU events, paired with new UAPI that
compels the user to select a specific PMU implementation
- Lazy save/restore of vCPU state for pKVM, along with various fixes
and cleanups to the management of vCPU state between the untrusted
host and pKVM hypervisor
- Disable traps of EL1 registers for nested hypervisors when FEAT_NV2p1
is present, guaranteeing that EL2-specific register bits are stateful
in the EL1 counterpart
- Leverage FEAT_NV3 to avoid unnecessary ERET/TLBI traps when the scope
of those instructions remains 'in host' (i.e. L1 kernel/userspace)
- Pile of fixes for the management of the VNCR pseudo-TLB, such as
under-invalidations and races with concurrent TLBIs on other vCPUs
- Consolidate the non-protected and pKVM view of ICH_VTR_EL2 to a
runtime-patched constant, allowing the same data to be shared with
pKVM prior to dropping host privileges
- Considerable pile of LLM-assisted fixes around the shop but mostly in
the VGIC, our in-kernel generator of bugs (and sometimes interrupts)
-----BEGIN PGP SIGNATURE-----
iI0EABYKADUWIQSNXHjWXuzMZutrKNKivnWIJHzdFgUCaoZ/khccb2xpdmVyLnVw
dG9uQGxpbnV4LmRldgAKCRCivnWIJHzdFkK7AP9zvAcDf+DVte8+mZjCMDrvNB1n
UWsBnQkdZ1nDDYBJlwD8D1pvurK4ZV3UIl68IgpTqYKhMspCuOWDHrnBt1QyqQU=
=2iPX
-----END PGP SIGNATURE-----
Merge tag 'kvmarm-7.3' of https://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm into HEAD
KVM/arm64 changes for 7.3
- Add support for 'slot' based PMU events, paired with new UAPI that
compels the user to select a specific PMU implementation
- Lazy save/restore of vCPU state for pKVM, along with various fixes
and cleanups to the management of vCPU state between the untrusted
host and pKVM hypervisor
- Disable traps of EL1 registers for nested hypervisors when FEAT_NV2p1
is present, guaranteeing that EL2-specific register bits are stateful
in the EL1 counterpart
- Leverage FEAT_NV3 to avoid unnecessary ERET/TLBI traps when the scope
of those instructions remains 'in host' (i.e. L1 kernel/userspace)
- Pile of fixes for the management of the VNCR pseudo-TLB, such as
under-invalidations and races with concurrent TLBIs on other vCPUs
- Consolidate the non-protected and pKVM view of ICH_VTR_EL2 to a
runtime-patched constant, allowing the same data to be shared with
pKVM prior to dropping host privileges
- Considerable pile of LLM-assisted fixes around the shop but mostly in
the VGIC, our in-kernel generator of bugs (and sometimes interrupts)
|
||
Taimuraz Kaitmazov
|
7e33ba3a1d |
accel/amdxdna: put the chained BO when its mapping fails
amdxdna_cmd_set_error() looks up the first BO of a command chain, which
takes a reference, and drops it at the end of the function. The mapping of
that BO is established in between, and the failure path returns without the
put, so the reference is leaked.
Ordinary use does not reach it. The chain has been submitted before any of
this runs, so aie2_cmdlist_fill_slot() has already called
amdxdna_cmd_get_op() on that BO and amdxdna_gem_vmap() has cached its
address. What makes it reachable is that the BO is resolved again by
handle here, and the handle is userspace's to recycle: closing it after
submission and importing a dma-buf whose exporter implements no vmap onto
the same id leaves amdxdna_gem_get_obj() returning an object this cannot
map, since prime_import() types every import AMDXDNA_BO_SHARE.
Fixes:
|
||
|
Taimuraz Kaitmazov
|
ef6d27af71 |
accel/amdxdna: reject a command chain that carries no commands
A chain whose command_count is zero passes the payload length check,
because struct_size(payload, data, 0) is just the header. The fill loop
then does not run, so offset stays zero and the request is submitted with
a zero-length buffer.
On firmware without AIE2_NPU_COMMAND that ends at the opcode check, since
op is still ERT_INVALID_CMD and aie2_get_chain_msg_op() answers
MSG_OP_MAX_OPCODE. aie2_get_npu_chain_msg_op() answers
MSG_OP_CHAIN_EXEC_NPU whatever it is given, so there the submission
continues to drm_clflush_virt_range(cmd_buf, 0), which reads the byte
before the buffer and faults on the vmap guard page. EXEC_CMD is
reachable by any process that can open the render node.
Reject the request instead.
Fixes:
|
||
Lizhi Hou
|
b3709d3545 |
accel/amdxdna: Remove __counted_by from struct amdxdna_cmd_chain
struct amdxdna_cmd_chain contains a flexible array annotated with
__counted_by(command_count). Since the structure is stored in shared
AMDXDNA_BO_SHARE memory, userspace can modify command_count concurrently.
If command_count is changed to zero, the bounds check generated from
__counted_by may fail and trigger a kernel panic.
Remove __counted_by to avoid relying on the userspace-controlled
command_count for the flexible array bounds check.
Fixes:
|
||
|
Linus Torvalds
|
47096fc3d0 |
i2c for v7.3, part 2
Fixes and cleanups around probe error handling, resource management and a minor Rust cleanup. Drivers: - several drivers: drop duplicate IRQ error reporting - imx-lpi2c: improve probe initialization and error cleanup - mxs: fix DMA channel leak on probe failure - ocores: fix clock cleanup on resume failure - rcar: handle reset controllers without status support Muxes: - demux-pinctrl: fix OF node leak on allocation failure Rust: - mark trivial I2cAdapter reference-counting methods inline -----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQScDfrjQa34uOld1VLaeAVmJtMtbgUCaowtFAAKCRDaeAVmJtMt btHCAQCsWbWHyIgqrfHvJqD0IhdB6jc5UB/9Uu1cArF9V4mCVwD/XLkzuBtKDw82 QAaonKQUp9OaS7TAlZqcmGxMn+yGhg8= =ULkr -----END PGP SIGNATURE----- Merge tag 'i2c-7.3-part2' of git://git.kernel.org/pub/scm/linux/kernel/git/andi.shyti/linux Pull more i2c updates from Andi Shyti: "Fixes and cleanups around probe error handling, resource management and a minor Rust cleanup. Drivers: - several drivers: drop duplicate IRQ error reporting - imx-lpi2c: improve probe initialization and error cleanup - mxs: fix DMA channel leak on probe failure - ocores: fix clock cleanup on resume failure - rcar: handle reset controllers without status support Muxes: - demux-pinctrl: fix OF node leak on allocation failure Rust: - mark trivial I2cAdapter reference-counting methods inline" * tag 'i2c-7.3-part2' of git://git.kernel.org/pub/scm/linux/kernel/git/andi.shyti/linux: i2c: rust: mark I2cAdapter methods as inline i2c: rcar: fix reset handling for Gen5 i2c: mxs: fix DMA channel leak on probe error i2c: mux: demux-pinctrl: fix OF node leak on kstrdup failure i2c: ocores: Disable clock on failed resume i2c: imx-lpi2c: reset controller in probe stage i2c: imx-lpi2c: properly unwind resources on probe failure i2c: busses: drop redundant dev_err_probe() around irq helpers |
||
|
Linus Torvalds
|
cf9610f911 |
Pin control bulk changes for kernel v7.3
Core changes:
- Use the non-blocking mux_state_try_select() in the generic
MUX pin control back-end.
- Free pin maps on pinctrl_generic_to_map() failure in the core
helpers.
New drivers:
- Qualcomm Maili TLMM SoC pin control.
- Qualcomm PMG1110 PMIC pin control.
- Qualcomm Eliza LPASS LPI TLMM SoC pin control (this is for
the low power audio, LPASS = Low Power Audio SubSystem
portions).
- Upboard support on top of the Intel pin controller.
- Apple T6030 and T6031 support (just compatible strings).
- Samsung Exynos 8855 SoC pin control.
- Mediatek MT6858 SoC pin control.
- Rockchip RK3308B SoC pin control.
- Rockchip RV1106 SoC pin control.
- Airoha EN7523 SoC pin control.
- Airoha AN7563 SoC pin control.
Improvements:
- Qualcomm TLMM GPIOs are unconditionally marked as wakeup capable.
- Qualcomm improvements on top of the Qualcomm PDC (power domain
controller) irqchip improvements from tglx:s tree.
- Qualcomm IPQ806x and IPQ9650 nonurgent pin grop fixups.
- The NPCM8xx driver has been put into shape fixing many pin and
group definitions.
- Some nonurgent Tegra 264 pin assignments are fixed up.
- Some nonurgent fixups to Airoha AN7581 and AN7583 registers and
pin assignments, missing features etc.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEElDRnuGcz/wPCXQWMQRCzN7AZXXMFAmqMBvYACgkQQRCzN7AZ
XXOCRw//aRnxM6R7HJkmcJt70749sE2GSbQ5Vx22zkRLRt8FA0QL4GdPQWjG+rwA
/Q5XhMv5TpSXaBo63fFyAEHEhgbuxlgyUMijpXuMFVHB4AKIcp0P9Mn+TfTkpsIu
QPIUktn2wqaIoFoAZj7G2KhXUyyeQnISplBSFl4wfpsJ25fjKqqeoiOMrMCVc05A
Hfgm047beur5vkvYBIwFG0BC992l9ucSQJ4jDEm2XtkQ/NqIQBd16lYdxrb6vkJu
Bj2qUH/GVQN3c+n2ZgfwVbkoWMum7VgBymxbnjhraJmQoGm27IQsnBtDnhD5bv6s
bk5Y6Vyji0kNhHYU5uBFwjDWmYt5PxjXynkeFuruNuBkqnioQCyoTNlIeiJf5pZv
kM0dBkR0eUTQVPrZX5kXbi9B2JqdbnkdhKbL2YQt1zV0uvs1m8xl3dLu+bvtHjEM
xNghQKkSDvSHDgulbjTcKEthILSA48Q+poCaOoYre8KIOc4I7novSal6UzcHoTH7
4D8+BnwJXbS5RRIG2snUWHRLB8aY+yuPlfAQBrAu0apuKWrnr2SjfWMMek1kDv57
U/iXjSKvjSUQc+sYhq+cPMrD8yYqjIgfg483p4L8xsTIi0Mer6UhnHcZJ82TONTa
K1A3iGlKOtw4jNFOeow8VAW8MyEHcnx3q70rgA2O+eH7WpT28rs=
=sSjn
-----END PGP SIGNATURE-----
Merge tag 'pinctrl-v7.3-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl
Pull pin control updates from Linus Walleij:
"Core changes:
- Use the non-blocking mux_state_try_select() in the generic MUX pin
control back-end
- Free pin maps on pinctrl_generic_to_map() failure in the core
helpers
New hardware pin control:
- Qualcomm Maili TLMM SoC, PMG1110 PMIC, and Eliza LPASS LPI TLMM SoC
(this is for the low power audio, LPASS = Low Power Audio SubSystem
portions)
- Upboard support on top of the Intel pin controller
- Apple T6030 and T6031 support (just compatible strings)
- Samsung Exynos 8855 SoC
- Mediatek MT6858 SoC
- Rockchip RK3308B and RV1106 SoCs
- Airoha EN7523 and AN7563 SoCs
Improvements:
- Qualcomm TLMM GPIOs are unconditionally marked as wakeup capable
- Qualcomm improvements on top of the Qualcomm PDC (power domain
controller) irqchip improvements from tglx:s tree
- Qualcomm IPQ806x and IPQ9650 non-urgent pin grop fixups
- The NPCM8xx driver has been put into shape fixing many pin and
group definitions
- Some non-urgent Tegra 264 pin assignments are fixed up
- Some non-urgent fixups to Airoha AN7581 and AN7583 registers and
pin assignments, missing features etc"
* tag 'pinctrl-v7.3-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl: (130 commits)
dt-bindings: pinctrl: Convert TI DA850 pupd to DT schema
pinctrl: meson: sync some modify from A4
pinctrl: meson: a4: Add input enable pin configuration
pinctrl: realtek: rtd1625: remove unused group name spdif_sel
pinctrl: realtek: rtd1625: fix base_bit for VE4 GPIO 13
dt-bindings: pinctrl: microchip,pic32mzda-pinctrl: Convert to DT schema
Revert "Merge branch 'ib-rsk7204' into devel"
pinctrl: rockchip: Add RV1106 pinctrl support
dt-bindings: pinctrl: rockchip: Add RV1106 compatible
pinctrl: rockchip: Decode drive strength in the get function
pinctrl: fix PINCTRL_GENERIC_MUX not always being selectable
pinctrl: airoha: add support of an7563 SoC
dt-bindings: pinctrl: airoha: add support of an7563 pin controller
pinctrl: airoha: try to find chip scu node by phandle first
pinctrl: airoha: add support of en7523 SoC
dt-bindings: pinctrl: airoha: add support of en7523 pin controller
pinctrl: airoha: an7583: add support for olt pinmux
pinctrl: airoha: an7583: add support for pon_alt pinmux
pinctrl: airoha: an7583: add support for npu_uart pinmux
dt-bindings: pinctrl: airoha: an7583: add missed features
...
|
||
Seongjae Jeong
|
3b2c5d35cf |
f2fs: use adjusted write range after f2fs_write_checks()
generic_write_checks() in f2fs_write_checks() can adjust iocb->ki_pos for append writes and truncate the iterator to limit the number of bytes to write. In f2fs_file_write_iter(), the pinned-file overwrite check currently uses the position and count saved before f2fs_write_checks(), so it can check a range different from the actual write range. The forced buffered I/O cleanup also uses orig_pos saved before f2fs_write_checks(). For O_APPEND writes, this can make the cleanup flush and invalidate the wrong page cache range. Move the pinned-file overwrite check after f2fs_write_checks() and use the adjusted iocb->ki_pos and iov_iter_count(from). Also save the adjusted write position and use it for the forced buffered I/O cleanup. Fixes: |
||
|
Linus Torvalds
|
0b0e645ed2 |
auxdisplay for v7.3-1
* Cancel backlight work on panel registration failure * Miscellaneous cleanups -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEqaflIX74DDDzMJJtb7wzTHR8rCgFAmqL4y0ACgkQb7wzTHR8 rCh9oQ/+LJ/jsPyYb43AupK1iyOVCA9BO6Vjn/eb8bM+v4cyt9BN3NdoIgLe5bQM HdLBqQuuB2UD5Fo5QmGNitcmqU9XGucOMzrGK9nJlgdXHsMCeNtykbt0Jpunr5t8 1d0CQgCfsk2PF6YcPLuwZOK1jsHjyI5bmyhFENilO/+mxTFsZNj1s9s4auGDIqnH nhfmIWogCnL9CQQYsnHkZvj41DBY7ReM8Wt5T4gj4Bk5VHfcytOIouq5g/+j3r/D rAu/7oV5xPZmQBGovmD4ZHaxmF9bjpe32wsmhXKxEsQ+rvoKh71XAIvf/o+gvwBv V5DCJfLc3TvCLv/eoGNutNwXejX4EgoSfPBVDxj1+YhjuydGFmWRTvNwnELAGoKW /lhLCQ9+MzRHoDaIEcI3ae1Yzwpo95PnI6yKSCzhxaLAzJ9VgAMETnHIwHUOQ/fu 7YjknaCTIFt/2OlXlBXuZzyRmXSAbFSv0P3S/H2IWrY7BHJQlTmO+w1G98sqDQLQ lXiO1kd8mVRjOtCZIDFLqGig729DXvnmX3idbjkwGF7G2KApnW7Kl55QmvM9RqEi bHRLxhBrtAtj1Exu47hV9dR6Xy2lLYb7zFr9SpV7+b4MnCXygayB1S2SzxozFUG8 Br3rfwEavUDBnh5p3h+Q0itaoCaOvuj/j9O84TvIoSwp/QzhxfU= =GaAa -----END PGP SIGNATURE----- Merge tag 'auxdisplay-v7.3-1' of git://git.kernel.org/pub/scm/linux/kernel/git/andy/linux-auxdisplay Pull auxdisplay updates from Andy Shevchenko: - Cancel backlight work on panel registration failure - Miscellaneous cleanups * tag 'auxdisplay-v7.3-1' of git://git.kernel.org/pub/scm/linux/kernel/git/andy/linux-auxdisplay: auxdisplay: charlcd: cancel backlight work on registration failure auxdisplay: panel: Remove unused callback binding code auxdisplay: Remove redundant dev_err() |
||
Jimmy Zuber
|
34b5c4a6e4 |
fuse: zero the partial EOF page when extending a file
Extending a fuse file past a non-page-aligned EOF does not zero the tail of the old last page. When that page is cached and has been mmap-dirtied beyond the old EOF, the now in-bounds tail is served to later reads as stale data rather than zeros, which violates POSIX file-extension semantics. Some file systems get this zeroing automatically at writeback time (block_write_full_folio() / iomap_writeback_handle_eof() zero the tail of the folio straddling i_size). A non-writeback caching fuse file system uses neither path, so it has to zero the tail itself from the size-extending paths, like XFS (xfs_file_write_zero_eof()) and ext4 (ext4_block_zero_eof()) do. Call truncate_pagecache_range() over the newly-exposed range up front from the three paths that extend a file, before the new size is published: - a buffered write whose position is past the old EOF (fuse_perform_write()); - a size-extending setattr/truncate (fuse_do_setattr()); - a size-extending fallocate (fuse_file_fallocate()). This unmaps the stale mappings and zeroes the partial tail of the old EOF folio, so a later read returns zeros. Truncating [old EOF, write start) before a buffered write keeps the dropped range disjoint from the written data, so a write that lands inside the old EOF folio is preserved. writeback_cache connections are unaffected, as their writes go through iomap_file_buffered_write(), which zeroes post-EOF folios. The bug is observable on a non-writeback_cache server that returns FOPEN_KEEP_CACHE on writable files (without FOPEN_DIRECT_IO), and is caught by the new write_extend_eof fuse selftest. Signed-off-by: Jimmy Zuber <jamz@amazon.com> Signed-off-by: Miklos Szeredi <mszeredi@redhat.com> |
||
Vladimir Murzin
|
b8f070ac31 |
arm64: process: Fix context switching MTE store-only tag check
SCTLR_EL1.TCSO0 is set when user opt-in for MTE store-only tag check
mode. However, it is not part of SCTLR_USER_MASK which imply that on
context switch we never clear SCTLR_EL1.TCSO0, so we are leaking that
setting into another task.
Fix that by including SCTLR_EL1_TCSO0_MASK into SCTLR_USER_MASK
Fixes:
|
||
Alexander Graf
|
1476cca098 |
dma-contiguous: fix truncation of numa_cma / cma_pernuma sizes >= 2G
numa_cma=0:4G reserves nothing at all. dma_numa_cma_reserve() copies the
requested size into a local int before handing it to
cma_declare_contiguous_nid(), so 0x100000000 truncates to zero and the
loop skips the node silently. Both parameters are documented in
kernel-parameters.txt as nn[MG], so that is the syntax the documentation
invites.
Which bits survive decides what a request turns into: 4G, 8G and 16G
reserve nothing, 2G, 3G and 6G sign-extend into a size the allocator
rejects with a warning, and 5G quietly reserves 1G.
It reaches further than those parameters. On a CMA_SIZE_PERNUMA kernel
with no per-node parameter, dma_numa_cma_reserve() takes the per-node
size from the default area, so a plain cma=4G on a multi-node machine
feeds that size through the same local and loses every per-node area.
numa_cma_size[] and pernuma_size_bytes are both phys_addr_t, so use it
for the local too, and give early_numa_cma() separate variables for the
node id and the size while in there.
Fixes:
|
||
Wei-Lin Chang
|
beca1b97a2 |
KVM: arm64: ptdump: Flush the last region
Currently the stage-2 ptdump calls note_page() at each leaf entry visit.
This simply misses the output of the last region, because note_page()
only dumps output when it detects a change in level/prot, or when the
walk enters a next marker section. The last region in the guest IPA
space with the same level/prot is not dumped since there is no change
after it.
Call note_page_flush() to dump the final region. note_page_flush()
uses ptdump_pg_state.end_address to call the final note_page(), so also
provide the end address.
Also change the second marker's start address to ULONG_MAX so we never
cross it. This avoids dumping redundant marker names (which are NULL),
and advancing beyond the end of the marker array.
Fixes:
|
||
|
Wei-Lin Chang
|
902caade3c |
arm64: ptdump: Make note_page_flush() range aware
note_page_flush() calls note_page() with addr == 0 and level == -1 to
dump the last row of a ptdump. addr == 0 (1 << 64 wrapped around)
renders a huge region with enormous size for address spaces with
IA bits < 64. For example the stage-2 page tables and the EFI runtime
page table.
More importantly, the last region of the address space and everything
after the address space up to 1 << 64 are merged into one row of
output. If the last region within the address space is valid, it will
appear to remain valid up to 1 << 64 with the same attributes.
Currently only the EFI runtime ptdump is affected by this, but KVM will
soon fix its stage-2 ptdump by using note_page_flush(). Here is an
example of an EFI runtime ptdump (last row):
0x0000008000000000-0x0000000000000000 17179868672G PGD
With this patch:
0x0000008000000000-0x0001000000000000 261632G PGD
To fix this, cache the end address of a ptdump in ptdump_pg_state so
note_page_flush() can call the final note_page() with the correct end
address.
Fixes:
|
||
Shuming Fan
|
60e73c07b3 |
ASoC: rt766: add RT766/RT767 VA1 device IDs
This patch adds the RT766/RT767 VA1 device IDs, which support SoundWire v1.3. Signed-off-by: Shuming Fan <shumingf@realtek.com> Link: https://patch.msgid.link/20260824103936.3524080-1-shumingf@realtek.com Signed-off-by: Mark Brown <broonie@kernel.org> |
||
Tetsuo Handa
|
72dd0ec09e |
printk: Don't WARN on kthread_run failure.
Since __kthread_create_on_node() returns -EINTR upon SIGKILL, we should not use WARN_ON() in order to catch kthread_run() failure. Reported-by: syzbot+1ebbc20f223b99446034@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=1ebbc20f223b99446034 Fixes: |
||
Vlastimil Babka (SUSE)
|
564ed40708 |
Merge branch 'slab/for-7.3/kfree_rcu_nolock' into slab/for-next
Merge series "mm/slab: introduce kfree_rcu_nolock() and improve slub_kunit coverage" from Harry Yoo. From the cover letter [1]: This series improves kmalloc_nolock() and kfree_nolock() coverage in slub_kunit and introduces kfree_rcu_nolock() for unknown context as suggested by Alexei Starovoitov. Unknown context means the caller does not know whether spinning on a lock is safe (e.g., a BPF program attached to an arbitrary kernel function or in NMI context). The slab allocator already supports unknown context via kmalloc_nolock() and kfree_nolock(), but te slab allocator does not support freeing objects by RCU in unknown context. It is not ideal to have completely separate batching for unknown context because the worst scenario where spinning on a lock would lead to deadlock is very rare, and in most cases, it is safe to use the existing mechanism (kfree_rcu_sheaf()). Since most part of the slab allocator already supports unknown context and sheaves support batching kvfree_rcu() calls for slab objects, implement kfree_rcu_nolock() with minimal changes by teaching kfree_rcu_sheaf() how to support unknown context and making it a little bit harder to allocate an empty sheaf, instead of making intrusive changes to the existing kvfree_rcu batching logic. kfree_rcu_nolock() tries to free the object to the rcu sheaf if trylock succeeds. Once the rcu sheaf becomes full, it is submitted to RCU via call_rcu() if spinning is allowed or IRQs are enabled (to avoid calling call_rcu() in the middle of call_rcu()). Otherwise, call_rcu() is deferred via irq work. When there is no sheaf available, kfree_rcu_sheaf() falls back to defer_kfree_rcu(). It submits the object to kvfree_rcu batching via irq work. To do this, patch 6 converts kvfree_rcu to use kvfree_rcu_head without visible changes to the API for now. Unlike kfree_rcu(), only the 2-argument variant is supported. This is because the last resort of the 1-arg variant is synchronize_rcu(), which cannot be used in an unknown context. As suggested by Alexei Starovoitov, kfree_rcu_nolock() can be used with struct kvfree_rcu_head (8 bytes), which is smaller than struct rcu_head (16 bytes). Link: https://lore.kernel.org/all/20260729-kfree_rcu_nolock-v5-0-a28cdcda9673@kernel.org/ [1] |
||
|
Vlastimil Babka (SUSE)
|
160dcfe7f9 |
Merge branch 'slab/for-7.3/objext_split' into slab/for-next
Merge series "mm/slab, alloc_tag: reduce obj_ext memory waste" from myself. From the cover letter [1]: It's been bothering me that the memory usage of struct slabobj_ext depend only on config options and not whether the fields are actually used. So with both CONFIG_MEMCG=y and CONFIG_MEM_ALLOC_PROFILING=y there is always objcg field and codetag_ref field. And thus: 1) Having memory allocation profiling config-enabled but not boot-enabled means wasted memory on unused codetag_refs. This makes it less suitable for a general distro config and the page allocator side doesn't suffer from this, only slab and percpu. 2) Complementary, with memory allocation profiling enabled, there are caches/slabs that don't need the objcg field, so memory is wasted on those. This series should solve the point 1) fully for slab; pcpuobj_ext handling can be perhaps improved similarly, haven't looked into that. For 2) it avoids allocating objcg fields for KMALLOC_NORMAL and KMALLOC_NO_OBJ_EXT caches where we know they are not necessary because kmalloc() with __GFP_ACCOUNT will pick a KMALLOC_CGROUP type (except with SLUB_TINY). The named kmem_caches are tricky. They can be created with SLAB_ACCOUNT and then we know objcg fields are always needed. But also they can be created without SLAB_ACCOUNT and then some allocations have __GFP_ACCOUNT and some not and we don't know that in advance. This series introduces a SLAB_MAY_ACCOUNT flag that's currently internal only and is applied to all caches (unless kmem accounting is disabled) except KMALLOC_NORMAL (unless that aliases KMALLOC_RECLAIM) and KMALLOC_NO_OBJ_EXT. As a followup we can make SLAB_MAY_ACCOUNT explicit and add it to to caches where we know __GFP_ACCOUNT is used. Then we could only honour __GFP_ACCOUNT for those, while warning for an unexpected usage elsewhere. To check for regressions, I forward-ported a microbenchmark hacked into slub_kunit that was used to evaluate sheaves. Tried 3 scenarios, MEMCG and KFENCE were always enabled: - CONFIG_MEM_ALLOC_PROFILING=n - CONFIG_MEM_ALLOC_PROFILING=y but _ENABLED_BY_DEFAULT=n - same but booted with sysctl.vm.mem_profiling=1 The results are quite noisy, but no regression was apparent, except perhaps few percents for the last case. I don't expect it will be visible in any real workloads. Link: https://lore.kernel.org/all/20260727-b4-objext_split-v3-0-c29ef0f1f257@kernel.org/ [1] |
||
Daniel Palmer
|
c9e17e381e |
rtc: msc313: Select by default on MSTARV7
All of the ARCH_MSTARV7 chips have this RTC so it's more likely ARCH_MSTARV7 wants it than doesn't. At the same time fix up the indent on the depends on line that looks like it got converted from a tab to spaces at some point. Signed-off-by: Daniel Palmer <daniel@0x0f.com> Link: https://patch.msgid.link/20260713133919.1356748-1-daniel@thingy.jp Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> |
||
Babanpreet Singh
|
93847823b6 |
tee: qcomtee: fix kernel-doc warnings
Fix kernel-doc issues present since the driver was added in commit |