| Age | Commit message (Collapse) | Author |
|---|
|
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)
|
|
Resume and full GPU reset retain the selected UMD profile level in
driver state.
The GFX and PMFW state behind it is reinitialized.
Add a generic DPM reapply path after CG and PG restoration.
It restores the UMD GFX state and asks the PM backend to replay the
retained level.
v2:
- Reapply only GFX CG to preserve the profile-owned GFX PG reference.
- Fall back to AUTO when reapply fails without failing device recovery.
- Propagate PowerPlay DPM errors before accepting AUTO fallback.
- Limit workload-profile error reporting to the swSMU reapply path.
This covers:
- PCI runtime resume
- Full GPU reset recovery
- System resume, including S3 and s2idle
Signed-off-by: Kevin Wang <kevin.wang@amd.com>
Reviewed-by: Kenneth Feng <kenneth.feng@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit fd0699fc9f4266fc07d6ce6dbb484fac04601106)
Cc: stable@vger.kernel.org
|
|
For AMDGPU_GEM_USERPTR_ANONONLY, amdgpu_ttm_tt_get_user_pages() only
checks the VMA at the start of the range for a backing file, and
amdgpu_hmm_range_get_pages() then faults in the whole range, across any
other VMAs. The check used to reject ranges ending beyond the first VMA
(vma->vm_end < end), which got lost when the code moved to HMM.
An ANONONLY userptr over one page of file-backed memory is rejected
with -EPERM, but one over an anonymous page followed by the same
file-backed page is accepted.
Restore the check and reject ANONONLY userptrs that cross more than one
VMA. The second userptr is now rejected too.
v2: reject ranges spanning multiple VMAs instead of walking every VMA
(Christian)
v3: cast num_pages to u64 to avoid an overflow (Christian)
Fixes: 6826cb3b92a3 ("drm/amdgpu: support userptr cross VMAs case with HMM")
Cc: Christian König <christian.koenig@amd.com>
Cc: Philip Yang <Philip.Yang@amd.com>
Cc: Felix Kuehling <Felix.Kuehling@amd.com>
Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Acked-by: Felix Kuehling <felix.kuehling@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 75d753ed4704d5efc72164d9e546b2a282e42ae2)
Cc: stable@vger.kernel.org
|
|
[Why]
On an MST teardown that runs through the reset path
(dcn31_reset_hw_ctx_wrap -> link_set_dpms_off -> deallocate_mst_payload),
fill_dc_mst_payload_table_from_drm() is asked to remove a payload whose
vcpi is not present in link->mst_stream_alloc_table and trips:
WARNING: .../amdgpu_dm_helpers.c:275 fill_dc_mst_payload_table_from_drm
This is a legitimate case, not an error: deallocate_mst_payload() can be
called for a stream whose MST payload was never programmed into DC's
HW-maintained table (a new stream created for a modeset whose enable
never completed, as already documented in deallocate_mst_payload()).
There is simply nothing to remove.
[How]
Drop the ASSERT and fall through to the fill loop, which rebuilds the
allocation table from the remaining entries. The table ends up unchanged,
which is correct: the payload being removed was never in it.
Note the loop must not early-return here - the caller passes a zeroed
proposed_table, so returning early would zero the whole link's table and
drop the other MST streams sharing the link.
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/5875
Reviewed-by: Wayne Lin <wayne.lin@amd.com>
Signed-off-by: Mario Limonciello <mario.limonciello@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 88a27f624dc0ebc14a7ab274a84d977ce8513cb6)
Cc: stable@vger.kernel.org
|
|
[Why & How]
The FFE electrical compliance test behavior is not correct. The driver
doesn't properly iterate over the FFE levels and select PS/DE based on
test request and/or cable-ID.
Fix the initialization of the link state so that when the polling loop
takes over, the test proceeds as described in the spec.
Reviewed-by: Relja Vojvodic <relja.vojvodic@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 1903c3389c81bc65f57f0edeea879359d674bb33)
|
|
The check-and-allocate sequence on pdd->qpd.proc_doorbells is
lockless at every call site of kfd_alloc_process_doorbells():
kfd_get_process_doorbells() (mmap of /dev/kfd),
kfd_ioctl_create_queue() and the CRIU restore path each test the
pointer under different locking (or none), so two racing threads can
both observe NULL and each allocate a doorbell BO and bitmap,
orphaning one allocation and handing the two mappings different
backing pages.
Move the serialization into kfd_alloc_process_doorbells() itself,
using a new per-process-device mutex so all three call sites are
covered regardless of their own locking. The device-global
kfd->doorbell_mutex is not suitable here: it is acquired under
dqm->lock on the kernel-doorbell path (start_cpsch() -> pm_init() ->
kq_initialize() -> kfd_get_kernel_doorbell()), so holding it across
the sleeping allocations above would create a lock-ordering
inversion with dqm->lock via TTM eviction, and it would also
serialize doorbell setup of unrelated processes behind a
device-wide lock for per-process state.
This issue was discovered by Tencent CodeBuddy Security.
v3 (Felix Kuehling):
- Removed unlocked check in kfd_get_process_doorbell flagged as
problematic by Sashiko Bot. Fall back to the locked check inside
kfd_alloc_process_doorbells
- Added missing mutex_destroy
v4 (Felix Kuehling):
- Removed unlocked checks around other kfd_alloc_process_doorbells calls
Fixes: 16f0013157bf ("drm/amdkfd: Allocate doorbells only when needed")
Signed-off-by: Henry Martin <bsdhenrymartin@gmail.com>
Signed-off-by: Felix Kuehling <felix.kuehling@amd.com>
Reviewed-by: Felix Kuehling <felix.kuehling@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 4e27ba5ad5f76932d4f6cbacd25c81c2dd40ec4a)
Cc: stable@vger.kernel.org
|
|
On MacBookPros with switchable graphics, the firmware puts VRAM at MC
address 0 when the iGPU is enabled. A later post (S3 resume, GPU
reset) moves VRAM back to the VBIOS default. gmc_v8_0 reads
MC_VM_FB_LOCATION once at init and reprograms it only on SR-IOV. On
bare metal, the driver then keeps using the old layout.
vi_reset_quirks[] handles this for the MacBookPro14,3 by PCI ID:
commit b6b1d9721851 ("drm/amdgpu: reset VI ASIC on MacBookPro14,3")
Add the test that SI and CIK use: an Apple subsystem vendor and VRAM at
0. Other Polaris MacBookPros then get the same reset at load, for
example the MacBookPro13,3 if its firmware leaves VRAM at 0. These
boards are not tested.
Keep vi_reset_quirks[]. Its MacBookPro15,1 entries fix a different
failure, a module reload after S3:
commit a5be7ad8f5f0 ("drm/amdgpu: reset VI ASIC on MacBookPro15,1")
VRAM is not at 0 at that point, so the new test may not cover it.
After the reset, FB_BASE is not 0, so the new test does not fire again
on a module reload.
Only compile-tested.
Suggested-by: Alex Deucher <alexander.deucher@amd.com>
Assisted-by: Claude:claude-opus-5-5
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Maciej Kucharek <qchcio@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit c2335b685b1e1e387f2fea1c67f56b5b8a8b6dc6)
Cc: stable@vger.kernel.org
|
|
On MacBookPros with switchable graphics, the firmware puts VRAM at MC
address 0 when the iGPU is enabled. A later post (S3 resume, GPU
reset) moves VRAM back to the VBIOS default. The SI fix resets and
posts the ASIC at load, so the driver uses the VBIOS layout from the
start:
"drm/amdgpu: reset SI ASIC on MacBookPros with VRAM at 0"
No MacBookPro has a CIK GPU, and no affected CIK board is known. Add
the same test to cik_need_reset_on_init(), so that SI, CIK and VI
handle this firmware layout in the same way. gmc_v7_0 reads
MC_VM_FB_LOCATION once at init and does not reprogram it. A CIK board
with VRAM at 0 therefore has the same problem as the SI boards.
After the reset, FB_BASE is not 0, so the new test does not fire again
on a module reload.
Only compile-tested.
Suggested-by: Alex Deucher <alexander.deucher@amd.com>
Assisted-by: Claude:claude-opus-5-5
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Maciej Kucharek <qchcio@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 6bb4b79d6a6c461b40750fd67cb4e2a070e20b67)
Cc: stable@vger.kernel.org
|
|
On MacBookPros with switchable graphics, the firmware puts VRAM at MC
address 0 when the iGPU is enabled. The EFI stub enables the iGPU on
these machines through apple_set_os(). On a MacBookPro11,5 (Radeon R9
M370X, 1002:6821, subsystem 106b:0149), the driver adopts this layout
at init:
MC_VM_FB_LOCATION=0x007f0000, HDP_NONSURFACE_BASE=0
VRAM at 0x0-0x7fffffff, GART table at 0x1400000
The driver posts the ASIC again on S3 resume and after a GPU reset.
The VBIOS asic_init table then moves VRAM back to the VBIOS default:
MC_VM_FB_LOCATION=0xf47ff400, HDP_NONSURFACE_BASE=0xf4000000
gmc_v6_0 does not reprogram these registers. The GART table is then
no longer in VRAM, and the gfx ring test times out:
amdgpu: ring gfx test failed (-110)
amdgpu: resume of IP block <gfx_v6_0> failed -110
Reset and post the ASIC at driver load on Apple boards with VRAM at 0.
The driver then uses the VBIOS layout (VRAM at 0xf400000000) from the
start, and later posts keep it. After the reset, FB_BASE is not 0, so
a module reload does not reset the ASIC again.
The test is the same one that commit c54e4d105077 ("drm/amdgpu: make
Mac FB workaround generic") uses: an Apple subsystem vendor and VRAM at
0. The VI quirk for the MacBookPro14,3 resets at load for the same
reason:
commit b6b1d9721851 ("drm/amdgpu: reset VI ASIC on MacBookPro14,3")
Other Apple SI boards get the same reset if FB_BASE reads 0 at load.
Tested on a MacBookPro11,5 with 7.2.5 and this patch: the panel comes
up at boot, and 4 of 4 deep S3 cycles resume. Without the patch, S3
resume fails every time. The GPU reset path is not tested.
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/5978
Assisted-by: Claude:claude-opus-5-5
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Maciej Kucharek <qchcio@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 60dd16ae10f286cb9cce5b6027b2d5ee869637af)
Cc: stable@vger.kernel.org
|
|
amdgpu_device_supports_boco() returns true for an AMD_IS_PX device on a
system with a hybrid ATPX method even when the device has no ACPI power
resource (_PR3). On an APU mini PC with a discrete GPU attached over
OCuLink, the iGPU's ATPX method reports hybrid graphics, the dGPU is
flagged AMD_IS_PX, and runtime PM in auto mode picks BOCO:
amdgpu: ATPX Hybrid Graphics
amdgpu 0000:c6:00.0: Using BOCO for runtime pm
In BOCO mode the driver leaves powering the device off to the PCI core,
which can only do it through _PR3 on the upstream bridge. No device on
this dGPU's path has _PR3, so when it runtime suspends the card stays
powered, with its fans at about 700 rpm.
Require has_pr3 for BOCO, as the function's description ("dGPU with ACPI
power resources") says. The same card then picks BACO, which powers it
down:
amdgpu 0000:c6:00.0: Using BACO for runtime pm
This only changes systems with a hybrid ATPX method and no _PR3 on the
dGPU's upstream bridge, where BOCO cannot cut the power today. Tested on
one such system only, an RX 9070 XT (Navi 48) over OCuLink with a Ryzen
AI 9 HX 470, with the change backported to 7.2.9: the stock module logs
"Using BOCO", the patched one "Using BACO"; BACO runtime suspend powers
the card off and it resumes cleanly. Not tested on a hybrid laptop or a
Thunderbolt eGPU.
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/5980
Assisted-by: Claude:claude-opus-5-5
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Luigi Lauro <luigi.lauro@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 1a039805354a44aab7abb2a6e685212d48b17a5e)
Cc: stable@vger.kernel.org
|
|
Some Qualcomm Snapdragon X2 Elite (Extreme)-based ASUS laptops (at
least the Zenbook A14 and A16) expose a custom, somewhat
Qualcomm reference-derived EC interface. Introduce a driver to
communicate with said EC, allowing for fan speed reporting, keyboard
backlight setting and receiving of a number of miscellaneous sideband
events.
Assisted-by: LLM
Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
[ij: add compiler.h and tweak initializer]
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Link: https://patch.msgid.link/20261015-topic-asus_ec-v4-2-af6305ffcb10@oss.qualcomm.com
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
The RTL8224 driver groups its four ports by rounding each PHY address
down to a multiple of four and uses the low two address bits as the
port index. This assumes that the first port's MDIO address is aligned
to a multiple of four.
The Hasivo S1100WP-8GT-2S+ uses two RTL8224 packages at MDIO addresses
1-4 and 5-8. Extend the driver to support such configurations by using
the base address from an ethernet-phy-package node when present and
calculating each port's offset relative to that address.
Use the package-relative port index to select the MDI pair order and
polarity fields. Reject PHY addresses outside the four-port package
and propagate explicit package errors rather than falling back to
another base address.
Share base-address parsing between probe and MDI configuration, and
calculate the port offset when configuring MDI rather than caching it
in an additional per-PHY private allocation.
Join both DT-described and legacy packages with devm_phy_package_join(),
as only the base address is needed, not a shared package node. This
avoids mixing OF and non-OF joins, which can unbalance package-node
references when members select the same base address.
Keep the existing aligned-address assumption when no package node
is present.
Signed-off-by: Manuel Stocker <mensi@mensi.ch>
[Oskari: rebased on net-next and reworked package handling]
Signed-off-by: Oskari Lemmela <oskari@lemmela.net>
Link: https://patch.msgid.link/20261013185635.1412452-3-oskari@lemmela.net
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
Bad configuration values from the dtb could result in out of bounds array
access. Verify parsed values are within range for the SoC and fail the
probe if invalid.
Reviewed-by: Simon Horman <horms@kernel.org>
Signed-off-by: Kyle Hendry <khendry@reliablecontrols.com>
Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Link: https://patch.msgid.link/20261014-miic-validate-dtb-v3-v4-2-b7da71b3a106@reliablecontrols.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
The port numbers on the RZ/T2H are documented as 0 to 3. Update the info
structure and change the member name to miic_port_last to be more accurate.
This value was being used as the number of miic registers when setting
default values. Add logic to get the total port count and loop over that.
Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Signed-off-by: Kyle Hendry <khendry@reliablecontrols.com>
Link: https://patch.msgid.link/20261014-miic-validate-dtb-v3-v4-1-b7da71b3a106@reliablecontrols.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
Three IRQ paths ignore the result of reading the direction registers
and then use the destination bitmap. pca953x_read_regs() does not populate
that bitmap when regmap_bulk_read() fails, leaving the callers to use
uninitialized stack data.
This can select incorrect GPIOs for direction changes during IRQ bus
synchronization, corrupt the saved input state during IRQ setup, or
produce incorrect pending interrupt decisions.
Check the read result at all three sites. Release irq_lock without
changing GPIO directions on failure, leave the IRQ history untouched
when pending detection fails, and propagate the error from IRQ setup.
The read helper already logs the error.
Fixes: 0f25fda840a9 ("gpio: pca953x: Zap ad-hoc reg_direction cache")
Cc: stable@vger.kernel.org
Signed-off-by: Sahaj Chaudhari <sahaj123.sc@gmail.com>
Link: https://patch.msgid.link/20261018165003.3372368-1-sahaj123.sc@gmail.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
|
|
pca953x_irq_set_wake() updates wakeup_path before asking the parent
IRQ controller to change its wake state. If irq_set_irq_wake() fails,
the IRQ core rolls back its wake state but the driver's counter remains
changed.
A failed enable can therefore leave the expander marked as part of the
wakeup path when no child IRQ has successfully enabled wakeup. A failed
disable can make the driver stop retaining power even though wakeup is
still enabled. The suspend and resume paths use this counter to decide
whether to disable or enable the regulator.
Update wakeup_path only after the parent operation succeeds, leaving it
unchanged on error.
Fixes: f70fbc15bae2 ("gpio: pca953x: Configure wake-up path when wake-up is enabled")
Cc: stable@vger.kernel.org
Signed-off-by: Sahaj Chaudhari <sahaj123.sc@gmail.com>
Fixes: f70fbc15bae2c89f ("gpio: pca953x: Configure wake-up path when wake-up is enabled")
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/20261018161042.3298045-1-sahaj123.sc@gmail.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
|
|
PTP SQs are allocated via mlx5e_ptp_alloc_txqsq(), which never sets
sq->channel. The excessive port timestamp delta recovery path
incorrectly used sq->channel->netdev for netdev_warn(), causing a NULL
pointer dereference. Use sq->netdev instead.
Fixes: 391dad2e686f ("net/mlx5e: Recover SQ on excessive PTP TX timestamp delta")
Signed-off-by: Carolina Jubran <cjubran@nvidia.com>
Reviewed-by: Alex Lazar <alazar@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Reviewed-by: Kalesh AP <kalesh-anakkur.purayil@broadcom.com>
Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev>
Link: https://patch.msgid.link/20261015080218.1102172-1-tariqt@nvidia.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
davinci_gpio_save_context() saves the registers of each 32-GPIO
register bank, but clears interrupt status only after the loop. At that
point g refers to the last bank, so pending status in all preceding
banks is left uncleared.
Move the interrupt-status write into the per-bank loop so that the
existing suspend-time clearing covers every register bank. Single-bank
controllers retain the same behavior.
Fixes: 0651a730924b ("gpio: davinci: Add support for system suspend/resume PM")
Cc: stable@vger.kernel.org
Signed-off-by: Sahaj Chaudhari <sahaj123.sc@gmail.com>
Link: https://patch.msgid.link/20261018170622.3406158-1-sahaj123.sc@gmail.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
|
|
The frequency_diff is reported by firmware in parts-per-trillion, which
is exactly what the DPLL core now expects from the ffo_get callback.
Commit bc443c253fcd ("dpll: expose fractional frequency offset in ppt")
switched the callback contract to ppt but assumed frequency_diff was in
ppm and scaled it by 1000000 to "convert" it. Since the value was
already ppt, this makes both exported attributes wrong.
Report frequency_diff as is and let the core divide it down for the
legacy ppm attribute.
Fixes: f035dca34ede ("net/mlx5: DPLL, Implement fractional frequency offset get pin op")
Signed-off-by: Carolina Jubran <cjubran@nvidia.com>
Reviewed-by: Jiri Pirko <jiri@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Reviewed-by: Daniel Machon <daniel.machon@microchip.com>
Reviewed-by: Ivan Vecera <ivecera@redhat.com>
Link: https://patch.msgid.link/20261015074035.1092340-1-tariqt@nvidia.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
If desc_set_label() fails after the chip's request callback succeeds,
gpiod_request_commit() clears GPIOD_FLAG_REQUESTED without calling the
free callback. The caller receives an error and has no GPIO to release,
leaving resources acquired by the request callback held.
Call the chip's free callback, if present, before clearing the requested
bit on label allocation failure. Leave request callback errors on the
existing path to avoid freeing a failed request.
Cc: stable@vger.kernel.org
Fixes: 1f2bcb8c8ccd ("gpio: protect the descriptor label with SRCU")
Signed-off-by: Baek Kyu, Kim <pocj8ur4in@gmail.com>
Link: https://patch.msgid.link/20261018044456.1259250-1-pocj8ur4in@gmail.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
|
|
The new WMI API supports multiple ACPI types by converting them into a
unified buffer that satisfies alignment and size requirements.
Adopt it to make our life easier.
Note that the Windows WMI-ACPI driver converts all ACPI objects into a
common buffer format, so adopting the new API intentionally accepts more
ACPI types as a followup of commit 465dc9da8ff6 ("platform/x86:
lenovo-wmi-helpers: Convert returned buffer into u32").
Suggested-by: Armin Wolf <W_Armin@gmx.de>
Link: https://lore.kernel.org/r/f1787927-b655-4321-b9d9-bc12353c72db@gmx.de/
Reviewed-by: Armin Wolf <W_Armin@gmx.de>
Tested-by: Navon John Lukose <navonjohnlukose@gmail.com>
Reviewed-by: Derek J. Clark <derekjohn.clark@gmail.com>
Reviewed-by: Mark Pearson <mpearson-lenovo@squebb.ca>
Signed-off-by: Rong Zhang <i@rong.moe>
Link: https://patch.msgid.link/20261019-lwmi-wmi-new-api-v5-11-71557d28d058@rong.moe
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
