| Age | Commit message (Collapse) | Author |
|---|
|
Adds Tunable table for XBOX ROG Ally X 20.
Signed-off-by: Derek J. Clark <derekjohn.clark@gmail.com>
Link: https://patch.msgid.link/20261018160603.65449-1-derekjohn.clark@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
fbcon_rotate_font() records the font, its geometry and the rotation in
par->rotated before calling font_data_rotate(). If the allocation
fails, the error path clears par->rotated.buf, but the recorded key
already looks up to date, so the next call takes the early-out and
never retries. The rotated putcs/cursor ops keep returning early on
the NULL buffer, and the console stays blank even after memory is
available again.
Also test par->rotated.buf in the early-out, so a failed allocation
is retried on the next call: at the next fbcon_switch(),
fbcon_modechanged() or font change.
Fixes: e4ef723d8975 ("fbcon: Avoid OOB font access if console rotation fails")
Cc: stable@vger.kernel.org
Signed-off-by: Yao Yiqi <yaoyiqi3@huawei.com>
Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Helge Deller <deller@gmx.de>
|
|
fbcon_rotate_font() caches a rotated copy of the console font in
par->rotated.buf. The buffer is sized from the font's width, height
and charcount, and is rebuilt in fbcon_init(), fbcon_switch() and
fbcon_modechanged(), but not in fbcon_do_set_font().
When the font is changed through KDFONTOP, the new geometry is
installed and vc_resize() redraws before the buffer is rebuilt. The
rotated putcs/cursor ops then index the old buffer with the new cell
size; KASAN reports a slab-out-of-bounds read in soft_cursor().
Rebuild the buffer for the visible console before the redraw, as the
other callers do: select the console's blitting state with
set_blitting_type() (which also uploads the new font's map on
tile-blitting hardware), then rebuild. Background consoles keep
their rebuild at fbcon_switch() time, as the buffer is shared per
framebuffer and must not be updated for a console that is not being
displayed.
To ensure a correct rollback when the rebuild or the following
vc_resize() fails, save the rotated font state, clear it before
rebuilding, and restore it in the error path of
fbcon_do_set_font().
Fixes: 6cc50e1c5b57 ("[PATCH] fbcon: Console Rotation - Add support to rotate font bitmap")
Cc: stable@vger.kernel.org
Signed-off-by: Yao Yiqi <yaoyiqi3@huawei.com>
Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Helge Deller <deller@gmx.de>
|
|
fbcon_rotate_font() caches a rotated copy of the console font and
skips the rebuild when the fontdata pointer and the rotation match.
Raw font data carries no geometry, though: width, height and
charcount live in vc->vc_font. fbcon_set_font() deduplicates uploads
by byte equality, so the same bytes re-uploaded with different
dimensions keep the fontdata pointer while the geometry changes, and
the early-out skips the rebuild.
The rotated cell size depends on the geometry (rotation swaps width
and height), so the stale buffer is indexed with the new cell size.
Re-uploading a 4x16 font as 16x8 on a CW-rotated console, for
example, doubles the rotated cell size and reads past the end of the
old buffer.
Record the geometry the buffer was built from and compare it in the
early-out. The pointer-only key used to be backed by an explicit
width check in the deduplication, which commit 1e3c49aa03fb
("lib/fonts: Compare font data for equality with font_data_is_equal()")
dropped.
Fixes: 6cc50e1c5b57 ("[PATCH] fbcon: Console Rotation - Add support to rotate font bitmap")
Cc: stable@vger.kernel.org
Signed-off-by: Yao Yiqi <yaoyiqi3@huawei.com>
Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Helge Deller <deller@gmx.de>
|
|
Commit 3637d34b35b2 ("fbdev: Add bounds checking in bit_putcs to fix
vmalloc-out-of-bounds") made bit_putcs() clip glyphs to var.yres. When
fbcon scrolls by panning, it draws text rows up to var.yres_virtual,
so after the first pan most new text is not drawn until the next full
redraw. This affects fbdev drivers that set FBINFO_HWACCEL_YPAN or
FBINFO_HWACCEL_YWRAP, such as vesafb with the ypan option, when
CONFIG_FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION=y.
Clip to GETVYRES() instead, which fbcon_ud.c and fbcon_ccw.c already
use as the drawing area height. When fbcon does not pan, GETVYRES()
returns var.yres, keeping the existing bound. When fbcon pans, it
returns var.yres_virtual, which the framebuffer memory must cover
anyway for panning to work.
Fixes: 3637d34b35b2 ("fbdev: Add bounds checking in bit_putcs to fix vmalloc-out-of-bounds")
Reported-by: Thomas Zimmermann <tzimmermann@suse.de>
Closes: https://lore.kernel.org/linux-fbdev/b8b52ffd-ecec-4fba-b432-ba32135c2f99@suse.de/
Tested-by: Thomas Zimmermann <tzimmermann@suse.de>
Cc: stable@vger.kernel.org
Signed-off-by: Tingjie Zhong <catme0w@live.cn>
Signed-off-by: Helge Deller <deller@gmx.de>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull x86 resource control updates from Borislav Petkov:
- Push down into arch code the rounding of bandwidth control user
values due to the different ways ARM and x86 report MBA
- Fix task reporting for the default group for systems which support
only bandwidth monitoring, aka Haswell vintage computing
- The usual fixlets and improvements
* tag 'x86_cache_for_v7.4_rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
fs/resctrl: Ensure default group reports tasks on monitor-only systems
x86,fs/resctrl: Add event group descriptions for Intel Diamond Rapids
x86/resctrl: Update documented unit for the "activity" event
fs/resctrl: Simplify pseudo_lock_measure_trigger()
fs/resctrl: Avoid extra call to strlen() in schemata_list_add()
fs/resctrl: Factor MBA parse-time conversion to be per-arch
arm_mpam: resctrl: Add pass-through resctrl_arch_preconvert_bw()
x86,fs/resctrl: Add resctrl_arch_preconvert_bw()
|
|
On MSI notebooks, several keys generate a WMI event through the Wind
event GUID in addition to a regular AT keyboard event. Their event
codes are not in the keymap, so every press logs "Unknown key
pressed".
These keys already work through the AT keyboard, so mark their WMI
codes as KE_IGNORE, as is already done for the MSI Claw. On models
where a code does not also produce a keyboard event, the event is
already dropped, so the only change there is that the log
message goes away.
The Wind event GUID is not specific to the MSI Wind. It is present in
17 of 18 MSI notebooks in the linuxhw ACPI dump collection (2012 to
2024), with the same _WED structure. The codes are shared across
models too: the volume keys on the tested notebook send the same codes
as the MSI Claw (0x21, 0x32).
Tested on an MSI Katana 15 B13VFK: Fn (0x0b), mic mute (0x19),
settings (0x1d), mute (0x23) and Bluetooth (0x78) no longer log
unknown key messages, and the keys keep working through atkbd.
Link: https://github.com/linuxhw/ACPI/tree/d6d30c6ef6f4/Notebook/MSI
Signed-off-by: Patryk Pilichowski <pat.pilichowski@gmail.com>
Link: https://patch.msgid.link/20261020141427.1580282-3-pat.pilichowski@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
The scancode enum is grouped by model, so the values are not in order
and are hard to follow. The grouping is not meaningful either, as the
same event codes are used across MSI models.
Sort the enum by scancode, give every entry an explicit value and use
lowercase hex.
No functional change.
Suggested-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Patryk Pilichowski <pat.pilichowski@gmail.com>
Link: https://patch.msgid.link/20261020141427.1580282-2-pat.pilichowski@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
hinic_xmit_frame() pads short frames with skb_pad(), then
sets skb->len directly, leaving skb->tail stale.
Use skb_put_padto(), which updates both and is a litle less confusing.
Also remove one pointless netdev_err() call.
Signed-off-by: Eric Dumazet <edumazet@kernel.org>
Link: https://patch.msgid.link/20261016093518.2756935-1-edumazet@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Replace the open-coded skb_pad() + __skb_put() sequence
in fm10k_xmit_frame() with skb_put_padto().
Signed-off-by: Eric Dumazet <edumazet@kernel.org>
Link: https://patch.msgid.link/20261016094312.2759956-1-edumazet@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Replace skb_pad() and the manual skb->len and tail pointer updates
in iavf_xmit_frame() with skb_put_padto().
No functional change.
Signed-off-by: Eric Dumazet <edumazet@kernel.org>
Link: https://patch.msgid.link/20261016094925.2762785-1-edumazet@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
In bcmasp_netfilt_get_init(), when looking up an existing filter (!init)
for a specified location, if the filter at loc was not claimed, the
previous loop continued searching higher indices and could return an
arbitrary unrelated filter belonging to the port. This caused flow get or
delete operations on an empty rule location to return or delete an
unintended filter.
Fix this by checking only the requested location on lookup and rejecting
RX_CLS_LOC_ANY when !init. In addition, harden wake filter allocation
and release by ensuring wake filter pair searches stay on even boundaries
where both entries are free, checking that loc + 1 is free for positioned
wake filters, and validating parity and bounds on release.
Fixes: c5d511c49587 ("net: bcmasp: Add support for wake on net filters")
Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
Link: https://patch.msgid.link/20261013204439.3494046-7-florian.fainelli@broadcom.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
When hardware checksum offload is enabled for an skb,
bcmasp_csum_offload() prepends a struct bcmasp_pkt_offload header
(20 bytes) to the skb via skb_push(). This increases skb->len and
skb_headlen(skb) by sizeof(struct bcmasp_pkt_offload).
Because the hardware descriptor processor strips this offload header
before transmitting the packet on the wire, the wire packet length is
smaller by sizeof(struct bcmasp_pkt_offload). The padding calculation
must account for this extra header; otherwise, short frames are sent on
the wire smaller than the minimum Ethernet frame size (ETH_ZLEN +
ETH_FCS_LEN).
Furthermore, small frames with payload in page fragments (such as small
TCP segments with CHECKSUM_PARTIAL) have nr_frags > 0 and were skipping
padding entirely because the padding check was restricted to
nr_frags == 0.
Perform the padding check on skb->len before the descriptor loop using
skb_put_padto(), adding sizeof(struct bcmasp_pkt_offload) to min_size
when checksum offload is enabled, and re-read nr_frags after padding in
case the skb was linearized.
Fixes: 490cb412007d ("net: bcmasp: Add support for ASP2.0 Ethernet controller")
Reviewed-by: Justin Chen <justin.chen@broadcom.com>
Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
Link: https://patch.msgid.link/20261013204439.3494046-6-florian.fainelli@broadcom.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
In bcmasp_interface_create(), intf->phy_dn is obtained via
of_parse_phandle() or assigned ndev_dn. of_parse_phandle() returns a
node reference with its refcount incremented, but of_node_put() was
never called on intf->phy_dn in bcmasp_interface_destroy() or the
error unwind path in bcmasp_interface_create().
Acquire a reference on ndev_dn for the fixed-link case as well so that
intf->phy_dn consistently holds a reference, and release it with
of_node_put() on teardown and error.
Fixes: 490cb412007d ("net: bcmasp: Add support for ASP2.0 Ethernet controller")
Reviewed-by: Nicolai Buchwitz <nb@tipi-net.de>
Reviewed-by: Justin Chen <justin.chen@broadcom.com>
Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
Link: https://patch.msgid.link/20261013204439.3494046-5-florian.fainelli@broadcom.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
In bcmasp_rx_poll(), the driver removes a 2-byte alignment pad and
optionally strips the ETH_FCS_LEN CRC from received packets before
passing them to eth_type_trans().
If the hardware reports a descriptor size smaller than the sum of the
2-byte pad, the Ethernet header (ETH_HLEN), and optional CRC
(ETH_FCS_LEN), subtracting the pad and CRC lengths underflows u32 len.
This adds ~4 GiB to rx_bytes statistics, while the undersized frame
reaches eth_type_trans(), which reads past skb->len into stale buffer
data.
Check that desc->size is at least (2 + ETH_HLEN + (crc_fwd ? ETH_FCS_LEN
: 0)) before proceeding to process the descriptor.
Fixes: 490cb412007d ("net: bcmasp: Add support for ASP2.0 Ethernet controller")
Reviewed-by: Justin Chen <justin.chen@broadcom.com>
Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
Link: https://patch.msgid.link/20261013204439.3494046-4-florian.fainelli@broadcom.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
When mapping an skb with fragments for transmission in bcmasp_xmit(),
if mapping fails on fragment i > 0, the error handler calls
bcmasp_clean_txcb() for previous iterations j < i. However,
bcmasp_clean_txcb() only zeroes the control block fields without
unmapping the DMA buffers, leaking the DMA mappings allocated for the
head and earlier fragments.
Call dma_unmap_single() before calling bcmasp_clean_txcb() in the error
cleanup loop.
Fixes: 490cb412007d ("net: bcmasp: Add support for ASP2.0 Ethernet controller")
Reviewed-by: Nicolai Buchwitz <nb@tipi-net.de>
Reviewed-by: Justin Chen <justin.chen@broadcom.com>
Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
Link: https://patch.msgid.link/20261013204439.3494046-3-florian.fainelli@broadcom.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
When EDPKT stats were removed in commit e9f31435ee7d ("net: bcmasp: Add
support for asp-v3.0"), the corresponding entries were removed from
bcmasp_gstrings_stats in bcmasp_ethtool.c, but the edpkt_* fields were
left at the beginning of struct bcmasp_mib_counters in bcmasp.h.
Because bcmasp_update_mib_counters() and bcmasp_get_ethtool_stats() index
into struct bcmasp_mib_counters sequentially based on the order of
bcmasp_gstrings_stats, this 16-byte offset caused ethtool to read from
shifted offsets: the first four software counters read unused fields and
reported 0, the next four software counters reported the values of
alloc_rx_skb_failed, tx_dma_failed, mc_filters_full_cnt, and
uc_filters_full_cnt, while filters_combine_cnt, promisc_filters_cnt,
tx_realloc_offload_failed, and tx_timeout_cnt were never reported.
Remove the obsolete edpkt_* fields from struct bcmasp_mib_counters so
that it aligns with bcmasp_gstrings_stats.
Fixes: e9f31435ee7d ("net: bcmasp: Add support for asp-v3.0")
Reviewed-by: Nicolai Buchwitz <nb@tipi-net.de>
Reviewed-by: Justin Chen <justin.chen@broadcom.com>
Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
Link: https://patch.msgid.link/20261013204439.3494046-2-florian.fainelli@broadcom.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
The timeout worker calls the driver's close and open methods without
RTNL or a running-state check. A timeout queued before an interface is
closed can call close again after ndo_stop has disabled NAPI. The second
napi_disable() can then wait indefinitely. The worker can also race with
an ongoing close.
Take RTNL and skip recovery when the interface is no longer running.
Use the netdev core close and open helpers so a failed reopen leaves the
interface down, rather than leaving it marked running with NAPI disabled.
After unregister_netdev() has stopped the watchdog, drain the worker
before releasing its MDIO and descriptor resources. This wait is outside
RTNL, allowing an already queued worker to take RTNL, observe the down
state, and finish.
This issue was identified as part of our ongoing research while
reviewing kernel code.
Fixes: 57c5bc9ad7d7 ("net: hisilicon: add hix5hd2 mac driver")
Co-developed-by: Ijae Kim <ae878000@gmail.com>
Signed-off-by: Ijae Kim <ae878000@gmail.com>
Signed-off-by: Myeonghun Pak <mhun512@gmail.com>
Reviewed-by: Jijie Shao <shaojijie@huawei.com>
Link: https://patch.msgid.link/179203116093.2621539.3718842986255459438.G202@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
RTL8211F and RTL8211F-VD both use rtl8211f_config_rgmii_delay() during
initialization and share rtl821x_resume(). The RTL8211F-VD loses its
RGMII TX and RX delay enable bits across a software power-down, but the
shared resume path only clears BMCR_PDOWN and waits for the receive clock
to stabilize.
On a BeagleV Ahead configured for rgmii-id, carrier and the negotiated
speed return after an interface close/open, but the receive path does not
work. At 100 Mbit/s no frames were received. At 1000 Mbit/s all 11
observed frames had CRC errors.
Reapply the RGMII delay configuration after the existing resume delay.
Tested on a BeagleV Ahead with an RTL8211F-VD at 100 and 1000 Mbit/s,
including close/open without a link partner.
Fixes: bb726b753f75 ("net: phy: realtek: add support for RTL8211F(D)(I)-VD-CG")
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
Link: https://patch.msgid.link/20261015045001.83986-1-kmehltretter@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
qede_flow_spec_to_rule() declares a netlink_ext_ack on the stack
without initializing it. qede_parse_flow_attr() and
qede_flow_spec_validate() only set extack._msg on error paths via
NL_SET_ERR_MSG_MOD(), so on a successful parse the err_out block
reads an uninitialized pointer. If that garbage happens to be
non-NULL, DP_NOTICE("%s", extack._msg) dereferences it inside
vsnprintf, causing a page fault and kernel panic.
This manifests when configuring ethtool ntuple flow rules (ethtool -U
flow-type tcp4/udp4) on kernels built with CONFIG_INIT_STACK_NONE=y.
With CONFIG_INIT_STACK_ALL_ZERO=y the bug is masked because the
compiler zero-initializes extack, making _msg NULL.
Reproduced on RHEL 9.8 (kernel-5.14.0-687.47.1.el9_8) and mainline
(v7.3-rc6) with the following reproducer:
IFACE=ens2f0
ip link set $IFACE up
ethtool -K $IFACE ntuple on
for i in $(seq 1 100); do
ethtool -U $IFACE flow-type udp4 src-ip 192.168.2.$i action -1
done
The loop panics reliably after 10-15 iterations with:
BUG: unable to handle page fault
RIP: string+0x49/0xd0
Call Trace:
vsnprintf
qede_flow_spec_to_rule+0x2b6/0x4b0 [qede]
qede_add_cls_rule
ethtool_set_rxnfc
Zero-initialize extack so _msg is NULL unless explicitly set by an
error path.
Fixes: eb705d734525 ("net: qede: use faked extack in qede_flow_spec_to_rule()")
Signed-off-by: Anirudh Virdi <avirdi@redhat.com>
Reviewed-by: Asbjørn Sloth Tønnesen <ast@fiberby.net>
Reviewed-by: Daniel Machon <daniel.machon@microchip.com>
Link: https://patch.msgid.link/20261013105451.201211-1-avirdi@redhat.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
hash_del_rcu() only unlinks the node; a reader that already holds the
bucket iterator still uses the node. The immediate kfree() has no
grace period, so a concurrent transmit on a socket whose skb priority
carries the deleted classid reads node->classid / node->qid from freed
memory (use-after-free in the softirq transmit path).
Fix this by calling synchronize_net() before the node is freed, as
mlx5e does.
Found during a static-analysis-assisted audit: candidate sites were
surfaced by a Coccinelle rule, and the reader/writer paths were
confirmed by LLM-assisted (GLM-5.3) code inspection. The issue was
not observed at runtime; it is identified by code inspection only.
Fixes: 5e6808b4c68d ("octeontx2-pf: Add support for HTB offload")
Signed-off-by: Binbin Deng <18983559317@163.com>
Reviewed-by: Ratheesh Kannoth <rkannoth@marvell.com>
Link: https://patch.msgid.link/20261014064204.291688-1-18983559317@163.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull x86 boot updates from Borislav Petkov
- Rework the early decompressor some and drop the version of panic()
there which used vsnprintf() supplied by the EFI stub even in legacy
boot cases, where the EFI stub is not present (Ard Biesheuvel)
- Fix unbootable VMs with CONFIG_PVH=y and CONFIG_KASAN_GENERIC=y where
the compiler decides not to inline __builtin_{memcmp,memset}(). Force
the inlining with the kernel's own __inline_* versions (Mauricio
Faria de Oliveira)
- Cleanups and fixlets
* tag 'x86_boot_for_v7.4_rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86/boot: Drop unused implementation of panic()
x86/boot: Move unaccepted memory handling out of the decompressor
x86/tdx: Share tdx_panic() with the EFI stub
x86/pvh: Really inline memcmp() and memset() to fix unbootable VMs
x86/asm: Group inline string functions
x86/asm, x86/boot: Carve out inline memcmp() into a separate header
x86/boot: Remove redundant "cc" clobber in memcmp() and document it
x86/boot: Use BASE_BAUD and DEFAULT_SERIAL_PORT
|
|
axienet_start_xmit_dmaengine() bumps lp->tx_ring_head before
skb_to_sgvec(), dma_map_sg() and device_prep_slave_sg(), and none of
their error paths undo it. The skb is freed and nothing is submitted,
but the slot stays claimed. axienet_dma_tx_cb() walks tx_ring_tail
once per completion, so the next completion lands on the abandoned slot
and dereferences whatever skb pointer is left there: NULL if the slot
was never used or was already completed, or a stale skb that gets
consumed a second time. Every completion after that is accounted
against the wrong slot.
dma_map_sg() and device_prep_slave_sg() can fail at runtime, and so can
skb_to_sgvec() on a malformed skb. Only advance tx_ring_head once
those have succeeded. The completion callback can't run before
dmaengine_submit(), so claiming the slot just before that is fine.
dmaengine_submit() itself can also fail on xilinx_dma after a channel
error, and its return isn't checked either. That's a separate problem
and isn't changed here.
This was found by the Sashiko AI review of the skbuff BUG_ON() series.
Cc: stable+noautosel@kernel.org # LLM report + LLM fix, untested
Fixes: 6a91b846af85 ("net: axienet: Introduce dmaengine support")
Link: https://lore.kernel.org/all/20261007-b4-skbuff-bug-on-v2-0-b9a5f732895b@toxicpanda.com/
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20261013-b4-axienet-dmaengine-ring-head-v1-1-7add24e74477@toxicpanda.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
In mtk_wed_wo_queue_refill(), the entry->buf is DMA mapped with length
q->buf_size which saved in entry->len. However, in mtk_wed_wo_dequeue(),
the same buffer is DMA unmapped with length buf_len which is set to
SKB_WITH_OVERHEAD(q->buf_size).
Change the size to q->buf_size.
This was discovered with static analysis and was only compile-tested.
Cc: stable+noautosel@kernel.org # LLM report + LLM fix, untested
Fixes: 799684448e3e ("net: ethernet: mtk_wed: introduce wed wo support")
Signed-off-by: Thomas Fourier <fourier.thomas@gmail.com>
Acked-by: Lorenzo Bianconi <lorenzo@kernel.org>
Link: https://patch.msgid.link/20261015140110.41988-2-fourier.thomas@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
veth_newlink() creates the peer netdev from tbp, which points at the
nested VETH_INFO_PEER attributes when they are supplied (peer_tb) and
only aliases the primary device's tb otherwise. However the queue
reduction is gated on the primary device's attributes:
err = veth_init_queues(peer, tb);
veth_init_queues() checks !tb[IFLA_NUM_{TX,RX}_QUEUES], so for the peer
it inspects the wrong attribute set whenever nested peer attributes are
used:
- If the user requests IFLA_NUM_TX/RX_QUEUES only for the peer, tb
carries no such attribute and veth_init_queues() still shrinks the
peer's real_num_{tx,rx}_queues back to 1, silently dropping the
user's explicit multi-queue request for the peer.
- If the user requests the counts only for the primary device, the
peer keeps nr_possible_cpus real queues instead of the legacy
default of 1.
Pass tbp so the peer's queue count is decided from the peer's own
attributes. When no nested peer attributes are given tbp aliases tb, so
the common case is unchanged.
Cc: stable+noautosel@kernel.org # never worked, high regression risk
Fixes: 9d3684c24a52 ("veth: create by default nr_possible_cpus queues")
Signed-off-by: Li RongQing <lirongqing@baidu.com>
Link: https://patch.msgid.link/20261014013620.2497-1-lirongqing@baidu.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
In xgene_enet_refill_bufpool(), the skb->data is dma-mapped with length
len which is set to XGENE_ENET_STD_MTU which equals 1536. However, in
xgene_enet_delete_bufpool(), the same buffer is unmapped with length
XGENE_ENET_MAX_MTU which is 9600. This may erroneously unmap other
DMA buffers or cause other issues.
Change unmap length to XGENE_ENET_STD_MTU.
Cc: stable+noautosel@kernel.org # LLM report + LLM fix, untested
Fixes: a9380b0f7be8 ("drivers: net: xgene: Add support for Jumbo frame")
Signed-off-by: Thomas Fourier <fourier.thomas@gmail.com>
Reviewed-by: Daniel Machon <daniel.machon@microchip.com>
Link: https://patch.msgid.link/20261015124547.29996-2-fourier.thomas@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Qualcomm/Sierra SDX55/SDX65 modems withhold unsolicited AT result codes
(URCs such as +CREG, and the +DMI OMA-DM/LwM2M session indications) on
an AT port until the host asserts DTR. mhi_wwan_ctrl exposed the AT
(DUN) ports but had no way to signal DTR, so URCs never reached
userspace.
Carry the host serial-control lines to the modem over the dedicated
IP_CTRL MHI channel, which this module now also binds. IP_CTRL uses a
separate mhi_driver with its own callbacks so the AT/QMI/MBIM data path
is untouched; the control-channel device for each MHI controller is
tracked in a small registry so an AT port drives the IP_CTRL channel of
its own modem (multiple modems are supported).
The IP_CTRL channel has to be declared in the controller's channel config
for this driver to bind. For the Sierra EM919x/EM929x this is done by
commit 83c29a55b89e ("bus: mhi: host: pci_generic: Add IP_CTRL channel
for Sierra EM919x/EM929x") in the MHI tree. On controllers that do not
declare IP_CTRL the driver does not bind and ->dtr_rts is a no-op.
The wwan core, with "net: wwan: core: propagate modem control signals to
port drivers", raises DTR/RTS on first open and drops them on last close
(if HUPCL is set) for any AT port whose driver implements ->dtr_rts, so
no open/close handling is needed here. The new ->dtr_rts op lets
userspace assert or de-assert them via TIOCMSET/TIOCMBIC/TIOCMBIS.
Received device->host serial state messages are silently discarded; a
single recycled sink buffer keeps the IP_CTRL DL ring live so the
modem's transmit path does not stall.
->dtr_rts is void, following the tty_port_operations model it is
modelled on. It records the requested state and schedules a per-port
work item that sends the latest state to the modem, so a burst of
changes is coalesced into one message and cannot fill the IP_CTRL UL
ring. If a send fails because the ring is full or memory is short, the
work retries shortly with whatever state is latest by then, so the modem
ends up with the final state that was requested. The DL sink buffer is
requeued from a work item, which retries a transient -ENOMEM so the DL
ring does not stay empty, and which remove() disables before tearing
down the channel.
Signed-off-by: Peter Hunt <peter.hunt@opengear.com>
Reviewed-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
Link: https://patch.msgid.link/20261013183500.261229-3-peter.hunt@opengear.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
The WWAN character device emulates the TTY modem-control ioctls
(TIOCMGET/TIOCMSET/TIOCMBIC/TIOCMBIS) for AT and QCDM ports, but the
result is only stored in port->at_data.mdmbits and never reaches the port
driver. A driver therefore cannot act on the host raising or dropping
DTR/RTS, even though some modems depend on it (e.g. they withhold
unsolicited AT result codes until the host asserts DTR).
Add an optional ->dtr_rts(port, mdmbits) operation to struct wwan_port_ops.
Drivers that implement it receive the TIOCM output bitmask so they can
assert or de-assert DTR and RTS independently. As in tty_tiocmset(), the
wwan core keeps only the output bits (DTR, RTS, OUT1, OUT2, LOOP) of the
TIOCMSET/TIOCMBIS/TIOCMBIC value in port->at_data.mdmbits, and calls
->dtr_rts when DTR or RTS actually changes, gated on WWAN_PORT_AT to match
the open/close raise/drop behaviour.
Also raise DTR/RTS in wwan_port_op_start on first open of an AT port
when the driver implements ->dtr_rts, and drop them in wwan_port_op_stop
on last close if HUPCL is set in the port's termios. This follows TTY
open/close semantics, although the termios baud rate is not used, and
means individual drivers do not need to implement this themselves. As on
a TTY, HUPCL defaults to on for AT ports, and userspace can clear it
with TCSETS to keep DTR asserted across close, for example so that
closing the port does not end a call on a modem set to AT&D1/AT&D2.
TCSETS and TCSETS2 now only commit the new termios when the copy from
userspace succeeds, so a faulting call cannot silently clear HUPCL.
->dtr_rts must be called under ops_lock, which serialises port ops and
protects against port removal (removal clears port->ops under it). So
that updates to the TIOCM state and the ->dtr_rts calls are serialised
together, the termios/TIOCM state now also lives under ops_lock and the
separate data_lock is removed. The AT/QCDM ioctl handler only holds
ops_lock while it reads or updates that state, never across a
user-memory copy, and takes it interruptibly since a driver's blocking
write holds it while it waits. Ioctls that do not touch that state, such
as TCFLSH, TIOCEXCL and the FIONREAD fallback, do not take it.
wwan_remove_port() also drops DTR/RTS before ->stop() when a port is
removed while still open, regardless of HUPCL since the device is going
away. The raise and drop paths go through two small helpers, which do
the AT port and ->dtr_rts checks and pass the driver the resulting
bitmask.
Signed-off-by: Peter Hunt <peter.hunt@opengear.com>
Reviewed-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
Link: https://patch.msgid.link/20261013183500.261229-2-peter.hunt@opengear.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
efx_tc_flower_replace_foreign() walks the rule's actions with an 'act'
cursor. After a redirect action it adds the action set to the rule and
sets the cursor to NULL:
list_add_tail(&act->list, &rule->acts.list);
act = NULL;
if (fa->id == FLOW_ACTION_REDIRECT)
break; /* end of the line */
The break only leaves the switch statement, so flow_action_for_each()
carries on with the next action while act is NULL. A following redirect
or mirred action then does "save = *act", and a following tunnel decap
action passes act to efx_tc_flower_action_order_ok(), which reads
act->decap. Both dereference a NULL pointer.
The loop is missing the check that efx_tc_flower_replace() performs at
the start of every iteration for the same cursor: reject the rule if an
action follows a non-pipe action. The foreign variant was added without
it.
As a result, a TC flower rule on a tunnel netdevice that redirects to an
sfc representor and lists another redirect, mirred or tunnel decap
action after the first redirect causes a kernel NULL pointer
dereference. It happens in the context of the task adding the filter,
with efx->tc->mutex held. Adding such a rule requires CAP_NET_ADMIN.
Add the same check at the top of the action loop in
efx_tc_flower_replace_foreign(), returning -EINVAL with the same extack
message as efx_tc_flower_replace(). The release path already copes with
act being NULL.
Cc: stable+noautosel@kernel.org # LLM report + LLM fix, untested
Fixes: 17654d84b47c ("sfc: add offloading of 'foreign' TC (decap) rules")
Signed-off-by: Rand Deeb <rand.sec96@gmail.com>
Acked-by: Edward Cree <ecree.xilinx@gmail.com>
Link: https://patch.msgid.link/20261014145800.726-1-rand.sec96@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
skb_unshare() only copies cloned skbs. A shared skb that is not a clone
comes back unchanged, which the name doesn't suggest. The loopback
selftest hooks got caught by this and hit BUG_ON(skb_shared()).
Rename it to skb_unclone_full(). Like skb_unclone() it only acts on
clones, but it copies the whole skb, not just the head.
Suggested-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Nicolai Buchwitz <nb@tipi-net.de>
Reviewed-by: Ioana Ciornei <ioana.ciornei@nxp.com> # dpaa2
Link: https://patch.msgid.link/20261015-nb-skb-unclone-full-v1-1-0dfbf01f60f2@tipi-net.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/ras/ras
Pull EDAC updates from Borislav Petkov:
- Orphan several EDAC drivers: i82975x, x38, xgene, i3200. Those have
been receiving just drive-by updates and no one really uses them. At
least there are no traces of usage on the mailing lists. So, with the
advent of AI-generated fixes frenzy, and because no one can really
test fixes on those, it is time to sunset them and point them towards
the eternal happy hunting-grounds
- Add a dummy EDAC driver with which the EDAC core glue can be
exercised in a VM for the cases where one does not necessarily have
access to the hardware. This glue should be extended with all the
necessary functionality that needs and can be tested this way
- Add an EDAC driver to reset bitfix filters in Intel hardware. Bitfix
filters are a hw mechanism for tracking stuck bits in memory and CPU
arrays due to, e.g., silicon aging. Those filters can become clogged
by transient errors accumulating over a long system uptime so this
intel-bff (LOL :)) driver glue resets those filters on overflow. Work
by Qiuxu Zhuo and Tony Luck
- Export get_cpu_cacheinfo_id() for use by the new intel-bff driver
- i10nm: Handle the case where hw disables memory controllers which
leads to reporting the wrong memory controller when reporting an
error
- The now-usual AI-powered fixes and other misc cleanups and updates
all over the place
* tag 'edac_updates_for_v7.4_rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/ras/ras:
MAINTAINERS: Orphan drivers/edac/i3200_edac.c
EDAC/skx_base: Fix ambiguous bitwise and logical operator style
EDAC/i10nm: Fix mdev reference leak in i10nm_get_ddr_munits()
MAINTAINERS: Orphan drivers/edac/xgene_edac.c
MAINTAINERS: Orphan drivers/edac/x38_edac.c
MAINTAINERS: Orphan drivers/edac/i82975x_edac.c
EDAC/dummy: Add a dummy EDAC driver
EDAC/ie31200: Disable PCI device when probing fails
EDAC/{bluefield,loongson}: Use named initializers for acpi_device_id
MAINTAINERS: Update Qiuxu Zhuo's email address
EDAC/intel-bff: Report frequent filter overflows
EDAC/intel-bff: Compute unique ID for overflowed filter
EDAC/intel-bff: Reset bitfix filter when it overflows
EDAC/intel-bff: Add Diamond Rapids support
EDAC/intel-bff: Add stub Intel bitfix filter driver
x86/mce: Add enumeration for Intel bitfix filter reset
cacheinfo: Export get_cpu_cacheinfo_id() for loadable modules
EDAC/i10nm: Fix Granite Rapids ADXL MC mapping
|
|
anslcd_write() checks the user buffer with access_ok() and then reads it
one byte at a time with __get_user(), writing each byte to the LCD in
between. The ANSLCD_SENDCTRL ioctl does the same with the ioctl
argument, but with no access_ok() at all, so on architectures where
__get_user() does not check the address it will read from any address it
is given.
Use get_user() in both places. The ignored return values stay as they
were: a fault still reads as zero, which ends the SENDCTRL loop.
This is part of getting rid of __get_user() and __put_user() entirely.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
write_block() reads the user buffer one byte at a time with __get_user()
while programming and then verifying the flash, relying on the
access_ok() done in flash_write(). Each __get_user() enables and
disables user access on its own anyway, so the separation saves nothing.
Use get_user().
This is part of getting rid of __get_user() and __put_user() entirely.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
execbuffer prefaults the relocation array and reads timeline fence
values one element at a time with __get_user(), after checking each
array with access_ok() up front. Each of those accesses enables and
disables user access on its own, so the up-front check saves nothing.
Both run with no object locks held: the prefault between dropping and
retaking the ww locks, the fence parsing before the ww context exists.
Use get_user(). The access_ok() checks stay, since they also decide how
a bad array fails.
The gem mman selftests use the unchecked variants on addresses they got
from their own mmaps, with no check at all. Convert those too.
This is part of getting rid of __get_user() and __put_user() entirely.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
The execbuffer relocation fast path writes each updated presumed_offset
back to the user's relocation array with __put_user(), ignoring any
failure. It does that while holding the objects' dma_resv locks, and
with page faults enabled unless the relocation cache happens to have an
atomic mapping active. So if that write faults, for example on a
copy-on-write page after a fork(), the fault handler takes mmap_lock
under dma_resv. That is the opposite of the order the i915 fault
handler uses, which takes the object lock under mmap_lock.
The comment above it claimed this could not happen, because "we did
previously check if the relocations were writable (access_ok)".
access_ok() is purely a range check. The comment dates from when this
was access_ok(VERIFY_WRITE), and that only ever made a difference on the
original i386, whose write-protect bit did not stop supervisor writes.
So nothing has made sure the array was writable for decades.
Do the write with page faults disabled, and if it fails, fall back to
the slow path exactly as we already do when reading the relocations
fails part-way through. We cannot just ignore the failure: the object
has already been relocated, and a stale presumed_offset could later
match again and skip a relocation that is needed. The slow path
prefaults and retries. If the write still fails, it copies the
relocations and marks every presumed_offset invalid with faults allowed
and no locks held, which breaks copy-on-write as needed.
One user-visible change: a relocation array in genuinely read-only
memory used to get through the fast path, silently losing the
presumed_offset updates. It now gets -EFAULT from the slow path, as it
already did whenever anything else sent execbuffer there. The uapi has
the kernel updating presumed_offset, so the array is expected to be
writable.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
gntdev_copy() updates per-segment status words with __get_user() and
__put_user(). privcmd writes back mmap batch errors and the resource
frame count with __put_user(). The pointers were validated earlier,
away from the accesses: by a copy_from_user() of the enclosing
structure, or by an access_ok() on the whole array before a callback
walks it. Each access enables and disables user access on its own
anyway, so the separation saves nothing.
Use get_user() and put_user().
This is part of getting rid of __get_user() and __put_user() entirely.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
getu16_iotlb() and putu16_iotlb() use __get_user() and __put_user() when
the IOTLB maps to user virtual addresses. Nothing nearby checks the
translated address: that relies on the mapping having been validated
against the user's VMAs when it was set up.
Use get_user() and put_user(), which do the same single, untorn access
and also check the address. The only atomic-context use, the vdpa
simulators' notification check, now disables page faults around it, so
the might_fault() in the checked accessors stays quiet there.
This is part of getting rid of __get_user() and __put_user() entirely.
Tested-and-acked-by: Michael S. Tsirkin <mst@redhat.com>
Fixes: 42823a871fd4 ("vringh: support VA with iotlb")
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
When vdpa_sim runs with use_va (the default), its rings live in user
memory, and vringh reads the ring's flags and event index with
__get_user() through the user address. The net and block simulators
call vringh_need_notify_iotlb() with bottom halves disabled, so those
reads happen in atomic context.
That only works today because __get_user() has no might_fault() check: a
fault is not handled in atomic context and simply comes back as -EFAULT.
Make that explicit with pagefault_disable() around the call, so vringh
can use the normal user accessors without complaint. Only the
notification check needs this: the rest of the ring processing runs in
the same kthread without bottom halves disabled, and can fault normally.
Tested-and-acked-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux
Pull arm64 updates from Catalin Marinas:
"Here are the arm64 updates for 7.4.
The more interesting bits are the removal of big-endian kernel support
(already marked BROKEN for some time), preemptible this_cpu_*()
operations and MPAM support for the firmware-backed (Fb) interface.
CCA (Arm's confidential compute) is slowly trickling in with host RMI
(Realm Management Interface) support and some refactoring, including a
dedicated SMCCC bus to advertise firmware services. There are also the
usual PMU updates for new hardware and a few fixes/cleanups.
Core features:
- Remove big-endian kernel support: CONFIG_CPU_BIG_ENDIAN has
depended on BROKEN for a while, so drop the remaining code (BE
hypervisor object, BPF JIT, assembly/crypto/library routines,
endianness helper macros, selftests) and force a little-endian
build
- Add preemptible this_cpu_*() operations (read/write, RMW, xchg,
cmpxchg and cmpxchg128) that no longer need to disable preemption
around the per-CPU address generation and access
- Preparation patches for implementing CONFIG_HOTPLUG_PARALLEL on
arm64
Memory management:
- Treat faults taken by EFI runtime firmware as kernel faults
- Clear PTE_WRITE for EFI_MEMORY_RO mappings (with hardware dirty
state management enabled, this is not truly read-only)
- Raise the default ARCH_MMAP_RND_BITS for 48-bit and 52-bit VA
configurations (28/26/24 bits for 4K/16K/64K pages)
- Implement clear_page[s]() using memset()
- Enable BBML2 no-abort (a.k.a. BBML3) for the NVIDIA Rigel CPU
Perf and PMU:
- Support for HiSilicon's ITS PMU
- Add support for some new events: INST_SIMD_ALU_VEC for Apple PMUs
and a cycle counter for the latest version of HiSilicon's MN PMU
hardware
- A bunch of fixes to the CXL PMU driver to address pre-existing
issues from Sashiko
- Fix generation of PERF_RECORD_ITRACE_START records for SPE and ETM
drivers
- Reduce excessive stack consumption in the Marvell DDR PMU driver
- Minor driver updates and cleanups all over
Arm Confidential Compute Architecture (CCA):
- Add an Arm SMCCC bus for firmware services discovered through SMCCC
and move the TRNG and CCA guest (TSM provider) drivers onto it,
removing the dummy CCA platform device and adding a sysfs ABI for
Realm guests
- Move the Realm Service Interface (RSI) code out of arch/arm64/ into
drivers/firmware/arm_rmm/
- Add the host side of the Realm Management Interface (RMI): detect,
configure and activate the RMM, add SRO support and wrappers for
the Realm RMI commands
- Block hibernation (new arch hook in the PM core) and kexec while
the RMM is active. To be revisited in the future with proper
support for deactivation
- Handle Granule Protection Faults (GPFs) taken by the host, caused
by accesses to memory delegated to the RMM. In a future patch, the
exception table lookup will be limited to is_kdump_kernel() cases
MPAM (Memory Partitioning And Monitoring):
- Add support for the MPAM firmware-backed (Fb) interface, allowing
MSC accesses to be mediated by firmware
- Fix a list of theoretical issues with the driver (MSC access error
propagation, MBWU monitor save/restore and locking, resctrl class
handling, error interrupt restore, maximum number of PARTIDs)
- Add the mailing list and a missing file to the MAINTAINERS entry
- Document when to set arm64.nompam
Errata and CPU features:
- Add the NXP i.MX8QM/8QP workaround for the Cortex-A53 cache
coherency issue (ERR050104), using a new ARM64_CPUCAP_SOC_ERRATUM
capability type for SoC-level errata
Miscellaneous:
- Mask debug exceptions (DAIF) around the hardware breakpoint
register manipulations when called from generic kernel code
- Don't zero the SVE state buffer when the SVE state is live
- Return -EPERM instead of -EBUSY from the GCS prctl() locking
failures (matching x86), with the selftest updated. Slight ABI
change but no software deployment yet
- kselftest: fix unsound MTE fault skipping by introducing MTE-safe
memory accessors, avoid copying each signal test binary more than
once
- Update sysreg definitions (fix three enum values and two field
names, mark architecturally dropped fields as RES0) and remove the
TME transaction state check from the BRBE driver
- Fix the description of ARM64_HAS_LPA2 and remove a redundant
ID_AA64MMFR0 define"
* tag 'arm64-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: (144 commits)
arm64: cpufeature: Enable BBML2 for NVIDIA Rigel
arm64: cputype: Add NVIDIA Rigel definitions
arm64: raise default ARCH_MMAP_RND_BITS for 48-bit and 52-bit VA
arm64/debug: mask debug exceptions when called from common code
kselftest/arm64: signal: copy each test binary only once
kselftest/arm64: Check for -EPERM not -EBUSY in the locking test
arm64: gcs: Return -EPERM not -EBUSY for prctl() locking failures
perf: arm_brbe: Remove the check for TME transaction states
arm64: sysreg: Mark fields the architecture dropped as RES0
arm64: sysreg: Fix the names of two misspelt fields
arm64: sysreg: Fix three incorrect enum values
arm64: smp: Defer RCU registration during secondary CPU bringup
arm64: smp: Don't bother printing the I-cache policy for each CPU
arm64: smp: Defer update of secondary CPU capabilities
arm64: smp: Tidy up cpuinfo init and cpufeature updates
arm64: smp: Tidy up smp_prepare_cpus()
arm64: cpufeature: Store every ID register with its overrides applied
arm64: cpufeature: Read MPAMIDR_EL1 in __cpuinfo_store_cpu()
arm64: cpufeature: Add read_cpuid_with_overrides()
arm64: cpufeature: Check arm64_ftr_regs[] before the first store
...
|
|
reserve_mem_limit() computes available VRAM as
vram_size - reserved - vram_pin_size - kfd.vram_used
However, kfd.vram_used already includes BOs that are later pinned.
Pinning does not consume extra VRAM. Subtracting
vram_pin_size counts those bytes twice and causes fake-OOM
while VRAM is still free.
Reuse get_available_memory() in reserve_mem_limit(). Move
ALIGN_DOWN to the ioctl so the userspace ABI is unchanged. The
VRAM counter is a parameter: the ioctl passes vram_used_aligned[],
the gate passes vram_used[] so a 4K BO is not charged 2MB.
kfd.vram_pinned is only updated in gpuvm_pin_bo(). dma-buf pin
calls amdgpu_bo_pin() only, so the counter stays zero. Update it
from amdgpu_bo_pin() through a KFD helper, on first pin and last
unpin, matching vram_pin_size.
Track per-XCP pins in vram_pin_size_xcp[] and kfd.vram_pinned[].
Pins that are not owned by a single partition go to
vram_pin_size_common, which every partition subtracts.
A KFD VRAM BO always carries a partition, so the KFD credit is only
correct for xcp >= 0. Call the helper for both branches and let it
warn once and skip if that ever stops holding: without the credit the
BO would be subtracted through vram_pin_size_common and never added
back, which is the double counting this patch removes, and
kfd.vram_pinned[] would be indexed out of bounds.
Suggested-by: Philip Yang <Philip.Yang@amd.com>
Signed-off-by: Zhen Han <Zhen.Han@amd.com>
Reviewed-by: Mukul Joshi <mukul.joshi@amd.com>
Reviewed-by: Lijo Lazar <lijo.lazar@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 894cbb31c50e3cf49657130396bbf6c0475304e4)
Cc: stable@vger.kernel.org
|
|
amdgpu_vm_make_npa() builds the UALink NPA VM on top of
amdgpu_vm_make_compute(), which unconditionally sets need_tlb_fence.
That flag makes amdgpu_vm_tlb_flush() queue an asynchronous PASID based
TLB invalidation after every page table update.
The NPA VM is created by the driver itself in
amdgpu_ualink_manager_start() and never gets a PASID assigned, so
vm->pasid stays 0, which MES cannot resolve on the MMHUB. The invalidation
never completes and MES stays unresponsive for the rest of the probe:
amdgpu: MES(0, 0) failed to respond to msg=INVALIDATE_TLBS
The invalidation is not needed in the first place. An NPA VM is bound to
the reserved NPA VMID and amdgpu_ualink_flush_tlb() already invalidates
that VMID on the MMHUB after every mapping change. Clear need_tlb_fence
for NPA VMs.
Fixes: e05a54573df7 ("drm/amdgpu: Pin page tables in NPA VMs")
Signed-off-by: Horatio Zhang <hongkun.zhang@amd.com>
Reviewed-by: Felix Kuehling <felix.kuehling@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit e419e52cad769df45f496b7621841b25b63235da)
|
|
Pinned objects that are not kfd objects reduce the total vram available
to kfd, so we subtract the total size of pinned objects from kdf vram
availability. However this double counts objects pinned by kfd itself,
because they are counted both as used and pinned. So track the total
size of objects pinned by kfd and add it back to kfd availability to
remove the double accounting.
Signed-off-by: Daniel Phillips <daniel.phillips@amd.com>
Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit b8257bdb26ca5d9a75f4b81f629422f17afa221b)
Cc: stable@vger.kernel.org
|
|
13.0.0/smu 14.0.2
PMFW interprets OverDriveTable.FeatureCtrlMask as the complete set of
overdrive features that are currently overridden, not as a delta
describing the operation at hand. On import it resets every feature
whose bit is clear back to its default value - for the VF curve that
means zeroing VoltageOffsetPerZoneBoundary[] outright.
The driver assumed the opposite. smu_v14_0_2_od_edit_dpm_table() clears
the mask after a successful commit, so a subsequent above-default
power1_cap write goes through smu_v14_0_2_set_ppt_limit() and uploads a
table carrying only PP_OD_FEATURE_PPT_BIT. PMFW then drops the user's
voltage offset and reverts to the stock V/F curve, while the driver's
cached user table still reports the offset through pp_od_clk_voltage.
Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/5935
Signed-off-by: Kenneth Feng <kenneth.feng@amd.com>
Reviewed-by: Kevin Wang <kevin.wang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 1b63bb397db208a8f84778a9d9cafc93da9373eb)
Cc: stable@vger.kernel.org
|
|
updates
amdgpu_vm_make_compute() switches a VM from SDMA to CPU page table
updates when a KFD process acquires it. It syncs "with the last SDMA
update/clear" through amdgpu_bo_sync_wait() on the root PD, but that
walks the reservation with DMA_RESV_USAGE_READ, and the clears of the
VM's page tables (the root PD from amdgpu_vm_init(), and the PDs/PTs
the seq64 mapping allocates at the render node's open) are added there
by amdgpu_vm_sdma_commit() with DMA_RESV_USAGE_BOOKKEEP only:
amdgpu_vm_pt_clear() commits them with a NULL fence, so they do not
reach vm->last_update. The CPU path's own waits (amdgpu_vm_cpu_update(),
amdgpu_bo_kmap()) use DMA_RESV_USAGE_KERNEL. None of them waits for a
clear that is still queued.
When one is, the CPU writes the first entries of the new compute VM (the
KFD trap handler's TBA/TMA page at AMDGPU_VA_RESERVED_TRAP_START, mapped
during ACQUIRE_VM) into a page directory the SDMA then clears. The
entries are gone, the handler's page is unmapped, and the first wave
save of any queue of the process faults in the SQC instruction fetch at
the handler's address (GCVM_L2_PROTECTION_FAULT_STATUS 0x008012B1,
PERMISSION_FAULTS 0xb). The MES then fails REMOVE_QUEUE and SUSPEND, and
the device takes a MODE1 reset with VRAM lost on 7.2.9; on 7.3-rc6 the
queue is reset instead.
The window is the time between the render node's open and ACQUIRE_VM.
ROCr spends milliseconds there and is practically never hit; a minimal
KFD client that opens the render node and acquires the VM at once is hit
most of the time. On a Radeon AI PRO R9700 (gfx1201, Resizable BAR, so
vm_update_mode defaults to CPU updates for compute VMs), a wave reading
the trap handler's page right after queue creation found it unmapped in
8 of 12 runs; a 5 ms sleep between the open and ACQUIRE_VM made that 0
of 9, and the same sleep after queue creation instead 3 of 3.
The wait covered these jobs until commit 926c79ad6ecd ("drm/amdgpu:
promote the implicit sync to the dependent read fences") narrowed
amdgpu_sync_resv() from DMA_RESV_USAGE_BOOKKEEP to DMA_RESV_USAGE_READ;
the VM's page table jobs have been added with BOOKKEEP since commit
4247084057cf ("drm/amdgpu: use DMA_RESV_USAGE_BOOKKEEP v2"), so from
v6.16 on the sync in amdgpu_vm_make_compute() waits for nothing of
them.
Record the clears in vm->last_update, as amdgpu_vm_update_pdes() does
with its updates, and wait for it, uninterruptibly, before switching the
update functions. The clears all go through vm->delayed, so the last one
covers the earlier ones; immediate clears are not recorded, as before.
With this, on 7.3-rc6 and on 7.2.9, the same client reads the handler
10 of 10 times, 8 busy queues on the 4 compute slots complete in 5 of 5
runs on 7.3-rc6 and 3 of 3 on 7.2.9 (1 of 6 before), 16 and 32 queues
complete on 7.3-rc6, and two processes with 8 queues each complete
together on both, with no fault.
Fixes: 926c79ad6ecd ("drm/amdgpu: promote the implicit sync to the dependent read fences")
Cc: Prike Liang <Prike.Liang@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: John Fisher <jfisher84@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 9ec91b35baba45209c3fcd00f086224a158dd512)
Cc: stable@vger.kernel.org # v6.16+
|
|
When a GPU reset takes the reset domain, KFD eviction cannot unmap
user queues: execute_queues_cpsch() fails its trylock with -EIO, so
the queues keep running until the ASIC is reset. The TLB flush is also
skipped while the reset is in progress. If the process unmaps and frees
a BO in that window, its pages are released while a queue can still
access them through stale translations.
On MI300X, munmap() then crashes in free_swap_cache() on a small bogus
page pointer in its mmu_gather batch page:
BUG: unable to handle page fault for address: 0000000000002900
RIP: 0010:free_swap_cache+0x5/0xb0
Call Trace:
free_pages_and_swap_cache+0x3a/0x60
tlb_batch_pages_flush+0x43/0x80
tlb_flush_mmu+0x3d/0x110
zap_pte_range+0x80d/0xcd0
...
do_vmi_align_munmap+0x3e8/0x5b0
do_vmi_munmap+0xdf/0x190
__vm_munmap+0xad/0x180
__x64_sys_munmap+0x1b/0x30
In a traced crash the bogus pointer was the read pointer value of an SDMA
queue the process had just destroyed, at the read pointer's page offset:
the queue's writeback landed in its freed rptr page after the page was
reused as the batch page.
commit f0b4440cdc18 ("drm/amdkfd: Fix mode1 reset crash issue") fixed
this race on process exit by waiting for the reset to complete before
freeing the process's BOs. Free through the ioctl has the same race.
Wait for the reset there too, using the same helper.
Fixes: 9c33e5fd4fb6 ("drm/amdgpu: fix locking scope when flushing tlb")
Reviewed-by: Felix Kuehling <felix.kuehling@amd.com>
Signed-off-by: William Palacek <William.Palacek@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 06ff8ce77726b15a98fcc285dd6005cb3f48558b)
Cc: stable@vger.kernel.org
|
|
median3() is meant to return the median of three values, but its last
compare-and-swap step swaps b and c instead of a and b. When c is
smaller than both a and b, it returns max(a, b) instead of min(a, b).
For example, median3(2, 3, 1) returns 3 instead of 2.
_do_calc_rc_params() always passes 0 as the first argument, and the
second argument is never below 12. So whenever the third argument is
negative, first_line_bpg_offset (and second_line_bpg_offset for 4:2:0)
is set to the second argument instead of 0.
Fix this by swapping a and b in the last step, as intended.
Note that this change does not affect valid DSC configurations. The
third argument is negative only when bits per pixel exceeds the
uncompressed rate of the colour format:
- 3 * bpc for 4:4:4, 3 * bpc + 2 for RGB
- 2 * bpc for 4:2:2
- 1.5 * bpc for 4:2:0
Fixes: 97bda0322b8a ("drm/amd/display: Add DSC support for Navi (v2)")
Signed-off-by: Keita Morisaki <kmta1236@gmail.com>
Tested-by: Dan Wheeler <daniel.wheeler@amd.com>
Reviewed-by: Roman Li <roman.li@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 1ddc4bc97a62fc89d9d3681413d9f977e1fa1a83)
Cc: stable@vger.kernel.org
|
|
Add extra type-2 TLB flush for GC 9.5.0, similar race condition was
observed as Vega20+XGMI. Add to GC 9.4.3 and 9.4.4 too, as they share
the same multi-XCD TLB topology.
Reported-by: Shahzeb Ahmed <shahzeb.ahmed@amd.com>
Reported-by: Manjunath Gaonkar <Manjunath.Gaonkar@amd.com>
Signed-off-by: Elena Sakhnovitch <Elena.Sakhnovitch@amd.com>
Reviewed-by: Apurv Mishra <apurv.mishra@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 138cfb165ae6aa98c0767b431e718d1a8199db28)
Cc: stable@vger.kernel.org
|
|
Reading the KFD HQD debugfs node (dqm_debugfs_hqds) on a gc_12_1_0 part
oopses with a NULL pointer dereference:
BUG: kernel NULL pointer dereference, address: 0000000000000000
RIP: hqd_sdma_dump_v12_1+0x6a [amdgpu]
Call Trace:
dqm_debugfs_hqds+0x2da/0x360 [amdgpu]
kfd_debugfs_hqds_by_device+0x74/0xa0 [amdgpu]
seq_read ... __x64_sys_read
get_sdma_rlc_reg_offset() assumes an interleaved layout where the second
SDMA per XCC lives in a separate SDMA1_HWIP register aperture. On
gc_12_1_0 that aperture does not exist.
Rewrite get_sdma_rlc_reg_offset() to mirror sdma_v7_1_get_reg_offset():
base the offset on adev->reg_offset[GC_HWIP][xcc_id][0] and add the
per-instance SDMA1 offset for the odd instance.
Fixes: 7bd5d763b8e1 ("drm/amdkfd: Add gfx_v12_1_kfd2kgd interface for GFX12_1")
Signed-off-by: Harish Kasiviswanathan <Harish.Kasiviswanathan@amd.com>
Reviewed-by: Mukul Joshi <mukul.joshi@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 94b2c5b06d37adc0e9a23138252758657b64b58a)
Cc: stable@vger.kernel.org
|
|
When kfd_queue_acquire_buffers() fails, its error path calls
kfd_queue_release_buffers(), which also drops a queue_refcount on the
SVM range at ctx_save_restore_area_address. The SVM range is the last
buffer acquired, and kfd_queue_buffer_svm_get() takes no reference when
it fails, so on every error path this reference was never taken. If
another queue of the process uses that CWSR range, its reference is
dropped instead, and unmapping the range no longer evicts that queue
while its CWSR area is unmapped from the GPU.
On navi31, with queue A using an SVM CWSR range: munmap() of the range
logs
Freeing queue vital buffer 0x..., queue evicted
but after a CREATE_QUEUE that reuses A's CWSR address with an unmapped
write pointer (-EINVAL), the same munmap() leaves A running without the
message.
Only put the BOs on the acquire error path. The warning and the eviction
are back after the failed CREATE_QUEUE.
Fixes: b049504e211e ("drm/amdkfd: Validate user queue svm memory residency")
Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com>
Reviewed-by: Felix Kuehling <felix.kuehling@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 9a08122e6361ef73f4b512d5db9596d561305519)
Cc: stable@vger.kernel.org
|
|
[Why & How]
Extend LT timeout for link rates <16G to avoid intermittent compliance
failures.
Reviewed-by: Relja Vojvodic <relja.vojvodic@amd.com>
Reviewed-by: Chris Park <chris.park@amd.com>
Signed-off-by: Ilya Bakoulin <Ilya.Bakoulin@amd.com>
Signed-off-by: Ray Wu <ray.wu@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 378e096423269a466d23a5d5ce65051e8ef1e474)
|
