| Age | Commit message (Collapse) | Author |
|---|
|
When the DT node has "wakeup-source", vm_find_vqs() calls
enable_irq_wake() on the shared IRQ, but vm_del_vqs() freed that IRQ
without a matching disable_irq_wake(). That leaves a wake reference
behind and can warn on later free_irq()/request_irq() cycles.
Record whether enable_irq_wake() succeeded, and disable it in
vm_del_vqs() before free_irq().
Fixes: 02213273f72a ("virtio_mmio: add support to set IRQ of a virtio device as wakeup source")
Cc: stable@vger.kernel.org
Signed-off-by: Xiong Weimin <xiongweimin@kylinos.cn>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <20260805032937.1606737-1-xiongweimin@kylinos.cn>
|
|
vhost_vdpa_config_cb() loads v->config_ctx and signals it without taking
a reference and without holding any lock:
struct eventfd_ctx *config_ctx = v->config_ctx;
if (config_ctx)
eventfd_signal(config_ctx);
VHOST_VDPA_SET_CONFIG_CALL replaces that field and drops what is normally
the last reference to the old context:
swap(ctx, v->config_ctx);
if (ctx)
eventfd_ctx_put(ctx);
eventfd_ctx_put() drops the last kref and frees the context immediately,
with no RCU grace period, so a callback that has already loaded the
pointer goes on to dereference freed memory. The two sides share no
lock: the ioctl runs under vhost_dev.mutex, while the parent invokes the
callback from its own interrupt or workqueue context.
This is not the reopen refcount underflow fixed by commit f6bbf0010ba0
("vhost-vdpa: fix use-after-free of v->config_ctx"), which was about
vhost_vdpa_config_put() leaving a stale pointer behind. Here the pointer
is maintained correctly and it is the read side that is unprotected.
With VDUSE as the parent this is reachable from userspace with access to
/dev/vduse (root by default). VDUSE_DEV_INJECT_CONFIG_IRQ queues
dev->inject, and vduse_dev_irq_inject() runs the callback under VDUSE's
own dev->irq_lock, which vhost does not hold. vduse_dev_reset() does
flush_work(&dev->inject), but VHOST_VDPA_SET_CONFIG_CALL never goes
through reset, so an inject already in flight is not waited for. A
process that injects config interrupts on the VDUSE fd while another
thread swaps the call fd on the vhost-vdpa fd hits it in seconds:
BUG: KASAN: slab-use-after-free in native_queued_spin_lock_slowpath
Read of size 4 at addr ffff888107d21808 by task kworker/u17:1/2993
Workqueue: vduse-irq vduse_dev_irq_inject
Call Trace:
native_queued_spin_lock_slowpath+0x97/0x5b0
_raw_spin_lock_irqsave+0xd4/0xe0
eventfd_signal_mask+0x69/0x120
vhost_vdpa_config_cb+0x34/0x50
vduse_dev_irq_inject+0x46/0x60
process_one_work+0x468/0x950
Allocated by task 2992:
do_eventfd+0x50/0x200
__x64_sys_eventfd2+0x2e/0x40
Freed by task 2992:
eventfd_ctx_put+0xb9/0xc0
vhost_vdpa_unlocked_ioctl+0x116c/0x2190
Add a spinlock covering every access to config_ctx, so the callback
either signals a context that is still alive or observes NULL, and the
put happens only once no callback can reach the old value.
Clearing the parent's callback before the put would not be enough: of the
in-tree set_config_cb() implementations only VDUSE takes a lock, the rest
store the pointer unlocked, so that would not order against an in-flight
invocation.
Fixes: 776f395004d8 ("vhost_vdpa: Support config interrupt in vdpa")
Signed-off-by: Yu Zhang <yuz08559@gmail.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <20260807100025.19750-3-yuz08559@gmail.com>
|
|
vhost_vdpa_set_config_call() swaps the eventfd_ctx_fdget() return value
into v->config_ctx before checking it, so on failure the field briefly
holds an ERR_PTR:
ctx = fd == VHOST_FILE_UNBIND ? NULL : eventfd_ctx_fdget(fd);
swap(ctx, v->config_ctx);
if (!IS_ERR_OR_NULL(ctx))
eventfd_ctx_put(ctx);
if (IS_ERR(v->config_ctx)) {
long ret = PTR_ERR(v->config_ctx);
v->config_ctx = NULL;
return ret;
}
Commit 0bde59c1723a ("vhost-vdpa: set v->config_ctx to NULL if
eventfd_ctx_fdget() fails") added that clearing, and spelled out the
invariant the rest of the file relies on: "we consider 'v->config_ctx'
valid if it is not NULL". The window between the swap and the clearing
still breaks it. vhost_vdpa_config_cb() only tests for NULL, so a config
interrupt delivered inside the window hands the ERR_PTR to
eventfd_signal().
Check the fd before installing it instead. That closes the window and
matches how vhost_vring_ioctl() handles the same failure for the vq call
fd.
It also stops a rejected fd from tearing down a config interrupt that was
working: until now the swap replaced the live context and put it, so
after an EBADF the device silently stopped delivering config interrupts
until userspace installed a new fd.
Fixes: 776f395004d8 ("vhost_vdpa: Support config interrupt in vdpa")
Signed-off-by: Yu Zhang <yuz08559@gmail.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <20260807100025.19750-2-yuz08559@gmail.com>
|
|
vhost_vring_set_num() accepts any non-zero power-of-two queue size that
fits in 16 bits. vhost-vdpa then passes that value to set_vq_num()
without comparing it with get_vq_num_max().
A process with access to /dev/vhost-vdpa-* can therefore configure a
queue larger than the device advertises. With vdpa_sim, the worker can
walk descriptors beyond the mapped descriptor ring. KASAN reports a
16-byte out-of-bounds read, corresponding to one vring_desc, in the
vringh IOTLB path:
BUG: KASAN: out-of-bounds in _copy_from_iter
Read of size 16
copy_from_iotlb
copydesc_iotlb
vringh_getdesc_iotlb
vdpasim_net_work
Cache get_vq_num_max() immediately after reset. Some backends derive
it from writable queue-size state, so querying it after SET_NUM may
return the current size instead of the device capability. Invalidate
the cached value before reset so a failed reset leaves SET_NUM
disabled.
For VHOST_SET_VRING_NUM, copy the complete vring state once and use
the same index and size for validation, vq->num, and set_vq_num().
This ensures that validation and use operate on the same copied values.
Fixes: 4c8cf31885f6 ("vhost: introduce vDPA-based backend")
Signed-off-by: Jia Jia <physicalmtea@gmail.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <20260810010300.132959-1-physicalmtea@gmail.com>
|
|
__send_control_msg() publishes &portdev->cpkt as the control-out
virtqueue cookie. remove_vqs() walks every virtqueue and passes leftover
cookies to free_buf(), which treats them as struct port_buffer and
reads sgpages.
If a control message is still on c_ovq when the device is unbound,
free_buf() reads past the ports_device object.
KASAN reported slab-out-of-bounds in free_buf():
free_buf
remove_vqs
virtcons_remove
unbind_store
The object was the ports_device allocated in virtcons_probe().
Drain c_ovq without freeing. The packet lives in portdev and is released
with it.
Fixes: a7a69ec0d8e4 ("virtio_console: free buffers after reset")
Signed-off-by: Jia Jia <physicalmtea@gmail.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <20260819021230.292696-1-physicalmtea@gmail.com>
|
|
device_unregister() is device_del() plus put_device(). When the caller
holds no extra reference, that drops the last one and runs the release
callback, which for several transports frees the memory the embedded
struct virtio_device sits in. unregister_virtio_device() then calls
virtio_debug_device_exit(), which reads dev->debugfs_dir out of the freed
object.
Affected transports are the ones whose release callback frees and whose
remove path takes no reference: virtio_mmio, virtio_vdpa, virtio_uml,
mlxbf-tmfifo and virtio_ccw. virtio_pci is unaffected because
virtio_pci_remove() brackets the call with get_device() and put_device().
Remove the debugfs entries before the device can go away. They are only
accessed through the protected debugfs interface, so
debugfs_remove_recursive() waits for in-progress file operations before
returning. Tearing them down while the device is still alive is therefore
safe.
Reproduced on User-Mode Linux with CONFIG_KASAN and CONFIG_VIRTIO_DEBUG
by unbinding a virtio-uml device:
BUG: KASAN: slab-use-after-free in virtio_debug_device_exit+0x36/0x4d
Read of size 8 at addr 00000000616e0b10 by task init/1
__asan_report_load8_noabort
virtio_debug_device_exit+0x36/0x4d
unregister_virtio_device+0x48/0x75
virtio_uml_remove
platform_remove
device_release_driver_internal
unbind_store
Freed by task 1:
kfree
virtio_uml_release_dev
device_release
kobject_put
put_device
device_unregister
With this applied, the report is gone and unbind is clean.
Fixes: 96a8326d69ff ("virtio: add debugfs infrastructure to allow to debug virtio features")
Assisted-by: Claude:claude-opus-5
Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <20260821213953.76906-1-kmehltretter@gmail.com>
|
|
In a packed ring the AVAIL and USED bits sit in the descriptor itself,
so writing them makes that descriptor available. Those bit combinations
flip meaning on every round of the ring, tracked by a wrap counter, so
invalidating or validating a descriptor means inverting both bits.
Commit 1ce9e6055fa0 ("virtio_ring: introduce packed ring support") has
virtqueue_add_packed() make every descriptor of a chain available as it
maps the chain, and write the head last. The device consumes the ring in
order and stops at a head that is not available yet, so it never reaches
the rest.
When vring_map_one_sg() fails partway, unmap_release unmaps the segments
and restores avail_used_flags, but the descriptors it wrote to in the
ring stay marked with AVAIL and USED bits. The head is now the only
entry that keeps the device from consuming these stale entries.
For example, the ring would look like this now.
Z - pre-previous command
A - previous command
B - aborted command
C - current command
[A1 DONE] [A2 DONE] <C1 EMPTY> [B2] [B3] [Z1 DONE]
When the driver now attempts to issue the C command, the next add starts
at the same head as B. If C spans less descriptors than B, there is no
end marker because AVAIL and USED bits were still in place. And that
means the device will start interpreting these stale entries (B2/B3) as
another command entry, which then blocks the queue.
This effect typically happens in swiotlb configurations under memory
pressure, because vring_map_one_sg() can then fail with larger I/O
requests which then leads to command abortions.
There are broadly 2 ways to avoid leaving those flags behind:
1) Defer those flags too until the chain is complete.
2) Rewrite those flags for the previous wrap counter.
Implement the second option in both packed add paths. The first option
traverses the chain a second time on every successful add. The second
option invalidates all added descriptors when any add fails.
With this patch applied, a packed virtqueue keeps completing requests
after a failed add.
Fixes: 1ce9e6055fa0 ("virtio_ring: introduce packed ring support")
Fixes: f6a15d854986 ("virtio_ring: add in order support")
Assisted-by: Kiro:claude-opus-5 checkpatch sparse
Signed-off-by: Alexander Graf <graf@amazon.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <20260817223229.28954-1-graf@amazon.com>
|
|
fs210x_init_chip() marks the register cache dirty and replays it after
reset and scene setup, but ignores a replay failure and publishes
is_inited. Its resume caller already returns the helper status.
Keep is_inited clear and return a cache replay failure so the ASoC
component wrapper can report the incomplete restoration.
The issue was found by our static-analysis tool and manually reviewed.
Fixes: 756117701779 ("ASoC: codecs: Add FourSemi FS2104/5S audio amplifier driver")
Assisted-by: gpt 5
Signed-off-by: Pengpeng Hou <hppiscas@163.com>
Link: https://patch.msgid.link/20260906034217.85696-5-hppiscas@163.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
es8389_resume() ignores the reset-register read, bias restoration and
register-cache replay. A failed read can leave regv uninitialized before
it selects the initialization path.
Check those operations and always leave cache bypass before returning an
error. The ASoC component wrapper reports callback failures while retaining
its best-effort resume contract.
The issue was found by our static-analysis tool and manually reviewed.
Fixes: 0319c26889f7 ("ASoC: codecs: add support for ES8389")
Assisted-by: gpt 5
Signed-off-by: Pengpeng Hou <hppiscas@163.com>
Link: https://patch.msgid.link/20260906034217.85696-4-hppiscas@163.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
es8375_resume() ignores the clock-status read, bias restoration and
register-cache replay. A read failure can leave reg uninitialized before
it selects the initialization path, and later resume processing cannot
observe a failed restore.
Return the fallible operation results to the ASoC component wrapper, which
reports callback failures while retaining its best-effort resume contract.
The issue was found by our static-analysis tool and manually reviewed.
Fixes: de2b3119f9f7 ("ASoC: codecs: add support for ES8375")
Assisted-by: gpt 5
Signed-off-by: Pengpeng Hou <hppiscas@163.com>
Link: https://patch.msgid.link/20260906034217.85696-3-hppiscas@163.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
es8326_resume() ignores the status-register read, the direct clock-state
write and the register-cache replay. A read failure can also leave reg
uninitialized before it selects the reset path, and a cache failure is
followed by jack IRQ processing.
Return these errors before later resume work. The ASoC component wrapper
reports the callback failure while retaining its best-effort resume
contract.
The issue was found by our static-analysis tool and manually reviewed.
Fixes: 5c439937775d ("ASoC: codecs: add support for ES8326")
Assisted-by: gpt 5
Signed-off-by: Pengpeng Hou <hppiscas@163.com>
Link: https://patch.msgid.link/20260906034217.85696-2-hppiscas@163.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Correct "upto" to "up to", reported by scripts/checkpatch.pl using the
misspelling list in scripts/spelling.txt. Only touches comments, no code
changes.
Assisted-by: Cursor:claude-opus-5
Signed-off-by: Hemanth Selam <hemanth.selam@gmail.com>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://patch.msgid.link/20260907045331.16932-3-hemanth.selam@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Fix typos in comments, reported by scripts/checkpatch.pl using the
misspelling list in scripts/spelling.txt. Only touches comments, no code
changes.
Assisted-by: Cursor:claude-opus-5
Signed-off-by: Hemanth Selam <hemanth.selam@gmail.com>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://patch.msgid.link/20260907045331.16932-2-hemanth.selam@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Update the TODO file to reflect the plan to drop the ipu7 driver in favour
of IPU7 and later support in ipu6 driver. The ipu7 driver may still exist
for some time as users switch to the ipu6 driver.
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
|
|
Enable support for Intel IPU 7 and IPU 7.5, found in Lunar lake and
Panther lake, respectively, in the ipu6 driver.
Disabling the CONFIG_VIDEO_INTEL_IPU6_IPU7 Kconfig option can be used to
still default the support of IPU7 and 7.5 to the ipu7 driver, while
default is enabled. The driver binding can still be configured at runtime
by using force_probe and force_no_ipu7_probe options in ipu6 and ipu7
drivers, respectively.
Signed-off-by: Antti Laakso <antti.laakso@linux.intel.com>
Co-developed-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
|
|
The Acer Nitro AN17-41 uses "RB" as its board vendor and has no entry
in yc_acp_quirk_table, so acp6x_probe() finds no DMI match, registers
no card, and the internal digital microphone records only silence.
Add a quirk entry for it so the DMIC is enabled.
Signed-off-by: Aaron Welwood <abwelwood@gmail.com>
Link: https://patch.msgid.link/20260907031738.17257-1-abwelwood@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/driver-core/driver-core into drm-rust-next
rust: dma: tie DMA allocations to the device's bound lifetime
DMA allocations carry device resources (e.g. IOMMU mappings) that must
not outlive the device's bound lifetime. Add lifetime parameters to the
DMA allocation types (Coherent, CoherentBox, CoherentHandle) to enforce
at compile time that they are freed before the device is unbound.
Since DMA types with lifetime parameters are exposed through debugfs in
the nova-core driver, first drop the unnecessary T: 'static bound from
the debugfs ScopedDir file creation methods by formalizing a type
invariant on FileOps.
This is a stable tag for other trees to merge.
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
lifetime"
Danilo Krummrich <dakr@kernel.org> says:
DMA allocations carry device resources (e.g. IOMMU mappings) that must
not outlive the device's bound lifetime. Add lifetime parameters to the
DMA allocation types (Coherent, CoherentBox, CoherentHandle) to enforce
at compile time that they are freed before the device is unbound.
Since DMA types with lifetime parameters are exposed through debugfs in
the nova-core driver, first drop the unnecessary T: 'static bound from
the debugfs ScopedDir file creation methods by formalizing a type
invariant on FileOps.
Link: https://patch.msgid.link/20260830193824.471089-1-dakr@kernel.org
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
Agilex5 integrates GIC600 with an ACE-lite interface limited to a 32-bit
address bus, so the ITS can only access the first 4 GB of physical address
space. Register intel,socfpga-agilex5 on the existing
dma_32bit_impaired_platforms list so ITS allocations use GFP_DMA32.
The workaround is guarded by ALTERA_ERRATUM_AGILEX5_2_1_23, which is
selected by ARCH_INTEL_SOCFPGA as all Agilex5 devices are affected.
This limitation is documented as Agilex 5 ES Device Errata 2.1.23 (825514).
Signed-off-by: Adrian Ng Ho Yin <adrian.ho.yin.ng@altera.com>
Signed-off-by: Thomas Gleixner <tglx@kernel.org>
Reviewed-by: Marc Zyngier <maz@kernel.org>
Link: https://docs.altera.com/r/docs/825514/current/agilex-5-es-device-errata-and-user-guidelines/hps-gicv3-its-and-lpi-unable-to-access-physical-memory-larger-than-32-bits-causing-msi-x-interrupt-failure
Link: https://lore.kernel.org/linux-arm-kernel/372f059069a5551ea1096015f855cc306dbd7cd4.1747368554.git.adrianhoyin.ng@altera.com/ # v1
Link: https://lore.kernel.org/linux-arm-kernel/6a44509ca0edaabc17e59d2e27fef1c782183456.1751618484.git.adrianhoyin.ng@altera.com/ # v2
Link: https://lore.kernel.org/linux-arm-kernel/20260622024945.21354-1-muhammad.nazim.amirul.nazle.asmade@altera.com/ # v3 (untagged)
Link: https://lore.kernel.org/all/20260904091114.2259616-1-adrian.ho.yin.ng@altera.com/ #v4
Link: https://patch.msgid.link/fc927e43892b86200e157fa303b0d1dd344caffd.1788751033.git.adrian.ho.yin.ng@altera.com
|
|
free_lpi_range() cannot give LPIs back to the allocator without
allocating a struct lpi_range to describe the freed range, so it
returns -ENOMEM (its only failure mode) when that allocation fails,
and its_lpi_free() turns this into a WARN_ON().
syzbot triggers the WARN_ON() by injecting a slab allocation failure
on device teardown, which with panic_on_warn becomes a panic:
WARNING: drivers/irqchip/irq-gic-v3-its.c:2251 at its_msi_teardown+0x3a4/0x424
its_msi_teardown+0x3a4/0x424
msi_remove_device_irq_domain+0x16c/0x27c
msi_device_data_release+0x38/0x9c
The failure is transient and the consequence benign: the freed range
is simply never returned to the allocator. This does not warrant a
WARN_ON() backtrace, so log a rate-limited error instead.
Fixes: 880cb3cddd16 ("irqchip/gic-v3-its: Refactor LPI allocator")
Reported-by: syzbot+229d761b8a110e6de517@syzkaller.appspotmail.com
Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
Signed-off-by: Thomas Gleixner <tglx@kernel.org>
Assisted-by: Claude:claude-fable-5
Link: https://patch.msgid.link/20260811095532.48454-1-kmehltretter@gmail.com
Closes: https://syzkaller.appspot.com/bug?extid=229d761b8a110e6de517
|
|
Now that __irq_domain_instantiate() automatically sets
IRQ_DOMAIN_FLAG_DESTROY_GC when dgc_info is provided, the explicit
flag in the irq_domain_info is redundant. Remove it.
Signed-off-by: Qingshuang Fu <fuqingshuang@kylinos.cn>
Signed-off-by: Thomas Gleixner <tglx@kernel.org>
Reviewed-by: Herve Codina <herve.codina@bootlin.com>
Link: https://patch.msgid.link/20260907024046.28845-4-fuqingshuang@kylinos.cn
|
|
Now that __irq_domain_instantiate() automatically sets
IRQ_DOMAIN_FLAG_DESTROY_GC when dgc_info is provided, the explicit
flag in the irq_domain_info is redundant. Remove it.
Signed-off-by: Qingshuang Fu <fuqingshuang@kylinos.cn>
Signed-off-by: Thomas Gleixner <tglx@kernel.org>
Reviewed-by: Herve Codina <herve.codina@bootlin.com>
Link: https://patch.msgid.link/20260907024046.28845-3-fuqingshuang@kylinos.cn
|
|
When a driver uses irq_domain_instantiate() with dgc_info to create
generic irq chips, IRQ_DOMAIN_FLAG_DESTROY_GC is required so that
irq_domain_remove() can clean up those generic chips.
All existing in-tree callers manually set this flag today, but this
pattern is error-prone. A future new caller forgetting to set the flag
would leave generic chips allocated by irq_domain_alloc_generic_chips()
leaked on domain removal.
Set IRQ_DOMAIN_FLAG_DESTROY_GC right after
irq_domain_alloc_generic_chips() succeeds inside
__irq_domain_instantiate(). This makes automatic cleanup the default
for all users that provide dgc_info via irq_domain_instantiate().
This is the correct location for the flag because:
- irq_domain_instantiate() is a high-level wrapper which internally
allocates the generic chips, so it should also take responsibility
for arranging their cleanup.
- Setting the flag in irq_domain_alloc_generic_chips() would affect
legacy callers like __irq_alloc_domain_generic_chips(), some of
which have custom cleanup paths that manually free the generic
chips (e.g. gpio-tb10x does kfree(domain->gc) before
irq_domain_remove()), leading to use-after-free.
Signed-off-by: Qingshuang Fu <fuqingshuang@kylinos.cn>
Signed-off-by: Thomas Gleixner <tglx@kernel.org>
Reviewed-by: Herve Codina <herve.codina@bootlin.com>
Link: https://patch.msgid.link/20260907024046.28845-2-fuqingshuang@kylinos.cn
|
|
Fix typos and repeated words in comments as reported by
scripts/checkpatch.pl.
[ tglx: Fold the two trivial patches ]
Signed-off-by: Hemanth Selam <hemanth.selam@gmail.com>
Signed-off-by: Thomas Gleixner <tglx@kernel.org>
Assisted-by: Cursor:claude-opus-5
Link: https://patch.msgid.link/20260907065328.32009-1-hemanth.selam@gmail.com
Link: https://patch.msgid.link/20260907065659.12034-1-hemanth.selam@gmail.com
|
|
Scoped locking simplifies the return path in a spot, and removes
a couple lines in another couple spots. The devm mutex init will
call mutex_destroy() for us on remove, which only really matters
when CONFIG_DEBUG_MUTEXES is set, but it is nice to do anyway.
Signed-off-by: Andrew Davis <afd@ti.com>
Signed-off-by: Thomas Gleixner <tglx@kernel.org>
Reviewed-by: Radu Rendec <radu@rendec.net>
Link: https://patch.msgid.link/20260903185220.2014861-2-afd@ti.com
|
|
The match data is fetched before the instance data is available, but it is
not used until after. Skip the temporary variable and fetch the match data
after it has a place to be stored.
Signed-off-by: Andrew Davis <afd@ti.com>
Signed-off-by: Thomas Gleixner <tglx@kernel.org>
Reviewed-by: Radu Rendec <radu@rendec.net>
Link: https://patch.msgid.link/20260903185220.2014861-1-afd@ti.com
|
|
In addition to EN, ICC_CR0_EL1 contains other fields, such as LINK and
LINK_IDLE. The driver only needs to modify EN, and must preserve the
values of all other fields when enabling or disabling the CPU
interface.
Define the missing LINK and LINK_IDLE fields, and use read-modify-write
accesses to update EN without affecting the rest of ICC_CR0_EL1.
Fixes: 7ec80fb3f025 ("irqchip/gic-v5: Add GICv5 PPI support")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Signed-off-by: Sascha Bischoff <sascha.bischoff@arm.com>
Signed-off-by: Thomas Gleixner <tglx@kernel.org>
Reviewed-by: Marc Zyngier <maz@kernel.org>
Link: https://patch.msgid.link/20260907164945.714545-1-sascha.bischoff@arm.com
Closes: https://lore.kernel.org/r/20260807121703.D4B7A1F00A3A@smtp.kernel.org
|
|
The MT6351 codec platform driver uses mt6351_of_match to bind devices
with compatible mediatek,mt6351-sound. The codec can be a separate
module, but the OF table is not exported to module alias metadata.
Publish the existing table without changing codec matching, register
access or the machine-driver configuration.
Fixes: a74d51ba0e17 ("ASoC: add mt6351 codec driver")
Signed-off-by: hpp.iscas <hppiscas@163.com>
Link: https://patch.msgid.link/20260905133210.63803-1-hppiscas@163.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
On Layerscape platforms when SMMU is disabled by ATF, the root DPRC probes
with its dma_mask pointer unset which leads to a notification:
"DMA mask not set"
so the device is left with a zero DMA mask instead of a sane default.
Let's seed the masks for all cases.
It was tested on LX2160A with no SMMU on the MC domain: the warning is gone
and the DPAA2 children probe unchanged.
Signed-off-by: Vincent Jardin <vjardin@free.fr>
Reviewed-by: Ioana Ciornei <ioana.ciornei@nxp.com>
Link: https://lore.kernel.org/r/20260731-for-upstream-fsl-mc-dprc-dma-mask-v2-1-ea7058b90f06@free.fr
Signed-off-by: Christophe Leroy (CS GROUP) <chleroy@kernel.org>
|
|
Drop the second 'for', reported by checkpatch.pl as a possible repeated
word. Only touches a comment, no code changes.
Assisted-by: Cursor:claude-opus-5
Signed-off-by: Hemanth Selam <hemanth.selam@gmail.com>
Link: https://lore.kernel.org/r/20260904124540.7652-3-hemanth.selam@gmail.com
Signed-off-by: Christophe Leroy (CS GROUP) <chleroy@kernel.org>
|
|
A C=2 build on mpc83xx_defconfig provides following warnings:
drivers/soc/fsl/qe/gpio.c:44:34: warning: incorrect type in assignment (different base types)
drivers/soc/fsl/qe/gpio.c:44:34: expected restricted __be32 [usertype] cpdata
drivers/soc/fsl/qe/gpio.c:44:34: got unsigned int [usertype] cpdata
drivers/soc/fsl/qe/gpio.c:45:34: warning: incorrect type in assignment (different base types)
drivers/soc/fsl/qe/gpio.c:45:34: expected restricted __be32 [usertype] cpdir1
drivers/soc/fsl/qe/gpio.c:45:34: got unsigned int
drivers/soc/fsl/qe/gpio.c:46:34: warning: incorrect type in assignment (different base types)
drivers/soc/fsl/qe/gpio.c:46:34: expected restricted __be32 [usertype] cpdir2
drivers/soc/fsl/qe/gpio.c:46:34: got unsigned int
drivers/soc/fsl/qe/gpio.c:47:34: warning: incorrect type in assignment (different base types)
drivers/soc/fsl/qe/gpio.c:47:34: expected restricted __be32 [usertype] cppar1
drivers/soc/fsl/qe/gpio.c:47:34: got unsigned int
drivers/soc/fsl/qe/gpio.c:48:34: warning: incorrect type in assignment (different base types)
drivers/soc/fsl/qe/gpio.c:48:34: expected restricted __be32 [usertype] cppar2
drivers/soc/fsl/qe/gpio.c:48:34: got unsigned int
drivers/soc/fsl/qe/gpio.c:49:33: warning: incorrect type in assignment (different base types)
drivers/soc/fsl/qe/gpio.c:49:33: expected restricted __be32 [usertype] cpodr
drivers/soc/fsl/qe/gpio.c:49:33: got unsigned int
drivers/soc/fsl/qe/gpio.c:297:17: warning: restricted __be32 degrades to integer
drivers/soc/fsl/qe/gpio.c:299:17: warning: restricted __be32 degrades to integer
drivers/soc/fsl/qe/gpio.c:302:17: warning: restricted __be32 degrades to integer
drivers/soc/fsl/qe/gpio.c:304:17: warning: restricted __be32 degrades to integer
drivers/soc/fsl/qe/gpio.c:308:18: warning: restricted __be32 degrades to integer
drivers/soc/fsl/qe/gpio.c:314:9: warning: restricted __be32 degrades to integer
The problem is the 'struct qe_pio_reg' embedded in 'struct qe_gpio_chip'
to save register values. As the values are read with ioread32be(), they
are now in CPU byte order and can't be stored as-is in a __be32 object.
Replace 'struct qe_pio_reg saved_regs' by individual u32 fields.
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202608051952.ADkLIB86-lkp@intel.com/
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202608130908.gEy44F1D-lkp@intel.com/
Link: https://lore.kernel.org/r/6a84b38e766729676b375c93bf54c67ea455288d.1786080840.git.chleroy@kernel.org
Signed-off-by: Christophe Leroy (CS GROUP) <chleroy@kernel.org>
|
|
Rust does now have abstractions for dma_fence. These abstractions are
quite complicated and require expertise with both the C and the Rust
side. Therefore, using the existing entry also for maintenance of the
Rust code appears reasonable.
Philipp volunteers to help maintain the dma_fence abstractions. Add a
corresponding MAINTAINERS entry.
Signed-off-by: Philipp Stanner <phasta@kernel.org>
Acked-by: Christian König <christian.koenig@amd.com>
Acked-by: Sumit Semwal <sumit.semwal@linaro.org>
Tested-by: Daniel Almeida <daniel.almeida@collabora.com>
Acked-by: Danilo Krummrich <dakr@kernel.org>
Link: https://patch.msgid.link/20260905085343.1827305-4-phasta@kernel.org
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
DMA fences are synchronisation primitives that will be needed by all
Rust GPU drivers.
The dma_fence framework sets a number of rules, notably:
- fences must only be signaled once
- all fences must be signaled at some point
- fence error codes must only be set before signaling
- every pointer to a fence must be backed by a reference
All those rules are being addressed by these abstractions.
To cleanly decouple fence issuers and consumers, two types are provided:
- DriverFence: the only fence type that can be signaled and that
carries driver-specific data.
- Fence: the fence type to be shared with other drivers and / or
userspace. The only type callbacks can be registered on.
Cannot be signaled.
Hereby, a Fence lives in the same chunk of memory as a DriverFence. Both
share the refcount of the underlying C dma_fence. Since this
implementation does not provide a custom dma_fence_backend_ops.release()
function, the memory is freed by the dma_fence backend once the refcount
drops to 0.
To create a DriverFence, the user must first allocate a
DriverFenceAllocation, so that the creation of the DriverFence later on
can always succeed. Otherwise, deadlocks could occur if fences need to
be created in a GPU job submission path.
Synchronization is ensured by the dma_fence backend.
All DriverFence's created through this abstraction must be signaled by
the creator with an error code. In case a DriverFence drops without
being signaled beforehand, it is signaled with -ECANCELLED as its
error and a warning is printed. This allows the Rust abstraction to very
cleanly decouple fence issuer and consumer by relying on the decoupling
mechanisms in the C backend, which ensures through RCU and the
'signaled' fence-flag that dma_fence_backend_ops functions cannot
access the potentially unloaded driver code anymore.
Signalling fences on drop thus grants many advantages. Not signaling
fences on drop would risk deadlock and does not grant real advantages:
By definition only the drivers can ensure that a fence always represents
the hardware's state correctly.
This implementation models a DmaFenceContext object on which fences are
to be created, thereby ensuring correct sequence numbering according to
the timeline.
dma_fence supports a variety of callbacks. The mandatory callbacks
(get_timeline_name() and get_driver_name()) are implemented in this
patch. For convenience, they store those name parameters in the fence
context, saving the driver from implementing these two callbacks.
Support for other callbacks (like for hardware signaling) is prepared
for through the fact that both DriverFence and Fence live in the same
allocation, allowing for usage of container_of from the callback to
access the driver-specific data.
It is expected that other callbacks, added in the future, also mostly
operate on the generic data in the FenceContext. To make this safe, the
implementation ensures through a lifetime that a DriverFence cannot
outlive its FenceContext.
Synchronization for dma_fence_ops callbacks is ensured by only running the
Rust deconstructor delayed with call_rcu(), which prevents UAF-bugs
should a DriverFence drop while a Fence callback is currently operating
on the associated driver data. Since they can also operate on the
FenceContext's data, its drop implementation also performs the necessary
delay with rcu_barrier().
An additional issue discovered during the review process of this code is
that there is (currently) no mechanism in Rust to prevent someone from
circumventing the DriverFence's FenceContext-reference's lifetime by
"forgetting" the fence, e.g. with core::mem::forget(). This would enable
UAF bugs on the FenceContext. Throw a panic if this happens and document
a path towards a more robust solution.
Add abstractions for dma_fence in Rust.
Signed-off-by: Philipp Stanner <phasta@kernel.org>
Tested-by: Daniel Almeida <daniel.almeida@collabora.com>
Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com>
Link: https://patch.msgid.link/20260905085343.1827305-3-phasta@kernel.org
[ In dma_fence_callback(), split combined unsafe block into separate
blocks for container_of!() and pointer dereference. - Danilo ]
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
node_init_node_access() frees the access node with kfree() if
device_register() fails. After device_register() the embedded device is
initialized and must be released with put_device() so that
node_access_release() can free it.
Fixes: 08d9dbe72b1f ("node: Link memory nodes to their compute nodes")
Signed-off-by: Linkai Gong <gonglinkai@kylinos.cn>
Link: https://patch.msgid.link/20260907024732.1452228-1-gonglinkai@kylinos.cn
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
imx8_run(), imx8x_run() and imx8_shutdown() check the return value of
every imx_sc_misc_set_control() call but ignore the one from
imx_sc_pm_cpu_start(), which propagates errors from imx_scu_call_rpc()
and can fail with -ETIMEDOUT, -EINVAL or -EPERM.
Reporting success after a failed start leaves the caller loading
firmware onto a core that is not running, and a failed shutdown is
similarly hidden from imx_chip_core_shutdown() callers, which do act on
the return value.
Propagate the error, matching imx95_core_shutdown() in imx9.c.
Signed-off-by: Ștefan Ghețu <stefanghetu9@gmail.com>
Link: https://patch.msgid.link/20260902175517.209406-1-stefanghetu9@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools
Pull perf tools fixes from Namhyung Kim:
"Two simple fixes for this cycle:
- Do not use separate debug files for Intel PT decoding
- Fix size of raw data in the PowerPC VPA DTL samples"
* tag 'perf-tools-fixes-for-v7.3-2026-09-07' of git://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools:
perf powerpc-vpadtl: Fix raw_size of DTL samples
perf symbol: Do not use debug file as the binary type
|
|
Fix typos in comments, reported by scripts/checkpatch.pl using the
misspelling list in scripts/spelling.txt. Only touches comments, no code
changes.
Assisted-by: Cursor:claude-opus-5
Signed-off-by: Hemanth Selam <hemanth.selam@gmail.com>
Link: https://patch.msgid.link/20260904110420.13707-1-hemanth.selam@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The interrupt handler distinguishes the rail that reported the fault, but
the body ignores it. Every SW interrupt walks the regulator array looking
for the name "SW3" and every LDO interrupt looks for "LDO3", so an
over-current on SW1 is reported to the consumers of SW3 while the
consumers of SW1 hear nothing.
The lookup itself is unreliable as well. rdev_get_name() returns the
device tree regulator-name property whenever the board supplies one, and
only falls back to the name in the driver descriptor when it does not.
The binding example for this device sets regulator-name to "sw3" and
"ldo3", which strcmp() does not match against the upper case literals
used here, so a board that follows the documentation gets no over-current
notification at all. A board that names its rails after the schematic
does not match either. No other driver in the tree selects a notification
target this way.
Replace the name lookup with rdev_get_id(), which returns the descriptor
id set by the driver and cannot be overridden from the device tree, and
take both the id and the event from a table indexed by the interrupt.
The die temperature interrupts keep notifying every regulator since they
report a chip wide condition.
Fixes: 7320d41c29bb ("regulator: pf1550: Add support for regulator")
Signed-off-by: Donggeun Yoo <donggeunyoo.kernel@gmail.com>
Link: https://patch.msgid.link/20260904105624.48577-1-donggeunyoo.kernel@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/leitao/linux
Pull configfs fixes from Breno Leitao:
- A symlink racing with rmdir of its target could reach a freed
->ci_dentry.
The reference that get_target() takes pins the config_item, not
its dentry; the dentry is pinned by DCACHE_PERSISTENT, which
configfs_remove_dir() drops while the item is still alive.
Take the target's configfs_dirent under ->d_lock instead of chasing
->ci_dentry.
- configfs_rmdir() left the dentry hashed across the final put of the
item, and configfs_get_config_item() treats a hashed dentry as proof
of a live item. A concurrent symlink could therefore resurrect a
dying item and hit a use-after-free.
Unhash in configfs_remove_dir(), while the item is still guaranteed
to be there.
Both issues were found by syzbot.
* tag 'configfs-7.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/leitao/linux:
configfs: unhash the dentry before dropping the item in rmdir
configfs: pin the symlink target's dirent instead of chasing ->ci_dentry
|
|
DMA page allocation fallbacks use alloc_pages_node() with get_order(size),
wasting the unused tail for non-power-of-two requests.
Use alloc_pages_exact_nid() and free_pages_exact() so that a buddy
fallback retains only requested pages.
Signed-off-by: Qingfang Deng <qingfang.deng@linux.dev>
Link: https://lore.kernel.org/r/20260903012914.312305-1-qingfang.deng@linux.dev
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
|
|
Function dma_opt_mapping_size() implies from its name that it returns a
target or sweet spot DMA mapping size. However, it is just an upper limit
optimal DMA mapping size. Above this size, DMA mapping performance may
significantly degrade.
Rename to dma_max_opt_mapping_size() to reflect the real behaviour. Also
rename the internal DMA mapping symbols to align with this.
The DMA API documentation already described this behaviour properly (so
there is nothing to update).
Signed-off-by: John Garry <john.garry@linux.dev>
Link: https://lore.kernel.org/r/20260831093620.3481337-1-john.g.garry@oracle.com
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
|
|
Add a missing paragraph about code review in 6.Followthrough.rst and
fix a grammatical error. Fix formatting and translate an English snippet
in 8.Conclusion.rst. Fix several instances of omitted 'xyzzy'
placeholders in code examples, restore truncated sentences, and fix
missing links in adding-syscalls.rst. Fix typos in applying-patches.rst.
Fix a typo and fix a broken markdown link to reStructuredText format
in backporting.rst.
Signed-off-by: Daniel Pereira <danielmaraboo@gmail.com>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Message-ID: <20260829162438.13039-4-danielmaraboo@gmail.com>
|
|
Fix minor typographical, punctuation, and untranslated text errors in
the Brazilian Portuguese translations of Documentation/process/2.Process.rst,
3.Early-stage.rst, 4.Coding.rst, and 5.Posting.rst to better match the
original text and improve readability.
Signed-off-by: Daniel Pereira <danielmaraboo@gmail.com>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Message-ID: <20260829162438.13039-3-danielmaraboo@gmail.com>
|
|
Translate Documentation/process/embargoed-hardware-issues.rst into
Brazilian Portuguese and add it to the pt_BR process index.
Signed-off-by: Daniel Pereira <danielmaraboo@gmail.com>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Message-ID: <20260829162438.13039-2-danielmaraboo@gmail.com>
|
|
Translate volatile-considered-harmful.rst into Brazilian Portuguese and
add it to the pt_BR process documentation index.
Assisted-by: ChatGPT:GPT-5.5
Signed-off-by: Lucas Adryell Ramalho <lucasadramalho@gmail.com>
Reviewed-by: Daniel Pereira <danielmaraboo@gmail.com>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Message-ID: <20260830205912.478358-1-lucasadramalho@gmail.com>
|
|
NLM_F_DUMP_FILTERED is only set on data elements in the conntrack dump.
But when everything is filtered out it is confusing for the user space,
since the flag is not reported anymore and it looks like the table was
empty, which may or may not be the case.
'answer_flags' were introduced precisely for this use case, and the
conntrack dump should set the flag in there in case the filtering was
applied.
This is important, for example, to be able to tell if the filters are
supported or not by the kernel without modifying the kernel state.
With the proper reporting of NLM_F_DUMP_FILTERED on NLMSG_DONE, an
application in user space can just try and dump with an arbitrary
filter without worrying that there could be no matching entry. The
reported flag will signal that the filtering was applied and therefore
supported.
Fixes: cb8aa9a3affb ("netfilter: ctnetlink: add kernel side filtering for dump")
Cc: stable@vger.kernel.org
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Reviewed-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
|
|
The ip6tables traverser doesn't search the extension header chain unless
userspace did set the IP6T_F_PROTO flag.
This also means that userspace that sets the e->ipv6.proto flag can bypass
the protocol check for the rule by not setting this flag.
That in turn means that all ip6_tables modules and targets that want to
reject rules without '-p' flag MUST also check for that flag.
Not all do, likely because they got copied from iptables which lacks
this flag (no extension headers).
Instead of fixing up all the relevant targets, emulate ip6tables behaviour
in the kernel (like nft_compat.c) and set the flag if the protocol is set.
Reported-by: Zhiling Zou <zhilinz@nebusec.ai>
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
|
|
This feature is required to use 32bit arptables binary on 64bit kernels.
It's already off in many distributions including Debian and Fedora for
many years.
Zap arptables first, it's the most esoteric of the 4 flavors.
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
|
|
Translate coding-assistants.rst into Brazilian Portuguese
and add it to the pt_BR process documentation index.
Assisted-by: LLM
Signed-off-by: Giovanna Macedo Cox <giovannamccds@gmail.com>
Reviewed-by: Daniel Pereira <danielmaraboo@gmail.com>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Message-ID: <20260902005603.18836-1-giovannamccds@gmail.com>
|
|
Currently the documentation still mention dynticks-testing.
Recently the repository name and the tool have been renamed
to cpunoise (see Link tag below), so fix the URL.
Link: https://lore.kernel.org/all/20260815083728.15470-1-marco.crivellari@suse.com/
Signed-off-by: Marco Crivellari <marco.crivellari@suse.com>
Acked-by: Frederic Weisbecker <frederic@kernel.org>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Message-ID: <20260902092434.85096-3-marco.crivellari@suse.com>
|
