| Age | Commit message (Collapse) | Author |
|---|
|
dev_pm_opp_put_opp_table() frees the opp_table which is subsquently used
by dev_err_probe(). This causes an Oops during boot on gs101-oriole.
cpu cpu0: error 000000006b6b6b6b: Couldn't find clock
Unable to handle kernel paging request at virtual address 006b6b6b6b6b6cd3
...
Hardware name: Oriole (DT)
pstate: 00400005 (nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : _of_add_table_indexed+0x80/0xbb0
lr : _of_add_table_indexed+0x6c/0xbb0
...
Call trace:
_of_add_table_indexed+0x80/0xbb0 (P)
dev_pm_opp_of_cpumask_add_table+0x70/0x120
dt_cpufreq_probe+0x23c/0x480
platform_probe+0x64/0xb8
Fixes: 84f05af0975c9 ("opp: Use clk_get_optional() to avoid leaving opp_table->clk as an error pointer")
Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
Reviewed-by: Tudor Ambarus <tudor.ambarus@linaro.org>
[ Viresh: use return value of dev_err_probe() ]
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
|
|
In preparation to using this field as an upper limit to truncation,
return the size of the allocated region.
Fixes: ae98dbf43d75 ("io_uring/kbuf: add support for incremental buffer consumption")
Cc: stable@vger.kernel.org
Signed-off-by: Gabriel Krisman Bertazi <krisman@suse.de>
Link: https://patch.msgid.link/20260902230041.1320658-2-krisman@suse.de
Signed-off-by: Jens Axboe <axboe@kernel.dk>
|
|
Commit b000145e9907 moved both the fsnotify calls and the write
accounting out of the kiocb completion handler and into the
io_req_rw_complete() task_work. However, only the fsnotify part actually
needed to move as it may sleep. Ending the write accounting is just a
percpu_up_read() on the superblock writers sem.
Deferring it is a problem, because it makes dropping SB_FREEZE_WRITE
protection depend on the ring owner getting to running task_work. But
the task may be blocked in freeze_super(), causing it to never get to
that:
task io-wq worker
--------------------------------------------------------------
io_write()
io_kiocb_start_write() (takes sb_writers, hidden from
lockdep by __sb_writers_release)
write_iter() -> -EIOCBQUEUED
ioctl(FS_IOC_SHUTDOWN)
bdev_freeze()
freeze_super()
percpu_down_write() <- waits for the reader above
io_write()
kiocb_start_write()
percpu_down_read() <- queued
behind the
writer
<bio completes>
io_complete_rw()
queues io_req_rw_complete() <- never runs, task is in D state
End the write from io_complete_rw() instead, and leave only the fsnotify
calls in task_work.
Reported-by: syzbot+2eb3d983669d3e49d4fa@syzkaller.appspotmail.com
Cc: stable@vger.kernel.org
Fixes: b000145e9907 ("io_uring/rw: defer fsnotify calls to task context")
Signed-off-by: Jens Axboe <axboe@kernel.dk>
|
|
Commit 95308225e5ba ("dma-buf: Rename dma_buf_move_notify() to
dma_buf_invalidate_mappings()") left the DMABUF section of the P2PDMA
documentation pointing at move_notify(), a symbol that no longer exists.
Readers grepping for it find nothing, and this is the only place in
Documentation/ describing the revocation requirement.
Name the current function and record that importers which cannot unmap
within bounded time have to be rejected at attach time, which is what makes
the synchronous unmap on remove() achievable.
Fixes: 95308225e5ba ("dma-buf: Rename dma_buf_move_notify() to dma_buf_invalidate_mappings()")
Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Logan Gunthorpe <logang@deltatee.com>
Link: https://patch.msgid.link/20260830-doc-p2p-move-v1-1-61a388620588@nvidia.com
|
|
Nicolai Buchwitz says:
====================
net: macb: fix two probe path leaks
Two independent leaks on macb probe paths, both noticed while reviewing
the fixed-link unbind crash fix [1].
Patch 1 destroys the phylink instance when probe fails after
macb_mii_init() has succeeded. Patch 2 drops the "mdio" child node
reference on the success path of macb_mii_init().
[1] https://lore.kernel.org/netdev/20260902102836.2019355-1-vineeth.karumanchi@amd.com/
====================
Link: https://patch.msgid.link/20260907210856.1673589-1-nb@tipi-net.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
macb_mii_init() holds the reference returned by of_get_child_by_name()
for macb_mdiobus_register() and drops it only on the error paths, so
every successful probe leaks a node reference. On a CM5, overlay
removal after four bind cycles reports
OF: ERROR: memory leak, expected refcount 1 instead of 5
Drop the reference after registration, where __mdiobus_register() has
already taken its own for the lifetime of the bus.
Fixes: 8a6631f1cece ("net: macb: avoid redundant lookup for "mdio" child node in MDIO setup")
Signed-off-by: Nicolai Buchwitz <nb@tipi-net.de>
Link: https://patch.msgid.link/20260907210856.1673589-3-nb@tipi-net.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
macb_mii_init() creates a phylink instance on both of its success paths,
but the probe unwind frees the netdev without destroying it, so a failing
macb_alloc_tieoff() or register_netdev() leaks the instance.
Destroy it at err_out_unregister_mdio, which is only reachable once
macb_mii_init() has succeeded, so bp->phylink is valid there.
Fixes: 7897b071ac3b ("net: macb: convert to phylink")
Signed-off-by: Nicolai Buchwitz <nb@tipi-net.de>
Link: https://patch.msgid.link/20260907210856.1673589-2-nb@tipi-net.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
CFM and MRP register a global br_frame_type whose hlist_node is linked
into the per-bridge frame_type_list when the first MEP/MRP instance is
created. Enabling the protocol on multiple bridges therefore inserts the
same node into multiple lists. Unregistering it on one bridge then
corrupts list state belonging to another.
These handlers can only be installed once per bridge, and they are
uncommon. Track their per-bridge enable state with net_bridge option
bits, which already live on the Rx hot cache line, and dispatch the
matching handler directly from the receive path. Check both bits
together first as an unlikely case.
Remove the generic frame_type_list and br_frame_type helpers, which
have had no other users since CFM and MRP were added. That shrinks
struct net_bridge by 8 bytes and drops the list walk from the fast
path. When neither protocol is compiled in, BR_CFM_MRP_OPTS is 0 and
the compiler prunes the branch.
Fixes: 90c628dd47ff ("net: bridge: extend the process of special frames")
Fixes: dc32cbb3dbd7 ("bridge: cfm: Kernel space implementation of CFM. CCM frame RX added.")
Cc: stable@vger.kernel.org
Reported-by: Vega <vega@nebusec.ai>
Suggested-by: Nikolay Aleksandrov <razor@blackwall.org>
Co-developed-by: Yilin Zhu <zylzyl2333@gmail.com>
Signed-off-by: Yilin Zhu <zylzyl2333@gmail.com>
Signed-off-by: Zhiling Zou <zhilinz@nebusec.ai>
Acked-by: Nikolay Aleksandrov <razor@blackwall.org>
Link: https://patch.msgid.link/0345b9d5aa60ba416f6738ff1b87140f0a749cb8.1788417901.git.zhilinz@nebusec.ai
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
The ABI file documents .../endpoint_id/monitor_rx, but
drivers/net/ipa/ipa_sysfs.c has only ever created modem_rx and modem_tx
in the endpoint_id group. No monitor endpoint attribute exists.
Drop the entry.
Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260905092719.41497-1-kmehltretter@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
smc9.rst was removed with the separate smc91c92 driver. Stop
pointing SMC91X users to the nonexistent file.
Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260905051944.11604-1-kmehltretter@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
When I tried to install and run bonding selftests via:
make INSTALL_PATH=/tmp/kself TARGETS=drivers/net/bonding \
-C tools/testing/selftests install
Some tests fail because net/lib/sh/defer.sh is missing:
/tmp/kself/net/forwarding/../lib.sh: line 5: /tmp/kself/net/lib/sh/defer.sh: No such file or directory
One option is to add defer.sh directly to TEST_INCLUDES. Alternatively,
follow the approach from commit f72aa1b27628 ("selftests: net: include
lib/sh/*.sh with lib.sh"), which pulls in all .sh files to accommodate
future changes to the library directory.
This patch adds a wildcard to include all shell files for drivers/net
tests that consume net lib.sh. TEST_INCLUDES is also sorted to avoid
ordering‑related problems for future modifications. The team driver is
not affected by this bug, but we use the wildcard for it as well, rather
than listing only defer.sh.
Signed-off-by: Hangbin Liu <liuhangbin@kylinos.cn>
Reviewed-by: Petr Machata <petrm@nvidia.com>
Reviewed-by: Breno Leitao <leitao@debian.org>
Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20260907-selftest_lib_defer-v1-1-8af94645aaa3@kylinos.cn
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Maxime Chevallier says:
====================
selftests: drv-net: Allow cross-compiling the hardware tests
====================
Link: https://patch.msgid.link/20260907161438.755125-1-maxime.chevallier@bootlin.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
To test for the presence of zerocopy support in the available liburing,
a small check program is compiled.
The CC value used for the io_uring library check defaults to the host
compiler, which will incorrectly validate liburing based on the host's
sysroot and not the target's.
Normally the CC for cross-compile is set in lib.mk, but this also
requires the test list to be set when we include it, and this check
needs to run first.
Note that this doesn't cover the LLVM cross-compiling case though, as
with LLVM we may still detect based on the host liburing.
Suggested-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Reviewed-by: Matthieu Baerts (Netdev Foundation) <matttbe@kernel.org>
Signed-off-by: Maxime Chevallier (Netdev Foundation) <maxime.chevallier@bootlin.com>
Link: https://patch.msgid.link/20260907161438.755125-3-maxime.chevallier@bootlin.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
The ynl tool and libraries may be built standalone or through the
drivers/net/hw selftest machinery. This may target a different arch, so
we need to take the CROSS_COMPILE variable into account for LLVM and
gcc.
Let's include the tools/scripts/Makefile.include that deals with the
CC/AR resolution.
Fixup the ynltool CFLAGS handling to use +=, so that we don't override
the ones set in Makefile.include.
Makefile.include also sets the Q variable for verbose mode, so we can
drop it from the ynltool Makefile. This will allow properly selection
the verbosity of ynltool builds with the V=1 make flag.
Reviewed-by: Matthieu Baerts (Netdev Foundation) <matttbe@kernel.org>
Signed-off-by: Maxime Chevallier (Netdev Foundation) <maxime.chevallier@bootlin.com>
Link: https://patch.msgid.link/20260907161438.755125-2-maxime.chevallier@bootlin.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
tbl_mask_array_realloc() retires the old mask_array before it stops being
reachable:
old = ovsl_dereference(tbl->mask_array);
if (old) {
...
call_rcu(&old->rcu, mask_array_rcu_cb);
}
rcu_assign_pointer(tbl->mask_array, new);
call_rcu() only waits for read-side critical sections already in flight.
tbl->mask_array still points at old between the call_rcu() and the
rcu_assign_pointer(), so a reader entering ovs_flow_tbl_lookup_stats() in
that window picks up old in a fresh critical section that the pending
grace period does not cover.
tbl_mask_array_realloc() runs in process context under ovs_mutex, so the
window is preemptible and can outlast the grace period. Then
mask_array_rcu_cb() frees old before the swap runs:
BUG: KASAN: slab-use-after-free in flow_lookup.constprop.0+0x2bf/0x2f0
Read of size 8 at addr ffff888020b3e018 by task poc/741
flow_lookup.constprop.0+0x2bf/0x2f0
ovs_flow_tbl_lookup_stats+0x4a3/0x5c0
ovs_dp_process_packet+0x19c/0x710
ovs_vport_receive+0x243/0x390
internal_dev_xmit+0x81/0x170
Freed by task 728:
kfree+0x16a/0x4e0
rcu_core+0x853/0x1030
Publish the new array before retiring the old one. The kfree_rcu() that
call_rcu() replaced ran after the swap.
Fixes: eac87c413bf9 ("net: openvswitch: reorder masks array based on usage")
Cc: stable@vger.kernel.org
Signed-off-by: Norbert Szetei <norbert@doyensec.com>
Reviewed-by: Ilya Maximets <i.maximets@ovn.org>
Acked-by: Eelco Chaudron echaudro@redhat.com
Link: https://patch.msgid.link/DE115F9C-2545-423E-A702-986FC952FD62@doyensec.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Maxime Chevallier says:
====================
net: phy: motorcomm: Enable analog frontend DAC on yt8531S
It enables the analog frontend DAC at config_init() similar to what the
most recent vendor driver does.
Sashiko thought this would break after suspend/resume, this has been
tested and it's actually fine. This V2 just rewords a bit patch 3's
commit log, no other changes.
====================
Link: https://patch.msgid.link/20260905072830.28986-1-maxime.chevallier@bootlin.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
The YT6801 PCIe NIC includes the dwmac-motorcomm IP for the MAC part, as
well as a YT8531S PHY, configured in GMII mode.
It seems this PHY requires the Analog Front-end (AFE) DAC clock to be
enabled for link to reliably establish, otherwise the link just doesn't
come up.
Let's enable it at config_init() whenever the PHY is in GMII mode.
This logic has been extracted from the vendor driver provided by
Motorcomm.
It's really unclear if this is specific to the integrated version of
that PHY, and how this potentially interacts with the fiber mode this
PHY supports, so this configuration is only enabled when the interface
is GMII, i.e. the PHY is integrated.
With this, the PHY reliably establishes link and the YT6801 PCIe card
becomes fully functional. Supend/Resume was also tested, the link
stays operational after resume.
Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Link: https://patch.msgid.link/20260905072830.28986-4-maxime.chevallier@bootlin.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
The YT8531S PHY configuration logic is similar to the YT8521, but with
some extra steps for the RGMII configuration. In preparation for
improvements in the YT8531S configuration for the version found
integrated with the YT6801 PCIe NIC, let's split the logic out by
extending the YT8521 configuration sequence.
Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Link: https://patch.msgid.link/20260905072830.28986-3-maxime.chevallier@bootlin.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
In preparation for separate .config_init() implementations for YT8521
and YT8531S, let's split the yt8521_config_init() into a high-level
helper that deals with page handling, and another one that implements
the logic. This will ease splitting the YT8531S-specific logic out.
Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Link: https://patch.msgid.link/20260905072830.28986-2-maxime.chevallier@bootlin.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
syzbot reported a null-ptr-deref in __ip6_del_rt_siblings() [0].
The stack trace hinted towards a null dereference of rt->fib6_node when
fn->leaf is accessed in __ip6_del_rt_siblings(). With
RTNL_FLAG_DOIT_UNLOCKED set, inet6_rtm_delroute() operations run
concurrently without acquiring the RTNL lock. In ip6_route_del(), the
route lookup happens under rcu_read_lock() without acquiring
table->tb6_lock.
Between ip6_route_del() looking up the route and __ip6_del_rt_siblings()
acquiring table->tb6_lock, another thread can modify the routing table.
For example, when an ECMP route is replaced via RTM_NEWROUTE with
NLM_F_REPLACE, fib6_add_rt2node() unlinks all old siblings and sets
iter->fib6_node = NULL. A reproducer was found that triggers this [1].
Add a check to ensure rt->fib6_node is non-null before accessing it.
[0]
KASAN: null-ptr-deref in range [0x0000000000000020-0x0000000000000027]
RIP: 0010:__ip6_del_rt_siblings+0x31e/0x7c0 net/ipv6/route.c:4056
Call Trace:
<TASK>
ip6_route_del+0x1054/0x1110 net/ipv6/route.c:4232
inet6_rtm_delroute+0x5d7/0x6d0 net/ipv6/route.c:5669
rtnetlink_rcv_msg+0x802/0xc00 net/core/rtnetlink.c:7132
netlink_rcv_skb+0x226/0x4a0 net/netlink/af_netlink.c:2556
netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]
netlink_unicast+0x7f5/0x990 net/netlink/af_netlink.c:1345
netlink_sendmsg+0x813/0xb40 net/netlink/af_netlink.c:1900
sock_sendmsg_nosec+0x13a/0x180 net/socket.c:800
__sock_sendmsg net/socket.c:815 [inline]
____sys_sendmsg+0x565/0x870 net/socket.c:2713
___sys_sendmsg+0x2a5/0x360 net/socket.c:2767
__sys_sendmsg net/socket.c:2799 [inline]
__do_sys_sendmsg net/socket.c:2804 [inline]
__se_sys_sendmsg net/socket.c:2802 [inline]
__x64_sys_sendmsg+0x1b7/0x290 net/socket.c:2802
do_syscall_x64 arch/x86/entry/syscall_64.c:61 [inline]
do_syscall_64+0x166/0x520 arch/x86/entry/syscall_64.c:84
entry_SYSCALL_64_after_hwframe+0x77/0x7f
</TASK>
[1] https://gist.github.com/NamanGulati/0766a1159b6ca61928faaf87425ff899
Fixes: bd11ff421d36 ("ipv6: Get rid of RTNL for SIOCDELRT and RTM_DELROUTE.")
Reported-by: syzbot+a73e5ee0fd534fed75bd@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/netdev/6a9b03f9.04649fcc.10325f.0003.GAE@google.com
Signed-off-by: Naman Gulati <namangulati@google.com>
Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Reviewed-by: Fernando Fernandez Mancera <fmancera@suse.de>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Link: https://patch.msgid.link/20260904180645.706425-1-namangulati@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
When of_get_mac_address() fails, return the actual error code (rc)
instead of the hardcoded -ENODEV. This preserves the original error
information, which may be more specific (e.g., -EINVAL, -EPROBE_DEFER)
and helps callers handle the failure appropriately.
Use dev_err_probe() to avoid printing an extra error message in case of
-EPROBE_DEFER.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://patch.msgid.link/20260903213241.1040204-1-rosenp@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
When WARN_ON_ONCE() wraps a conditional lock acquisition (such as
down_write_trylock()) on architectures relying on DO_ONCE_LITE_IF()
(e.g. arm), Clang's context analysis (Thread Safety Analysis) failed
with a false positive:
fs/ext2/xattr.c:825:6: error: rw_semaphore 'EXT2_I().xattr_sem' is not held on every path through here [-Werror,-Wthread-safety-analysis]
825 | if (WARN_ON_ONCE(!down_write_trylock(&EXT2_I(inode)->xattr_sem)))
| ^
This happens because DO_ONCE_LITE_IF() branches on __ONCE_LITE_IF()'s
return value (__ret_once), creating an intermediate branch merge point
where the lock may or may not be held depending on whether the once-flag
(__already_done) was already set. Because the merge branch condition is
__ret_once rather than the trylock predicate (__ret_do_once), Clang
cannot reconcile the lockset at the branch merge points.
Fix it by refactoring __ONCE_LITE_IF() into an unconditional
__ONCE_LITE() primitive and redefining __ONCE_LITE_IF(condition) as:
(unlikely(condition) && __ONCE_LITE())
This simplifies the implementation, short-circuits evaluation so that
__ONCE_LITE() is not called when the condition is false, and ensures
that DO_ONCE_LITE_IF() only enters __ONCE_LITE() when __ret_do_once is
true.
Reported-by: Nathan Chancellor <nathan@kernel.org>
Link: https://lore.kernel.org/all/20260903072759.GA1750084@ax162/
Signed-off-by: Marco Elver <elver@google.com>
Tested-by: Nathan Chancellor <nathan@kernel.org> # build
Link: https://patch.msgid.link/20260903101843.3462767-1-elver@google.com
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
|
|
Ruizhe Zhou says:
====================
net: Remove obsolete 32-bit DMA mask fallbacks
A lot of Ethernet drivers set a >32 bit DMA mask and retry with a
32-bit mask if the first call fails. This treats the return value of
dma_set_mask_and_coherent() as an indication that the platform requires
a narrower DMA width.
That is not a correct interpretation of dma_set_mask_and_coherent().
The mask describes the DMA addresses the device can accept and constrains
subsequent mappings to that range. A wider mask includes every address
permitted by a 32-bit mask, including addresses from a platform that only
produces 32-bit DMA addresses. Retrying with 32 bits therefore adds a stricter
constraint and cannot correct a failure to establish the wider mask.
The DMA API HOWTO explicitly calls this fallback pattern incorrect [1].
See [2] and [3] for details.
A net subsystem tree-wide audit found 28 Ethernet drivers with this pattern.
This series contains 14 straightforward cases where the fallback can be
removed without changing the mask selected for the device. The return-value
check is retained. DMA setup errors are still reported and still abort device
initialization. The other 14 cases are less straightforward. So I will submit
those as a separate follow-up after review of this series concludes and any
issues are resolved.
Testing was compile-only. No hardware testing was performed.
[1] DMA API HOWTO, "DMA addressing capabilities"
https://docs.kernel.org/core-api/dma-api-howto.html#dma-addressing-capabilities
[2] DMA direct addressability change, commit 91ef26f91417
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=91ef26f914171cf753330f13724fd9142b5b1640
[3] DMA HOWTO correction, commit f7ae20f2fc4e
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f7ae20f2fc4e
====================
Link: https://patch.msgid.link/20260903084339.870562-1-zhouruizhe@resnics.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
The DMA API guarantees support for masks of 32 bits or wider and
explicitly identifies retrying a 32-bit mask after a wider request as
incorrect:
https://docs.kernel.org/core-api/dma-api-howto.html#dma-addressing-capabilities
Remove the obsolete fallback while retaining the error check so that a
genuine DMA setup failure is still reported and aborts initialization.
A successful setup now necessarily uses the 44-bit mask, so advertise
NETIF_F_HIGHDMA directly after checking the result.
Signed-off-by: Ruizhe Zhou <zhouruizhe@resnics.com>
Link: https://patch.msgid.link/20260903084339.870562-15-zhouruizhe@resnics.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
The DMA API guarantees support for masks of 32 bits or wider and
explicitly identifies retrying a 32-bit mask after a wider request as
incorrect:
https://docs.kernel.org/core-api/dma-api-howto.html#dma-addressing-capabilities
Remove the obsolete fallback while retaining the error check so that a
genuine DMA setup failure still aborts initialization.
Signed-off-by: Ruizhe Zhou <zhouruizhe@resnics.com>
Link: https://patch.msgid.link/20260903084339.870562-14-zhouruizhe@resnics.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
The DMA API guarantees support for masks of 32 bits or wider and
explicitly identifies retrying a 32-bit mask after a 64-bit request as
incorrect:
https://docs.kernel.org/core-api/dma-api-howto.html#dma-addressing-capabilities
Remove the obsolete fallback while retaining the error check so that a
genuine DMA setup failure is still reported and aborts initialization.
Signed-off-by: Ruizhe Zhou <zhouruizhe@resnics.com>
Link: https://patch.msgid.link/20260903084339.870562-13-zhouruizhe@resnics.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
The DMA API guarantees support for masks of 32 bits or wider and
explicitly identifies retrying a 32-bit mask after a wider request as
incorrect:
https://docs.kernel.org/core-api/dma-api-howto.html#dma-addressing-capabilities
Remove the obsolete fallback while retaining the error check so that a
genuine DMA setup failure is still reported and aborts initialization.
Signed-off-by: Ruizhe Zhou <zhouruizhe@resnics.com>
Link: https://patch.msgid.link/20260903084339.870562-12-zhouruizhe@resnics.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
The DMA API guarantees support for masks of 32 bits or wider and
explicitly identifies retrying a 32-bit mask after a 64-bit request as
incorrect:
https://docs.kernel.org/core-api/dma-api-howto.html#dma-addressing-capabilities
Remove the obsolete fallback while retaining the error check so that a
genuine DMA setup failure is still reported and aborts initialization.
Update the error message to identify the combined streaming and coherent
DMA mask operation.
Signed-off-by: Ruizhe Zhou <zhouruizhe@resnics.com>
Reviewed-by: Petr Machata <petrm@nvidia.com>
Link: https://patch.msgid.link/20260903084339.870562-11-zhouruizhe@resnics.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
The DMA API guarantees support for masks of 32 bits or wider and
explicitly identifies retrying a 32-bit mask after a 64-bit request as
incorrect:
https://docs.kernel.org/core-api/dma-api-howto.html#dma-addressing-capabilities
Remove the obsolete fallback while retaining the error check so that a
genuine DMA setup failure is still reported and aborts initialization.
Signed-off-by: Ruizhe Zhou <zhouruizhe@resnics.com>
Reviewed-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20260903084339.870562-10-zhouruizhe@resnics.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
The DMA API guarantees support for masks of 32 bits or wider and
explicitly identifies retrying a 32-bit mask after a 64-bit request as
incorrect:
https://docs.kernel.org/core-api/dma-api-howto.html#dma-addressing-capabilities
Remove the obsolete fallback while retaining the error check so that a
genuine DMA setup failure is still reported and aborts initialization.
Signed-off-by: Ruizhe Zhou <zhouruizhe@resnics.com>
Reviewed-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20260903084339.870562-9-zhouruizhe@resnics.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
The DMA API guarantees support for masks of 32 bits or wider and
explicitly identifies retrying a 32-bit mask after a wider request as
incorrect:
https://docs.kernel.org/core-api/dma-api-howto.html#dma-addressing-capabilities
Remove the obsolete fallback while retaining the error check so that a
genuine DMA setup failure is still reported and aborts initialization.
Signed-off-by: Ruizhe Zhou <zhouruizhe@resnics.com>
Link: https://patch.msgid.link/20260903084339.870562-8-zhouruizhe@resnics.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
The DMA API guarantees support for masks of 32 bits or wider and
explicitly identifies retrying a 32-bit mask after a 64-bit request as
incorrect:
https://docs.kernel.org/core-api/dma-api-howto.html#dma-addressing-capabilities
Remove the obsolete fallback while retaining the error check so that a
genuine DMA setup failure is still reported and aborts initialization.
Signed-off-by: Ruizhe Zhou <zhouruizhe@resnics.com>
Link: https://patch.msgid.link/20260903084339.870562-7-zhouruizhe@resnics.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
The DMA API guarantees support for masks of 32 bits or wider and
explicitly identifies retrying a 32-bit mask after a wider request as
incorrect:
https://docs.kernel.org/core-api/dma-api-howto.html#dma-addressing-capabilities
Remove the obsolete fallback while retaining the error check so that a
genuine DMA setup failure is still reported and aborts initialization.
A successful setup now necessarily uses the 47-bit mask, so remove the
redundant using_dac flag and advertise NETIF_F_HIGHDMA directly.
Signed-off-by: Ruizhe Zhou <zhouruizhe@resnics.com>
Link: https://patch.msgid.link/20260903084339.870562-6-zhouruizhe@resnics.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
The DMA API guarantees support for masks of 32 bits or wider and
explicitly identifies retrying a 32-bit mask after a 64-bit request as
incorrect:
https://docs.kernel.org/core-api/dma-api-howto.html#dma-addressing-capabilities
Remove the obsolete fallback while retaining the error check so that a
genuine DMA setup failure is still reported and aborts initialization.
Signed-off-by: Ruizhe Zhou <zhouruizhe@resnics.com>
Link: https://patch.msgid.link/20260903084339.870562-5-zhouruizhe@resnics.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
The DMA API guarantees support for masks of 32 bits or wider and
explicitly identifies retrying a 32-bit mask after a wider request as
incorrect:
https://docs.kernel.org/core-api/dma-api-howto.html#dma-addressing-capabilities
Remove the obsolete fallback while retaining the error check so that a
genuine DMA setup failure is still reported and aborts initialization.
Signed-off-by: Ruizhe Zhou <zhouruizhe@resnics.com>
Link: https://patch.msgid.link/20260903084339.870562-4-zhouruizhe@resnics.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
The DMA API guarantees support for masks of 32 bits or wider and
explicitly identifies retrying a 32-bit mask after a 64-bit request as
incorrect:
https://docs.kernel.org/core-api/dma-api-howto.html#dma-addressing-capabilities
Remove the obsolete fallback while retaining the error check so that a
genuine DMA setup failure is still reported and aborts initialization.
Signed-off-by: Ruizhe Zhou <zhouruizhe@resnics.com>
Link: https://patch.msgid.link/20260903084339.870562-3-zhouruizhe@resnics.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
The DMA API guarantees support for masks of 32 bits or wider and
explicitly identifies retrying a 32-bit mask after a 64-bit request as
incorrect:
https://docs.kernel.org/core-api/dma-api-howto.html#dma-addressing-capabilities
Remove the obsolete fallback while retaining the error check so that a
genuine DMA setup failure still aborts initialization.
Signed-off-by: Ruizhe Zhou <zhouruizhe@resnics.com>
Link: https://patch.msgid.link/20260903084339.870562-2-zhouruizhe@resnics.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Commit 5c6baef3885c ("selftests: drv-net: convert so_txtime to
drv-net") moved the test to tools/testing/selftests/drivers/net/, but
the SOCKET TIMESTAMPING entry still lists the old path and
scripts/get_maintainer.pl --self-test=patterns reports it as matching
nothing.
Point the pattern at the new location.
Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
Reviewed-by: Jason Xing <kerneljasonxing@gmail.com>
Reviewed-by: Willem de Bruijn <willemb@google.com>
Link: https://patch.msgid.link/20260905100608.42539-1-kmehltretter@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
struct sockaddr_spn does not exist; the name is struct sockaddr_pn.
Use struct sockaddr_pn.
Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Link: https://patch.msgid.link/20260905104123.43511-1-kmehltretter@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
ppp_receive_nonmp_frame() prepends a two-byte direction tag before running
the pass/active BPF filters:
*(__be16 *)skb_push(skb, 2) = htons(PPP_FILTER_INBOUND_TAG);
Nothing on the receive path guarantees those two bytes of headroom. The
frame-error path in ppp_async's process_input_packet() resets a reused skb's
headroom to zero while claiming to restore it to a freshly allocated state -
but a fresh skb from dev_alloc_skb() carries NET_SKB_PAD:
err:
if (skb) {
/* make skb appear as freshly allocated */
skb_trim(skb, 0);
skb_reserve(skb, - skb_headroom(skb));
}
ap->rpkt still points at that skb, so the next frame is reassembled into it
with no headroom at all. A peer that sends a bad-FCS frame followed by one
beginning ff 03 then leaves a single byte of headroom by the time the filter
tag is pushed, which lands one byte below skb->head:
skbuff: skb_under_panic: len:49 put:2 head:ffff888003c10000
data:ffff888003c0ffff tail:0x30 end:0x640 dev:<NULL>
kernel BUG at net/core/skbuff.c:214!
RIP: 0010:skb_panic+0x13e/0x230
Call Trace:
skb_push+0xbd/0x100
ppp_receive_nonmp_frame+0x48a/0x1d10
ppp_input+0x4e9/0x2f80
ppp_async_process+0x2a/0xe0
tasklet_action_common+0x20f/0x8a0
handle_softirqs+0x18e/0x590
Kernel panic - not syncing: Fatal exception in interrupt
Zeroing the headroom violates the NET_SKB_PAD guarantee that dev_alloc_skb()
gives the rest of the receive path. Besides the filter panic above, when CCP
compression is enabled ppp_decompress_frame() hands skb->data - 2 to
->decompress()/->incomp(), which then reads out of bounds before skb->head
for the same reason.
Rather than restore the headroom, drop the errored frame - as ppp_synctty
already does on its error path - and clear ap->rpkt so the next frame is
reassembled into a fresh skb with proper headroom. This is simpler and fixes
both the filter under-panic and the CCP out-of-bounds read.
The original V1 of this patch made room in ppp_receive_nonmp_frame() with
skb_cow_head(); Eric pointed out that fixing the root cause in the transport
is the right approach.
Found by fuzzing the PPP receive path with a mutating peer on a pty; it is an
interesting (remote) DoS: root configures PPP, the peer supplies two crashing
frames. The reproducer (repro-ppp-skb.c, unchanged from v1) panics in about a
second, and returns cleanly with this applied.
Fixes: 6722e78c9005 ("[PPP]: handle misaligned accesses")
Suggested-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Vlatko Kosturjak <kost@linux.hr>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Link: https://patch.msgid.link/apkR6ZU+tqP2C3Fl@griffin.linux.hr
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Mingpei says:
====================
libbpf: Fix array comparison in BTF dedup
The recursive array comparison in BTF dedup reads both descriptors from
the first type. This can merge distinct structures and corrupt CO-RE
relocation metadata. Fix the comparison and add three regression cases to
the existing BTF dedup tests.
Changes in v2:
- Move the tests into prog_tests/btf.c using Alan Maguire's two cases.
- Add a separate negative case with the same index type to isolate
element-type comparison.
- Keep patch 1 unchanged.
v1: https://lore.kernel.org/bpf/20260907131021.34343-1-caomingpei@gmail.com/
Report: https://lore.kernel.org/bpf/CABzjXVz3iBuump-pXFkefZ5v+2uu4fG61zqRyWD4xmz3PuBycw@mail.gmail.com/
Validation with a focused runner using the existing selftest sources and
assertions:
- 52 existing BTF cases passed before and after the fix.
- Both negative cases failed before the fix and passed afterwards.
- The positive case passed before and after the fix.
====================
Link: https://patch.msgid.link/20260908164920.108074-1-caomingpei@gmail.com
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
|
|
Exercise recursive array comparison with different and identical
element definitions using the existing BTF dedup tests. Add a separate
case with the same index type to isolate the element-type comparison.
Check that distinct containers remain separate and identical types
are deduplicated. Both negative cases fail before the fix and pass
afterwards; the positive case passes both before and after the fix.
Suggested-by: Alan Maguire <alan.maguire@oracle.com>
Signed-off-by: Mingpei CAO <caomingpei@gmail.com>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/bpf/20260908164920.108074-3-caomingpei@gmail.com
|
|
btf_dedup_identical_types() reads both array descriptors from t1,
skipping comparisons of their referenced types. This can incorrectly
merge distinct structs and corrupt CO-RE relocation metadata.
Read the second descriptor from t2.
Fixes: 62e23f183839 ("libbpf: Improve BTF dedup handling of "identical" BTF types")
Closes: https://lore.kernel.org/bpf/CABzjXVz3iBuump-pXFkefZ5v+2uu4fG61zqRyWD4xmz3PuBycw@mail.gmail.com/
Signed-off-by: Mingpei CAO <caomingpei@gmail.com>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/bpf/20260908164920.108074-2-caomingpei@gmail.com
|
|
mana_rdma_remove() sets gd->rdma_teardown to stop
mana_rdma_service_handle() from acting on servicing events, but nothing
ever clears it. A hardware service reset (GDMA_EQE_HWC_RESET_REQUEST)
goes through mana_gd_suspend() -> mana_rdma_remove() and mana_gd_resume()
-> mana_rdma_probe(), so from the first reset onwards every
GDMA_EQE_HWC_SOC_SERVICE event returns early and RDMA suspend/resume
servicing is silently dropped for the life of the device.
gd->is_suspended has the same problem: it is set when servicing removes
the adev and is cleared only by a matching resume. A reset while RDMA is
suspended re-adds the adev but leaves is_suspended set, so a later resume
event calls add_adev() on top of a live gd->adev and leaks it. This is
currently masked by the rdma_teardown bug.
Clear both in mana_rdma_probe(). On the reset path mana_rdma_remove()
has closed the gate and drained the service workqueue, so clear
is_suspended first and re-open the gate with smp_store_release(), paired
with smp_load_acquire() in the handler, so the handler cannot observe an
open gate with a stale is_suspended. On the initial probe path the gate
was never closed and both flags are already clear.
This does not order gd->adev, which add_adev() publishes afterwards. A
servicing event arriving in that window is still dropped, as it is in
mainline today on the initial probe path; closing it needs probe and the
handler to be serialized and is left to a separate change.
Fixes: 505cc26bcae0 ("net: mana: Add support for auxiliary device servicing events")
Signed-off-by: Long Li <longli@microsoft.com>
Link: https://patch.msgid.link/20260902175153.3410560-1-longli@microsoft.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
lookup_address_in_pgd_attr() accumulates the effective NX and RW bits of
the walked page table levels so that verify_rwx() can detect mappings that
are both writable and executable.
The RW bits are folded into a bool with
rw &= pXd_flags(*pXd) & _PAGE_RW;
but _PAGE_RW is 0x2. So consider the accumulation line:
rw &= pXd_flags(*pXd) & _PAGE_RW;
where rw=0x1 and the right side evaluates down to 0x2. It'll end up doing:
rw = 0x1 & 0x2
and rw always ends up 0.
This way rw becomes false at the first level walked, regardless of the
actual permissions, and verify_rwx() treats every mapping as non-writable
and never reports a W^X violation.
Add double negation to the right side to normalize the _PAGE_RW flag to
0 or 1.
Assisted-by: Copilot:claude-opus-4.8
Fixes: ceb647b4b529 ("x86/pat: Introduce lookup_address_in_pgd_attr()")
Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
Tested-by: syzbot@syzkaller.appspotmail.com
Tested-by: Atish Patra <atishp@meta.com>
Tested-by: Nikunj A Dadhania <nikunj@amd.com>
Cc:stable@vger.kernel.org
Link: https://patch.msgid.link/20260813-cpa-fixes-v2-5-39b4ff90f91d@kernel.org
|
|
Check the return value of zalloc() before dereferencing the allocated
dwfl_ui_ti structure.
Return -ENOMEM when the allocation fails to avoid a NULL pointer
dereference.
Signed-off-by: Triet Hoang <triet.hoang.dev@gmail.com>
Acked-by: Namhyung Kim <namhyung@kernel.org>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
|
|
When pretty-printing augmented struct payloads using BTF via
btf_struct_scnprintf(), augmented_arg->size is currently only validated
against values <= 0.
However, several edge cases can result in size mismatches or buffer
over-reads:
1. If arg->augmented.size is smaller than sizeof(*augmented_arg),
dereferencing augmented_arg->size reads past the available
buffer.
2. If augmented_arg->size exceeds arg->augmented.size -
sizeof(*augmented_arg), calculating consumed =
sizeof(*augmented_arg) + augmented_arg->size can overflow signed
integer limits (e.g., with crafted INT_MAX values in an
untrusted perf.data file) or cause arg->augmented.size to
underflow. This advances arg->augmented.args out of bounds,
corrupting the parsing state for subsequent arguments in
multi-argument syscalls.
3. If the captured payload is truncated (e.g., short reads in BPF,
or during cross-architecture analysis such as replaying a 32-bit
perf.data on a 64-bit host where host BTF type->size exceeds the
32-bit target payload), passing type->size to
btf_dump__dump_type_data() causes libbpf to read past the end of
the payload buffer.
Enforce an upper bound on augmented_arg->size against the remaining
buffer (arg->augmented.size - sizeof(*augmented_arg)) and verify that the
captured payload contains at least type->size bytes before passing it to
btf_dump__dump_type_data().
Fixes: cb32035214b9a09d ("perf trace: Pretty print struct data")
Reported-by: sashiko-bot <sashiko-bot@kernel.org>
Signed-off-by: Aaron Tomlin <atomlin@atomlin.com>
Cc: Howard Chu <howardchu95@gmail.com>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
|
|
Starting with bindgen 0.73.2 [1], `#[allow(unnecessary_transmutes)]`
are used, even when `--rust-target 1.85` is passed.
However, the lint was introduced in Rust 1.88.0. Thus building with
older Rust versions warns like:
error: unknown lint: `unnecessary_transmutes`
--> rust/uapi/uapi_generated.rs:26294:13
|
26294 | #[allow(unnecessary_transmutes)]
| ^^^^^^^^^^^^^^^^^^^^^^
|
= note: `-D unknown-lints` implied by `-D warnings`
= help: to override `-D warnings` add `#[allow(unknown_lints)]`
Thus allow `unknown_lints` in the generated bindings -- only when building
with older Rust versions.
I have asked upstream if this is intentional [1], i.e. if we are supposed
to always allow unknown lints in case `bindgen` uses such attributes,
or whether it is an oversight.
[ Emilio said it wasn't intentional -- we will work around it for now
on the kernel side. - Miguel ]
Cc: stable@vger.kernel.org # Needed in 6.12.y and later (Rust is pinned in older LTSs).
Cc: Emilio Cobos Álvarez <emilio@crisal.io>
Link: https://github.com/rust-lang/rust-bindgen/pull/3455#issuecomment-5588526559 [1]
Assisted-by: LLM
Link: https://patch.msgid.link/20260908170539.345207-1-ojeda@kernel.org
[ Removed the `cfg` for `allow(unnecessary_transmutes)` as suggested by
Gary. - Miguel ]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
|
|
btusb_reset calls usb_autopm_get_interface to resume the device
before queuing a reset of it, but never calls the matching
usb_autopm_put_interface.
usb_queue_reset_device ends up in usb_reset_device(), and since
btusb provides no pre_reset/post_reset callbacks the interface is
merely unbound and rebound: the interface device object survives
this cycle, and so does its PM usage count, which is not cleared
when the driver is unbound.
As a result every reset permanently leaks a PM usage reference,
preventing the interface from being runtime suspended again until
it is unbound.
Set BTUSB_RESET flag before usb_queue_reset_device so that
btusb_disconnect drops the reference. If the flag is already set,
drop one reference.
Fixes: c9209b269afd ("Bluetooth: btusb: Introduce generic USB reset")
Assisted-by: Claude:qwen3.8-max
Signed-off-by: Jiajia Liu <liujiajia@kylinos.cn>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
|
MT7925 on HP Pro Mini 260 sometimes timed out during reloading driver
and reset usb device. btusb_suspend is not called again after closing
bluetooth interface.
usbcore: registered new interface driver btusb
Bluetooth: hci0: HW/SW Version: 0x00000000, Build Time: 20260605184935
Bluetooth: hci0: Execution of wmt command timed out
Bluetooth: hci0: Failed to send wmt patch dwnld (-110)
Bluetooth: hci0: Failed to set up firmware (-110)
usb 3-10: reset high-speed USB device number 4 using xhci_hcd
Bluetooth: hci0: HW/SW Version: 0x00000000, Build Time: 20260605184935
Bluetooth: hci0: Device setup in 1856545 usecs
Bluetooth: hci0: AOSP extensions version v1.00
Bluetooth: hci0: AOSP quality report is supported
Bluetooth: MGMT ver 1.23
btusb_mtk_reset calls usb_autopm_get_interface to resume the device
before driving the hardware reset, but never calls the matching
usb_autopm_put_interface. Every hardware reset therefore leaks a PM
usage reference of the interface, preventing the device from being
runtime suspended again until it is unbound.
Add the BTUSB_RESET flag. It is set before usb_queue_reset_device
and is cleared in btusb_disconnect, which drops the reference as well.
If the flag is already set when a new reset is requested, drop one
reference.
Also clear BTMTK_HW_RESET_ACTIVE if usb_autopm_get_interface fails,
otherwise no further reset could ever be attempted.
Fixes: 25b6d7593a3a ("Bluetooth: btmtk: introduce btmtk reset work")
Assisted-by: Claude:qwen3.8-max
Signed-off-by: Jiajia Liu <liujiajia@kylinos.cn>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
