| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
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>
|
|
ubi_get_ec_info() checks the user's erase_counters array with
access_ok() and then fills it one entry at a time with __put_user(),
taking the wear-leveling lock for each entry in between. Each of those
accesses enables and disables user access on its own, so the up-front
check saves nothing.
Use put_user(). The access_ok() stays, so a bad array still fails
before anything is written.
This is part of getting rid of __get_user() and __put_user() entirely.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
isapnp_proc_bus_read() checks the user buffer with access_ok() and then
copies the configuration registers one byte at a time with __put_user(),
reading each register in between. Each of those accesses enables and
disables user access on its own, so the up-front check saves nothing.
Use put_user(). The ignored return value and the access_ok() stay as
they were.
This is part of getting rid of __get_user() and __put_user() entirely.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
proc_bus_pci_read() and proc_bus_pci_write() check the user buffer with
access_ok() and then copy config space one byte, word or dword at a time
with __put_user() and __get_user(). Each of those accesses enables and
disables user access on its own, so the up-front check saves nothing.
Use put_user() and get_user(). This deliberately changes nothing else:
the return values were ignored before and still are, and the access_ok()
stays, since it is the only error these functions report for a bad
buffer.
This is part of getting rid of __get_user() and __put_user() entirely.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
read_port() and write_port() check the whole user buffer with
access_ok() and then move it one byte at a time with __put_user() and
__get_user(), doing an inb() or outb() for each. Each of those accesses
enables and disables user access on its own, so the up-front check saves
nothing.
Use put_user() and get_user(). The access_ok() stays, because it also
makes a partly invalid buffer fail up front, rather than after some
ports have already been read or written.
This is part of getting rid of __get_user() and __put_user() entirely.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi
Pull SCSI fixes from James Bottomley:
"All fixes in drivers (or the tape ULD) and one core fix to bsg (the
block ioctl equivalent of sg_io).
The biggest is the race in auth updates fix in iscsi configfs, but the
next biggest one is in bsg but the generic pieces of that are mostly
threading reply_len"
* tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
scsi: bsg: Pass reply_len to bsg_setup_queue() to fit UFS ARPMB replies
scsi: libsas: Fix SMP IO deadlock during HA resume
scsi: libiscsi: Validate the task named by a management response
scsi: libiscsi: Validate the ITT reflected in a Reject PDU
scsi: libiscsi: Reject a negative task index from parse_pdu_itt
scsi: target: iscsi: Fix race in discovery auth updates
scsi: target: Disable interrupts while holding delayed_cmd_lock
scsi: st: Fix use-after-free race between st_remove() and st_open()
scsi: st: Save the visited block for the partition the drive is in
scsi: xen/scsifront: Check for a NULL shadow entry on a backend response
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi
Pull spi fixes from Mark Brown:
"A small collection of driver specific fixes, all quite important if
you have the relevant hardware"
* tag 'spi-fix-v7.3-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi:
spi: spi-fsl-lpspi: directly return ret in fsl_lpspi_transfer_one()
spi: spi-fsl-lpspi: pass struct fsl_lpspi_data instead of struct spi_controller if possible
spi: imx: fix slab corruption from undersized DMA bounce buffers
spi: tegra114: assert CS GPIO for every transfer in a message
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap
Pull regmap fixes from Mark Brown:
"The main thing here is a fix for lockdep warnings with MMIO regmaps
that use a raw spinlock and a cache, some other lockdep fixes we'd
done for the benefit of the maple tree on sleeping buses meant that we
were doing allocations for those MMIO regmaps under a raw spinlock.
While fixing that Michael Reeves also noticed that the debugfs files
were briefly available without the cache structures backing them.
There's also a fix for interrupt freeing on error in regmap-irq which
had been hanging around because it's not super urgent"
* tag 'regmap-fix-v7.3-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap:
regmap: Drop map lock during cache init and exit
regmap: Remove debugfs before cache teardown
regmap: irq: Free the irqdomain we create
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/andi.shyti/linux
Pull i2c fixes from Andi Shyti:
"Three independent clock management fixes, plus one for a simple
reset mask blunder in the qcom-cci interrupt handler"
* tag 'i2c-fixes-7.3-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/andi.shyti/linux:
i2c: xiic: restore non-managed runtime PM to fix clk WARN flood
i2c: qcom-cci: Fix HALT_ACK reset request being dropped
i2c: qcom-geni: Restore the source-clock selection policy
i2c: viai2c-wmt: Fix clock leak in wmt_i2c_probe()
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394
Pull firewire fix from Takashi Sakamoto:
"Fix a regression introduced in v6.19. It affects cancellation of the
timer for split transaction timeout when handling a response. The
issue is unlikely to occur in practice"
* tag 'firewire-fixes-7.3-final' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394:
firewire: core: fix race condition in split transaction handling
|
|
For a split transaction, either fw_core_handle_response() or
split_transaction_timeout_callback() may manipulate the same transaction
entry in the pending transaction list. The return value of timer_delete()
is used to determine which function handles the entry. If the transaction
is a split transaction and timer_delete() returns zero, the timeout
callback may already be running. In this case, the response handler must
leave the entry in the list for the timeout callback to remove.
A previous code refactoring broke this behavior, introducing a race
condition in which both functions could process the same transaction.
This could lead to a use-after-free on the transaction initiator side.
Fix the regression by ensuring that the response handler does not process
the transaction when timer_delete() returns zero. The timeout callback is
responsible for removing the entry from the pending transaction list.
Fixes: fa2dc2710076 ("firewire: core: code refactoring to find and pop transaction entry")
Link: https://lore.kernel.org/r/20261018025504.290598-1-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
|
|
Pull drm fixes from Dave Airlie:
"Last set of fixes, mostly amdgpu, some i915 and xe.
I think the dma-buf revert is probably the most important: while it is
technically correct the fallout from it means we shouldn't enable
DMABUF_DEBUG like that yet, and fix the fallout first.
Summary:
MAINTAINERS update
dma-buf:
- revert dma-debug y on debug kernel due to msm interaction
core:
- fix drm_exec prelocked object interaction
i915:
- Fix ARL-S host bridge detection
- Add sanity checks for malformed DMC firmware
xe:
- OA uAPI fix
- shrinker fix
- fix eviction of object with no bo resource
- fix LRU for external objects
amdgpu:
- UVD fix
- TTM sched entity fixes
- SMU 14 fix
- Userptr leak fixes
- Runpm ref count fix
- CRIU fix
- UserQ fixes
- USB4 fix
- SDMA 3 fix
virtio-gpu:
- revert double setting blend property
- reset device before deleting vqs on freeze
vc4:
- fix hdmi audio runtime_pm interaction
amdxdna:
- fix Kconfig invalid configuration
rocket:
- fix error path for failed init
- fix core unbinding and scheduler lookup paths
panthor:
- fix immortalis configuration"
* tag 'drm-fixes-2026-10-17' of https://gitlab.freedesktop.org/drm/kernel: (31 commits)
drm/amdgpu/sdma3: Work around POLL_REGMEM / FENCE hang
drm/amdgpu: keep the eviction fence until the last handle is closed
drm/amd/display: Fix NULL sink dereference in USB4 bandwidth functions
drm/amdgpu/userq: actually validate userq BOs
drm/amdgpu: report the BO alignment in bytes in GEM_LIST_HANDLES
drm/amdgpu: free the userptr ranges when a CS fails after parser_bos
drm/amdgpu: don't drop the runtime PM reference twice in amdgpu_gpr
drm/amdgpu: fix GEM object leak on ENOMEM in userptr ioctl
drm/amd/pm: add zero fan stop temperature support on smu 14.0.2
drm/amdgpu: destroy mutex when tearing down ttm buffer entity
drm/amdgpu: fix sched entity leak in ttm buffer entity init
drm/amdgpu/uvd3.1: Fix checking whether UVD firmware keyselect was already set
drm/panthor: fix immortalis condition
drm/i915/cx0_phy: Fix ARL-S host bridge detection
drm/i915/dmc: Add sanity check for DMC load address
drm/i915/dmc: Harden DMC firmware payload parsing
drm/exec: don't immediately add prelocked obj to array of locked objs
drm/virtio: Reset device before deleting virtqueues on freeze
drm/xe: Bump LRU for external objects on exec and rebind
drm/xe/oa: Zero OA buffer at allocation
...
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci
Pull PCI fixes from Bjorn Helgaas:
- Ignore Immediate Readiness on Samsung 990 PRO and 990 EVO Plus NVMe,
which falsely advertise it; removal of unrelated delays in v7.2
caused post-FLR state restoration to fail, resulting in a VFIO
passthrough regression (Alexander Gruhlke)
-Don't treat ~0 as 'device is ready' in pci_dev_wait(); with RRS SV, a
device may respond with RRS (resulting in data of 0x0001) or may not
respond at all (typically resulting in ~0 data). A v6.12 change
treated ~0 as 'ready', resulting in a regression with Intel and
Samsung NVMe SSDs (Alexander Gruhlke)
* tag 'pci-v7.3-fixes-6' of git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci:
PCI: Don't treat ~0 as ready in pci_dev_wait() with RRS SV
PCI: Ignore Immediate Readiness on Samsung 990 PRO and 990 EVO Plus NVMe
|
|
With RRS Software Visibility, pci_dev_wait() considers a device ready as
soon as reading the Vendor ID doesn't return the RRS value. Devices aren't
required to respond with RRS while they aren't ready, so the read may
return ~0 and pci_dev_wait() stops waiting too early. This was seen with
Intel [8086:0a54] and Samsung [144d:a80c] NVMe SSDs.
Also wait while the Vendor ID reads ~0. A VF's Vendor ID always reads ~0,
so check its Command register instead, as is done without RRS SV.
Fixes: d591f6804e7e ("PCI: Wait for device readiness with Configuration RRS")
Link: https://lore.kernel.org/r/20250611101442.387378-1-hui.wang@canonical.com
Suggested-by: Lukas Wunner <lukas@wunner.de>
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Alexander Gruhlke <gruhlke@mailbox.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Lukas Wunner <lukas@wunner.de>
Link: https://patch.msgid.link/20261011190145.23621-3-gruhlke@mailbox.org
|
|
The Samsung 990 PRO [144d:a80c] advertises Immediate Readiness, so
pcie_flr() doesn't wait after FLR, but the drive returns ~0 for up to 7 ms.
Since commit 10baa9b4df40 ("PCI: Drop unnecessary retries when restoring
BARs"), the config restore after FLR is lost, which breaks VFIO passthrough
of the drive. Firmware 8B2QJXD7 responds right after FLR, but older
firmware such as 1B2QJXD7 doesn't, and the firmware version isn't visible
here.
[bhelgaas: The Samsung 990 EVO Plus [144d:a80d] with 2B2QKXG7 firmware
seems to have the same problem.]
Ignore Immediate Readiness on these devices, so pcie_flr() waits.
Fixes: 10baa9b4df40 ("PCI: Drop unnecessary retries when restoring BARs")
Link: https://bbs.archlinux.org/viewtopic.php?id=314833
Link: https://bbs.archlinux.org/viewtopic.php?pid=2312085#p2312085
Suggested-by: Lukas Wunner <lukas@wunner.de>
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Alexander Gruhlke <gruhlke@mailbox.org>
[bhelgaas: squashed in Samsung 990 EVO Plus from
https://lore.kernel.org/all/20261016102042.641801-1-gruhlke@mailbox.org]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Lukas Wunner <lukas@wunner.de>
Link: https://patch.msgid.link/20261011190145.23621-2-gruhlke@mailbox.org
Link: https://patch.msgid.link/20261016102042.641801-1-gruhlke@mailbox.org
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl
Pull pin control fixes from Linus Walleij:
- AMD: Clear S4 wake bits when firmware has _AEI, this is important for
some AMD systems.
- Do not accumulate sunxi npins across probe() attempts with deferred
probe. (desc->npins just went ++ and ++...)
- Qualcomm patch galore: split QUP functions on the Nord pin
controller, fix an OF module alias on IPQ5210 so the module
modprobes, fix two groups on the IPQ5018, make direction changes
exclusive on the SPMI-GPIO, and fix the interrupt target width on
four different SoCs.
* tag 'pinctrl-v7.3-3' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl:
pinctrl: sunxi: dt: do not accumulate npins across probe attempts
pinctrl: amd: Clear S4 wake bits when firmware has _AEI
pinctrl: qcom: ipq5018: replace gcc_plltest with pwm2 on gpio12
pinctrl: qcom: ipq5018: update PWM groups and corresponding pin functions
pinctrl: qcom: spmi-gpio: make direction changes exclusive
pinctrl: qcom: ipq5018: add missing pwm3 function on gpio13
pinctrl: qcom: qcs8300: Fix intr_target_width
pinctrl: qcom: maili: Fix intr_target_width
pinctrl: qcom: hawi: Fix intr_target_width
pinctrl: qcom: nord: fix GPIO interrupt target width
pinctrl: qcom: ipq5210: Publish the OF module alias
pinctrl: qcom: nord: Split QUP1 SE2/SE3 into lane-pair functions
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux
Pull power sequencing fix from Bartosz Golaszewski:
- with the PCIe code reworked to power the endpoint via pwrctl before
it starts the link training, we can now remove the workaround for
WLAN power which instead started causing an issue with endpoint
enumeration
* tag 'pwrseq-fixes-for-v7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux:
power: sequencing: qcom-wcn: power off WLAN at probe
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux
Pull gpio fixes from Bartosz Golaszewski:
- gracefully handle unsupported fwnode-only, no-device GPIO lookup for
shared pins
- mark the GPIO controller as sleeping in gpio-nct6694
- fix a GPIO device reference leak in kunit tests
- fix memory leak in error path in gpiod_set_array_value_complex()
- fix races in GPIO controller and its associated irqchip setup in
gpio-mxc
- use atomic bitops where races can occur in gpio-mxc
- fix build failure in gpio tools
* tag 'gpio-fixes-for-v7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux:
gpio: mxc: fix race between gpiochip registration and IRQ domain setup
gpio: mxc: fix wakeup_pads bit operations
gpio: mxc: fix both_edges bit operations
gpio: mxc: fix race between chained IRQ handler install and probe completion
gpiolib: fix memory leak in gpiod_set_array_value_complex() on error paths
gpio: kunit: fix GPIO device reference leak with __free()
gpio: shared: gracefully handle no-device lookup of shared GPIOs
gpio: shared: fix use-after-free bug when adding shared proxies
tools: gpio: fix building from the top level with O=
gpio: nct6694: Mark the GPIO controller as sleeping
|
|
This reverts commit 93ce8ea70451e800601bc9444aa33043de15d67b.
Mehmet reported that the offending commit breaks his AR9271 USB adapter
which uses zero-length replies to commands that don't return a value.
Revert the whole thing to restore the functionality.
Cc: stable@vger.kernel.org # the offending commit is in 6.12.113
Reported-by: Mehmet Fide <mehmet.fide@gmail.com>
Signed-off-by: Toke Høiland-Jørgensen <toke@toke.dk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
https://gitlab.freedesktop.org/drm/amdgpu/kernel into drm-fixes
amd-drm-fixes-7.3-2026-10-15:
amdgpu:
- UVD fix
- TTM sched entity fixes
- SMU 14 fix
- Userptr leak fixes
- Runpm ref count fix
- CRIU fix
- UserQ fixes
- USB4 fix
- SDMA 3 fix
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Alex Deucher <alexander.deucher@amd.com>
Link: https://patch.msgid.link/20261015221002.1728931-1-alexander.deucher@amd.com
|
|
https://gitlab.freedesktop.org/drm/xe/kernel into drm-fixes
An OA uAPI fix by zeroing OA buffer at allocation,
and other 3 small fixes around eviction and shrinker.
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patch.msgid.link/atDNMV-Aohu6s0gE@intel.com
|
|
https://gitlab.freedesktop.org/drm/misc/kernel into drm-fixes
A revert for the blend mode property patch being applied twice and a
patch to reset the device when frozen in virtio, a power state fix for
vc4, a Kconfig fix for amdxdna, an error handling, reference counting,
and a null pointer dereference fix for rocket, a revert for dma-buf for
a commit introducing a dangling reference, a locking fix for exec, and a
fix for panthor to handle 10-core GPUs.
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Maxime Ripard <mripard@kernel.org>
Link: https://patch.msgid.link/atCZfcTvshZx6mcA@houat
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc
Pull SoC fixes from Arnd Bergmann:
"A small number of last minute bug fixes came up since LPC.
Most of these are for devicetree files:
- Tegra264 needs fan descriptions to keep the system from overheating
- A cleanup on TI DRA7 caused a regression on PCI support and needs a
fixup
- The beaglev-fire board can no longer probe the mcp3564 sensor after
a an inconsistent update in 7.1
- A few fixes address compile time dtc warnings on tegra
The other three patches are all addressing minor problems
in tegra drivers and the sama5 defconfig"
* tag 'soc-fixes-7.3-3' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc:
ARM: configs: sama5: enable current Microchip KSZ DSA symbols
soc/tegra: pmc: Fix uninitialised clock rate
riscv: dts: microchip: beaglev-fire: remove double definition of gpio interrupts
ARM: dts: ti/omap: dra7: fix PCIe PHY clock divider definition
soc/tegra: fuse: Add missing newline to APBMISC error message
arm64: tegra: Add PCIe root ports on Tegra264
arm64: tegra: Reorder reg and reg-names to match bindings
arm64: tegra: Add PWM fan on Jetson AGX Thor DevKit
arm64: tegra: Add PWM controllers on Tegra264
|
|
Both fsl_lpspi_dma_transfer() and fsl_lpspi_pio_transfer() only return
negative error values in case of error or 0 in case of success.
Directly return ret, there is no need to check for positive error values
and return them as 0.
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Link: https://patch.msgid.link/20261009-spi-fsl-lpspi-more-cleanups-v1-2-2d4549d5205e@pengutronix.de
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
spi_controller if possible
Instead of passing a spi_controller pointer to functions and using
spi_controller_get_devdata() to get the struct fsl_lpspi_data pointer,
directly pass a struct fsl_lpspi_data pointer.
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20261009-spi-fsl-lpspi-more-cleanups-v1-1-2d4549d5205e@pengutronix.de
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Since commit faa8e404ad8e ("spi: imx: support dynamic burst length for
ECSPI DMA mode"), the driver allocates its private DMA TX/RX buffers
with kzalloc(dma_len), where dma_len is only rounded up to 4 bytes, but
maps, syncs and unmaps them with DMA_CACHE_ALIGNED_LEN(dma_len), i.e.
rounded up to the cache line size. As a result, the DMA API operates on
memory beyond the end of the allocation.
This was observed on a custom i.MX8MP platform with an mcp251xfd CAN
controller under heavy RPMSG load, as a series of refcount_t warnings
triggered from rpmsg_recv_done() in virtio_rpmsg_bus:
refcount_t: addition on 0; use-after-free.
refcount_t: underflow; use-after-free.
refcount_t: saturated; leaking memory.
Leading finally to an "Unable to handle kernel paging request" oops.
Reproducing this problem took between 30 minutes and roughly 30 hours
under the same workload.
Hardware watchpoints on the refcount of a struct rpmsg_endpoint showed
it was overwritten from 2 to 1 by __pi_memcpy_generic() in the
irq/155-spi2.0 thread. Additionally it was found that a "normal"
rpmsg_recv_done() took 11µs +/-2µs from its kref_get to kref_put. In
the error case the same sequence took about 215µs +/-10µs. Based on
this, an LLM was used to identify the size mismatch fixed here.
Allocate the buffers with DMA_CACHE_ALIGNED_LEN(dma_len) so they cover
the full mapped length, and use the same length for
dma_sync_single_for_cpu() to stay consistent with map and unmap.
With this patch applied, the same workload ran for more than 200 hours
without the problem reproducing.
Assisted-by: LLM
Fixes: faa8e404ad8e ("spi: imx: support dynamic burst length for ECSPI DMA mode")
Cc: stable@vger.kernel.org
Signed-off-by: Richard Leitner <richard.leitner@linux.dev>
Link: https://patch.msgid.link/20261015-fix-spi-imx-dma-v1-1-e28259671392@linux.dev
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The devres conversion replaced manual pm_runtime_enable()/disable() with
devm_pm_runtime_set_active_enabled() and dropped the remove-time runtime
PM teardown. The managed release tears runtime PM down in the wrong
order: it calls pm_runtime_dont_use_autosuspend() before
pm_runtime_disable(), i.e. while runtime PM is still enabled, and devres
is LIFO so the devm_clk_get_enabled() release runs afterwards.
At remove(), pm_runtime_put_sync() leaves the device active with the
autosuspend timer armed. Clearing use_autosuspend then makes rpm_idle()
suspend immediately, and xiic_i2c_runtime_suspend() clk_disable()s the
clock. The later devm_clk_get_enabled() release clk_disable_unprepare()s
the already-disabled clock, so clk_core_disable() WARNs ("clkN already
disabled") on every teardown.
Drop the managed helper and restore the non-managed runtime PM setup and
teardown, so runtime PM is enabled once in probe and disabled once in
remove and the clock enable count stays balanced.
Order the remove teardown so runtime PM is disabled before the usage
count is dropped: pm_runtime_disable() followed by pm_runtime_put_noidle()
instead of pm_runtime_put_sync(). Dropping the count first with autosuspend
still enabled arms the autosuspend timer, and a preemption before
pm_runtime_disable() lets it expire, suspend the device and clk_disable()
the clock, which the devm release then disables again - the same WARN.
Restore the non-managed IRQ request as well. The probe error paths now
unwind runtime PM by hand via goto, and a devm-registered handler is only
freed later during devres unwind, so it would stay live across the manual
teardown (and across any future failing step added after it). Request the
IRQ with request_threaded_irq() and free it explicitly in the probe error
path and in remove. The probe error path also clears use_autosuspend, to
match the teardown in remove().
Fixes: 50c63491ff26 ("i2c: xiic: switch to devres managed APIs")
Signed-off-by: Abdurrahman Hussain <abdurrahman@nexthop.ai>
Cc: <stable@vger.kernel.org> # v7.1+
Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
Link: https://patch.msgid.link/20261014-i2c-xiic-restore-runtime-pm-teardown-v8-1-40668c270069@nexthop.ai
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/iommu/linux
Pull IOMMU fixes from Joerg Roedel:
"AMD IOMMU:
- Revert an interrupt remapping check removal that caused GPU
regressions on some platforms
Generic page tables:
- Fix KUnit builds with distributed Clang ThinLTO by preserving
compiler flags, preventing x86-64 code generation from arm64
bitcode"
* tag 'iommu-fixes-v7.3-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/iommu/linux:
iommupt/kunit: Use if_changed_rule for the kunit
Revert "iommu/amd: Remove redundant check in irq_remapping_select()"
|
|
SDMA can randomly hang on Polaris 10. Hard to reproduce,
but has been occurring sporadically in the Mesa CI
on the RADV Polaris 10 job even when Mesa isn't using
the SDMA engine.
When Mesa actually uses the SDMA on Polaris, the hang
becomes more frequent and the reproduction rate goes up
significantly in the CI system.
We don't know why the hangs occur, but it seems
that inserting a single NOP packet before each
POLL_REGMEM and FENCE packet works around it.
At the moment it's unclear which GPUs are affected,
so let's apply this to SDMA 3.x for now.
Note that this issue is not documented or acknowledged by AMD.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit c343a27ed90823d08de125f7c447d96d056b75d9)
Cc: stable@vger.kernel.org
|
|
amdgpu_gem_object_close() detaches the user queue eviction fence from
the BO before it checks bo_va->ref_count, so closing any handle of a BO
removes the fence, even when the file still has another handle to the
BO and the bo_va with its GPU mappings stays. The BO can then be evicted
without suspending the user queues of the file, which keep accessing it
through mappings that are only marked for update.
Seen on navi31 with a SDMA user queue: a BO opened twice in the same
file (GEM_FLINK + GEM_OPEN) loses its eviction fence when the second
handle is closed (traced attach/detach of the fence):
attach bo=ffff8c78a6c84c00
GEM_CLOSE handle=7
detach bo=ffff8c78a6c84c00
while handle 6 and the mapping are still in use.
Only detach the fence when the last reference to the bo_va goes away,
matching amdgpu_gem_object_open(), which attaches it only when the
bo_va is created. With this the fence stays until the file is closed.
Fixes: 31f7efcdca4d ("drm/amdgpu: enable eviction fence")
Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 8387982f03d4026b7dc11b0b5e3118298eee4d6a)
Cc: stable@vger.kernel.org
|
|
allocate_usb4_bandwidth_for_stream() and allocate_usb4_bandwidth() both
use ASSERT(stream->sink) before dereferencing stream->sink->link. ASSERT
is compiled out in production builds, so a NULL stream->sink causes a
NULL pointer dereference.
link_set_dpms_off() already guards two earlier accesses to stream->sink
with explicit NULL checks, confirming that stream->sink can legitimately
be NULL. The subsequent call to deallocate_usb4_bandwidth() had no
equivalent guard.
Replace the ASSERT() calls with proper NULL checks that return false
early, and add a matching stream->sink guard at the call site in
link_set_dpms_off() consistent with the surrounding pattern.
v2: Keep the existing ASSERT() calls for diagnostics (to report
unexpected NULL sink), and add explicit NULL checks that return false
before dereferencing stream->sink. Also add a matching stream->sink
guard at the deallocation call site in link_set_dpms_off(). (Alex)
Fixes: 8fa813b7fd1e ("drm/amd/display: Remove sink usage from DPMS")
Reported-by: Dan Carpenter <error27@gmail.com>
Cc: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Cc: Dominik Kaszewski <dominik.kaszewski@amd.com>
Cc: George Zhang <george.zhang@amd.com>
Cc: Aurabindo Pillai <aurabindo.pillai@amd.com>
Cc: Roman Li <Roman.Li@amd.com>
Cc: Ivan Lipski <ivan.lipski@amd.com>
Cc: Dan Wheeler <daniel.wheeler@amd.com>
Cc: Alex Hung <alex.hung@amd.com>
Cc: Tom Chung <chiahsuan.chung@amd.com>
Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.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 98029a0ce61feb52c563f65349dd9b25f672e355)
Cc: stable@vger.kernel.org
|
|
This was supposed to loop over the individual evicted list, as the
kernel and always_valid evicted lists were already handled in
amdgpu_vm_validate.
Without this, BOs that were created and evicted before a userq was made
would never end up in an eviction fence rearm.
Also add the missing ref to the BO before drm_exec locks and refs it.
Fixes: 4cdbba5a16aa ("drm/amdgpu: restructure VM state machine v4")
Signed-off-by: Benjamin Cheng <benjamin.cheng@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 18decfc9e8cc0fa70b6de9944cc27a37729edfbd)
Cc: stable@vger.kernel.org
|
|
The uapi documents drm_amdgpu_gem_list_handles_entry.alignment as
"physical start_addr alignment in bytes", and GEM_OP
GET_GEM_CREATE_INFO returns the same value in bytes, but
GEM_LIST_HANDLES returns tbo.page_alignment, which is in pages. For a BO
created with a 64 KiB alignment on navi31:
GET_GEM_CREATE_INFO: alignment=65536
GEM_LIST_HANDLES: alignment=16
so a user such as CRIU that recreates BOs from this list uses the wrong
alignment. Convert it to bytes.
Fixes: f9db1fc52ceb ("drm/amdgpu: Add ioctl to get all gem handles for a process")
Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit aa4493ae949c13e79aba0731394dd7a7e431342b)
Cc: stable@vger.kernel.org
|
|
amdgpu_cs_parser_bos() allocates an HMM range for every userptr entry of
the BO list and looks up the user pages. Those ranges are only freed when
amdgpu_cs_parser_bos() itself fails or when amdgpu_cs_submit() checks
them under the notifier lock. If amdgpu_cs_patch_jobs(),
amdgpu_cs_vm_handling(), amdgpu_cs_sync_rings() or the early part of
amdgpu_cs_submit() fails, nothing frees them: neither
amdgpu_cs_parser_fini() nor amdgpu_bo_list_free() touch e->range.
Each such CS then leaks the range, its hmm_pfns array (8 bytes per page
of the userptr BO) and the BO reference the range holds. An IB on a ring
that patches the CS in place (e.g. VCN) with an unmapped va_start fails
in amdgpu_cs_patch_ibs() and takes this path.
Free the ranges on those error paths. Ranges amdgpu_cs_submit() already
dropped are NULL, so freeing them again is a no-op.
Fixes: fec8fdb54e8f ("drm/amdgpu: fix userptr HMM range handling v2")
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit c52a9542ed7cfd527feb938bd0accada2ac8d267)
Cc: stable@vger.kernel.org
|
|
amdgpu_debugfs_gpr_read() drops its runtime PM reference right after
reading the wave registers. When copying them to userspace fails, it
jumps to the err label, which drops the reference a second time. A read
into a bad buffer on Navi31 either steals a reference somebody else
holds (power/runtime_usage goes from 1 to 0) or underflows the count:
amdgpu 0000:03:00.0: Runtime PM usage count underflow!
The registers are already in the kernel buffer at that point, so finish
the hardware access first and copy the buffer with a single
copy_to_user() instead of the put_user() loop with its own error path.
Fixes: 9eee152aab56 ("drm/amdgpu/debugfs: fix ref count leak when pm_runtime_get_sync fails")
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 31035bbd74f7c3e10c163db875b8e67f8b50ee6a)
Cc: stable@vger.kernel.org
|
|
When amdgpu_hmm_range_alloc() fails amdgpu_gem_userptr_ioctl() returns
-ENOMEM right away and skips the cleanup every other error path goes
through. The GEM object, the bo->parent reference on the VM root and the
MMU notifier registration are all left behind.
Use release_object here, not user_pages_done, range is still NULL at
this point.
Fixes: e095b55155ef ("drm/amdgpu: use user provided hmm_range buffer in amdgpu_ttm_tt_get_user_pages")
Signed-off-by: Perry Yuan <perry.yuan@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit bbe739e407a542073ec1a7872b14843566b4919e)
Cc: stable@vger.kernel.org
|
|
add zero fan stop temperature support on smu 14.0.2
Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/5905
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 f990c94a2633d0ead477eb1b174e254a6d292e66)
Cc: stable@vger.kernel.org
|
|
Pair mutex_init() with mutex_destroy() on the GART window allocation
failure path and in amdgpu_ttm_buffer_entity_fini(). This is a |
