| Age | Commit message (Collapse) | Author |
|---|
|
Add an overflow check to ensure that data_offset + data_len + 8 does not
wrap, which would enable an OOB read of the USB data buffer.
Cc: Andrew Lunn <andrew+netdev@lunn.ch>
Cc: Shaoxu Liu <shaoxul@foxmail.com>
Signed-off-by: Griffin Kroah-Hartman <griffin@kroah.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/2026070900-denim-brook-52d4@gregkh
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Kuniyuki Iwashima says:
====================
net: Fix two issues in sk_clone() error path.
Sashiko reported issues in the sk_clone() error path.
https://lore.kernel.org/bpf/20260709032007.9E4D61F000E9@smtp.kernel.org/
This series fixes them.
====================
Link: https://patch.msgid.link/20260709183315.965751-1-kuniyu@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
When sk_clone() fails, sk_destruct() is called for the new socket.
If the parent socket has SK_FLAGS_TIMESTAMP in sk->sk_flags,
net_disable_timestamp() is called for the child socket even though
net_enable_timestamp() is not called for it.
Let's call net_enable_timestamp() before any failure path in
sk_clone().
Fixes: 704da560c0a0 ("tcp: update the netstamp_needed counter when cloning sockets")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: https://lore.kernel.org/all/20260709032007.9E4D61F000E9@smtp.kernel.org/
Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
Reviewed-by: Willem de Bruijn <willemb@google.com>
Reviewed-by: Jason Xing <kerneljasonxing@gmail.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260709183315.965751-3-kuniyu@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
When sk_clone() fails, sk_destruct() is called for the new socket.
If the parent socket has sk->sk_reuseport_cb, the child will call
reuseport_detach_sock() for the reuseport group.
Let's clear sk->sk_reuseport_cb before any failure path in sk_clone().
Note that this was not a problem before the cited commit because
reuseport_detach_sock() did nothing if the socket was not found in
the reuseport array.
Fixes: 5dc4c4b7d4e8 ("bpf: Introduce BPF_MAP_TYPE_REUSEPORT_SOCKARRAY")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: https://lore.kernel.org/all/20260709032007.9E4D61F000E9@smtp.kernel.org/
Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
Reviewed-by: Willem de Bruijn <willemb@google.com>
Reviewed-by: Jason Xing <kerneljasonxing@gmail.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260709183315.965751-2-kuniyu@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
MAC_AUTO_SW (VR_MII_DIG_CTRL1 bit 9) enables automatic XPCS speed
mode switching after CL37 auto-negotiation and is only meaningful in
SGMII MAC mode. The original code unconditionally set this bit on
every call to xgbe_an37_set(), including when called from
xgbe_an37_disable() with enable=false. This left MAC_AUTO_SW=1 after
AN was disabled, causing the XPCS to autonomously switch speed from
stale AN state during subsequent mode changes, breaking SGMII speed
negotiation on 1G copper SFP modules.
Patrick: This was breaking negotiation for all 1G SFP modules,
not just copper modules.
Fixes: 42fd432fe6d3 ("amd-xgbe: align CL37 AN sequence as per databook")
Reported-by: Patrick Oppenlander <patrick.oppenlander@gmail.com>
Link: https://lore.kernel.org/netdev/CAEg67GmFS0Q4oSZkz8zWdOzckSth9_vBPiOy6a7-d697C2w2Xg@mail.gmail.com
Signed-off-by: Prashanth Kumar KR <PrashanthKumar.K.R@amd.com>
Tested-by: Patrick Oppenlander <patrick.oppenlander@gmail.com>
Link: https://patch.msgid.link/20260709095006.3683940-1-prashanthkumar.k.r@amd.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
The tcp_syn_ack_timeout() function gets inlined by Clang,
preventing tracing. Since the call is not in the fast
path, prevent it from being inlined.
Signed-off-by: Emil Tsalapatis <emil@etsalapatis.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Link: https://patch.msgid.link/20260708180837.9507-1-emil@etsalapatis.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Try to send per-connector hotplug events as often as possible, rather
than connector-less global hotplug events. This does result in more
hotplug events if multiple connectors changed at the same time, but
give userspace more actionable information.
Since the hotplug event needs to be sent outside of the mode_config
mutex to avoid a deadlock, the drm_client_dev_hotplug() call is split
off from the drm_sysfs_(connector_)?hotplug_event calls.
Co-developed-by: Marius Vlad <marius.vlad@collabora.com>
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Link: https://patch.msgid.link/20260526-hot-plug-passup-v10-2-f62351a9ea3e@collabora.com
Signed-off-by: Daniel Stone <daniels@collabora.com>
|
|
Since the very day epoch_counter in drm_connector was introduced, its
documentation was not accurate. It claims it's used to detect "any other
changes [...] besides status", when in reality, it's used to detect
changes including status, as a status change also increases the epoch
counter.
Adjust the documentation to rectify this discrepancy.
Fixes: 5186421cbfe2 ("drm: Introduce epoch counter to drm_connector")
Reviewed-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Link: https://patch.msgid.link/20260526-hot-plug-passup-v10-1-f62351a9ea3e@collabora.com
Signed-off-by: Daniel Stone <daniels@collabora.com>
|
|
An inode being evicted will never need its extra isize expanded. Set
EXT4_STATE_NO_EXPAND before ext4_mark_inode_dirty() in ext4_evict_inode()
to make this explicit and prevent any unnecessary work in
ext4_try_to_expand_extra_isize().
This also provides defense-in-depth for the s_writepages_rwsem deadlock
during mount-time orphan cleanup, ensuring the expand path is blocked
for inodes under eviction regardless of how they are reached.
Signed-off-by: Yun Zhou <yun.zhou@windriver.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Link: https://patch.msgid.link/20260623061903.2148767-2-yun.zhou@windriver.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
|
|
ext4_try_to_expand_extra_isize() is called from __ext4_mark_inode_dirty()
while holding an active jbd2 handle. During mount (!SB_ACTIVE), the
expand path may move xattrs to external blocks and release ea_inodes via
iput(). When !SB_ACTIVE, iput() calls write_inode_now() which acquires
s_writepages_rwsem, creating a circular lock dependency:
s_writepages_rwsem --> jbd2_handle --> xattr_sem --> s_writepages_rwsem
This can be triggered via:
ext4_process_orphan() -> ext4_truncate() -> ext4_mark_inode_dirty()
-> ext4_try_to_expand_extra_isize()
or:
ext4_evict_inode() -> ext4_mark_inode_dirty()
-> ext4_try_to_expand_extra_isize()
Skip expansion when !SB_ACTIVE. This is a minor loss of functionality
(extra isize won't grow for these inodes during mount), which e2fsck
can resolve later if needed.
Reported-by: syzbot+5d19358d7eb30ffb0cc5@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=5d19358d7eb30ffb0cc5
Fixes: c8585c6fcaf2 ("ext4: fix races between changing inode journal mode and ext4_writepages")
Signed-off-by: Yun Zhou <yun.zhou@windriver.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Link: https://patch.msgid.link/20260623061903.2148767-1-yun.zhou@windriver.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
|
|
ext4_read_inline_dir() can read a dirent header past the end of its inline
buffer, triggering a slab-out-of-bounds read during getdents64():
BUG: KASAN: slab-out-of-bounds in __ext4_check_dir_entry
Read of size 2 at addr ffff88800f3dd23c by task exploit/148
...
__ext4_check_dir_entry
ext4_read_inline_dir
iterate_dir
The dirent payload lives in a buffer of exactly inline_size bytes:
dir_buf = kmalloc(inline_size, GFP_NOFS);
but iteration runs in a position space extra_offset bytes larger
(extra_size = extra_offset + inline_size) so the synthetic "." and ".."
land at their block-dir offsets. A dirent is formed at "dir_buf + pos -
extra_offset", yet the ext4_check_dir_entry() length argument uses the
larger extra_size. A position whose dirent header would extend past
extra_size is therefore accepted, and the rescan loop's rec_len probe and
ext4_check_dir_entry() dereference de->rec_len before the entry is rejected.
Reject a position whose minimum-size dirent header would not fit within
extra_size before forming de, in both the rescan and main loops, and pass
inline_size rather than extra_size to ext4_check_dir_entry() so the length
check matches the physical buffer.
Fixes: c4d8b0235aa9 ("ext4: fix readdir error in case inline_data+^dir_index.")
Reported-by: Weiming Shi <bestswngs@gmail.com>
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: Xiang Mei <xmei5@asu.edu>
Reviewed-by: Jan Kara <jack@suse.cz>
Link: https://patch.msgid.link/20260615190519.946736-1-xmei5@asu.edu
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
|
|
This field comes from userspace and should be validated against specific
limits depending on which Shader Model (SM) is available.
Fixes: 504901dbb0b5 ("drm/vmwgfx: Refactor surface_define to use vmw_surface_metadata")
Reported-by: Zero Day Initiative <zdi-disclosures@trendmicro.com>
Cc: stable@vger.kernel.org
Signed-off-by: Ian Forbes <ian.forbes@broadcom.com>
Reviewed-by: Maaz Mombasawala <maaz.mombasawala@broadcom.com>
Signed-off-by: Zack Rusin <zack.rusin@broadcom.com>
Link: https://patch.msgid.link/20260623193314.506257-1-ian.forbes@broadcom.com
|
|
There's no need for a custom end_io routine here. We lose some
tracing of I/O completions, but we gain better error handling.
Well, consistent error handling anyway.
Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
Reviewed-by: Jan Kara <jack@suse.cz>
Link: https://patch.msgid.link/20260615182527.2208479-1-willy@infradead.org
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging
Pull hwmon fixes from Guenter Roeck:
- asus-ec-sensors: Add missed handle for ENOMEM, fix EC read
intervals, and fix looping over banks while reading from EC
- occ: validate poll response sensor blocks
- pmbus/max34440: Block unsupported VIN and IIN limit registers
- nzxt-kraken3, nzxt-smart2: gigabyte_waterforce, corsair-cpro,
corsair-psu: Stop device IO before calling hid_hw_stop
* tag 'hwmon-for-v7.2-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging:
hwmon: occ: validate poll response sensor blocks
hwmon: (asus-ec-sensors) add missed handle for ENOMEM
hwmon: (asus-ec-sensors) fix EC read intervals
hwmon: (asus-ec-sensors) fix looping over banks while reading from EC
hwmon: (pmbus/max34440) block unsupported VIN and IIN limit registers
hwmon: (nzxt-kraken3) Stop device IO before calling hid_hw_stop
hwmon: (nzxt-smart2) Stop device IO before calling hid_hw_stop
hwmon: (gigabyte_waterforce) Stop device IO before calling hid_hw_stop
hwmon: (corsair-cpro) Stop device IO before calling hid_hw_stop
hwmon: (corsair-psu) Stop device IO before calling hid_hw_stop
|
|
Commit 0ab03f353d36 ("net-gro: Fix GRO flush when receiving a GSO
packet.") added a flush check to skb_gro_receive(), but
skb_gro_receive_list() lacks the same validation.
As a result, packets marked with NAPI_GRO_CB(skb)->flush may still be
re-aggregated.
This allows already-GRO'd packets with existing frag_list to be
re-aggregated into a new GRO session, corrupting the frag_list chain
structure. When skb_segment() attempts to unpack these malformed packets,
it encounters invalid state and triggers a kernel panic.
Scenario (Tethering/Device forwarding):
1. Driver: Generated aggregated packet P1 via LRO with frag_list
2. Dev A: Receives aggregated fraglist packet and flush flag set
3. Dev A: Re-enters GRO, skb_gro_receive_list() is called
4. Missing flush check allows re-aggregation despite flush flag
5. Frag_list chain becomes corrupted (loops or dangling refs)
6. Dev B: TX path calls skb_segment(), crashes on corrupted frag_list
Root cause in skb_segment():
The check at line ~4891:
if (hsize <= 0 && i >= nfrags && skb_headlen(list_skb) &&
(skb_headlen(list_skb) == len || sg)) {
When frag_list is corrupted by double aggregation, when list_skb is
a NULL pointer from skb->next, skb_headlen(list_skb) dereference
NULL/corrupted pointers occurs.
Call Trace:
skb_headlen(NULL skb)
skb_segment
tcp_gso_segment
tcp4_gso_segment
inet_gso_segment
skb_mac_gso_segment
__skb_gso_segment
skb_gso_segment
validate_xmit_skb
validate_xmit_skb_list
sch_direct_xmit
qdisc_restart
__qdisc_run
qdisc_run
net_tx_action
Fix: Add NAPI_GRO_CB(skb)->flush validation to the early-return check in
skb_gro_receive_list(), matching the defensive programming pattern of
skb_gro_receive().
Fixes: 3a1296a38d0c ("net: Support GRO/GSO fraglist chaining.")
Cc: stable@vger.kernel.org
Signed-off-by: Shiming Cheng <shiming.cheng@mediatek.com>
Reviewed-by: Willem de Bruijn <willemb@google.com>
Link: https://patch.msgid.link/20260709014704.3625-1-shiming.cheng@mediatek.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
During a tree-wide gpio include cleanup, the linux/gpio.h include was
replaced with linux/gpio/consumer.h.
mdio-device.c was already including that header, resulting in a
duplicated inclusion. Let's drop it.
Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20260715201213.206180-1-maxime.chevallier@bootlin.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
The ThinkPad T14 Gen 2 AMD was sold under two machine types, 20XK and
20XL, but only 20XK has been in the s2idle quirk list since the quirk
was introduced in commit 455cd867b85b ("platform/x86: thinkpad_acpi:
Add a s2idle resume quirk for a number of laptops").
On 20XL machines the firmware SMI handler therefore still runs on the
NVMe D3->D0 transition when exiting suspend-to-idle. With IOMMU
translation enabled (the default), this intermittently stalls resume
for ~10.25 seconds: seven devices across three root ports (nvme, both
xhci_hcd functions, xhci-pci-renesas, snd_hda_intel x2, snd_rn_pci_acp3x)
block in pci_pm_resume_noirq and are released simultaneously, consistent
with all cores being held in SMM.
Add the missing 20XL machine type, mirroring the existing 20XK entry.
This is the same class of omission fixed by commit 9a469c6dfab3
("platform/x86: thinkpad_acpi: Add missing T14s Gen1 type to s2idle
quirk list").
Verified on a ThinkPad T14 Gen 2a (type 20XLS41C00, BIOS R1MET62W 1.32,
kernel 6.12.95): with this entry the quirk message appears at probe and
a 14-hour suspend resumes in ~1s with no noirq stalls, where previously
even short suspends could hit the ~10s delay. A further two-day soak
(short naps and two ~14-hour suspends) showed every resume clean.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=221755
Signed-off-by: Yap Weei Choong <ywc8891@gmail.com>
Tested-by: Yap Weei Choong <ywc8891@gmail.com>
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
Link: https://patch.msgid.link/20260717060744.1252065-2-ywc8891@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
Getting ext4_group_desc structure can contribute to the cost of
ext4_mb_prefetch() without any need, as most groups fail the
!EXT4_MB_GRP_TEST_AND_SET_READ check.
Optimize ext4_mb_prefetch by getting the group description only when
necessary.
The result is further increase in performance of fallocate() system call
path that triggers ext4_mb_prefetch() via a linear group scan.
Signed-off-by: Bohdan Trach <bohdan.trach@huaweicloud.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Reviewed-by: Andreas Dilger <adilger@dilger.ca>
Link: https://patch.msgid.link/20260615100331.163997-3-bohdan.trach@huaweicloud.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
|
|
EXT4_MB_GRP_TEST_AND_SET_READ uses test_and_set_bit function which
issues an atomic write. This can cause high overhead due to cache
contention when multiple threads iterate over groups in a tight loop,
as is the case for ext4_mb_prefetch(). We have seen this to be a
problem for Kunpeng 920b CPUs which uses a single ARM LSE instruction
for this purpose.
Avoid this unconditional atomic write by testing the bit first without
changing its value. This is OK for this use case as this bit is never
unset.
This change significantly reduces costs of fallocate() operations which
trigger linear group scans on large multicore machines where
test_and_set_bit issues an atomic write operation unconditionally.
Signed-off-by: Bohdan Trach <bohdan.trach@huaweicloud.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Link: https://patch.msgid.link/20260615100331.163997-2-bohdan.trach@huaweicloud.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
|
|
Move iput(tmp_inode) after ext4_writepages_up_write() to avoid a
circular lock dependency between s_writepages_rwsem and sb_internal
(freeze protection).
The deadlock scenario:
CPU0 (EXT4_IOC_MIGRATE) CPU1 (orphan cleanup during mount)
---- ----
ext4_ext_migrate()
ext4_writepages_down_write()
s_writepages_rwsem (write)
ext4_evict_inode()
sb_start_intwrite() [sb_internal]
...
ext4_writepages()
s_writepages_rwsem (read) [BLOCKED]
iput(tmp_inode)
ext4_evict_inode()
sb_start_intwrite() [BLOCKED]
The tmp_inode is a temporary inode with nlink=0 created solely for
building the extent tree. Its eviction does not require
s_writepages_rwsem protection, so deferring iput() until after
releasing the rwsem is safe.
Reported-by: syzbot+212e8f62790f8e0bc63b@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=212e8f62790f8e0bc63b
Fixes: cb85f4d23f79 ("ext4: fix race between writepages and enabling EXT4_EXTENTS_FL")
Signed-off-by: Yun Zhou <yun.zhou@windriver.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Link: https://patch.msgid.link/20260612005330.1930804-1-yun.zhou@windriver.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
|
|
Ext4 buffered writes into large folios also pay a full buffer_head
walk in ext4_block_write_begin(). For a small overwrite of an existing
cached folio, the folio is already uptodate and the write only needs to
prepare the buffers through the written range. Walking the suffix still
makes the write_begin cost proportional to the folio size.
Before ext4 enabled large folios for regular files, the same loop was
bounded by a single page of buffers. That commit made the existing
full-folio walk visible as a regression for cached small overwrites.
The suffix walk is needed for non-uptodate folios, where ext4 may have
to submit reads for partial blocks, preserve new-buffer cleanup, and run
error zeroing. Keep those folios on the old full walk.
For already-uptodate folios, keep the walk starting at the first buffer
rather than seeking directly to from. This preserves the existing prefix
buffer state handling. Stop once block_start reaches the end of the
write range, because the skipped suffix would only repeat the
outside-range uptodate handling for buffers beyond @to.
On current master, the libMicro ext4 large-folio overwrite test shows
the following full-series result. Results are median usecs/call over 10
runs, lower is better:
case nofix this series improvement
write_u1k 1.418 0.3405 76.0%
write_u10k 1.887 0.4175 77.9%
pwrite_u1k 1.6775 0.3390 79.8%
pwrite_u10k 1.9035 0.4130 78.3%
Fixes: 7ac67301e82f0 ("ext4: enable large folio for regular file")
Cc: stable@vger.kernel.org # v6.16+
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Jia Zhu <zhujia.zj@bytedance.com>
Link: https://patch.msgid.link/20260609035202.90669-3-zhujia.zj@bytedance.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
|
|
block_commit_write() always walks every buffer_head attached to the
folio. That was cheap for order-0 folios, but large folios can contain
hundreds of buffer_heads. For a small buffered overwrite of an
already-uptodate large folio, the commit work is therefore proportional
to the folio size rather than the copied range.
This became visible with ext4 regular-file large folios, where cached
small overwrites reach block_commit_write() through block_write_end().
Before ext4 enabled large folios for regular files, this path was only
hit with order-0 folios for normal ext4 buffered writes, so the full walk
was bounded. The ext4 large-folio commit is therefore the regression
point for this generic helper cost.
The full walk is still needed when the folio is not uptodate, because
block_commit_write() uses per-buffer uptodate state to decide whether
the whole folio can be marked uptodate. Keep those folios on the old
full-buffer path.
For a folio that was already uptodate on entry, the commit no longer
needs tail buffers for folio-uptodate discovery. The copied range has
already been processed once block_start reaches @to, so stop there and
avoid the suffix walk.
Fixes: 7ac67301e82f0 ("ext4: enable large folio for regular file")
Suggested-by: Matthew Wilcox (Oracle) <willy@infradead.org>
Cc: stable@vger.kernel.org # v6.16+
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Jia Zhu <zhujia.zj@bytedance.com>
Link: https://patch.msgid.link/20260609035202.90669-2-zhujia.zj@bytedance.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
|
|
If s_inodes_per_group is not a multiple of s_inodes_per_block, the
division that computes s_itb_per_group truncates, reserving fewer blocks
for the inode table than needed.
On a crafted filesystem image, this allows __ext4_get_inode_loc() to
compute a block offset beyond the inode table, reading unrelated data as
an inode structure.
Add the missing divisibility check alongside the existing validation in
ext4_block_group_meta_init().
Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: https://sashiko.dev/#/patchset/20260608061112.392391-1-libaokun%40linux.alibaba.com
Signed-off-by: Baokun Li <libaokun@linux.alibaba.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Reviewed-by: Zhang Yi <yi.zhang@huawei.com>
Reviewed-by: Andreas Dilger <adilger@dilger.ca>
Link: https://patch.msgid.link/20260608111150.827117-4-libaokun@linux.alibaba.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
|
|
The mke2fs man page documents:
Valid cluster-size values are from 2048 to 256M bytes per cluster.
but EXT4_MAX_CLUSTER_LOG_SIZE was set to 30 (1GB), allowing crafted
filesystem images to specify cluster sizes up to 1GB.
On 32-bit systems with bigalloc enabled, the consistency check in
ext4_handle_clustersize():
s_blocks_per_group == s_clusters_per_group * (clustersize / blocksize)
can overflow when the cluster ratio is large enough. Since
s_blocks_per_group is not range-checked in the bigalloc path, the
wrapped product can pass the consistency check, leading to inconsistent
group geometry and potential out-of-bounds block allocation.
Reduce EXT4_MAX_CLUSTER_LOG_SIZE to 28 to match the documented 256MB
limit. With this cap, the maximum product is:
(blocksize * 8) * (256M / blocksize) = 2^31
which fits safely in a 32-bit unsigned long for all block sizes.
Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: https://sashiko.dev/#/patchset/20260608061112.392391-1-libaokun%40linux.alibaba.com
Signed-off-by: Baokun Li <libaokun@linux.alibaba.com>
Reviewed-by: Andreas Dilger <adilger@dilger.ca>
Link: https://patch.msgid.link/20260608111150.827117-3-libaokun@linux.alibaba.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
|
|
The block and inode bitmap checksums are computed over a whole number of
bytes: ext4_inode_bitmap_csum_*() use EXT4_INODES_PER_GROUP(sb) >> 3 and
ext4_block_bitmap_csum_*() use EXT4_CLUSTERS_PER_GROUP(sb) / 8 as the
length passed to ext4_chksum().
If s_inodes_per_group or s_clusters_per_group is not a multiple of 8, the
trailing fractional bits are excluded from the checksum. Those bits are
then unprotected, and any incremental csum update path that assumes a
byte-aligned bitmap can compute a checksum inconsistent with the full
recalculation, corrupting the on-disk bitmap checksum.
Reject such filesystems at mount time by adding the missing " & 7"
alignment checks alongside the existing range validation.
Suggested-by: Theodore Ts'o <tytso@mit.edu>
Link: https://patch.msgid.link/h3n7jlfhyna64dn5o76qxcspnhxdddcs6crpxftmy7gnl7b3sx@jenszfpcsnit
Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: https://sashiko.dev/#/patchset/20260508121539.4174601-1-libaokun%40linux.alibaba.com?part=10
Signed-off-by: Baokun Li <libaokun@linux.alibaba.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Reviewed-by: Zhang Yi <yi.zhang@huawei.com>
Link: https://patch.msgid.link/20260608111150.827117-2-libaokun@linux.alibaba.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
|
|
Pull kvm fixes from Paolo Bonzini:
"RISC-V:
- Avoid redundant allocations when allocating IMSIC page tables
- Apply SBI FWFT LOCK flag only on successful set
- Bound SBI PMU counter mask scan to BITS_PER_LONG, since on RV32 the
PMU SBI start/stop helper can only access 32 PMU counters.
- Skip TLB flush when G-stage PTE becomes valid if the Svvptc
extension is available.
- Always show Zicbo[m|z|p] block sizes in ONE_REG
- Inject instruction access fault on unmapped guest fetch
- Use raw spinlock for irqs_pending and irqs_pending_mask
- Fix Spectre-v1 in vector register access via ONE_REG
x86:
- Fixes to SEV selftests
- Once free_nested() did a VMCLEAR of shadow VMCS, there's no need to
VMCLEAR it again if the kernel is preempted and thread migration
happens
- Preserve nested TDP shadow page tables if they are used as roots,
instead of clearing them unnecessarily
- Fix use of stale data if out-of-memory happens after vendor module
reload
- Check for invalid/obsolete root *after* making MMU pages available,
because the latter can make a page invalid
- Only reset TSC Deadline Timer in apic_timer_expired on KVM_RUN"
* tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm:
KVM: x86: Only reset TSC Deadline Timer in apic_timer_expired on KVM_RUN
KVM: selftests: sev_init2_tests: Derive SEV availability from KVM
KVM: selftests: sev_smoke_test: Only run VM types the host offers
KVM: x86/mmu: Fix use-after-free on vendor module reload
KVM: x86/mmu: Preserve nested TDP shadow page tables if they are used as roots
KVM: x86: Check for invalid/obsolete root *after* making MMU pages available
KVM: nVMX: Hide shadow VMCS right after VMCLEAR
KVM: riscv: Fix Spectre-v1 in vector register access
RISC-V: KVM: Serialize virtual interrupt pending state updates
RISC-V: KVM: Inject instruction access fault on unmapped guest fetch
RISC-V: KVM: Zicbo[m|z|p] block sizes should be always present in ONE_REG
riscv: kvm: Skip TLB flush when G-stage PTE becomes valid with Svvptc
KVM: riscv: PMU: Bound counter mask scan to BITS_PER_LONG
KVM: riscv: SBI FWFT: Apply LOCK flag only on successful set
RISC-V: KVM: Avoid redundant page-table allocations in ioremap topup
|
|
prevent_memory_remove_notifier() advances pfn while scanning the requested
range for early memory. When the loop completes, pfn is at or beyond
end_pfn. Passing it to can_unmap_without_split() therefore checks a range
after the one being offlined.
Consequently, a valid request can be rejected based on the following
range, while a request that would split a leaf mapping can be accepted if
the shifted range can be unmapped without a split. This was observed with
CXL DAX memory, where the final memory block was incorrectly allowed to
be offlined.
Pass arg->start_pfn into can_unmap_without_split() so it checks the
requested range.
Fixes: 95a58852b0e5 ("arm64/mm: Reject memory removal that splits a kernel leaf mapping")
Signed-off-by: Richard Cheng <icheng@nvidia.com>
Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
Signed-off-by: Will Deacon <will@kernel.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace
Pull probes fixes from Masami Hiramatsu:
- Avoid temporary buffer truncation in match_command_args()
Compare argument name, delimiter, and comm expression directly
instead of formatting into a stack buffer to prevent false
matching failures
- Prevent out-of-bounds write in __trace_probe_log_err()
Return early when trace_probe_log.argc is zero to prevent
out-of-bounds access when constructing the formatted error
command string
- Fix potential underflow in LEN_OR_ZERO macro
Ensure buffer length is greater than current position before
subtraction to prevent unsigned size underflow when formatting
print strings
- Fix exact system name matching in eprobe_dyn_event_match()
Check system name null-termination to avoid partial prefix
matching when comparing event probe target system names
* tag 'probes-fixes-v7.2-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace:
tracing/eprobe: Fix exact system name matching in eprobe_dyn_event_match()
tracing/probes: Fix potential underflow in LEN_OR_ZERO macro
tracing/probes: Prevent out-of-bounds write in __trace_probe_log_err()
tracing/probes: Avoid temporary buffer truncation in trace_probe_match_command_args()
|
|
This reverts commit 0be5c3f0fbef3679f50f345b9237b8f9ea5de4e9.
Commit 0be5c3f0fbef ("gtp: annotate PDP lookups under RTNL") added a
lockdep_rtnl_is_held condition to hlist_for_each_rcu() loops to help
insure that RTNL is held.
Unfortunately, as pointed out by Pablo Neira Ayuso, the PDP context list
is actually protected by the genetlink mutex. And so the condition
is incorrect.
Compile tested only.
Link: https://lore.kernel.org/ak4NgOrro-4OZjz3@chamomile
Signed-off-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260708-gtp-rtnl-v1-1-218091f171bc@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Address size fault, level -1 is encoded as 0b101001 or 0x29 according to
the Arm ARM. Correct the value to match the spec. This also matches the
offset of "level -1 address size fault" in the fault_info array in
fault.c.
Fixes: fb8a3eba9c81 ("KVM: arm64: Only read HPFAR_EL2 when value is architecturally valid")
Signed-off-by: Steven Price <steven.price@arm.com>
Reviewed-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Will Deacon <will@kernel.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux
Pull btrfs fixes from David Sterba:
"I'm catching up with the fix backlog in the development branch, so
here's a number of them and will probably send one more for this or
the next rc:
- relocation fixes:
- skip attempting compression on reloc inodes
- exclude inline extents from file extent offset checks
- fix minor memory leak after error when adding reloc root
- fix root cleanup after inserting and merging
- fix clearing folio tags after writeback
- clear logging flag of extent map before splitting
- fix unsigned 32/64 type conversions when accounting dirty metadata,
leading to continually exceeding threshold
- fix regression in 32bit compat ioctl for subvolume info
- fix type of SEARCH_TREE ioctl buffer in UAPI header
- fix expression in ASSERT expression which can be unconditionally
evaluated on some compilers
- only account delalloc bytes for regular inodes"
* tag 'for-7.2-rc4-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux:
btrfs: fix GET_SUBVOL_INFO after compat refactor
btrfs: free mapping node on duplicate reloc root insert
btrfs: fix a regression where PAGECACHE_TAG_DIRTY is never cleared
btrfs: don't propagate EXTENT_FLAG_LOGGING to split extent maps
btrfs: fix u32 to s64 type conversion in dirty_metadata_bytes accounting
btrfs: fix NULL pointer deref during assertion in btrfs_backref_free_node()
btrfs: only account delalloc bytes for regular file inodes in btrfs_getattr()
btrfs: reject inline file extents item in get_new_location()
btrfs: do not try compression for data reloc inodes
btrfs: declare btrfs_ioctl_search_args_v2::buf as __u8
btrfs: fix reloc root cleanup in merge_reloc_roots()
btrfs: fix use-after-free on reloc root after error in insert_dirty_subvol()
|
|
In acpi_video_bus_check() and find_video(), simply replace
acpi_get_pci_dev() with acpi_dev_get_pci_dev() that can be used
in both places because the ACPI device needed to do the lookup is
available.
In acpi_video_dev_register_backlight(), instead of doing a parent ACPI
handle lookup based on the handle of an ACPI device that is already
available, pass that ACPI device to acpi_dev_parent() which is much
more straightforward and pass the return value of the latter directly
to acpi_dev_get_pci_dev() to get the PCI device associated with it.
That allows local variable acpi_parent to be eliminated.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://patch.msgid.link/2047771.PYKUYFuaPT@rafael.j.wysocki
|
|
Update acpi_video_dev_register_backlight() to put the parent device after
registering the backlight class device under it instead of attempting to
register the backlight class device under a parent that (theoretically)
may be gone at that point.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://patch.msgid.link/10885673.nUPlyArG6x@rafael.j.wysocki
|
|
Some acpi_get_pci_dev() callers already have a struct ACPI device for
which they want to get the struct pci_dev pointer of the associated
PCI device, so they don't need to look for one.
For this reason, add acpi_dev_get_pci_dev() that will get a PCI device
for a given ACPI one (if possible) and turn acpi_get_pci_dev() into
a static inline helper passing the acpi_fetch_acpi_dev() return value
directly to acpi_dev_get_pci_dev().
No intentional functional impact.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://patch.msgid.link/3430928.44csPzL39Z@rafael.j.wysocki
|
|
Use a mutex guard in acpi_get_pci_dev() for the physical_node_lock
locking and drop local variable pci_dev that becomes redundant after
that change.
No intentional functional impact.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Link: https://patch.msgid.link/3056272.e9J7NaK4W3@rafael.j.wysocki
|
|
The MSI Crosshair A16 HX D7WFKG has an internal digital microphone
connected through AMD ACP6x, but the system does not expose the
AcpDmicConnected ACPI property. As a result, acp_yc_mach does not bind
and no DMIC capture device is created.
Add a DMI quirk for this model. This was tested on a system with board
MS-15PL, BIOS E15PLAMS.10B, and AMD ACP6x rev 0x62. After applying the
quirk, the internal microphone appears as an acp6x DMIC capture device
and records correctly.
Signed-off-by: 郑鸿源 <spark_psc@outlook.com>
Reviewed-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com>
Link: https://patch.msgid.link/20260721-master-v1-1-6f56d5a54d96@outlook.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
acpi_pci_root_add() assigns the freshly allocated root to
device->driver_data before dmar_device_add() and pci_acpi_scan_root().
Both failure paths reach the end: label where root is kfree()'d, but
only the pci_acpi_scan_root() path clears driver_data first.
When dmar_device_add() fails during a hot-add, root is freed while
device->driver_data still points at it. The ACPI core does not clear
driver_data on attach failure, so a later acpi_pci_find_root() call may
dereference this dangling pointer.
acpi_pci_root_remove() has the same problem: it frees root without
clearing device->driver_data, leaving a dangling pointer behind after
the root bridge is removed.
Move the NULL assignment to the shared end: label so every error path in
acpi_pci_root_add() clears driver_data before freeing root, and clear it
in acpi_pci_root_remove() as well, so the object is never left reachable
through driver_data after being freed.
Fixes: db89b4f0dbab ("ACPI: catch calls of acpi_driver_data on pointer of wrong type")
Reported-by: Sashiko AI review <sashiko-bot@kernel.org>
Link: https://sashiko.dev/#/patchset/20260526025118.38935-1-cp0613@linux.alibaba.com
Link: https://sashiko.dev/#/patchset/20260707121258.11640-1-cp0613@linux.alibaba.com
Signed-off-by: Chen Pei <cp0613@linux.alibaba.com>
Link: https://patch.msgid.link/20260715135048.3278-1-cp0613@linux.alibaba.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
The IOAPIC hotplug lookup parses both MADT and _MAT records directly.
The MADT walk previously used a subtable's declared length to advance
the cursor after only locating a generic header. The _MAT path likewise
passed a generic header to the IOAPIC helper.
Validate that a current record has a complete generic header, that its
declared length is contained in the available record range, and that a
typed IOAPIC record contains the full fixed IOAPIC body before reading
its fields. Use the same relation for both MADT and _MAT provider
paths.
Fixes: ecf5636dcd59 ("ACPI: Add interfaces to parse IOAPIC ID for IOAPIC hotplug")
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
Link: https://patch.msgid.link/20260715083253.22831-1-pengpeng@iscas.ac.cn
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Tariq Toukan says:
====================
net/mlx5e: PSP cleanups and improvements
This series by Cosmin refactors mlx5 PSP support in preparation for
HW-GRO support.
There are almost no functionality changes in all but the last two
patches, which address a long-standing TODO in mlx5e_psp_set_config().
====================
Link: https://patch.msgid.link/20260707130858.969928-1-tariqt@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
mlx5e_psp_register() was forced to eat PSP dev registration errors as
the caller was not propagating them. Change this so PSP dev registration
failures get reported back to the caller instead.
After the recent changes in the series, PSP dev registration failures
will just leave some data structs in priv->psp (mostly counters), with
no steering rules and no means to configure them. There's no point
actively cleaning those up on failure, as they'll get removed during
profile->cleanup.
Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20260707130858.969928-16-tariqt@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
profile->enable is called before enabling an mlx5 netdevice and
currently doesn't return errors. Code called from it has to either:
1. eat errors and keep going, leaving a netdevice initialized with
missing functionality
or
2. manually clean up things that other parts of the init flow might have
set up.
Option 1 might be useful in some cases for optional functionality but
option 2 doesn't make for good design.
Add a 3rd option for code which wants to propagate errors from
profile->enable and fail netdev init. This change is a noop for now, the
first 'user' of this option 3 will be in the next patch.
Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20260707130858.969928-15-tariqt@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Only create PSP steering tables when PSP configuration is enabled on a
PSP device.
Previously, mlx5e_psp_set_config (== .set_config on the PSP device) did
nothing. Steering was created and hooked up to incoming traffic at
device initialization time, via mlx5e_init_nic_rx -> mlx5e_accel_init_rx
-> mlx5_accel_psp_fs_init_rx_tables. Similarly, TX tables were created
and hooked to egress traffic at mlx5e_init_nic_tx -> mlx5e_accel_init_tx
-> mlx5_accel_psp_fs_init_tx_tables
Doing this means both ingress and egress UDP packets go through the
PSP steering tables, causing extra latency and overhead.
A better solution is to let the incoming encrypted PSP packets get
dropped by SW and not impose an overhead on all UDP packets which have
to traverse the PSP steering rules when PSP isn't used.
Additionally, upcoming changes to support HW-GRO need to reconfigure PSP
steering dynamically and this patch is a necessary step in that
direction.
Two new functions are defined:
- accel_psp_fs_create: Creates steering tables and connects RX UDP v4/v6
traffic to PSP RX tables.
- accel_psp_fs_destroy: Disconnects incoming RX traffic from PSP
steering and destroys steering tables.
PSP steering cleanup, which happens independently from PSP device
configuration, is unchanged. When the device is going away, steering
tables are destroyed as well.
The netdev lock is now used for proper synchronization between the new
set_config flow and device steering init/cleanup. This will be important
in future patches, when PSP will be able to reconfigure itself
dynamically upon netdev feature changes.
Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com>
Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20260707130858.969928-14-tariqt@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
PSP steering code has two dynamically allocated structures to store RX
and TX steering structs. Remove those and flatten out everything into
the parent mlx5e_psp_fs.
The tx_counter was moved out of the TX table as well, because the table
doesn't own it, it outlives TX table destruction.
All table creation/destruction now happens in
accel_psp_fs_{rx,tx}_{create,destroy}. This will be used in subsequent
patches to make PSP configuration dynamic.
Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com>
Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20260707130858.969928-13-tariqt@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
PSP uses a check steering table per IP version, but the PSP rules are
IP-version agnostic, so there's no point duplicating these in HW.
This commit makes the rx check steering table independent of the IP
version, with the final table added in the previous patch responsible
for directing packets to the corresponding UDP TIRs (or the TTC table
itself for non-UDP traffic).
Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com>
Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20260707130858.969928-12-tariqt@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Successfully decrypted PSP traffic is currently forwarded to the UDP
v4/v6 TTC default destination from its respective PSP rx_check table.
In preparation for flattening out RX steering and for decapsulation
support (which needs to handle non-UDP traffic as well), add an RX table
which directs traffic to either the UDP v4/v6 default TTC destinations,
or back to the TTC table itself for further processing. There can be no
loops as non-UDP traffic will not go through PSP processing again.
This is now used as a destination for successfully decrypted PSP
packets. The rx_counter is also incremented there, freeing the rx_check
rule for PSP_OK for atomic destination update in a future patch.
Use this opportunity to separate RX flow table levels from IPsec, as
reusing random IPsec ft levels as PSP isn't clear and now is a good
opportunity to separate them.
Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com>
Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20260707130858.969928-11-tariqt@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
The rx_check ft was requesting max_fte == 2, but it created 4 entries.
While this accidentally works, it's not accurate, so change that and use
the correct number of entries. Also use an explicit drop_group for the
last match(*) drop rule.
Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com>
Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20260707130858.969928-10-tariqt@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
There are multiple naming inconsistencies and the code is fragmented and
hard to follow.
For example, the PSP TX steering structure is named 'mlx5e_psp_tx', but
its RX counterpart is 'mlx5e_accel_fs_psp' and its protocol
instantiation 'mlx5e_accel_fs_psp_prot', neither of which make it clear
they relate to RX.
This commit renames things to be more consistent, realigns declarations
to abide by the xmas tree rule, and merges some functions to reduce
fragmentation. Renamed:
mlx5e_accel_fs_psp -> mlx5e_psp_rx
mlx5e_accel_fs_psp_prot -> mlx5e_psp_rx_decrypt_table
fs_prot -> decrypt
accel_psp -> rx_fs
mlx5e_psp_rx_err -> mlx5e_psp_rx_check_table
mlx5e_psp_tx -> mlx5e_psp_tx_table
def_rule -> rule
Also renamed many functions with names of the form
accel_psp_fs_A_B_C_..._verb, with A->B->C->... following a
general->specific hierarchy. Full list:
accel_psp_fs_rx_err_destroy_ft -> accel_psp_fs_rx_check_ft_destroy
accel_psp_fs_rx_err_create_ft -> accel_psp_fs_rx_check_ft_create
accel_psp_fs_rx_fs_destroy -> accel_psp_fs_rx_decrypt_ft_destroy
accel_psp_fs_rx_create_ft -> accel_psp_fs_rx_decrypt_ft_create
accel_psp_fs_tx_create_ft_table -> accel_psp_fs_tx_ft_create
accel_psp_fs_tx_destroy -> accel_psp_fs_tx_ft_destroy
accel_psp_fs_{init,cleanup}_{rx,tx} ->
accel_psp_fs_{rx,tx}_{init,cleanup}
Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com>
Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20260707130858.969928-9-tariqt@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
The PSP error flow table copies the HW syndrome to metadata register B,
but this value is never used in the RX path. Bad packets (auth fail,
bad trailer) are dropped by HW via explicit drop rules before reaching
software.
Remove the syndrome copy action, the syndrome macro, and the dead
syndrome check in the RX handler.
Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com>
Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20260707130858.969928-8-tariqt@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
There are 3 rules added with the same structure. Factor out common code
into a helper function to reduce duplication.
Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com>
Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20260707130858.969928-7-tariqt@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Add helper functions for creating and destroying PSP steering objects to
reduce code duplication.
This will become more relevant in future patches which add more steering
tables/groups/flows.
One nice side-effect of this is that the cleanup functions become
idempotent and can be used instead of long goto chains. This further
simplifies the code.
Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com>
Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20260707130858.969928-6-tariqt@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
