summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2026-10-14Bluetooth: hci_core: Return -ENOMEM when the sent_cmd clone failsIbrahim Abdelkader
hci_send_cmd_sync() returns -EINVAL when skb_clone() fails for sent_cmd, which describes an invalid argument rather than an allocation failure. Return -ENOMEM instead. The only caller, hci_cmd_work(), tests the result for zero, so there is no functional change. Signed-off-by: Ibrahim Abdelkader <iabdelka@qti.qualcomm.com> Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-10-14Input: da7280 - fix input device parent assignmentDmitry Torokhov
Assigning the I2C bus controller (client->dev.parent) instead of the I2C client (&client->dev) as the parent device after devm_input_allocate_device() causes input_register_device() to attach the devm unregistration action to the parent controller device rather than the client device. This leaves the input device registered on driver unbind, leading to use-after-free. devm_input_allocate_device() already sets input_dev->dev.parent to &client->dev. Drop the redundant and erroneous assignment. Fixes: cd3f609823a5 ("Input: new da7280 haptic driver") Assisted-by: LLM Link: https://patch.msgid.link/20261008094736.918137-1-dmitry.torokhov@gmail.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-10-14Bluetooth: enable context analysis for headersPauli Virtanen
Remove context analysis suppression for include/net/bluetooth/*, now that previous commits have resolved the warnings. Reviewed-by: Bart Van Assche <bvanassche@acm.org> Signed-off-by: Pauli Virtanen <pav@iki.fi> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-10-14Bluetooth: L2CAP: add locking annotations for l2cap_chan_lock/unlockPauli Virtanen
Add minimal context analysis annotations to l2cap_chan_lock/unlock() and callers required for no warnings. Reviewed-by: Bart Van Assche <bvanassche@acm.org> Signed-off-by: Pauli Virtanen <pav@iki.fi> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-10-14Bluetooth: L2CAP: avoid maybe-return-locked in l2cap_get_chan_by_scid/dcidPauli Virtanen
Replace the maybe-return-locked pattern in l2cap_get_chan_by_scid/dcid() by doing locking in the caller after NULL check. This allows adding context analysis annotations for the locking. Reviewed-by: Bart Van Assche <bvanassche@acm.org> Signed-off-by: Pauli Virtanen <pav@iki.fi> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-10-14Bluetooth: hci_core: add lockdep check to hci_conn lookupsPauli Virtanen
Add lockdep check for RCU || hdev->lock in hci_conn_hash lookups that return hci_conn pointer, as dereferencing that without locks can be TOCTOU issue. It used to be several callsites did not hold appropriate locks. The check is equivalent to removing rcu_read_lock() and doing instead list_for_each_entry_rcu(c, &h->list, list, lockdep_is_held(&hdev->lock)) Although there should not be any remaining callsites without locks, don't remove the rcu_read_lock() for now, and just add the warning here. Signed-off-by: Pauli Virtanen <pav@iki.fi> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-10-14Bluetooth: hci_serdev: Fix use-after-free in hci_uart_unregister_device()ZhaoJinming
hci_uart_unregister_device() frees the HCI device (hci_free_dev) before cancelling write_work via cancel_work_sync(). If write_work is executing concurrently on another CPU, it can access hu->hdev and write to hdev->stat after the memory has been freed. Additionally, HCI_UART_PROTO_READY is not cleared until after cancel_work_sync, so the write_wakeup serdev callback can still schedule write_work via hci_uart_tx_wakeup() even after hci_free_dev has freed the device. Fix this by mirroring the same ordering used in the tty/ldisc path (hci_uart_tty_close, hci_ldisc.c:565-593): 1. Save the PROTO_READY state and clear it under the write lock so a concurrent hci_uart_tx_wakeup() cannot re-schedule write_work 2. Cancel write_work (no new work can be scheduled and no work is in flight) 3. Unregister the HCI device 4. Close the protocol (may access hu->hdev and the serdev device) 5. Close the serdev port (safe now that write_work is quiesced and protocol is done) 6. Free the HCI device Also free any partially transmitted frame (hu->tx_skb) left over by write_work once the transmit path is quiesced, since hci_uart_close() would skip hci_uart_flush() because HCI_UART_PROTO_READY is cleared. Signed-off-by: ZhaoJinming <zhaojinming@uniontech.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-10-14Bluetooth: btmtksdio: fix deadlock in close and reset pathsZhaoJinming
btmtksdio_close() and btmtksdio_reset() call cancel_work_sync() on bdev->txrx_work while holding the sdio host lock, which is also acquired by btmtksdio_txrx_work(). If txrx_work is queued when close/reset runs, a worker thread may start it after the host lock is taken and block in sdio_claim_host(), while cancel_work_sync() waits for the work to finish. The host lock is only released after cancel_work_sync() returns, so both sides wait forever, deadlocking close/reset. Fix this by releasing the sdio host lock before calling cancel_work_sync(), then re-acquiring it afterwards. In btmtksdio_close() the interrupt is already disabled by sdio_release_irq(), which also unregisters the IRQ handler, so no new work can be scheduled and cancel_work_sync() fully quiesces txrx_work. btmtksdio_reset() must additionally unregister the IRQ handler before dropping the host lock: btmtksdio_txrx_work() unconditionally re-enables the device interrupt (C_INT_EN_SET) when the handler is still registered, so an in-flight worker would re-enable interrupts and be rescheduled while the device is being reset, defeating the cancellation. The IRQ is re-claimed by btmtksdio_open() when the HCI device is re-opened after the reset. This mirrors the pattern already used by btmtksdio_flush(), which cancels the work without holding the host lock. Signed-off-by: ZhaoJinming <zhaojinming@uniontech.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-10-14Input: maple_keyb - remove unused mdev->driver assignmentDmitry Torokhov
The driver field in struct maple_device is no longer used since commit 1795cf48b322 ("sh/maple: clean maple bus code") which removed the reading of this field. Remove the unused assignment to mdev->driver and the now unused mdrv variable in probe_maple_kbd. Assisted-by: Antigravity:gemini-3.5-flash Link: https://patch.msgid.link/20260703-b4-maple-cleanup-v1-13-41e424964da5@gmail.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-10-14Input: maplecontrol - remove unused mdev->driver assignmentDmitry Torokhov
The driver field in struct maple_device is no longer used since commit 1795cf48b322 ("sh/maple: clean maple bus code") which removed the reading of this field. Remove the unused assignment to mdev->driver and the now unused mdrv variable in probe_maple_controller. Assisted-by: Antigravity:gemini-3.5-flash Link: https://patch.msgid.link/20260703-b4-maple-cleanup-v1-12-41e424964da5@gmail.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-10-14Bluetooth: virtio_bt: Fix use-after-free and memory leak in probe error pathsZhaoJinming
When virtbt_open_vdev() fails in virtbt_probe(), hci_free_dev(hdev) is called without first calling hci_unregister_dev(hdev). Since hci_register_dev() already succeeded, the HCI device remains registered while its memory is freed, leading to a use-after-free when accessed via sysfs or HCI sockets. Additionally, the probe function leaks the virtio_bluetooth structure (vbt) in several error paths: - When virtio_find_vqs() fails, vbt is not freed. - When hci_alloc_dev() or hci_register_dev() fails, vbt is not freed. - When virtbt_open_vdev() fails, vbt is not freed. Furthermore, when virtbt_open_vdev() fails after virtio_device_ready() has been called, the device is left live (DRIVER_OK set) while its virtqueues are torn down, and any scheduled work is not flushed, potentially allowing a use-after-free from device-initiated callbacks. Fix all of these by restructuring the error labels to properly unwind in reverse order of the allocation/registration sequence. The new labels err_del_vqs and err_free_vbt ensure that del_vqs and kfree(vbt) are called as appropriate for each failure point. For the virtbt_open_vdev() failure path, call virtio_reset_device() and virtbt_close_vdev() before unregistering the HCI device, matching the cleanup pattern in virtbt_remove(). Signed-off-by: ZhaoJinming <zhaojinming@uniontech.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-10-14Input: maplemouse - remove unused mdev->driver assignmentDmitry Torokhov
The driver field in struct maple_device is no longer used since commit 1795cf48b322 ("sh/maple: clean maple bus code") which removed the reading of this field. Remove the unused assignment to mdev->driver and the now unused mdrv variable in probe_maple_mouse. Assisted-by: Antigravity:gemini-3.5-flash Link: https://patch.msgid.link/20260703-b4-maple-cleanup-v1-11-41e424964da5@gmail.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-10-14Input: maplecontrol - remove redundant drvdata resettingDmitry Torokhov
The driver core automatically resets driver data to NULL on probe failures and device removal, so we can remove it from the driver. Assisted-by: Antigravity:gemini-3.5-flash Link: https://patch.msgid.link/20260703-b4-maple-cleanup-v1-10-41e424964da5@gmail.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-10-14Bluetooth: btusb: Add Realtek RTL8821CE device 13d3:3558Richard Nunley
The IMC Networks Bluetooth controller with USB ID 13d3:3558 uses an RTL8821CE. Without BTUSB_REALTEK, btusb uses generic initialization and does not load the controller firmware. BLE connections then fail before pairing with HCI error 0x3e. Add the device ID to the RTL8821CE table. This enables loading rtl_bt/rtl8821c_fw.bin and rtl_bt/rtl8821c_config.bin, after which a BLE HID keyboard pairs successfully. Signed-off-by: Richard Nunley <richard.w.nunley@gmail.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-10-14Input: maple_keyb - remove redundant drvdata resettingDmitry Torokhov
The driver core automatically resets driver data to NULL on probe failures and device removal, so we can remove it from the driver. Assisted-by: Antigravity:gemini-3.5-flash Link: https://patch.msgid.link/20260703-b4-maple-cleanup-v1-9-41e424964da5@gmail.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-10-14Input: maplemouse - remove redundant drvdata resettingDmitry Torokhov
The driver core automatically resets driver data to NULL on probe failures and device removal, so we can remove it from the driver. Assisted-by: Antigravity:gemini-3.5-flash Link: https://patch.msgid.link/20260703-b4-maple-cleanup-v1-8-41e424964da5@gmail.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-10-14Bluetooth: btmrvl: Slightly simplify btmrvl_process_event()Christophe JAILLET
In btmrvl_process_event(), all error handling paths except one do a direct return. Update the only one that makes a goto to be consistent. This does not change the behavior because ret is known to be != 0 when 'exit' is reached. This simplifies the code, saves 2 LoC and pleases one of my coccinelle script that tries to spot erroneously mixed goto and return statements. Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-10-14Input: maple_keyb - implement open and close methodsDmitry Torokhov
Instead of polling the keyboard constantly from probe, implement open and close methods for the input device to only start polling when the device is actually opened by userspace, and stop polling when it is closed. This matches the behavior of maplemouse and maplecontrol drivers. Assisted-by: Antigravity:gemini-3.5-flash Link: https://patch.msgid.link/20260703-b4-maple-cleanup-v1-7-41e424964da5@gmail.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-10-14Input: maplemouse - stop polling and clear callback on closeDmitry Torokhov
In dc_mouse_close(), pass NULL instead of dc_mouse_callback to maple_getcond_callback() to both stop polling and clear the callback pointer when the input device is closed. This makes the manual clearing of mdev->callback in remove_maple_mouse() redundant, as input_unregister_device() automatically closes the device if it was open. Remove the redundant assignment. Assisted-by: Antigravity:gemini-3.5-flash Link: https://patch.msgid.link/20260703-b4-maple-cleanup-v1-4-41e424964da5@gmail.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-10-14Bluetooth: bnep: refactor deprecated strcpyAjith P V
The strcpy() function is deprecated across the kernel tree and moving towards complete elimination. It provides no verification limits against buffer overflows and does not guarantee strict boundary restrictions [1][2]. Replace instances of strcpy() in `net/bluetooth/bnep/core.c` with the safer strscpy() alternative. Since both target destination blocks are statically allocated fixed-size arrays within their structure definitions, leverage the compile time sizeof() operator to explicitly pass the destination buffer capacities. Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strcpy [1] Link: https://github.com/KSPP/linux/issues/88 [2] Signed-off-by: Ajith P V <ajithpv.linux@gmail.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-10-14Input: maplecontrol - stop polling and clear callback on closeDmitry Torokhov
In dc_pad_close(), pass NULL instead of dc_pad_callback to maple_getcond_callback() to both stop polling and clear the callback pointer when the input device is closed. This makes the manual clearing of mdev->callback in remove_maple_controller() redundant, as input_unregister_device() automatically closes the device if it was open. Remove the redundant assignment. Assisted-by: Antigravity:gemini-3.5-flash Link: https://patch.msgid.link/20260703-b4-maple-cleanup-v1-5-41e424964da5@gmail.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-10-14Bluetooth: hci_sync: Factor common cleanup code into a helperHans de Goede
The hci_dev_init_sync() failure path in hci_dev_open_sync() and the cleanup code in hci_dev_close_sync() have a bunch of common code. Factor this duplicate code out into a hci_dev_drop_last_cmd_req_and_close() helper function. Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-10-14Input: maplecontrol - emit EV_SYN report after reporting eventsDmitry Torokhov
The driver decodes controller packets and reports button presses and axis positions in dc_pad_callback(), but never calls input_sync() to signal completion of the input report frame. Consequently, events remain pending without waking up userspace readers. Emit an EV_SYN/SYN_REPORT event after reporting buttons and axis states. Fixes: 01461d7e65a6 ("Input: add support for Maple controller as a joystick") Reported-by: sashiko-bot@kernel.org Closes: https://lore.kernel.org/r/20260704061045.036701F000E9@smtp.kernel.org Assisted-by: LLM Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-10-14Input: maplecontrol - only enable present axesDmitry Torokhov
The driver was unconditionally enabling all possible analog axes and hats on the input device, even if the controller reported it did not have them in its function data. Move the input_set_abs_params() calls inside the capability check loop so that only actually present axes are enabled on the input device. Also, correct the D-pad (hat) axis limits. They were initialized with inverted limits (min=1, max=-1). Correct them to min=-1, max=1, which matches the values (-1, 0, 1) reported by the driver. Assisted-by: Antigravity:gemini-3.5-flash Link: https://patch.msgid.link/20260703-b4-maple-cleanup-v1-3-41e424964da5@gmail.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-10-14PCI: Set supported_speeds in set_pcie_port_type()Stian Halseth
sparc64 and powerpc create PCI devices from the device tree in of_create_pci_dev(), which calls set_pcie_port_type() but not pci_setup_device(). Since d2bd39c0456b, supported_speeds is only set in pci_setup_device(), so it stays 0 for these devices. pcie_get_speed_cap() then returns PCI_SPEED_UNKNOWN, the sysfs 'max_link_speed' attribute reads "Unknown", and the failed link retraining quirk passes PCI_SPEED_UNKNOWN to pcie_set_target_speed(), which warns on a SPARC T7-1: WARNING: drivers/pci/pcie/bwctrl.c:125 at pcie_set_target_speed+0x284/0x2e0 Set supported_speeds in set_pcie_port_type(), which all three paths call. Fixes: d2bd39c0456b ("PCI: Store all PCIe Supported Link Speeds") Closes: https://github.com/sparclinux/issues/issues/109 Signed-off-by: Stian Halseth <stian@itx.no> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Tested-by: Tony Rodriguez <unixpro1970@gmail.com> Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20261007131304.309511-1-stian@itx.no
2026-10-14docs: kernel-parameters: adjust reserve_mem build optionRandy Dunlap
"[RAM]" means that the command line option is applicable when "RAM disk support is enabled." However, the reserve_mem command line option is not related to RAM disk support, so modify its build option relevance to "[MM]" instead. Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org> Acked-by: SJ Park <sj@kernel.org> Signed-off-by: Jonathan Corbet <corbet@lwn.net> Message-ID: <20261003213457.96408-1-rdunlap@infradead.org>
2026-10-14workqueue: mark pool->nr_running as __data_racyNguyen Ngoc Thang
wq_worker_running() increments pool->nr_running with only preemption disabled, while kick_pool_pick() reads it via need_more_worker() under pool->lock, so the two can run concurrently on different CPUs. KCSAN reports: BUG: KCSAN: data-race in kick_pool_pick / wq_worker_running write to 0xffff888059c2af24 of 4 bytes by task 3007 on cpu 0: wq_worker_running+0x114/0x130 schedule_timeout+0x16e/0x180 io_schedule_timeout+0x4c/0x70 submit_bio_wait+0xd7/0x110 blkdev_issue_flush+0x4c/0x70 ext4_sync_file+0x60d/0x6c0 aio_fsync_work+0x7f/0x270 process_one_work+0x4ae/0xa00 read to 0xffff888059c2af24 of 4 bytes by task 3001 on cpu 1: kick_pool_pick+0x7a/0x3a0 __queue_work+0x72d/0xcf0 queue_work_on+0x9d/0xb0 schedule_on_each_cpu+0x11a/0x2d0 vmstat_refresh+0x23/0x140 proc_sys_call_handler+0x2b9/0x4f0 The race is benign. The increment in wq_worker_running() is the only lockless write to nr_running; decrements and the reset are done under pool->lock, so a reader holding the lock sees either the old or the new count. A stale 0 costs at most a spurious wakeup of an idle worker. A nonzero count is correct because the incrementing worker is running and re-checks the worklist under pool->lock before it stops counting. The increment can also go 1 -> 2, e.g. when a worker sleeping in a work item wakes up after kick_pool() woke another worker. The lockless increment is part of how nr_running is designed to work, as the comment above the field documents. Mark the field __data_racy so that every reader is covered, not just need_more_worker(). Reported-by: syzbot+8922e6b8343f70be92e8@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=8922e6b8343f70be92e8 Signed-off-by: Nguyen Ngoc Thang <ngocthang2710.1999@gmail.com> Signed-off-by: Tejun Heo <tj@kernel.org>
2026-10-14docs: kernel-parameters: don't mix cmdline options & build optionsRandy Dunlap
Some kernel command line descriptions mix, mingle, or conflate an optional part of the command line with the build options that are applicable to those command line options. Specifically, a few command line options that use "KMG" to specify a memory size mix that string with build options like "X86,EARLY". These should be separate fields although they are both enclosed in square brackets, so separate the conflated fields. Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Jonathan Corbet <corbet@lwn.net> Message-ID: <20261003213508.96424-1-rdunlap@infradead.org>
2026-10-14PCI: Fix out-of-bounds MMIO read in nvme_disable_and_flr()Mohamad Raizudeen
In nvme_disable_and_flr(), the PCI bar is mapped using NVME_REG_CC + sizeof(cfg) which is (0x14 + 4 = 0x18 bytes) However, the function later reads the controller status from NVME_REG_CSTS - offset 0x1C, which is outside the mapped 0x18 byte boundary. This violates the API contract. Fix this by increasing the mapping size to include NVME_REG_CSTS. Also change sizeof(cfg) to sizeof(u32) to make the intent clearer. Fixes: ffb0863426eb9 ("PCI: Disable Samsung SM961/PM961 NVMe before FLR") Signed-off-by: Mohamad Raizudeen <raizudeen.kerneldev@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Alex Williamson <alex@shazbot.org> Link: https://patch.msgid.link/20260903164615.5744-1-raizudeen.kerneldev@gmail.com
2026-10-14docs/ja_JP: translate submitting-patches.rst (review and report tags)Akiyoshi Kurita
Translate the section describing Reported-by, Tested-by, Reviewed-by, Suggested-by, and Fixes tags into Japanese. This includes the Reviewer's Statement and the guidance on adding or removing review and testing tags in subsequent patch versions. Keep the Reviewer's Statement in English and add a Japanese tentative translation in a formal style. Signed-off-by: Akiyoshi Kurita <weibu@redadmin.org> Reviewed-by: Akira Yokosawa <akiyks@gmail.com> Signed-off-by: Jonathan Corbet <corbet@lwn.net> Message-ID: <20261007004715.107860-1-weibu@redadmin.org>
2026-10-14Input: maple_keyb - fix key press detectionDmitry Torokhov
The key press detection logic was using ptr instead of !ptr (where ptr is the result of memchr searching for the new key in the old keys). If ptr is not NULL, it means the key was already pressed in the previous report, so it is not a new press. If ptr is NULL, it means the key was not pressed before, so it is a new press. Using ptr instead of !ptr caused new presses to be ignored in the first poll cycle (only reported in the second cycle if still held, because then it was in 'old'), and caused redundant press events to be sent on every subsequent poll while the key was held. Fix this by using !ptr for press detection, matching the release detection logic. Fixes: b11d2127c489 ("Input: add support for SEGA Dreamcast keyboard") Assisted-by: Antigravity:gemini-3.5-flash Tested-by: Florian Fuchs <fuchsfl@gmail.com> Link: https://patch.msgid.link/20260703-b4-maple-cleanup-v1-2-41e424964da5@gmail.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-10-14docs: remove Assisted-by referencesSasha Levin
Commit 78d979db6cef ("docs: add AI Coding Assistants documentation") asked contributors to add an Assisted-by tag to patches developed with help from an LLM, and commit 816d9992d9ed ("coding-assistants: simplify attribution") later reduced the tag to "Assisted-by: LLM". A proposal to drop the tag was turned down in July [1]. The main argument for keeping it was that maintainers wanted a signal that a patch was LLM-assisted, so that they could review it accordingly. The tag came up again at the 2026 Maintainers Summit [2]. Roughly 10% of the 18,533 non-merge commits in 7.3 through -rc7 carry an Assisted-by tag, while actual LLM use is far more widespread. Some contributors do not know about the rule, others leave the tag off on purpose, and few maintainers ask about it. As a result, the tag does not provide the signal it was kept for: its absence says nothing about how a patch was made, and for developers who use these tools for almost everything, its presence says little more. The choice was between finding a way to enforce the requirement and dropping it, and there was a strong, though not unanimous, consensus in the room to drop it. Greg Kroah-Hartman, who argued for keeping the tag in July, supports removing it now [3]. Maintainers do still want to know how a patch was created, but the view at the Summit was that this belongs in the cover letter, where it can describe how the tools were used, rather than in the changelog. Documentation/process/generated-content.rst already asks contributors to be transparent about tool use and is not changed here. The rules on the DCO and on the submitter's responsibility for the patch stay as they are. Remove the Assisted-by sections from coding-assistants.rst, submitting-patches.rst, and the Italian, Brazilian Portuguese and Traditional Chinese translations, and drop the handling of the tag from checkpatch. [1] https://lore.kernel.org/workflows/2026070224-unholy-commode-cf45@gregkh/ [2] https://lwn.net/Articles/1099594/ [3] https://lore.kernel.org/all/2026101327-cupid-legal-6cf6@gregkh/ Acked-by: Lorenzo Stoakes (ARM) <ljs@kernel.org> Reviewed-by: Kees Cook <kees@kernel.org> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org> Reviewed-by: Jeff Layton <jlayton@kernel.org> Reviewed-by: Jori Koolstra <jkoolstra@xs4all.nl> Acked-by: Krzysztof Kozlowski <krzk@kernel.org> Acked-by: SJ Park <sj@kernel.org> Acked-by: David Hildenbrand (Arm) <david@kernel.org> Acked-by: Mark Brown <broonie@kernel.org> Acked-by: Daniel Pereira <danielmaraboo@gmail.com> Acked-by: Shuah Khan <skhan@linuxfoundation.org> Acked-by: Weijie Yuan <wy@wyuan.org> Reviewed-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Jonathan Corbet <corbet@lwn.net> Message-ID: <20261013121501.3738437-1-sashal@kernel.org>
2026-10-14Merge asoc/for-7.4 into asoc-nextMark Brown
2026-10-14Merge asoc-linus into asoc-nextMark Brown
2026-10-14Merge branches 'fixes' and 'misc' into for-nextRussell King (Oracle)
2026-10-14Merge tag 'kvmarm-7.4' of ↵Paolo Bonzini
git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm into HEAD KVM/arm64 updates for 7.4 * New features - pKVM state isolation: years after pKVM started being enabled upstream, we finally get the basics in the form of state isolation. The vcpu state is now off-limit for the host for protected VMs. - pKVM also grows a hypervisor-private memory allocator, allowing it to deal with sub-page allocation, much like everywhere else. - pKVM also lands a trace_printk() equivalent, which hopefully will make debugging a bit easier. - First shot at annotating portions of the KVM/arm64 code to be extracted and built on s390. The real fun is yet to come. - Allow pre-faulting of stage-2 canonical mappings from userspace, joining x86 and s390 in implementing this feature. - Add a reverse mapping infrastructure for shadow stage-2, significantly improving performance when MMU notifiers kick in, and avoiding full unmap of all shadow tables for this VM. - Next step of GICv5 enablement, adding support for the IRS block, and providing both SPI and LPI support. This is the first point where KVM/arm64 can support an SMP GICv5 guest. * Improvements - As a preliminary to eventually enabling CCA, add a bunch of infrastructure to KVM/arm64, splitting some of the basic operations into individual backends (normal VM, normal pKVM VM, protected pKVM VM). This allows CCA to later slot in without polluting the rest of KVM with its firmware-driven nonsense. - Make ID registers immutable from the point where a vcpu is able to run, even if it fails to run. This prevents KVM from sampling untrusted values. - Restore some type checking to the EL2 object. KVM/arm64 originally had some strong type checking between the kernel and the EL2 object, but lost it along the way when the private hypercall interface was (somewhat pointlessly) converted to SMCCC. Type checking is back, syscall style, and with added sparse goodies. - Expand the FFA support to FFA_NOTIFICATION_*, and add some sanitisation of the protocol that pKVM relays to the "trusted" runtime. * Fixes - Make GICv3 RD assignment more robust to userspace nonsense - Convert the remaining MMU fault handler backends to kvm_s2_fault_vma_info and co, fixing a number of bugs in the process. - Fix the SError/SEA selftests to be both more robust and less braindead. - Fix a smattering of documentation bugs, some of them as a result of our AI friends spitting out credible assertions based on non-existing symbols. - The usual collection of low impact bug fixes (SMCCC, timers, PMU).
2026-10-14ARM: 9493/1: asid: Do not replace active_asids if already 0Catalin Marinas
Under some uncommon timing conditions, a generation check and xchg(active_asids, A1) in check_and_switch_context() on P1 can race with an ASID roll-over on P2. If P2 has not seen the update to active_asids[P1], it can re-allocate A1 to a new task T2 on P2. P1 ends up waiting on the spinlock since the xchg() returned 0 while P2 can go through a second ASID roll-over with (T2,A1,G2) active on P2. This roll-over copies active_asids[P1] == A1,G1 into reserved_asids[P1] and active_asids[P2] == A1,G2 into reserved_asids[P2]. A subsequent scheduling of T1 on P1 and T2 on P2 would match reserved_asids and get their generation bumped to G3: P1 P2 -- -- TTBR0.BADDR = T0 TTBR0.ASID = A0 asid_generation = G1 check_and_switch_context(T1,A1,G1) generation match check_and_switch_context(T2,A0,G0) new_context() ASID roll-over asid_generation = G2 flush_context() active_asids[P1] = 0 asid_map[A1] = 0 reserved_asids[P1] = A0,G0 xchg(active_asids, A1) active_asids[P1] = A1,G1 xchg returns 0 spin_lock_irqsave() allocated ASID (T2,A1,G2) asid_map[A1] = 1 active_asids[P2] = A1,G2 ... check_and_switch_context(T3,A0,G0) new_context() ASID roll-over asid_generation = G3 flush_context() active_asids[P1] = 0 asid_map[A1] = 1 reserved_asids[P1] = A1,G1 reserved_asids[P2] = A1,G2 allocated ASID (T3,A2,G3) asid_map[A2] = 1 active_asids[P2] = A2,G3 new_context() check_update_reserved_asid(A1,G1) matches reserved_asid[P1] reserved_asid[P1] = A1,G3 updated T1 ASID to (T1,A1,G3) check_and_switch_context(T2,A1,G2) new_context() check_update_reserved_asid(A1,G2) matches reserved_asids[P2] reserved_asids[P2] = A1,G3 updated T2 ASID to (T2,A1,G3) At this point, we have two tasks, T1 and T2 both using ASID A1 with the latest generation G3. Any of them is allowed to be scheduled on the other CPU leading to two different tasks with the same ASID on the same CPU. This patch changes the xchg to cmpxchg so that the active_asids is only updated if non-zero to avoid a race with an ASID roll-over on a different CPU. Cc: Will Deacon <will@kernel.org> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Tested-by: Karl Mehltretter <kmehltretter@gmail.com> Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2026-10-14ARM: 9490/1: backtrace-clang: fix wrong sp usage for unwindingOnkarnath
show_stack() can be called for any task, but c_backtrace is always unwinding frames based on "sp" register. Which leads to printing backtrace of current task instead of required task. Try with normal TC: ================== for_each_process(p){ sched_show_task(p); } [7.433271] task:kthreadd state:S stack:0 pid:2 tgid:2 ppid:0 task_flags:0x208040 flags:0x00000000 [7.433633] Call trace: [7.433640] [<80113418>] (dump_backtrace) from [<80113510>] (show_stack+0x14/0x18) .. [7.433676] [<8016749c>] (sched_show_task) from [<803cb324>] (meminfo_proc_show+0x6c/0x930) [7.434019] r5:8158e300 r4:8b4882d0 [7.434024] [<803cb324>] (meminfo_proc_show) from [<80365788>] (seq_read_iter+0x148/0x4bc) [7.434045] [<80365788>] (seq_read_iter) from [<803c044c>] (proc_reg_read_iter+0xb8/0xc4) [7.434060] [<803c044c>] (proc_reg_read_iter) from [<80377104>] (copy_splice_read+0x228/0x308) It should unwind frame based on passed "fp". (CONFIG_UNWINDER_FRAME_POINTER=y) Extra sp manipulation is needed only when c_backtrace() is called from dump_backtrace() with "frame == fp" i.e. NULL regs and not current task. (Suggested by Ard Biesheuvel) Otherwise passed "fp" should be used to unwind backtraces. With fix: ========= [13.933732] task:kthreadd state:S stack:0 pid:2 tgid:2 ppid:0 task_flags:0x208040 flags:0x00000000 [13.934165] Call trace: [13.934604] [<80afa1a8>] (schedule) from [<8015426c>] (kthreadd+0x124/0x208) [13.934654] r10:8100bbf0 r4:8116f440 [13.934664] [<8015426c>] (kthreadd) from [<8010010c>] (ret_from_fork+0x14/0x28) [13.934691] Exception stack(0xf081df9c to 0xf081dfe4) Suggested-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Onkarnath <onkarnath.1@samsung.com> Signed-off-by: Maninder Singh <maninder1.s@samsung.com> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2026-10-14Merge tag 'kvmarm-fixes-7.3-2' of ↵Paolo Bonzini
git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm into HEAD KVM/arm64 fixes for 7.3, round #2 - Take a reference on the last IRQ loaded into an LR to prevent it from being freed while running the guest (Marc Zyngier) - Ensure that the ITS MOVALL command only affects LPIs that were previously affined to the source redistributor (Marc Zyngier) - Fix + test for honoring the host's trap configuration when running non-protected VMs while KVM is in protected mode (Fuad Tabba) - Use the host stage-1 mapping granularity for VM_PFNMAP mappings at stage-2 (Mostafa Saleh)
2026-10-14ARM: 9482/5: decompressor: always set endianess on xscaleLinus Walleij
In BE32 configurations, endianess is always set to BE in Control Register C1, originally to allow booting BE kernels from a LE bootloader on IXP12xx. To also allow the opposite and allow booting LE kernels from a BE IXP4xx bootloader, moving this code into head-xscale.S along with the recommended serialization sequence and flip the B bit into the correct position regardless of its original state. Note that both the endianess switch sequence and the cp15wait I add here should be harmless on all supported ARMv4/v4t/v5 CPUs, but the existing cache flush code is not actually defined on ARM720 and may cause problems in multiplatform kernels that include both Xscale and CLPS711x. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Linus Walleij <linusw@kernel.org> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2026-10-14KVM: Replace CONFIG_KVM_MMIO with __KVM_NO_MMIOSteffen Eiden
Defining KVM_MMIO is not flexible enough for multi-KVM systems where one KVM implements MMIO but others do not. Therefore, remove KVM_MMIO from the config space and use the macro __KVM_NO_MMIO instead. Define __KVM_NO_MMIO for KVM/s390 and for HV-only 64-bit Book3s (aka pSeries/sPAPR) configurations. In particular, for PowerPC configurations: * KVM_BOOK3S_32 got KVM_MMIO via KVM_BOOK3S_32_HANDLER and KVM_BOOK3S_PR_POSSIBLE * KVM_BOOK3S_64 got KVM_MMIO via KVM_BOOK3S_PR_POSSIBLE if !KVM_BOOK3S_HV_POSSIBLE * KVM_BOOK3S_64 + KVM_BOOK3S_64_PR got KVM_MMIO via KVM_BOOK3S_PR_POSSIBLE * likewise for KVM_BOOK3S_64 + KVM_BOOK3S_64_PR + KVM_BOOK3S_64_HV * KVM_E500V2 and KVM_E500MC directly selected KVM_MMIO but KVM_BOOK3S_64 + KVM_BOOK3S_64_HV didn't and therefore needs __KVM_NO_MMIO. coalesced_mmio.c is now always compiled and linked. However, for architectures/configurations defining __KVM_NO_MMIO this effectively collapses to an empty object with no mmio code. No functional changes. Suggested-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Steffen Eiden <seiden@linux.ibm.com> Link: https://patch.msgid.link/20260930173441.66762-4-seiden@linux.ibm.com [Simplify powerpc condition, add underscores. - Paolo] Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2026-10-14KVM: Move architecture capability Kconfigs to header definesSteffen Eiden
With s390 hosting multiple independent KVM implementations within the same kernel build (native s390 KVM and arm64 on s390), global Kconfig selections force both implementations to inherit options that only apply to one of them. Replace global Kconfig options which only apply to one KVM implementation with architecture-specific opt-in defines in the respective <asm/kvm_host.h>. Only remove Kconfig symbols that would be different on both s390 KVM implementations - __KVM_HAVE_INVALID_WAKEUPS (formerly HAVE_KVM_INVALID_WAKEUPS) - __KVM_HAVE_MSI (formerly HAVE_KVM_MSI) - __KVM_HAVE_NO_POLL (formerly HAVE_KVM_NO_POLL) - __KVM_HAVE_READONLY_MEM (formerly HAVE_KVM_READONLY_MEM) - __KVM_HAVE_VCPU_RUN_PID_CHANGE (formerly HAVE_KVM_VCPU_RUN_PID_CHANGE) This allows each architecture and guest implementation to configure its supported capabilities independently in its kvm_host header and eliminates adding unnecessary fallback stubs across different KVM targets. Acked-by: Hendrik Brueckner <brueckner@linux.ibm.com> Signed-off-by: Steffen Eiden <seiden@linux.ibm.com> Link: https://patch.msgid.link/20261013121343.1997112-1-seiden@linux.ibm.com Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2026-10-14KVM: uapi: remove dead #definesPaolo Bonzini
These #defines were used for the old KVM-specific device assignment and have had no in-tree use for more than 10 years. Drop them. Link: https://patch.msgid.link/kvm/20261012174847.147915-1-pbonzini@redhat.com/ Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2026-10-14ARM: 9524/1: mm: align hugetlb mappings to the huge page sizeKarl Mehltretter
mmap(MAP_HUGETLB) on 32-bit Arm can return an address which is not aligned to the huge page size. In a QEMU virt guest, unmapping the VMA then hits the alignment check in __unmap_hugepage_range(): kernel BUG at mm/hugetlb.c:5213! Internal error: Oops - BUG: 0 [#1] SMP ARM PC is at __unmap_hugepage_range+0x540/0x584 LR is at __zap_vma_range+0x13a0/0x1410 Commit 7bd3f1e1a9ae ("mm: make hugetlb mappings go through mm_get_unmapped_area_vmflags") made hugetlb mappings use the architecture's arch_get_unmapped_area(). The generic implementations handle hugetlb alignment, but the Arm implementations only account for the optional SHMLBA cache-colouring constraint. A 4 KiB-page kernel can therefore align the mapping to 4 KiB or 16 KiB instead of the required 2 MiB. Set the alignment mask from the file's hstate for hugetlb mappings in both Arm implementations. Huge-page alignment also satisfies the SHMLBA constraint. Assisted-by: LLM Fixes: 7bd3f1e1a9ae ("mm: make hugetlb mappings go through mm_get_unmapped_area_vmflags") Cc: stable@vger.kernel.org Acked-by: Muchun Song <muchun.song@linux.dev> Link: https://lore.kernel.org/r/20260901085740.66283-1-kmehltretter@gmail.com/ Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2026-10-14ARM: 9523/1: topology: allocate the cacheinfo early on the boot CPUKarl Mehltretter
ARM secondary CPUs allocate cacheinfo in detect_cache_attributes(), called from secondary_start_kernel() with interrupts disabled. With PREEMPT_RT, the allocation takes a sleeping lock and triggers "BUG: sleeping function called from invalid context". Call fetch_cache_info() for each possible CPU from init_cpu_topology() on the boot CPU, following commit 5944ce092b97 ("arch_topology: Build cacheinfo from primary CPU"). This supplies the arrays before secondary CPUs populate them. Suppress -ENOENT and -EOPNOTSUPP, which leave cache detection to the existing late path. The CLIDR fallback uses the boot CPU's cache geometry. A secondary CPU with more cache leaves can still require late reallocation and trigger the warning. Assisted-by: LLM Fixes: a9ff94477836 ("ARM: 9433/2: implement cacheinfo support") Cc: stable@vger.kernel.org Tested-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Link: https://lore.kernel.org/r/20260912195552.76673-5-kmehltretter@gmail.com/ Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2026-10-14ARM: 9522/1: cacheinfo: guard the CLIDR read in populate_cache_leaves()Karl Mehltretter
ARM1176 and ARM11 MPCore can be reported as ARMv7 by cpu_architecture() even though they lack CLIDR. populate_cache_leaves() therefore needs the CTR-format check used by detect_cache_level(). DT-based early allocation bypasses init_cache_level(), so its check no longer protects populate_cache_leaves(). A combined ARMv6/ARMv7 SMP kernel can reach this path on BCM2835, whose DT describes its caches. Share the CLIDR capability check between detection and population. Return -ENOENT from population when CLIDR is unavailable, preserving the existing absence of cacheinfo and avoiding a new topology warning. Assisted-by: LLM Cc: stable@vger.kernel.org Tested-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Link: https://lore.kernel.org/r/20260912195552.76673-4-kmehltretter@gmail.com/ Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2026-10-14ARM: 9521/1: cacheinfo: count external caches in early_cache_level()Karl Mehltretter
early_cache_level() counts only caches described by CLIDR. An external PL310 is absent from CLIDR, and its arm,pl310-cache compatible is not accepted by init_of_cache_level(), so early allocation falls back to an incomplete count. init_cache_level() later adds the DT-described L2, forcing reallocation on the secondary CPU with interrupts disabled. This defeats early allocation on PREEMPT_RT. Use init_cache_level() for early sizing too, so the initial allocation includes external caches described by the device tree. Assisted-by: LLM Cc: stable@vger.kernel.org Tested-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Link: https://lore.kernel.org/r/20260912195552.76673-3-kmehltretter@gmail.com/ Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2026-10-14ARM: 9520/1: cacheinfo: avoid out-of-bounds write in populate_cache_leaves()Karl Mehltretter
populate_cache_leaves() advances its bounds-checking index once per cache level, but split instruction/data caches consume two entries. CLIDR-based allocation supplies enough entries. Early allocation from the device tree can supply fewer and expose an out-of-bounds write. Count each written leaf and stop before a split level that does not fit. This prepares ARM for DT-based early allocation and matches commit 875d742cf532 ("arm64: cacheinfo: Avoid out-of-bounds write to cacheinfo array"). Assisted-by: LLM Fixes: a9ff94477836 ("ARM: 9433/2: implement cacheinfo support") Cc: stable@vger.kernel.org Tested-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Link: https://lore.kernel.org/r/20260912195552.76673-2-kmehltretter@gmail.com/ Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2026-10-14ARM: 9519/1: dma-mapping: Fix wrong free function in __iommu_alloc_simple() ↵Marek Szyprowski
error path In __iommu_alloc_simple(), when IOMMU mapping creation fails, the error path unconditionally called __free_from_pool() regardless of the allocation path taken. For the COHERENT case, memory is allocated via __alloc_simple_buffer(), which does not use the atomic pool. Calling __free_from_pool() on such memory silently returns without freeing, causing a page memory leak. Fix this by matching the free function to the allocation path: - COHERENT: use __dma_free_buffer(virt_to_page(addr), size) - non-COHERENT: use __free_from_pool(addr, size) Fixes: 565068221b905 ("ARM: 8561/4: dma-mapping: Fix the coherent case when iommu is used") Signed-off-by: Li RongQing <lirongqing@baidu.com> Reviewed-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2026-10-14ARM: 9492/1: alignment: fix LSR #32 and ASR #32 offset decodingKarl Mehltretter
The register-offset form of LDR/STR may apply a shift to Rm. Per DecodeImmShift() (ARM ARM DDI0406C section A8.4.3, "Pseudocode details of instruction-specified shifts and rotates"), an imm5 of 0 encodes a shift of 32 for LSR and ASR; only LSL treats 0 as "no shift", and ROR with 0 encodes RRX. do_alignment() special-cases RRX but not LSR or ASR, and IS_SHIFT() does not filter these encodings out, so the block is entered with shiftval == 0 and the offset becomes Rm instead of 0 (LSR #32) or the replicated sign of Rm (ASR #32). do_alignment_finish_ldst() applies the offset to the base-register writeback of the post-indexed form, so the emulated access itself uses the correct faulting address but Rn is left holding the wrong value. Reproduced on ARM926EJ-S (versatile_defconfig, CONFIG_ALIGNMENT_TRAP=y, gcc 13.3.0) with a misaligned base and Rm = 0x1000: ldr r0, [r1], r2, lsr #32 Rn advanced by 0x1000, must be unchanged ldr r0, [r1], r2, asr #32 Rn advanced by 0x1000, must be unchanged ldr r0, [r1], r2, asr #32 with Rm negative, Rn must decrease by 1 All three are correct with the patch applied, while a lsr #1 control case is emulated correctly both before and after. Assisted-by: Claude:claude-fable-5 Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reviewed-by: Linus Walleij <linusw@kernel.org> Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>