Linus Torvalds [Thu, 12 Mar 2026 19:15:27 +0000 (12:15 -0700)]
Merge tag 'for-7.0-rc3-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux
Pull btrfs fixes from David Sterba:
- detect possible file name hash collision earlier so it does not lead
to transaction abort
- handle b-tree leaf overflows when snapshotting a subvolume with set
received UUID, leading to transaction abort
- in zoned mode, reorder relocation block group initialization after
the transaction kthread start
- fix orphan cleanup state tracking of subvolume, this could lead to
invalid dentries under some conditions
- add locking around updates of dynamic reclain state update
- in subpage mode, add missing RCU unlock when trying to releae extent
buffer
- remap tree fixes:
- add missing description strings for the newly added remap tree
- properly update search key when iterating backrefs
* tag 'for-7.0-rc3-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux:
btrfs: remove duplicated definition of btrfs_printk_in_rcu()
btrfs: remove unnecessary transaction abort in the received subvol ioctl
btrfs: abort transaction on failure to update root in the received subvol ioctl
btrfs: fix transaction abort on set received ioctl due to item overflow
btrfs: fix transaction abort when snapshotting received subvolumes
btrfs: fix transaction abort on file creation due to name hash collision
btrfs: read key again after incrementing slot in move_existing_remaps()
btrfs: add missing RCU unlock in error path in try_release_subpage_extent_buffer()
btrfs: set BTRFS_ROOT_ORPHAN_CLEANUP during subvol create
btrfs: zoned: move btrfs_zoned_reserve_data_reloc_bg() after kthread start
btrfs: hold space_info->lock when clearing periodic reclaim ready
btrfs: print-tree: add remap tree definitions
Linus Torvalds [Thu, 12 Mar 2026 18:33:35 +0000 (11:33 -0700)]
Merge tag 'net-7.0-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net
Pull networking fixes from Paolo Abeni:
"Including fixes from CAN and netfilter.
Current release - regressions:
- eth: mana: Null service_wq on setup error to prevent double destroy
Previous releases - regressions:
- nexthop: fix percpu use-after-free in remove_nh_grp_entry
- sched: teql: fix NULL pointer dereference in iptunnel_xmit on TEQL slave xmit
- bpf: fix nd_tbl NULL dereference when IPv6 is disabled
- neighbour: restore protocol != 0 check in pneigh update
- tipc: fix divide-by-zero in tipc_sk_filter_connect()
- eth:
- mlx5:
- fix crash when moving to switchdev mode
- fix DMA FIFO desync on error CQE SQ recovery
- iavf: fix PTP use-after-free during reset
- bonding: fix type confusion in bond_setup_by_slave()
- lan78xx: fix WARN in __netif_napi_del_locked on disconnect
Previous releases - always broken:
- core: add xmit recursion limit to tunnel xmit functions
- net-shapers: don't free reply skb after genlmsg_reply()
- netfilter:
- fix stack out-of-bounds read in pipapo_drop()
- fix OOB read in nfnl_cthelper_dump_table()
- mctp:
- fix device leak on probe failure
- i2c: fix skb memory leak in receive path
- can: keep the max bitrate error at 5%
- eth:
- bonding: fix nd_tbl NULL dereference when IPv6 is disabled
- bnxt_en: fix RSS table size check when changing ethtool channels
- amd-xgbe: prevent CRC errors during RX adaptation with AN disabled
- octeontx2-af: devlink: fix NIX RAS reporter recovery condition"
* tag 'net-7.0-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (71 commits)
net: prevent NULL deref in ip[6]tunnel_xmit()
octeontx2-af: devlink: fix NIX RAS reporter to use RAS interrupt status
octeontx2-af: devlink: fix NIX RAS reporter recovery condition
net: ethernet: ti: am65-cpsw-nuss: Fix rx_filter value for PTP support
net/mana: Null service_wq on setup error to prevent double destroy
selftests: rtnetlink: add neighbour update test
neighbour: restore protocol != 0 check in pneigh update
net: dsa: realtek: Fix LED group port bit for non-zero LED group
tipc: fix divide-by-zero in tipc_sk_filter_connect()
net: dsa: microchip: Fix error path in PTP IRQ setup
bpf: bpf_out_neigh_v6: Fix nd_tbl NULL dereference when IPv6 is disabled
bpf: bpf_out_neigh_v4: Fix nd_tbl NULL dereference when IPv6 is disabled
net: bonding: Fix nd_tbl NULL dereference when IPv6 is disabled
ipv6: move the disable_ipv6_mod knob to core code
net: bcmgenet: fix broken EEE by converting to phylib-managed state
net-shapers: don't free reply skb after genlmsg_reply()
net: dsa: mxl862xx: don't set user_mii_bus
net: ethernet: arc: emac: quiesce interrupts before requesting IRQ
page_pool: store detach_time as ktime_t to avoid false-negatives
net: macb: Shuffle the tx ring before enabling tx
...
The only user of psmouse_queue_work() and therefore kpsmoused workqueue
is psmouse-base itself, when it tries to schedule the resync work. Since
resyncing is not going to race with itself we no longer need the
dedicated ordered workqueue.
Remove it and switch to using regular (non-delayed) work structure
scheduled on the default workqueue.
Duoming Zhou [Wed, 17 Dec 2025 03:00:18 +0000 (11:00 +0800)]
Input: psmouse - replace flush_workqueue() with disable_delayed_work_sync()
The original code uses flush_workqueue() in psmouse_disconnect() to
ensure the completion of both resync_work and dev3_register_work.
Given that alps_disconnect() already uses disable_delayed_work_sync()
to cancel dev3_register_work, replacing flush_workqueue() with
disable_delayed_work_sync(&psmouse->resync_work) is more robust
and efficient.
Dmitry Torokhov [Wed, 11 Mar 2026 00:43:29 +0000 (17:43 -0700)]
Input: hgpk - remove protocol support
The protocol flavor for ALPS touchpads found in OLPC laptops has been
broken since 2015 commit c378b5119eb0 ("Input: psmouse - factor out
common protocol probing code") that forgot to add hgpk_init() to HGPK
entry in psmouse_protocols array.
Since nobody complained for 10 years let's remove it.
Merge cpupower utility updates, including a fix and improvements of the
existing functionality, for 7.0-rc4.
* pm-tools:
cpupower: Add intel_pstate turbo boost support for Intel platforms
cpupower: Add support for setting EPP via systemd service
cpupower: fix swapped power/energy unit labels
Linus Torvalds [Thu, 12 Mar 2026 17:58:02 +0000 (10:58 -0700)]
Merge tag 'apparmor-pr-mainline-2026-03-09' of git://git.kernel.org/pub/scm/linux/kernel/git/jj/linux-apparmor
Pull AppArmor fixes from John Johansen:
- fix race between freeing data and fs accessing it
- fix race on unreferenced rawdata dereference
- fix differential encoding verification
- fix unconfined unprivileged local user can do privileged policy management
- Fix double free of ns_name in aa_replace_profiles()
- fix missing bounds check on DEFAULT table in verify_dfa()
- fix side-effect bug in match_char() macro usage
- fix: limit the number of levels of policy namespaces
- replace recursive profile removal with iterative approach
- fix memory leak in verify_header
- validate DFA start states are in bounds in unpack_pdb
* tag 'apparmor-pr-mainline-2026-03-09' of git://git.kernel.org/pub/scm/linux/kernel/git/jj/linux-apparmor:
apparmor: fix race between freeing data and fs accessing it
apparmor: fix race on rawdata dereference
apparmor: fix differential encoding verification
apparmor: fix unprivileged local user can do privileged policy management
apparmor: Fix double free of ns_name in aa_replace_profiles()
apparmor: fix missing bounds check on DEFAULT table in verify_dfa()
apparmor: fix side-effect bug in match_char() macro usage
apparmor: fix: limit the number of levels of policy namespaces
apparmor: replace recursive profile removal with iterative approach
apparmor: fix memory leak in verify_header
apparmor: validate DFA start states are in bounds in unpack_pdb
KVM: x86: Advertise AVX512 Bit Matrix Multiply (BMM) to userspace
Advertise AVX512 Bit Matrix Multiply (BMM) and Bit Reversal instructions to
userspace via CPUID leaf 0x80000021_EAX[23]. This feature enables bit
matrix multiply operations and bit reversal. Like most AVX instructions,
there are no intercept controls for individual instructions, and no extra
work is needed in KVM to enable correct execution of the instructions in
the guest.
The instructions and CPUID feature are first described in:
AMD64 Bit Matrix Multiply and Bit Reversal Instructions
Publication #69192 Revision: 1.00
Issue Date: January 2026
While at it, reorder PREFETCHI in KVM's initialization sequence to match
the CPUID bit position order for better organization.
KVM: x86: Immediately fail the build when possible if required #define is missing
Guard usage of the must-be-defined macros in KVM's multi-include headers
with the existing #ifdefs that attempt to alert the developer to a missing
macro, and spit out an explicit #error message if a macro is missing, as
referencing the missing macro completely defeats the purpose of the #ifdef
(the compiler spews a ton of error messages and buries the targeted error
message).
David Woodhouse [Thu, 5 Mar 2026 19:49:55 +0000 (20:49 +0100)]
KVM: x86: Use __DECLARE_FLEX_ARRAY() for UAPI structures with VLAs
Commit 94dfc73e7cf4 ("treewide: uapi: Replace zero-length arrays with
flexible-array members") broke the userspace API for C++.
These structures ending in VLAs are typically a *header*, which can be
followed by an arbitrary number of entries. Userspace typically creates
a larger structure with some non-zero number of entries, for example in
QEMU's kvm_arch_get_supported_msr_feature():
Lai Jiangshan [Fri, 23 Jan 2026 09:03:03 +0000 (17:03 +0800)]
KVM: x86/mmu: KVM: x86/mmu: Skip unsync when large pages are allowed
Use the large-page metadata to avoid pointless attempts to search SP.
If the target GFN falls within a range where a large page is allowed,
then there cannot be a shadow page for that GFN; a shadow page in the
range would itself disallow using a large page. In that case, there
is nothing to unsync and mmu_try_to_unsync_pages() can return
immediately.
This is always true for TDP MMU without nested TDP, and holds for a
significant fraction of cases with shadow paging even all SPs are 4K.
For shadow paging, this optimization theoretically avoids work for about
1/e ~= 37% of GFNs, assuming one guest page table per 2M of memory and
that each GPT falls randomly into the 2M memory buckets. In a simple
test setup, it skipped unsync in a much higher percentage of cases,
mainly because the guest buddy allocator clusters GPTs into fewer
buckets.
Svyatoslav Ryhel [Thu, 12 Mar 2026 08:52:58 +0000 (10:52 +0200)]
rtc: max77686: convert to i2c_new_ancillary_device
Convert RTC I2C device creation from devm_i2c_new_dummy_device() to
i2c_new_ancillary_device() to enable the use of a device tree-specified
RTC address instead of a hardcoded value. If the device tree does not
provide an address, use hardcoded values as a fallback.
This addresses an issue with the MAX77663 PMIC, which can have the RTC at
different I2C positions (either 0x48, like the MAX77714, or 0x68, like
the MAX77620). The MAX77620 value is used as the default. The I2C position
of the MAX77663 is factory-set and cannot be detected from the chip
itself.
The config.regmap is already correctly initialized using dev_get_regmap()
on the parent device. Remove the redundant second assignment that was
overwriting it with pf1550->regmap.
KVM: selftests: Verify SEV+ guests can read and write EFER, CR0, CR4, and CR8
Add "do no harm" testing of EFER, CR0, CR4, and CR8 for SEV+ guests to
verify that the guest can read and write the registers, without hitting
e.g. a #VC on SEV-ES guests due to KVM incorrectly trying to intercept a
register.
Signed-off-by: Sean Christopherson <seanjc@google.com>
Message-ID: <20260310211841.2552361-3-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
KVM: X86: Fix array_index_nospec protection in __pv_send_ipi
The __pv_send_ipi() function iterates over up to BITS_PER_LONG vCPUs
starting from the APIC ID specified in its 'min' argument, which is
provided by the guest.
Commit c87bd4dd43a6 used array_index_nospec() to clamp the value of 'min'
but then the for_each_set_bit() loop dereferences higher indices without
further protection. Theoretically, a guest can trigger speculative access
to up to BITS_PER_LONG elements off the end of the phys_map[] array.
(In practice it would probably need aggressive loop unrolling by the
compiler to go more than one element off the end, and even that seems
unlikely, but the theoretical possibility exists.)
Move the array_index_nospec() inside the loop to protect the [map + i]
index which is actually being used each time.
Fixes: c87bd4dd43a6 ("KVM: x86: use array_index_nospec with indices that come from guest") Fixes: bdf7ffc89922 ("KVM: LAPIC: Fix pv ipis out-of-bounds access") Fixes: 4180bf1b655a ("KVM: X86: Implement "send IPI" hypercall") Signed-off-by: Anel Orazgaliyeva <anelkz@amazon.de> Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Reviewed-by: Jim Mattson <jmattson@google.com> Link: https://patch.msgid.link/9d50fc3ca9e8e58f551d015f95d51a3c29ce6ccc.camel@infradead.org Signed-off-by: Sean Christopherson <seanjc@google.com>
xuanqingshi [Fri, 6 Mar 2026 09:12:32 +0000 (17:12 +0800)]
KVM: x86: Add LAPIC guard in kvm_apic_write_nodecode()
kvm_apic_write_nodecode() dereferences vcpu->arch.apic without first
checking whether the in-kernel LAPIC has been initialized. If it has
not (e.g. the vCPU was created without an in-kernel LAPIC), the
dereference results in a NULL pointer access.
While APIC-write VM-Exits are not expected to occur on a vCPU without
an in-kernel LAPIC, kvm_apic_write_nodecode() should be robust against
such a scenario as a defense-in-depth measure, e.g. to guard against
KVM bugs or CPU errata that could generate a spurious APIC-write
VM-Exit.
Use KVM_BUG_ON() with lapic_in_kernel() instead of a simple
WARN_ON_ONCE(), as suggested by Sean Christopherson, so that KVM
kills the VM outright rather than letting it continue in a broken
state.
Found by a VMCS-targeted fuzzer based on syzkaller.
Yosry Ahmed [Sat, 7 Mar 2026 01:16:18 +0000 (01:16 +0000)]
KVM: x86: Use kvm_cpu_cap_has() for EFER bits enablement checks
Instead of checking that the hardware supports underlying features for
EFER bits, check if KVM supports them. It is practically the same, but
this removes a subtle dependency on kvm_set_cpu_caps() enabling the
relevant CPUID features.
Yosry Ahmed [Sat, 7 Mar 2026 01:16:17 +0000 (01:16 +0000)]
KVM: x86: Move some EFER bits enablement to common code
Move EFER bits enablement that only depend on CPU support to common
code, as there is no reason to do it in vendor code. Leave EFER.SVME and
EFER.LMSLE enablement in SVM code as they depend on vendor module
parameters.
Having the enablement in common code ensures that if a vendor starts
supporting an existing feature, KVM doesn't end up advertising to
userspace but not allowing the EFER bit to be set.
These happen with CONFIG_TRACE_BRANCH_PROFILING, CONFIG_KASAN_HW_TAGS,
CONFIG_STACKPROTECTOR, CONFIG_DEBUG_IRQFLAGS and indirectly from WARN_ON().
Add exceptions for each one that I have hit so far on arm64, x86_64 and arm
randconfig builds.
Other architectures likely hit additional ones, so it would be nice
to produce a little more verbose output that include the name of the
missing symbols directly.
Don't access of_root directly as it reduces the build test coverage for
this driver with COMPILE_TEST=y and OF=n. Use existing helper functions
to retrieve the relevant information.
Suggested-by: Rob Herring <robh@kernel.org> Reviewed-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Link: https://patch.msgid.link/20260223-soc-of-root-v2-7-b45da45903c8@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Don't access of_root directly as it reduces the build test coverage for
this driver with COMPILE_TEST=y and OF=n. Use existing helper functions
to retrieve the relevant information.
Suggested-by: Rob Herring <robh@kernel.org> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Reviewed-by: Peng Fan <peng.fan@nxp.com> Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Link: https://patch.msgid.link/20260223-soc-of-root-v2-6-b45da45903c8@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Don't access of_root directly as it reduces the build test coverage for
this driver with COMPILE_TEST=y and OF=n. Use existing helper functions
to retrieve the relevant information.
base: soc: rename and export soc_device_get_machine()
Some SoC drivers reimplement the functionality of
soc_device_get_machine(). Make this function accessible through the
sys_soc.h header and rename it to a more descriptive name.
dt-bindings: interrupt-controller: arm,gic-v3: Fix EPPI range
According to the "Arm Generic Interrupt Controller (GIC) Architecture
Specification, v3 and v4", revision H.b[1], there can be only 64
Extended PPI interrupts.
Jens Axboe [Thu, 12 Mar 2026 14:59:25 +0000 (08:59 -0600)]
io_uring/kbuf: check if target buffer list is still legacy on recycle
There's a gap between when the buffer was grabbed and when it
potentially gets recycled, where if the list is empty, someone could've
upgraded it to a ring provided type. This can happen if the request
is forced via io-wq. The legacy recycling is missing checking if the
buffer_list still exists, and if it's of the correct type. Add those
checks.
Cc: stable@vger.kernel.org Fixes: c7fb19428d67 ("io_uring: add support for ring mapped supplied buffers") Reported-by: Keenan Dong <keenanat2000@gmail.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
T.J. Mercier [Wed, 25 Feb 2026 22:34:03 +0000 (14:34 -0800)]
kernfs: Send IN_DELETE_SELF and IN_IGNORED
Currently some kernfs files (e.g. cgroup.events, memory.events) support
inotify watches for IN_MODIFY, but unlike with regular filesystems, they
do not receive IN_DELETE_SELF or IN_IGNORED events when they are
removed. This means inotify watches persist after file deletion until
the process exits and the inotify file descriptor is cleaned up, or
until inotify_rm_watch is called manually.
This creates a problem for processes monitoring cgroups. For example, a
service monitoring memory.events for memory.high breaches needs to know
when a cgroup is removed to clean up its state. Where it's known that a
cgroup is removed when all processes die, without IN_DELETE_SELF the
service must resort to inefficient workarounds such as:
1) Periodically scanning procfs to detect process death (wastes CPU
and is susceptible to PID reuse).
2) Holding a pidfd for every monitored cgroup (can exhaust file
descriptors).
This patch enables IN_DELETE_SELF and IN_IGNORED events for kernfs files
and directories by clearing inode i_nlink values during removal. This
allows VFS to make the necessary fsnotify calls so that userspace
receives the inotify events.
As a result, applications can rely on a single existing watch on a file
of interest (e.g. memory.events) to receive notifications for both
modifications and the eventual removal of the file, as well as automatic
watch descriptor cleanup, simplifying userspace logic and improving
efficiency.
There is gap in this implementation for certain file removals due their
unique nature in kernfs. Directory removals that trigger file removals
occur through vfs_rmdir, which shrinks the dcache and emits fsnotify
events after the rmdir operation; there is no issue here. However kernfs
writes to particular files (e.g. cgroup.subtree_control) can also cause
file removal, but vfs_write does not attempt to emit fsnotify events
after the write operation, even if i_nlink counts are 0. As a usecase
for monitoring this category of file removals is not known, they are
left without having IN_DELETE or IN_DELETE_SELF events generated.
Fanotify recursive monitoring also does not work for kernfs nodes that
do not have inodes attached, as they are created on-demand in kernfs.
Suggested-by: Jan Kara <jack@suse.cz> Signed-off-by: T.J. Mercier <tjmercier@google.com> Tested-by: syzbot@syzkaller.appspotmail.com Acked-by: Tejun Heo <tj@kernel.org> Link: https://patch.msgid.link/20260225223404.783173-3-tjmercier@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
T.J. Mercier [Wed, 25 Feb 2026 22:34:02 +0000 (14:34 -0800)]
kernfs: Don't set_nlink for directories being removed
If a directory is already in the process of removal its i_nlink count
becomes irrelevant because its contents are also about to be removed and
any pending filesystem operations on it or its contents will soon start
to fail. So we can avoid setting it for directories already flagged for
removal.
This avoids a race in the next patch, which adds clearing of the i_nlink
count for kernfs nodes being removed to support inotify delete events.
Use protection from the kernfs_iattr_rwsem to avoid adding more
contention to the kernfs_rwsem for calls to kernfs_refresh_inode.
Dan Williams [Tue, 3 Mar 2026 00:01:50 +0000 (16:01 -0800)]
device core: Fix kernel-doc warnings in base.h
In preparation for adding new fields to 'struct device_private' fix up
existing kernel-doc warnings in this header file of the form:
Warning: drivers/base/base.h:59 struct member 'subsys' not described in
'subsys_private'
Warning: drivers/base/base.h:59 struct member 'devices_kset' not described
in 'subsys_private'
Warning: drivers/base/base.h:59 struct member 'interfaces' not described in
'subsys_private'
Warning: drivers/base/base.h:59 struct member 'mutex' not described in
'subsys_private'
...which are simple replacements of " - " with ": ".
Add new descriptions for these previously undescribed fields:
Warning: drivers/base/base.h:58 struct member 'drivers_autoprobe' not
described in 'subsys_private'
Warning: drivers/base/base.h:117 struct member 'deferred_probe_reason' not
described in 'device_private'
Ilpo Järvinen [Tue, 3 Feb 2026 17:10:49 +0000 (19:10 +0200)]
serial: 8250_dw: Ensure BUSY is deasserted
DW UART cannot write to LCR, DLL, and DLH while BUSY is asserted.
Existance of BUSY depends on uart_16550_compatible, if UART HW is
configured with it those registers can always be written.
There currently is dw8250_force_idle() which attempts to achieve
non-BUSY state by disabling FIFO, however, the solution is unreliable
when Rx keeps getting more and more characters.
Create a sequence of operations that ensures UART cannot keep BUSY
asserted indefinitely. The new sequence relies on enabling loopback mode
temporarily to prevent incoming Rx characters keeping UART BUSY.
Ensure no Tx in ongoing while the UART is switches into the loopback
mode (requires exporting serial8250_fifo_wait_for_lsr_thre() and adding
DMA Tx pause/resume functions).
According to tests performed by Adriana Nicolae <adriana@arista.com>,
simply disabling FIFO or clearing FIFOs only once does not always
ensure BUSY is deasserted but up to two tries may be needed. This could
be related to ongoing Rx of a character (a guess, not known for sure).
Therefore, retry FIFO clearing a few times (retry limit 4 is arbitrary
number but using, e.g., p->fifosize seems overly large). Tests
performed by others did not exhibit similar challenge but it does not
seem harmful to leave the FIFO clearing loop in place for all DW UARTs
with BUSY functionality.
Use the new dw8250_idle_enter/exit() to do divisor writes and LCR
writes. In case of plain LCR writes, opportunistically try to update
LCR first and only invoke dw8250_idle_enter() if the write did not
succeed (it has been observed that in practice most LCR writes do
succeed without complications).
This issue was first reported by qianfan Zhao who put lots of debugging
effort into understanding the solution space.
Ilpo Järvinen [Tue, 3 Feb 2026 17:10:48 +0000 (19:10 +0200)]
serial: 8250: Add late synchronize_irq() to shutdown to handle DW UART BUSY
When DW UART is !uart_16550_compatible, it can indicate BUSY at any
point (when under constant Rx pressure) unless a complex sequence of
steps is performed. Any LCR write can run a foul with the condition
that prevents writing LCR while the UART is BUSY, which triggers
BUSY_DETECT interrupt that seems unmaskable using IER bits.
Normal flow is that dw8250_handle_irq() handles BUSY_DETECT condition
by reading USR register. This BUSY feature, however, breaks the
assumptions made in serial8250_do_shutdown(), which runs
synchronize_irq() after clearing IER and assumes no interrupts can
occur after that point but then proceeds to update LCR, which on DW
UART can trigger an interrupt.
If serial8250_do_shutdown() releases the interrupt handler before the
handler has run and processed the BUSY_DETECT condition by read the USR
register, the IRQ is not deasserted resulting in interrupt storm that
triggers "irq x: nobody cared" warning leading to disabling the IRQ.
Add late synchronize_irq() into serial8250_do_shutdown() to ensure
BUSY_DETECT from DW UART is handled before port's interrupt handler is
released. Alternative would be to add DW UART specific shutdown
function but it would mostly duplicate the generic code and the extra
synchronize_irq() seems pretty harmless in serial8250_do_shutdown().
Ilpo Järvinen [Tue, 3 Feb 2026 17:10:47 +0000 (19:10 +0200)]
serial: 8250_dw: Rework IIR_NO_INT handling to stop interrupt storm
INTC10EE UART can end up into an interrupt storm where it reports
IIR_NO_INT (0x1). If the storm happens during active UART operation, it
is promptly stopped by IIR value change due to Rx or Tx events.
However, when there is no activity, either due to idle serial line or
due to specific circumstances such as during shutdown that writes
IER=0, there is nothing to stop the storm.
During shutdown the storm is particularly problematic because
serial8250_do_shutdown() calls synchronize_irq() that will hang in
waiting for the storm to finish which never happens.
This problem can also result in triggering a warning:
irq 45: nobody cared (try booting with the "irqpoll" option)
[...snip...]
handlers:
serial8250_interrupt
Disabling IRQ #45
Normal means to reset interrupt status by reading LSR, MSR, USR, or RX
register do not result in the UART deasserting the IRQ.
Add a quirk to INTC10EE UARTs to enable Tx interrupts if UART's Tx is
currently empty and inactive. Rework IIR_NO_INT to keep track of the
number of consecutive IIR_NO_INT, and on fourth one perform the quirk.
Enabling Tx interrupts should change IIR value from IIR_NO_INT to
IIR_THRI which has been observed to stop the storm.
Fixes: e92fad024929 ("serial: 8250_dw: Add ACPI ID for Granite Rapids-D UART") Cc: stable <stable@kernel.org> Reported-by: Bandal, Shankar <shankar.bandal@intel.com> Tested-by: Bandal, Shankar <shankar.bandal@intel.com> Tested-by: Murthy, Shanth <shanth.murthy@intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://patch.msgid.link/20260203171049.4353-6-ilpo.jarvinen@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ilpo Järvinen [Tue, 3 Feb 2026 17:10:46 +0000 (19:10 +0200)]
serial: 8250_dw: Rework dw8250_handle_irq() locking and IIR handling
dw8250_handle_irq() takes port's lock multiple times with no good
reason to release it in between and calls serial8250_handle_irq()
that also takes port's lock.
Take port's lock only once in dw8250_handle_irq() and use
serial8250_handle_irq_locked() to avoid releasing port's lock in
between.
As IIR_NO_INT check in serial8250_handle_irq() was outside of port's
lock, it has to be done already in dw8250_handle_irq().
DW UART can, in addition to IIR_NO_INT, report BUSY_DETECT (0x7) which
collided with the IIR_NO_INT (0x1) check in serial8250_handle_irq()
(because & is used instead of ==) meaning that no other work is done by
serial8250_handle_irq() during an BUSY_DETECT interrupt.
This allows reorganizing code in dw8250_handle_irq() to do both
IIR_NO_INT and BUSY_DETECT handling right at the start simplifying
the logic.
Ilpo Järvinen [Tue, 3 Feb 2026 17:10:45 +0000 (19:10 +0200)]
serial: 8250: Add serial8250_handle_irq_locked()
8250_port exports serial8250_handle_irq() to HW specific 8250 drivers.
It takes port's lock within but a HW specific 8250 driver may want to
take port's lock itself, do something, and then call the generic
handler in 8250_port but to do that, the caller has to release port's
lock for no good reason.
Introduce serial8250_handle_irq_locked() which a HW specific driver can
call while already holding port's lock.
As this is new export, put it straight into a namespace (where all 8250
exports should eventually be moved).
Ilpo Järvinen [Tue, 3 Feb 2026 17:10:44 +0000 (19:10 +0200)]
serial: 8250_dw: Avoid unnecessary LCR writes
When DW UART is configured with BUSY flag, LCR writes may not always
succeed which can make any LCR write complex and very expensive.
Performing write directly can trigger IRQ and the driver has to perform
complex and distruptive sequence while retrying the write.
Therefore, it's better to avoid doing LCR write that would not change
the value of the LCR register. Add LCR write avoidance code into the
8250_dw driver's .serial_out() functions.
Ilpo Järvinen [Tue, 3 Feb 2026 17:10:43 +0000 (19:10 +0200)]
serial: 8250: Protect LCR write in shutdown
The 8250_dw driver needs to potentially perform very complex operations
during LCR writes because its BUSY handling prevents updates to LCR
while UART is BUSY (which is not fully under our control without those
complex operations). Thus, LCR writes should occur under port's lock.
Move LCR write under port's lock in serial8250_do_shutdown(). Also
split the LCR RMW so that the logic is on a separate line for clarity.
Conor Dooley [Tue, 3 Mar 2026 16:36:33 +0000 (16:36 +0000)]
dt-bindings: rtc: mpfs-rtc: permit resets
The RTC on mpfs and pic64gx has a reset pin, but until now this has been
undocumented because platform firmware takes the RTC out of reset on
first-party boards (or those using modified versions of the vendor
firmware), but not all boards may take this approach. Permit providing a
reset in devicetree for Linux, or other devicetree-consuming software,
to use.
This is found in popular brands such as StarTech.com or Delock, and has
been a source of frustration to quite a few people, if I can trust
Amazon comments complaining about Linux support via the official
out-of-the-tree driver.
Jiayuan Chen [Wed, 4 Feb 2026 07:43:20 +0000 (15:43 +0800)]
serial: core: fix infinite loop in handle_tx() for PORT_UNKNOWN
uart_write_room() and uart_write() behave inconsistently when
xmit_buf is NULL (which happens for PORT_UNKNOWN ports that were
never properly initialized):
- uart_write_room() returns kfifo_avail() which can be > 0
- uart_write() checks xmit_buf and returns 0 if NULL
This inconsistency causes an infinite loop in drivers that rely on
tty_write_room() to determine if they can write:
while (tty_write_room(tty) > 0) {
written = tty->ops->write(...);
// written is always 0, loop never exits
}
For example, caif_serial's handle_tx() enters an infinite loop when
used with PORT_UNKNOWN serial ports, causing system hangs.
Fix by making uart_write_room() also check xmit_buf and return 0 if
it's NULL, consistent with uart_write().
serial: uartlite: fix PM runtime usage count underflow on probe
ulite_probe() calls pm_runtime_put_autosuspend() at the end of probe
without holding a corresponding PM runtime reference for non-console
ports.
During ulite_assign(), uart_add_one_port() triggers uart_configure_port()
which calls ulite_pm() via uart_change_pm(). For non-console ports, the
UART core performs a balanced get/put cycle:
This leaves no spare reference for the pm_runtime_put_autosuspend() at
the end of probe. The PM runtime core prevents the count from actually
going below zero, and instead triggers a
"Runtime PM usage count underflow!" warning.
For console ports the bug is masked: the UART core skips the
uart_change_pm(OFF) call, so the UART core's unbalanced get happens to
pair with probe's trailing put.
Add pm_runtime_get_noresume() before pm_runtime_enable() to take an
explicit probe-owned reference that the trailing
pm_runtime_put_autosuspend() can release. This ensures a correct usage
count regardless of whether the port is a console.
Peng Zhang [Tue, 24 Feb 2026 12:16:39 +0000 (13:16 +0100)]
serial: 8250: always disable IRQ during THRE test
commit 039d4926379b ("serial: 8250: Toggle IER bits on only after irq
has been set up") moved IRQ setup before the THRE test, in combination
with commit 205d300aea75 ("serial: 8250: change lock order in
serial8250_do_startup()") the interrupt handler can run during the
test and race with its IIR reads. This can produce wrong THRE test
results and cause spurious registration of the
serial8250_backup_timeout timer. Unconditionally disable the IRQ for
the short duration of the test and re-enable it afterwards to avoid
the race.
Fixes: 039d4926379b ("serial: 8250: Toggle IER bits on only after irq has been set up")
Depends-on: 205d300aea75 ("serial: 8250: change lock order in serial8250_do_startup()") Cc: stable <stable@kernel.org> Signed-off-by: Peng Zhang <zhangpeng.00@bytedance.com> Reviewed-by: Muchun Song <songmuchun@bytedance.com> Signed-off-by: Alban Bedel <alban.bedel@lht.dlh.de> Tested-by: Maximilian Lueer <maximilian.lueer@lht.dlh.de> Link: https://patch.msgid.link/20260224121639.579404-1-alban.bedel@lht.dlh.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Raul E Rangel [Mon, 9 Feb 2026 20:58:18 +0000 (13:58 -0700)]
serial: 8250: Fix TX deadlock when using DMA
`dmaengine_terminate_async` does not guarantee that the
`__dma_tx_complete` callback will run. The callback is currently the
only place where `dma->tx_running` gets cleared. If the transaction is
canceled and the callback never runs, then `dma->tx_running` will never
get cleared and we will never schedule new TX DMA transactions again.
This change makes it so we clear `dma->tx_running` after we terminate
the DMA transaction. This is "safe" because `serial8250_tx_dma_flush`
is holding the UART port lock. The first thing the callback does is also
grab the UART port lock, so access to `dma->tx_running` is serialized.
Xin Zhao [Fri, 13 Feb 2026 08:50:39 +0000 (16:50 +0800)]
tty: tty_port: add workqueue to flip TTY buffer
On the embedded platform, certain critical data, such as IMU data, is
transmitted through UART. The tty_flip_buffer_push() interface in the TTY
layer uses system_dfl_wq to handle the flipping of the TTY buffer.
Although the unbound workqueue can create new threads on demand and wake
up the kworker thread on an idle CPU, it may be preempted by real-time
tasks or other high-prio tasks.
flush_to_ldisc() needs to wake up the relevant data handle thread. When
executing __wake_up_common_lock(), it calls spin_lock_irqsave(), which
does not disable preemption but disables migration in RT-Linux. This
prevents the kworker thread from being migrated to other cores by CPU's
balancing logic, resulting in long delays. The call trace is as follows:
__wake_up_common_lock
__wake_up
ep_poll_callback
__wake_up_common
__wake_up_common_lock
__wake_up
n_tty_receive_buf_common
n_tty_receive_buf2
tty_ldisc_receive_buf
tty_port_default_receive_buf
flush_to_ldisc
In our system, the processing interval for each frame of IMU data
transmitted via UART can experience significant jitter due to this issue.
Instead of the expected 10 to 15 ms frame processing interval, we see
spikes up to 30 to 35 ms. Moreover, in just one or two hours, there can
be 2 to 3 occurrences of such high jitter, which is quite frequent. This
jitter exceeds the software's tolerable limit of 20 ms.
Introduce flip_wq in tty_port which can be set by tty_port_link_wq() or as
default linked to default workqueue allocated when tty_register_driver().
The default workqueue is allocated with flag WQ_SYSFS, so that cpumask and
nice can be set dynamically. The execution timing of tty_port_link_wq() is
not clearly restricted. The newly added function tty_port_link_driver_wq()
checks whether the flip_wq of the tty_port has already been assigned when
linking the default tty_driver's workqueue to the port. After the user has
set a custom workqueue for a certain tty_port using tty_port_link_wq(), the
system will only use this custom workqueue, even if tty_driver does not
have %TTY_DRIVER_NO_WORKQUEUE flag. When tty_port register device, flip_wq
link operation is done by tty_port_link_driver_wq(), but for in-memory
devices the link operation cannot cover all the cases. Although
tty_port_install() is dedicated for in-memory devices lik PTY to link port
allocated on demand, the logic of tty_port_install() is so simple that
people may not call it, vc_cons[0].d->port is one such case. We check the
buf.flip_wq when flip TTY buffer, if buf.flip_wq of TTY port is NULL, use
system_dfl_wq as a backup.
To avoid naming conflict of the default tty_driver's workqueue, using
'"%s-%s", driver->name, driver->driver_name' as the workqueue name. In
cases where driver_name is not specified and therefore is NULL, the
workqueue is not created. Drivers that do not define driver_name are
potentially in-memory devices like vty, which generally do not require
special workqueue settings. Even with the combination of name and
driver_name, the workqueue names can still be duplicated, as many tty
serial drivers use "ttyS" as dev_name and "serial" as driver_name. I
modified the conflicting driver_name of these drivers by appending a
suffix of _xx based on the corresponding .c file. If this modification is
not made, it could not only lead to duplicate workqueue names but also
result in duplicate entries for the /proc/tty/driver/<driver_name> nodes.
Introduce %TTY_DRIVER_NO_WORKQUEUE flag meaning not to create the
default single tty_driver workqueue. Two reasons why need to introduce the
%TTY_DRIVER_NO_WORKQUEUE flag:
1. If the WQ_SYSFS parameter is enabled, workqueue_sysfs_register() will
fail when trying to create a workqueue with the same name. The pty is an
example of this; if both CONFIG_LEGACY_PTYS and CONFIG_UNIX98_PTYS are
enabled, the call to tty_register_driver() in unix98_pty_init() will fail.
2. Different TTY ports may be used for different tasks, which may require
separate core binding control via workqueues. In this case, the workqueue
created by default in the TTY driver is unnecessary. Enabling this flag
prevents the creation of this redundant workqueue.
After applying this patch, we can set the related UART TTY flip buffer
workqueue by sysfs. We set the cpumask to CPU cores associated with the
IMU tasks, and set the nice to -20. Testing has shown significant
improvement in the previously described issue, with almost no stuttering
occurring anymore.
Ronan Pigott [Tue, 3 Mar 2026 01:02:22 +0000 (18:02 -0700)]
vt: support ITU-T T.416 color subparameters
The colon ("bit combination 03/10") is a valid character in parameter
substrings. ECMA-48 says:
Each parameter sub-string consists of one or more bit combinations
from 03/00 to 03/10; the bit combinations from 03/00 to 03/09
represent the digits ZERO to NINE; bit combination 03/10 may be used
as a separator in a parameter sub-string, for example, to separate
the fractional part of a decimal number from the integer part of
that number.
To my knowledge, the only codes where 03/10 is actually used as a
separator are the CSI-m SGR sequences. The colon separated format is
superior as an embedded string for software that doesn't wish to link
ncurses terminal database, because terminals that do not support the
requested SGR sequence can safely skip the sub-parameters rather than
misinterpret them as another sequence. Hence, some software have started
using this "modern" format [1]. We should support the colon separated
format as well.
Anup Kulkarni [Tue, 10 Mar 2026 10:41:55 +0000 (16:11 +0530)]
serial: qcom-geni: Fix RTS behavior with flow control
When userspace enables flow control (CRTSCTS), the driver
deasserts RTS even when the receive buffer has space. This prevents the
peer device from transmitting, causing communication to stall.
The root cause is that the driver unconditionally uses manual RTS control
regardless of flow control mode. When CRTSCTS is set, the hardware should
automatically manage RTS based on buffer status, but the driver overrides
this by setting manual control.
Fix this by introducing port->manual_flow flag. In set_termios(), disable
manual flow when CRTSCTS is set. In set_mctrl(), only assert
SE_UART_MANUAL_RFR when manual_flow is active. Verified by enabling and
disabling hardware flow control with stty.
Robin Gong [Thu, 12 Mar 2026 09:45:26 +0000 (17:45 +0800)]
tty: serial: imx: keep dma request disabled before dma transfer setup
Since sdma hardware configure postpone to transfer phase, have to
disable dma request before dma transfer setup because there is a
hardware limitation on sdma event enable(ENBLn) as below.
Refer SDMA 2.6.28 Channel Enable RAM (SDMAARMx_CHNENBLn) section:
"It is thus essential for the Arm platform to program them before any
DMA request is triggered to the SDMA, otherwise an unpredictable
combination of channels may be started."
Michael Walle [Wed, 25 Feb 2026 08:17:23 +0000 (09:17 +0100)]
tty: serial: 8250: Add SystemBase Multi I/O cards
Add support for the SystemBase Multi I/O serial cards, which are
"compatible" with a standard 16550A controllers, except that they need
to have their interrupts enabled in a proprietary way.
Tested with a Delock "Serial PCI Express x1 Card 8x Serial RS-232".
Brian Masney [Sun, 22 Feb 2026 23:29:08 +0000 (18:29 -0500)]
serial: pic32_uart: allow driver to be compiled on all architectures with COMPILE_TEST
This driver currently only supports builds against a PIC32 target, or
with COMPILE_TEST on MIPS. Now that commit 24cad1a22848 ("serial:
pic32_uart: update include to use pic32.h from platform_data") is
merged, it's possible to compile this driver on other architectures.
To avoid future breakage of this driver in the future, let's update the
Kconfig so that it can be built with COMPILE_TEST enabled on all
architectures.
Francesco Lavra [Tue, 3 Mar 2026 11:14:38 +0000 (12:14 +0100)]
serial: tegra: remove Kconfig dependency on APB DMA controller
This driver runs also on SoCs without a Tegra20 APB DMA controller (e.g.
Tegra234).
Remove the Kconfig dependency on TEGRA20_APB_DMA, and remove reference to
the APB DMA controller from the Kconfig help text.
Xianwei Zhao [Tue, 3 Mar 2026 10:05:24 +0000 (10:05 +0000)]
dt-bindings: serial: amlogic,meson-uart: Add compatible string for A9
Amlogic A9 SoCs uses the same UART controller as S4 SoCs.
There is no need for an extra compatible line in the driver,
but add A9 compatible line for documentation.
Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Xianwei Zhao <xianwei.zhao@amlogic.com> Link: https://patch.msgid.link/20260303-serial-binding-v1-1-c3df2a8f6fa3@amlogic.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Zhaoyang Yu [Sun, 1 Mar 2026 16:22:56 +0000 (16:22 +0000)]
serial: auart: check clk_enable() return in console write
Add a check for clk_enable() in auart_console_write(). If
clk_enable() fails, return immediately to avoid accessing
hardware registers while the clock is not enabled.
Andrew Davis [Thu, 5 Mar 2026 19:35:45 +0000 (13:35 -0600)]
rtc: rx8025: Remove use of i2c_match_id()
The function i2c_match_id() is used to fetch the matching ID from
the i2c_device_id table. This is often used to then retrieve the
matching driver_data. This can be done in one step with the helper
i2c_get_match_data().
This helper has a couple other benefits:
* It doesn't need the i2c_device_id passed in so we do not need
to have that forward declared, allowing us to remove those or
move the i2c_device_id table down to its more natural spot
with the other module info.
* It also checks for device match data, which allows for OF and
ACPI based probing. That means we do not have to manually check
those first and can remove those checks.
Andrew Davis [Thu, 5 Mar 2026 19:35:44 +0000 (13:35 -0600)]
rtc: rv8803: Remove use of i2c_match_id()
The function i2c_match_id() is used to fetch the matching ID from
the i2c_device_id table. This is often used to then retrieve the
matching driver_data. This can be done in one step with the helper
i2c_get_match_data().
This helper has a couple other benefits:
* It doesn't need the i2c_device_id passed in so we do not need
to have that forward declared, allowing us to remove those or
move the i2c_device_id table down to its more natural spot
with the other module info.
* It also checks for device match data, which allows for OF and
ACPI based probing. That means we do not have to manually check
those first and can remove those checks.
Andrew Davis [Thu, 5 Mar 2026 19:35:43 +0000 (13:35 -0600)]
rtc: rs5c372: Remove use of i2c_match_id()
The function i2c_match_id() is used to fetch the matching ID from
the i2c_device_id table. This is often used to then retrieve the
matching driver_data. This can be done in one step with the helper
i2c_get_match_data().
This helper has a couple other benefits:
* It doesn't need the i2c_device_id passed in so we do not need
to have that forward declared, allowing us to remove those or
move the i2c_device_id table down to its more natural spot
with the other module info.
* It also checks for device match data, which allows for OF and
ACPI based probing. That means we do not have to manually check
those first and can remove those checks.
Andrew Davis [Thu, 5 Mar 2026 19:35:42 +0000 (13:35 -0600)]
rtc: pcf2127: Remove use of i2c_match_id()
The function i2c_match_id() is used to fetch the matching ID from
the i2c_device_id table. This is often used to then retrieve the
matching driver_data. This can be done in one step with the helper
i2c_get_match_data().
This helper has a couple other benefits:
* It doesn't need the i2c_device_id passed in so we do not need
to have that forward declared, allowing us to remove those or
move the i2c_device_id table down to its more natural spot
with the other module info.
* It also checks for device match data, which allows for OF and
ACPI based probing. That means we do not have to manually check
those first and can remove those checks.
Andrew Davis [Thu, 5 Mar 2026 19:35:41 +0000 (13:35 -0600)]
rtc: m41t80: Remove use of i2c_match_id()
The function i2c_match_id() is used to fetch the matching ID from
the i2c_device_id table. This is often used to then retrieve the
matching driver_data. This can be done in one step with the helper
i2c_get_match_data().
This helper has a couple other benefits:
* It doesn't need the i2c_device_id passed in so we do not need
to have that forward declared, allowing us to remove those or
move the i2c_device_id table down to its more natural spot
with the other module info.
* It also checks for device match data, which allows for OF and
ACPI based probing. That means we do not have to manually check
those first and can remove those checks.
Andrew Davis [Thu, 5 Mar 2026 19:35:40 +0000 (13:35 -0600)]
rtc: abx80x: Remove use of i2c_match_id()
The function i2c_match_id() is used to fetch the matching ID from
the i2c_device_id table. This is often used to then retrieve the
matching driver_data. This can be done in one step with the helper
i2c_get_match_data().
This helper has a couple other benefits:
* It doesn't need the i2c_device_id passed in so we do not need
to have that forward declared, allowing us to remove those or
move the i2c_device_id table down to its more natural spot
with the other module info.
* It also checks for device match data, which allows for OF and
ACPI based probing. That means we do not have to manually check
those first and can remove those checks.
Miguel Ojeda [Thu, 12 Mar 2026 11:10:14 +0000 (12:10 +0100)]
rust: kbuild: allow `unused_features`
Starting with the upcoming Rust 1.96.0 (to be released 2026-05-28),
`rustc` introduces the new lint `unused_features` [1], which warns [2]:
warning: feature `used_with_arg` is declared but not used
--> <crate attribute>:1:93
|
1 | #![feature(asm_const,asm_goto,arbitrary_self_types,lint_reasons,offset_of_nested,raw_ref_op,used_with_arg)]
| ^^^^^^^^^^^^^
|
= note: `#[warn(unused_features)]` (part of `#[warn(unused)]`) on by default
The original goal of using `-Zcrate-attr` automatically was that there
is a consistent set of features enabled and managed globally for all
Rust kernel code (modulo exceptions like the `rust/` crated).
While we could require crates to enable features manually (even if we
still keep the `-Zallow-features=` list, i.e. removing the `-Zcrate-attr`
list), it is not really worth making all developers worry about it just
for a new lint.
The features are expected to eventually become stable anyway (most already
did), and thus having to remove features in every file that may use them
is not worth it either.
Thus just allow the new lint globally.
The lint actually existed for a long time, which is why `rustc` does
not complain about an unknown lint in the stable versions we support,
but it was "disabled" years ago [3], and now it was made to work again.
For extra context, the new implementation of the lint has already been
improved to avoid linting about features that became stable thanks to
Benno's report and the ensuing discussion [4] [5], but while that helps,
it is still the case that we may have features enabled that are not used
for one reason or another in a particular crate.
Mika Kuoppala [Wed, 4 Mar 2026 21:17:28 +0000 (23:17 +0200)]
drm/xe: Fix overflow in guc_ct_snapshot_capture
snapshot->ctb is u32*, so pointer arithmetic on it scales
the byte offset from xe_bo_size() by 4, overshooting the
intended start of the g2h portion and writing past the
allocated buffer.
Fix this by using void * to get the arithmetic right and
prevent future mishaps.
v2: s/u8/void for memcpy and iosys_map consistency (Matt)
Fixes: af3de6cf06f9 ("drm/xe: Split H2G and G2H into separate buffer objects") Cc: Matthew Brost <matthew.brost@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: intel-xe@lists.freedesktop.org Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260304211728.249104-1-mika.kuoppala@linux.intel.com
Nicolas Pitre [Tue, 3 Feb 2026 04:52:48 +0000 (23:52 -0500)]
vt: add fallback to plain map for modifier-aware key types
When a key is pressed with modifiers (Shift, Ctrl, Alt, etc.) and the
modifier-specific keymap has no binding (K_HOLE) or doesn't exist, fall
back to the plain keymap if the plain entry is a modifier-aware type
(KT_CUR or KT_CSI).
This allows arrow keys and CSI navigation keys to automatically handle
all modifier combinations with just a single plain map entry. The key
handlers (k_cur and k_csi) read the modifier state at runtime and encode
it into the output sequence.
For example, with just:
keycode 103 = Up
keycode 104 = Csi_Home
All these combinations now work automatically:
Up -> ESC [ A
Shift+Up -> ESC [ 1 ; 2 A
Ctrl+Up -> ESC [ 1 ; 5 A
Home -> ESC [ 1 ~
Shift+Home -> ESC [ 1 ; 2 ~
Ctrl+Home -> ESC [ 1 ; 5 ~
Previously, each modifier combination required an explicit keymap entry,
which was tedious and consumed keymap slots.
Explicit modifier bindings still take precedence - the fallback only
triggers when the modifier-specific entry is empty.
Nicolas Pitre [Tue, 3 Feb 2026 04:52:47 +0000 (23:52 -0500)]
vt: add KT_CSI keysym type for modifier-aware CSI sequences
Add a new keysym type KT_CSI that generates CSI tilde sequences with
automatic modifier encoding. The keysym value encodes the CSI parameter
number, producing sequences like ESC [ <value> ~ or ESC [ <value> ; <mod> ~
when Shift, Alt, or Ctrl modifiers are held.
This allows navigation keys (Home, End, Insert, Delete, PgUp, PgDn) and
function keys to generate modifier-aware escape sequences without
consuming string table entries for each modifier combination.
Define key symbols for navigation keys (K_CSI_HOME, K_CSI_END, etc.)
and function keys (K_CSI_F1 through K_CSI_F20) using standard xterm
CSI parameter values.
The modifier encoding follows the xterm convention:
mod = 1 + (shift ? 1 : 0) + (alt ? 2 : 0) + (ctrl ? 4 : 0)
Allowed CSI parameter values range from 0 to 99.
Note: The Linux console historically uses a non-standard double-bracket
format for F1-F5 (ESC [ [ A through ESC [ [ E) rather than the xterm
tilde format (ESC [ 11 ~ through ESC [ 15 ~). The K_CSI_F1 through
K_CSI_F5 definitions use the xterm format. Converting F1-F5 to KT_CSI
would require updating the "linux" terminfo entry to match. Navigation
keys and F6-F20 already use the tilde format and are fully compatible.
Nicolas Pitre [Tue, 3 Feb 2026 04:52:46 +0000 (23:52 -0500)]
vt: add modifier support to cursor keys
Generate xterm-style CSI sequences with modifier parameters for arrow
keys when Shift, Alt, or Ctrl are held. For example, Shift+Up produces
ESC [ 1 ; 2 A instead of plain ESC [ A.
The modifier encoding follows the standard xterm convention:
mod = 1 + (shift ? 1 : 0) + (alt ? 2 : 0) + (ctrl ? 4 : 0)
When no modifiers are pressed, the original behavior is preserved.
Explicit keymap bindings for modified cursor keys (e.g., "shift keycode
103 = Find") take precedence over this automatic modifier encoding.
Randy Dunlap [Wed, 11 Mar 2026 05:23:47 +0000 (22:23 -0700)]
serdev: serdev.h: clean up kernel-doc comments
Correct kernel-doc comment format and add a missing to avoid
kernel-doc warnings:
Warning: include/linux/serdev.h:49 struct member 'write_comp' not
described in 'serdev_device'
Warning: include/linux/serdev.h:49 struct member 'write_lock' not
described in 'serdev_device'
Warning: include/linux/serdev.h:68 struct member 'shutdown' not described
in 'serdev_device_driver'
Warning: include/linux/serdev.h:134 function parameter 'serdev' not
described in 'serdev_device_put'
Warning: include/linux/serdev.h:162 function parameter 'ctrl' not
described in 'serdev_controller_put'
Julian Braha [Mon, 9 Mar 2026 12:23:21 +0000 (12:23 +0000)]
serial: remove drivers for espressif esp32
These drivers were added about 3 years ago, and depend on the
XTENSA_PLATFORM_ESP32 config option which has never existed,
so no device can actually use them.
They can only be compiled with COMPILE_TEST.
In a previous conversation [1], Greg suggested removing the
drivers, and Max, the original submitter of the drivers, agreed
due to a lack of foreseeable development.
Some DMA controllers require transfer lengths to be aligned to a
specific boundary. For example, the Tegra GPC DMA requires 4-byte
(word) aligned transfers and will reject unaligned lengths.
Align the TX DMA buffer length down to the DMA controller's copy_align
boundary before submitting the transfer. Any remaining unaligned bytes
will be transmitted via PIO on subsequent calls, which is the existing
fallback behavior when DMA is not used.
Kartik Rajput [Wed, 25 Feb 2026 06:59:13 +0000 (12:29 +0530)]
serial: amba-pl011: Add Tegra264 UART support
Add support for the NVIDIA Tegra264 UART controller, which is derived
from the AMBA PL011 design.
On Tegra264, the fractional baud rate divisor (FBRD) register is broken.
Using IBRD alone may not achieve the required baud rate
tolerance. Enable the skip_ibrd_fbrd and set_uartclk_rate flags for
the NVIDIA variant.
Kartik Rajput [Wed, 25 Feb 2026 06:59:12 +0000 (12:29 +0530)]
serial: amba-pl011: Introduce set_uartclk_rate vendor flag
The NVIDIA Tegra264 UART relies on configuring the UART clock rate
directly to program the desired baud rate.
Introduce the set_uartclk_rate vendor flag. When set, the driver
uses clk_set_rate() to program the UART clock to the desired baud
rate and clk_round_rate() to determine the maximum supported baud
rate.
Kartik Rajput [Wed, 25 Feb 2026 06:59:11 +0000 (12:29 +0530)]
serial: amba-pl011: Introduce skip_ibrd_fbrd vendor flag
The NVIDIA Tegra264 UART has a broken fractional baud rate
divisor register. Using IBRD and FBRD may cause the baud rate
to fall outside the required tolerance.
Introduce the skip_ibrd_fbrd vendor flag to skip IBRD/FBRD
programming. When set, the baud rate is derived directly from the
UART clock rate using a fixed divisor.
Peter Maydell [Tue, 10 Feb 2026 12:50:59 +0000 (12:50 +0000)]
serial: amba-pl011: Enable UART in earlycon setup
Currently the PL011 driver only enables the UART (by setting UARTEN
in REG_CR) in pl011_startup(), so if it is used for earlycon it is
relying on the bootrom/firmware having left the UART enabled.
There's no particular reason not to actively enable the UART before
using it for earlycon, and the earlycon handling for e.g. the 8250
UART sets up the UART in its setup function, so follow that in the
PL011.
This allows use of earlycon with a UART that the firmware hasn't
already been using for its own output, but the main motivation is
that QEMU will otherwise log a message complaining that the guest is
trying to write to a UART it never enabled.
Randy Dunlap [Fri, 30 Jan 2026 07:29:37 +0000 (23:29 -0800)]
tty: hvc_iucv: fix off-by-one in number of supported devices
MAX_HVC_IUCV_LINES == HVC_ALLOC_TTY_ADAPTERS == 8.
This is the number of entries in:
static struct hvc_iucv_private *hvc_iucv_table[MAX_HVC_IUCV_LINES];
Sometimes hvc_iucv_table[] is limited by:
(a) if (num > hvc_iucv_devices) // for error detection
or
(b) for (i = 0; i < hvc_iucv_devices; i++) // in 2 places
(so these 2 don't agree; second one appears to be correct to me.)
hvc_iucv_devices can be 0..8. This is a counter.
(c) if (hvc_iucv_devices > MAX_HVC_IUCV_LINES)
If hvc_iucv_devices == 8, (a) allows the code to access hvc_iucv_table[8].
Oops.
Andy Shevchenko [Wed, 28 Jan 2026 14:27:26 +0000 (15:27 +0100)]
serial: 8250_port: Drop duplicate NULL check
serial8250_release_dma() is NULL-aware, no need to check this in the caller.
While at it, make sure DMA won't be used again, by NULLifying the pointer.
Alyssa Milburn [Wed, 28 Jan 2026 11:28:54 +0000 (11:28 +0000)]
tty: serial: samsung_tty: avoid dev_dbg deadlock
commit a05025d0ce72 ("tty: serial: samsung_tty: use standard
debugging macros") changed the debug prints to dev_dbg, which can
result in deadlocks:
s3c24xx_serial_set_termios can be called with the port lock, and then
calls dev_dbg, which needs the console mutex. At the same time,
s3c24xx_serial_console_write can be called with the console lock
(e.g., inside console_unlock), and needs the port lock.
To avoid this, move one dev_dbg call and just delete the other.
Adam Ford [Tue, 10 Feb 2026 05:37:01 +0000 (23:37 -0600)]
pmdomain: mediatek: Fix power domain count
The wrong value of the number of domains is wrong which leads to
failures when trying to enumerate nested power domains.
PM: genpd_xlate_onecell: invalid domain index 0
PM: genpd_xlate_onecell: invalid domain index 1
PM: genpd_xlate_onecell: invalid domain index 3
PM: genpd_xlate_onecell: invalid domain index 4
PM: genpd_xlate_onecell: invalid domain index 5
PM: genpd_xlate_onecell: invalid domain index 13
PM: genpd_xlate_onecell: invalid domain index 14
Attempts to use these power domains fail, so fix this by
using the correct value of calculated power domains.
Signed-off-by: Adam Ford <aford173@gmail.com> Fixes: 88914db077b6 ("pmdomain: mediatek: Add support for Hardware Voter power domains") Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Linus Walleij [Wed, 18 Feb 2026 13:44:38 +0000 (14:44 +0100)]
HID: mcp2221: Add module parameter to enfoce GPIO mode
Add a module parameter to MCP2221 to enfor GPIO mode on the
general purpose pins GP0 thru GP3.
If I plug a device of this type into my machine, it will use the
GP0, GP1, GP2 and GP3 pins for IIO voltage readings by default
if CONFIG_IIO is set.
However there may be cases where IIO is available but we want to
use the GP0 thru GP3 lines for GPIO anyway.
Example use:
insmode hid-mcp2221.ko gpio_mode_enforce=1
Result in dmesg:
mcp2221 0003:04D8:00DD.0005: GPIO 0 not in gpio mode
mcp2221 0003:04D8:00DD.0005: GPIO 1 not in gpio mode
mcp2221 0003:04D8:00DD.0005: GPIO 2 not in gpio mode
mcp2221 0003:04D8:00DD.0005: GPIO 3 not in gpio mode
mcp2221 0003:04D8:00DD.0005: Set GPIO mode for gpio pin 0!
mcp2221 0003:04D8:00DD.0005: Set GPIO mode for gpio pin 1!
mcp2221 0003:04D8:00DD.0005: Set GPIO mode for gpio pin 2!
mcp2221 0003:04D8:00DD.0005: Set GPIO mode for gpio pin 3!
After this the gpiolib tools such as gpioset can be used to alter
the GPIO line values successfully.
Aditya Garg [Mon, 16 Feb 2026 21:24:46 +0000 (02:54 +0530)]
HID: appletb-kbd: add .resume method in PM
Upon resuming from suspend, the Touch Bar driver was missing a resume
method in order to restore the original mode the Touch Bar was on before
suspending. It is the same as the reset_resume method.
[jkosina@suse.com: rebased on top of the pm_ptr() conversion] Cc: stable@vger.kernel.org Signed-off-by: Aditya Garg <gargaditya08@live.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
Adrian Freund [Wed, 11 Mar 2026 19:19:33 +0000 (20:19 +0100)]
HID: logitech-hidpp: Enable MX Master 4 over bluetooth
The Logitech MX Master 4 can be connected over bluetooth or through a
Logitech Bolt receiver. This change adds support for non-standard HID
features, such as high resolution scrolling when the mouse is connected
over bluetooth.
Because no Logitech Bolt receiver driver exists yet those features
won't be available when the mouse is connected through the receiver.
Signed-off-by: Adrian Freund <adrian@freund.io> Signed-off-by: Jiri Kosina <jkosina@suse.com>
Merge patch series "move_mount: expand MOVE_MOUNT_BENEATH"
Christian Brauner <brauner@kernel.org> says:
I'm too tired now to keep refining this but I think it's in good enough
shape for review.
Allow MOVE_MOUNT_BENEATH to target the caller's rootfs, allowing to
switch out the rootfs without pivot_root(2).
The traditional approach to switching the rootfs involves pivot_root(2)
or a chroot_fs_refs()-based mechanism that atomically updates fs->root
for all tasks sharing the same fs_struct. This has consequences for
fork(), unshare(CLONE_FS), and setns().
This series instead decomposes root-switching into individually atomic,
locally-scoped steps:
Since each step only modifies the caller's own state, the
fork/unshare/setns races are eliminated by design.
A key step to making this possible is to remove the locked mount
restriction. Originally MOVE_MOUNT_BENEATH doesn't support mounting
beneath a mount that is locked. The locked mount protects the underlying
mount from being revealed. This is a core mechanism of
unshare(CLONE_NEWUSER | CLONE_NEWNS). The mounts in the new mount
namespace become locked. That effectively makes the new mount table
useless as the caller cannot ever get rid of any of the mounts no matter
how useless they are.
We can lift this restriction though. We simply transfer the locked
property from the top mount to the mount beneath. This works because
what we care about is to protect the underlying mount aka the parent.
The mount mounted between the parent and the top mount takes over the
job of protecting the parent mount from the top mount mount. This leaves
us free to remove the locked property from the top mount which can
consequently be unmounted:
unshare(CLONE_NEWUSER | CLONE_NEWNS)
and we inherit a clone of procfs on /proc then currently we cannot
unmount it as:
umount -l /proc
will fail with EINVAL because the procfs mount is locked.
After this series we can now do:
mount --beneath -t tmpfs tmpfs /proc
umount -l /proc
after which a tmpfs mount has been placed beneath the procfs mount. The
tmpfs mount has become locked and the procfs mount has become unlocked.
This means you can safely modify an inherited mount table after
unprivileged namespace creation.
Afterwards we simply make it possible to move a mount beneath the
rootfs allowing to upgrade the rootfs.
Removing the locked restriction makes this very useful for containers
created with unshare(CLONE_NEWUSER | CLONE_NEWNS) to reshuffle an
inherited mount table safely and MOVE_MOUNT_BENEATH makes it possible to
switch out the rootfs instead of using the costly pivot_root(2).
* patches from https://patch.msgid.link/20260224-work-mount-beneath-rootfs-v1-0-8c58bf08488f@kernel.org:
selftests/filesystems: add MOVE_MOUNT_BENEATH rootfs tests
move_mount: allow MOVE_MOUNT_BENEATH on the rootfs
move_mount: transfer MNT_LOCKED
Add tests for mounting beneath the rootfs using MOVE_MOUNT_BENEATH:
- beneath_rootfs_success: mount beneath /, fchdir, chroot, umount2
MNT_DETACH -- verify root changed
- beneath_rootfs_old_root_stacked: after mount-beneath, verify old root
parent is clone via statmount
- beneath_rootfs_in_chroot_fail: chroot into subdir of same mount,
mount-beneath fails (dentry != mnt_root)
- beneath_rootfs_in_chroot_success: chroot into separate tmpfs mount,
mount-beneath succeeds
- beneath_rootfs_locked_transfer: in user+mount ns: mount-beneath
rootfs succeeds, MNT_LOCKED transfers, old root unmountable
- beneath_rootfs_locked_containment: in user+mount ns: after full
root-switch workflow, new root is MNT_LOCKED (containment preserved)
- beneath_non_rootfs_locked_transfer: mounts created before
unshare(CLONE_NEWUSER | CLONE_NEWNS) become locked; mount-beneath
transfers MNT_LOCKED, displaced mount can be unmounted
- beneath_non_rootfs_locked_containment: same setup, verify new mount
is MNT_LOCKED (containment preserved)
move_mount: allow MOVE_MOUNT_BENEATH on the rootfs
Allow MOVE_MOUNT_BENEATH to target the caller's rootfs. When the target
of a mount-beneath operation is the caller's root mount, verify that:
(1) The caller is located at the root of the mount, as enforced by
path_mounted() in do_lock_mount().
(2) Propagation from the parent mount would not overmount the target,
to avoid propagating beneath the rootfs of other mount namespaces.
The root-switching is decomposed into individually atomic, locally-scoped
steps: mount-beneath inserts the new root under the old one, chroot(".")
switches the caller's root, and umount2(".", MNT_DETACH) removes the old
root. Since each step only modifies the caller's own state, this avoids
cross-namespace vulnerabilities and inherent fork/unshare/setns races
that a chroot_fs_refs()-based approach would have.
Userspace can use the following workflow to switch roots:
When performing a mount-beneath operation the target mount can often be
locked:
unshare(CLONE_NEWUSER | CLONE_NEWNS);
mount --beneath -t tmpfs tmpfs /proc
will fail because the procfs mount on /proc became locked when the mount
namespace was created from the parent mount namespace. Same logic for:
unshare(CLONE_NEWUSER | CLONE_NEWNS);
mount --beneath -t tmpfs tmpfs /
MNT_LOCKED is raised to prevent an unprivileged mount namespace from
revealing whatever is under a given mount. To replace the rootfs we need
to handle that case though.
We can simply transfer the locked mount property from the top mount to
the mount beneath. The new mount we mounted beneath the top mount takes
over the job of the top mount in protecting the parent mount from being
revealed. This leaves us free to allow the top mount to be unmounted.
This also works during mount propagation and also works for the
non-MOVE_MOUNT_BENEATH case:
For (1) can_move_mount_beneath() rejects overmounted @source_mnt (We
could allow this but whatever it's not really a use-case and it's fugly
to move an overmounted mount stack around. What are you even doing? So
let's keep that restriction.
For (2) we can have @source_mnt overmounted (Someone overmounted us
while we locked the target mount.). Both are fine. @source_mnt will be
mounted on whatever @q was mounted on and @q will be mounted on the top
of the @source_mnt mount stack. Even in such cases we can unlock @q and
lock @source_mnt if @q was locked.
This effectively makes mount propagation useful in cases where a mount
namespace has a locked mount somewhere and we propagate a new mount
beneath it but the mount namespace could never get at it because the old
top mount remains locked. Again, we just let the newly propagated mount
take over the protection and unlock the top mount.
Merge patch series "namespace: allow creating empty mount namespaces"
Christian Brauner <brauner@kernel.org> says:
Currently, creating a new mount namespace always copies the entire mount
tree from the caller's namespace. For containers and sandboxes that
intend to build their mount table from scratch this is wasteful: they
inherit a potentially large mount tree only to immediately tear it down.
This series adds support for creating a mount namespace that contains
only a clone of the root mount, with none of the child mounts. Two new
flags are introduced:
- CLONE_EMPTY_MNTNS (0x400000000) for clone3(), using the 64-bit flag
space.
- UNSHARE_EMPTY_MNTNS (0x00100000) for unshare(), reusing the
CLONE_PARENT_SETTID bit which has no meaning for unshare.
Both flags imply CLONE_NEWNS. The resulting namespace contains a single
nullfs root mount with an immutable empty directory. The intended
workflow is to then mount a real filesystem (e.g., tmpfs) over the root
and build the mount table from there.
* patches from https://patch.msgid.link/20260306-work-empty-mntns-consolidated-v1-0-6eb30529bbb0@kernel.org:
selftests/filesystems: add clone3 tests for empty mount namespaces
selftests/filesystems: add tests for empty mount namespaces
namespace: allow creating empty mount namespaces
selftests/filesystems: add clone3 tests for empty mount namespaces
Add a test suite for the CLONE_EMPTY_MNTNS flag exercising the empty
mount namespace functionality through the clone3() syscall.
The clone3() code path is distinct from the unshare() path already
tested in empty_mntns_test.c. With clone3(), CLONE_EMPTY_MNTNS
(0x400000000ULL) is a 64-bit flag that implies CLONE_NEWNS. The
implication happens in kernel_clone() before copy_process(), unlike
unshare() where it goes through UNSHARE_EMPTY_MNTNS to
CLONE_EMPTY_MNTNS conversion in unshare_nsproxy_namespaces().
The tests cover:
- basic functionality: clone3 child gets empty mount namespace with
exactly one mount, root and cwd point to the same mount
- CLONE_NEWNS implication: CLONE_EMPTY_MNTNS works without explicit
CLONE_NEWNS, also works with redundant CLONE_NEWNS
- flag interactions: combines correctly with CLONE_NEWUSER,
CLONE_NEWPID, CLONE_NEWUTS, CLONE_NEWIPC, CLONE_PIDFD
- mutual exclusion: CLONE_EMPTY_MNTNS | CLONE_FS returns EINVAL
because the implied CLONE_NEWNS conflicts with CLONE_FS
- error paths: EPERM without capabilities, unknown 64-bit flags
rejected
- parent isolation: parent mount namespace is unchanged after clone
- many parent mounts: child still gets exactly one mount
- mount properties: root mount is nullfs, is its own parent, is the
only listmount entry
- overmount workflow: child can mount tmpfs over nullfs root to build
a writable filesystem from scratch
- repeated clone3: each child gets a distinct mount namespace
- setns: parent can join child's empty mount namespace via setns()
- regression: plain CLONE_NEWNS via clone3 still copies the full
mount tree
selftests/filesystems: add tests for empty mount namespaces
Add a test suite for the UNSHARE_EMPTY_MNTNS and CLONE_EMPTY_MNTNS
flags exercising the empty mount namespace functionality through the
kselftest harness.
The tests cover:
- basic functionality: unshare succeeds, exactly one mount exists in
the new namespace, root and cwd point to the same mount
- flag interactions: UNSHARE_EMPTY_MNTNS works standalone without
explicit CLONE_NEWNS, combines correctly with CLONE_NEWUSER and
other namespace flags (CLONE_NEWUTS, CLONE_NEWIPC)
- edge cases: EPERM without capabilities, works from a user namespace,
many source mounts still result in one mount, cwd on a different
mount gets reset to root
- error paths: invalid flags return EINVAL
- regression: plain CLONE_NEWNS still copies the full mount tree,
other namespace unshares are unaffected
- mount properties: the root mount has the expected statmount
properties, is its own parent, and is the only entry returned by
listmount
- repeated unshare: consecutive UNSHARE_EMPTY_MNTNS calls each
produce a new namespace with a distinct mount ID
- overmount workflow: verifies the intended usage pattern of creating
an empty mount namespace with a nullfs root and then mounting tmpfs
over it to build a writable filesystem from scratch
Add support for creating a mount namespace that contains only a copy of
the root mount from the caller's mount namespace, with none of the
child mounts. This is useful for containers and sandboxes that want to
start with a minimal mount table and populate it from scratch rather
than inheriting and then tearing down the full mount tree.
Two new flags are introduced:
- CLONE_EMPTY_MNTNS for clone3(), using the 64-bit flag space.
- UNSHARE_EMPTY_MNTNS for unshare(), reusing the
CLONE_PARENT_SETTID bit which has no meaning for unshare.
Both flags imply CLONE_NEWNS. For the unshare path,
UNSHARE_EMPTY_MNTNS is converted to CLONE_EMPTY_MNTNS in
unshare_nsproxy_namespaces() before it reaches copy_mnt_ns(), so the
mount namespace code only needs to handle a single flag.
In copy_mnt_ns(), when CLONE_EMPTY_MNTNS is set, clone_mnt() is used
instead of copy_tree() to clone only the root mount. The caller's root
and working directory are both reset to the root dentry of the new
mount.
The cleanup variables are changed from vfsmount pointers with
__free(mntput) to struct path with __free(path_put) because the empty
mount namespace path needs to release both mount and dentry references
when replacing the caller's root and pwd. In the normal (non-empty)
path only the mount component is set, and dput(NULL) is a no-op so
path_put remains correct there as well.
projects / thirdparty / linux.git / log
