| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
If the export_binary parameter is disabled on runtime, profiles that
were loaded before that will still have their rawdata stored in
apparmorfs, with a symbolic link to the rawdata on the policy
directory. When one of those profiles are replaced, the rawdata is set
to NULL, but when trying to resolve the symbolic links to rawdata for
that profile, it will try to dereference profile->rawdata->name when
profile->rawdata is now NULL causing an oops. Fix it by checking if
rawdata is set.
[ 168.653080] BUG: kernel NULL pointer dereference, address: 0000000000000088
[ 168.657420] #PF: supervisor read access in kernel mode
[ 168.660619] #PF: error_code(0x0000) - not-present page
[ 168.663613] PGD 0 P4D 0
[ 168.665450] Oops: Oops: 0000 [#1] SMP NOPTI
[ 168.667836] CPU: 1 UID: 0 PID: 1729 Comm: ls Not tainted 6.19.0-rc7+ #3 PREEMPT(voluntary)
[ 168.672308] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
[ 168.679327] RIP: 0010:rawdata_get_link_base.isra.0+0x23/0x330
[ 168.682768] Code: 90 90 90 90 90 90 90 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 41 55 41 54 53 48 83 ec 18 48 89 55 d0 48 85 ff 0f 84 e3 01 00 00 <48> 83 3c 25 88 00 00 00 00 0f 84 d4 01 00 00 49 89 f6 49 89 cc e8
[ 168.689818] RSP: 0018:ffffcdcb8200fb80 EFLAGS: 00010282
[ 168.690871] RAX: ffffffffaee74ec0 RBX: 0000000000000000 RCX: ffffffffb0120158
[ 168.692251] RDX: ffffcdcb8200fbe0 RSI: ffff88c187c9fa80 RDI: ffff88c186c98a80
[ 168.693593] RBP: ffffcdcb8200fbc0 R08: 0000000000000000 R09: 0000000000000000
[ 168.694941] R10: 0000000000000000 R11: 0000000000000000 R12: ffff88c186c98a80
[ 168.696289] R13: 00007fff005aaa20 R14: 0000000000000080 R15: ffff88c188f4fce0
[ 168.697637] FS: 0000790e81c58280(0000) GS:ffff88c20a957000(0000) knlGS:0000000000000000
[ 168.699227] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 168.700349] CR2: 0000000000000088 CR3: 000000012fd3e000 CR4: 0000000000350ef0
[ 168.701696] Call Trace:
[ 168.702325] <TASK>
[ 168.702995] rawdata_get_link_data+0x1c/0x30
[ 168.704145] vfs_readlink+0xd4/0x160
[ 168.705152] do_readlinkat+0x114/0x180
[ 168.706214] __x64_sys_readlink+0x1e/0x30
[ 168.708653] x64_sys_call+0x1d77/0x26b0
[ 168.709525] do_syscall_64+0x81/0x500
[ 168.710348] ? do_statx+0x72/0xb0
[ 168.711109] ? putname+0x3e/0x80
[ 168.711845] ? __x64_sys_statx+0xb7/0x100
[ 168.712711] ? x64_sys_call+0x10fc/0x26b0
[ 168.713577] ? do_syscall_64+0xbf/0x500
[ 168.714412] ? do_user_addr_fault+0x1d2/0x8d0
[ 168.715404] ? irqentry_exit+0xb2/0x740
[ 168.716359] ? exc_page_fault+0x90/0x1b0
[ 168.717307] entry_SYSCALL_64_after_hwframe+0x76/0x7e
Fixes: 1180b4c757aab ("apparmor: fix dangling symlinks to policy rawdata after replacement")
Signed-off-by: Georgia Garcia <georgia.garcia@canonical.com>
Signed-off-by: John Johansen <john.johansen@canonical.com>
|
|
Add a quirk for a Lenovo laptop (SSID: 0x17aa3821) to allow using sidecar
CS35L57 amps with CS42L43 codec.
Signed-off-by: Maciej Strozek <mstrozek@opensource.cirrus.com>
Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com>
Link: https://patch.msgid.link/20260128092410.1540583-1-mstrozek@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The current implementation uses `vgic_state_iter` in `struct
vgic_dist` to track the sequence position. This effectively makes the
iterator shared across all open file descriptors for the VM.
This approach has significant drawbacks:
- It enforces mutual exclusion, preventing concurrent reads of the
debugfs file (returning -EBUSY).
- It relies on storing transient iterator state in the long-lived
VM structure (`vgic_dist`).
Refactor the implementation to use the standard `seq_file` iterator.
Instead of storing state in `kvm_arch`, rely on the `pos` argument
passed to the `start` and `next` callbacks, which tracks the logical
index specific to the file descriptor.
This change enables concurrent access and eliminates the
`vgic_state_iter` field from `struct vgic_dist`.
Signed-off-by: Fuad Tabba <tabba@google.com>
Link: https://patch.msgid.link/20260202085721.3954942-4-tabba@google.com
Signed-off-by: Marc Zyngier <maz@kernel.org>
|
|
The vgic-debug interface implementation uses XArray marks
(`LPI_XA_MARK_DEBUG_ITER`) to "snapshot" LPIs at the start of iteration.
This modifies global state for a read-only operation and complicates
reference counting, leading to leaks if iteration is aborted or fails.
Reimplement the iterator to use dynamic iteration logic:
- Remove `lpi_idx` from `struct vgic_state_iter`.
- Replace the XArray marking mechanism with dynamic iteration using
`xa_find_after(..., XA_PRESENT)`.
- Wrap XArray traversals in `rcu_read_lock()`/`rcu_read_unlock()` to
ensure safety against concurrent modifications (e.g., LPI unmapping).
- Handle potential races where an LPI is removed during iteration by
gracefully skipping it in `show()`, rather than warning.
- Remove the unused `LPI_XA_MARK_DEBUG_ITER` definition.
This simplifies the lifecycle management of the iterator and prevents
resource leaks associated with the marking mechanism, and paves the way
for using a standard seq_file iterator.
Signed-off-by: Fuad Tabba <tabba@google.com>
Link: https://patch.msgid.link/20260202085721.3954942-3-tabba@google.com
Signed-off-by: Marc Zyngier <maz@kernel.org>
|
|
The current implementation uses `idreg_debugfs_iter` in `struct
kvm_arch` to track the sequence position. This effectively makes the
iterator shared across all open file descriptors for the VM.
This approach has significant drawbacks:
- It enforces mutual exclusion, preventing concurrent reads of the
debugfs file (returning -EBUSY).
- It relies on storing transient iterator state in the long-lived VM
structure (`kvm_arch`).
- The use of `u8` for the iterator index imposes an implicit limit of
255 registers. While not currently exceeded, this is fragile against
future architectural growth. Switching to `loff_t` eliminates this
overflow risk.
Refactor the implementation to use the standard `seq_file` iterator.
Instead of storing state in `kvm_arch`, rely on the `pos` argument
passed to the `start` and `next` callbacks, which tracks the logical
index specific to the file descriptor.
This change enables concurrent access and eliminates the
`idreg_debugfs_iter` field from `struct kvm_arch`.
Signed-off-by: Fuad Tabba <tabba@google.com>
Link: https://patch.msgid.link/20260202085721.3954942-2-tabba@google.com
Signed-off-by: Marc Zyngier <maz@kernel.org>
|
|
Introduce support in AP mode for parsing of the Operating Mode Notification
frame sent by the client to enable/disable MLO eMLSR or eMLMR if supported
by both the AP and the client.
Add drv_set_eml_op_mode mac80211 callback in order to configure underlay
driver with eMLSR/eMLMR info.
Tested-by: Christian Marangi <ansuelsmth@gmail.com>
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Link: https://patch.msgid.link/20260129-mac80211-emlsr-v4-1-14bdadf57380@kernel.org
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Add support for making UHR connections and accepting AP
stations with UHR support.
Link: https://patch.msgid.link/20260130164259.7185980484eb.Ieec940b58dbf8115dab7e1e24cb5513f52c8cb2f@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Add initial support for making UHR connections (or suppressing
that), adding UHR capable stations on the AP side, encoding
and decoding UHR MCSes (except rate calculation for the new
MCSes 17, 19, 20 and 23) as well as regulatory support.
Link: https://patch.msgid.link/20260130164259.54cc12fbb307.I26126bebd83c7ab17e99827489f946ceabb3521f@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
This is based on Draft P802.11bn_D1.2, but that's still very
incomplete, so don't handle a number of things and make some
local decisions such as using 40 bits for MAC capabilities
and 8 bits for PHY capabilities.
Link: https://patch.msgid.link/20260130164259.b28c9456ff94.I5b11fb0345a933bf497fd802aecc72932d58dd68@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
This reverts commit d930ffa5d6e8867a290db9c6aad1c62731aeb2c3.
According to Thomas, commit d930ffa5d6e8 ("drm/gma500: use
drm_crtc_vblank_crtc()") breaks the driver with a NULL-ptr oops on
startup. This is because the IRQ initialization in gma_irq_install() now
uses CRTCs that are only allocated later in psb_modeset_init(). Stack
trace is below. Revert. Go back to the drawing board.
[ 65.831766] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000021: 0000 [#1] SMP KASAN NOPTI
[ 65.832114] KASAN: null-ptr-deref in range [0x0000000000000108-0x000000000000010f]
[ 65.832232] CPU: 1 UID: 0 PID: 296 Comm: (udev-worker) Tainted: G E 6.19.0-rc6-1-default+ #4622 PREEMPT(voluntary)
[ 65.832376] Tainted: [E]=UNSIGNED_MODULE
[ 65.832448] Hardware name: /DN2800MT, BIOS MTCDT10N.86A.0164.2012.1213.1024 12/13/2012
[ 65.832543] RIP: 0010:drm_crtc_vblank_crtc+0x24/0xd0
[ 65.832652] Code: 90 90 90 90 90 90 0f 1f 44 00 00 48 89 f8 48 81 c7
18 01 00 00 48 83 ec 10 48 ba 00 00 00 00 00 fc ff df 48 89 f9 48 c1 e9
03 <0f> b6 14 11 84 d2 74 05 80 fa 03 7e 58 48 89 c6 8b 90 18 01 00
00
[ 65.832820] RSP: 0018:ffff88800c8f7688 EFLAGS: 00010006
[ 65.832919] RAX: fffffffffffffff0 RBX: ffff88800fff4928 RCX: 0000000000000021
[ 65.833011] RDX: dffffc0000000000 RSI: ffffc90000978130 RDI: 0000000000000108
[ 65.833107] RBP: ffffed1001ffea03 R08: 0000000000000000 R09: ffffed100191eec7
[ 65.833199] R10: 0000000000000001 R11: 0000000000000001 R12: ffff8880014480c8
[ 65.833289] R13: dffffc0000000000 R14: fffffffffffffff0 R15: ffff88800fff4000
[ 65.833380] FS: 00007fe53d4d5d80(0000) GS:ffff888148dd8000(0000) knlGS:0000000000000000
[ 65.833488] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 65.833575] CR2: 00007fac707420b8 CR3: 000000000ebd1000 CR4: 00000000000006f0
[ 65.833668] Call Trace:
[ 65.833735] <TASK>
[ 65.833808] gma_irq_preinstall+0x190/0x3e0 [gma500_gfx]
[ 65.834054] gma_irq_install+0xb2/0x240 [gma500_gfx]
[ 65.834282] psb_driver_load+0x7b2/0x1090 [gma500_gfx]
[ 65.834516] ? __pfx_psb_driver_load+0x10/0x10 [gma500_gfx]
[ 65.834726] ? ksize+0x1d/0x40
[ 65.834817] ? drmm_add_final_kfree+0x3b/0xb0
[ 65.834935] ? __pfx_psb_pci_probe+0x10/0x10 [gma500_gfx]
[ 65.835164] psb_pci_probe+0xc8/0x150 [gma500_gfx]
[ 65.835384] local_pci_probe+0xd5/0x190
[ 65.835492] pci_call_probe+0x167/0x4b0
[ 65.835594] ? __pfx_pci_call_probe+0x10/0x10
[ 65.835693] ? local_clock+0x11/0x30
[ 65.835808] ? __pfx___driver_attach+0x10/0x10
[ 65.835915] ? do_raw_spin_unlock+0x55/0x230
[ 65.836014] ? pci_match_device+0x303/0x790
[ 65.836124] ? pci_match_device+0x386/0x790
[ 65.836226] ? __pfx_pci_assign_irq+0x10/0x10
[ 65.836320] ? kernfs_create_link+0x16a/0x230
[ 65.836418] ? do_raw_spin_unlock+0x55/0x230
[ 65.836526] ? __pfx___driver_attach+0x10/0x10
[ 65.836626] pci_device_probe+0x175/0x2c0
[ 65.836735] call_driver_probe+0x64/0x1e0
[ 65.836842] really_probe+0x194/0x740
[ 65.836951] ? __pfx___driver_attach+0x10/0x10
[ 65.837053] __driver_probe_device+0x18c/0x3a0
[ 65.837163] ? __pfx___driver_attach+0x10/0x10
[ 65.837262] driver_probe_device+0x4a/0x120
[ 65.837369] __driver_attach+0x19c/0x550
[ 65.837474] ? __pfx___driver_attach+0x10/0x10
[ 65.837575] bus_for_each_dev+0xe6/0x150
[ 65.837669] ? local_clock+0x11/0x30
[ 65.837770] ? __pfx_bus_for_each_dev+0x10/0x10
[ 65.837891] bus_add_driver+0x2af/0x4f0
[ 65.838000] ? __pfx_psb_init+0x10/0x10 [gma500_gfx]
[ 65.838236] driver_register+0x19f/0x3a0
[ 65.838342] ? rcu_is_watching+0x11/0xb0
[ 65.838446] do_one_initcall+0xb5/0x3a0
[ 65.838546] ? __pfx_do_one_initcall+0x10/0x10
[ 65.838644] ? __kasan_slab_alloc+0x2c/0x70
[ 65.838741] ? rcu_is_watching+0x11/0xb0
[ 65.838837] ? __kmalloc_cache_noprof+0x3e8/0x6e0
[ 65.838937] ? klp_module_coming+0x1a0/0x2e0
[ 65.839033] ? do_init_module+0x85/0x7f0
[ 65.839126] ? kasan_unpoison+0x40/0x70
[ 65.839230] do_init_module+0x26e/0x7f0
[ 65.839341] ? __pfx_do_init_module+0x10/0x10
[ 65.839450] init_module_from_file+0x13f/0x160
[ 65.839549] ? __pfx_init_module_from_file+0x10/0x10
[ 65.839651] ? __lock_acquire+0x578/0xae0
[ 65.839791] ? do_raw_spin_unlock+0x55/0x230
[ 65.839886] ? idempotent_init_module+0x585/0x720
[ 65.839993] idempotent_init_module+0x1ff/0x720
[ 65.840097] ? __pfx_cred_has_capability.isra.0+0x10/0x10
[ 65.840211] ? __pfx_idempotent_init_module+0x10/0x10
Reported-by: Thomas Zimmermann <tzimmermann@suse.de>
Closes: https://lore.kernel.org/r/5aec1964-072c-4335-8f37-35e6efb4910e@suse.de
Fixes: d930ffa5d6e8 ("drm/gma500: use drm_crtc_vblank_crtc()")
Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Tested-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Link: https://patch.msgid.link/20260130151319.31264-1-jani.nikula@intel.com
|
|
Pink-Ke Shih says:
==================
rtw-next patches for -next
Mainly refactor flow for preparation of rtw89 RTL8922DE. Others are random
fixes and refinements.
==================
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Prior initiating communication in a DFS channel, there should be a
monitoring of RADAR in that channel for a minimum of 600 seconds if it
is a Weather RADAR channel and 60 seconds for other DFS channels. This
Channel Availability Check(CAC) is currently implemented by scheduling
a work item for execution with a delay equal to an appropriate timeout.
But this work item is observed to take more delay than specified
(4-5 seconds in regular DFS channels and 25-30 seconds in Weather RADAR
channels). Even though this delay is expected in case of delayed work
queue as there is no guarantee that the work will be scheduled exactly
after the specified delay, a delay of more than 20 seconds is too much
for the AP to be in non-operational state.
Recently commit 7ceba45a6658 ("wifi: cfg80211: add an hrtimer based
delayed work item") added an infrastructure to overcome this issue by
supporting high resolution timers for mac80211 delayed work, which do not
have this timeout latency. Switch the CAC timeout to use this
infrastructure, so the CAC completion handling is triggered with tighter
timing and reduced latency.
Signed-off-by: Amith A <amith.a@oss.qualcomm.com>
Link: https://patch.msgid.link/20260130035511.2328713-1-amith.a@oss.qualcomm.com
[fix delay handling]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
After the split of ieee80211.h some include guard comments weren't
updated, update them to their new file names.
Signed-off-by: Lachlan Hodges <lachlan.hodges@morsemicro.com>
Link: https://patch.msgid.link/20260130005319.70019-1-lachlan.hodges@morsemicro.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Currently it is not possible to distinguish between the case where a
process has already exited and the case where a process is in a
different namespace, as both return -ESRCH.
glibc's pidfd_getpid() procfs-based implementation returns -EREMOTE
in the latter, so that distinguishing the two is possible, as the
fdinfo in procfs will list '0' as the PID in that case:
https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/pidfd_getpid.c;h=860829cf07da2267484299ccb02861822c0d07b4;hb=HEAD#l121
Change the error code so that the kernel also returns -EREMOTE in
that case.
Fixes: 7477d7dce48a ("pidfs: allow to retrieve exit information")
Signed-off-by: Luca Boccassi <luca.boccassi@gmail.com>
Link: https://patch.msgid.link/20260127225209.2293342-1-luca.boccassi@gmail.com
Signed-off-by: Christian Brauner <brauner@kernel.org>
|
|
Commit 8f1fc1bf1a3d ("dma: contiguous: Reserve default CMA heap")
introduced a bug where dma_heap_cma_register_heap() is called with
a NULL pointer when dma_contiguous_reserve_area() fails to reserve
the CMA area.
When dma_contiguous_reserve_area() fails, dma_contiguous_default_area
remains NULL (initialized as a global variable), but the code doesn't
check the return value and proceeds to call dma_heap_cma_register_heap()
with this NULL pointer.
Later during boot, add_cma_heaps() iterates through the dma_areas[]
array and attempts to register heaps. When it encounters the NULL
pointer stored by the earlier call, it crashes in __add_cma_heap()
-> dma_heap_add() when trying to dereference the NULL CMA pointer.
The crash manifests as:
Unable to handle kernel NULL pointer dereference at virtual address
0000000000000038
...
Call trace:
dma_heap_add+0x40/0x2b0
__add_cma_heap+0x80/0xe0
add_cma_heaps+0x64/0xb0
do_one_initcall+0x60/0x318
kernel_init_freeable+0x260/0x2f0
kernel_init+0x2c/0x168
ret_from_fork+0x10/0x20
Fix this by checking the return value of dma_contiguous_reserve_area()
and only calling dma_heap_cma_register_heap() when the reservation
succeeds.
Fixes: 8f1fc1bf1a3d ("dma: contiguous: Reserve default CMA heap")
Signed-off-by: Shanker Donthineni <sdonthineni@nvidia.com>
Reviewed-by: T.J. Mercier <tjmercier@google.com>
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Link: https://lore.kernel.org/r/20260129181317.2429196-1-sdonthineni@nvidia.com
|
|
The dma_map_sg tracepoint can trigger a perf buffer overflow when
tracing large scatter-gather lists. With devices like virtio-gpu
creating large DRM buffers, nents can exceed 1000 entries, resulting
in:
phys_addrs: 1000 * 8 bytes = 8,000 bytes
dma_addrs: 1000 * 8 bytes = 8,000 bytes
lengths: 1000 * 4 bytes = 4,000 bytes
Total: ~20,000 bytes
This exceeds PERF_MAX_TRACE_SIZE (8192 bytes), causing:
WARNING: CPU: 0 PID: 5497 at kernel/trace/trace_event_perf.c:405
perf buffer not large enough, wanted 24620, have 8192
Cap all three dynamic arrays at 128 entries using min() in the array
size calculation. This ensures arrays are only as large as needed
(up to the cap), avoiding unnecessary memory allocation for small
operations while preventing overflow for large ones.
The tracepoint now records the full nents/ents counts and a truncated
flag so users can see when data has been capped.
Changes in v2:
- Use min(nents, DMA_TRACE_MAX_ENTRIES) for dynamic array sizing
instead of fixed DMA_TRACE_MAX_ENTRIES allocation (feedback from
Steven Rostedt)
- This allocates only what's needed up to the cap, avoiding waste
for small operations
Reported-by: syzbot+28cea38c382fd15e751a@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=28cea38c382fd15e751a
Tested-by: syzbot+28cea38c382fd15e751a@syzkaller.appspotmail.com
Signed-off-by: Deepanshu Kartikey <Kartikey406@gmail.com>
Reviwed-by: Sean Anderson <sean.anderson@linux.dev>
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Link: https://lore.kernel.org/r/20260130155215.69737-1-kartikey406@gmail.com
|
|
A return value of 0 is treaded as successful lock acquisition. In fact, a
return value of 1 means getting the lock successfully.
Link: https://lore.kernel.org/linux-raid/20260127073951.17248-1-xni@redhat.com
Fixes: 9e59d609763f ("md: call del_gendisk in control path")
Reported-by: Bart Van Assche <bvanassche@acm.org>
Closes: https://lore.kernel.org/linux-raid/20250611073108.25463-1-xni@redhat.com/T/#mfa369ef5faa4aa58e13e6d9fdb88aecd862b8f2f
Signed-off-by: Xiao Ni <xni@redhat.com>
Reviewed-by: Bart Van Assche <bvanassche@acm.org>
Reviewed-by: Li Nan <linan122@huawei.com>
Signed-off-by: Yu Kuai <yukuai@fnnas.com>
|
|
raid1_run() calls setup_conf() which registers a thread via
md_register_thread(). If raid1_set_limits() fails, the previously
registered thread is not unregistered, resulting in a memory leak
of the md_thread structure and the thread resource itself.
Add md_unregister_thread() to the error path to properly cleanup
the thread, which aligns with the error handling logic of other paths
in this function.
Compile tested only. Issue found using a prototype static analysis tool
and code review.
Link: https://lore.kernel.org/linux-raid/20260126071533.606263-1-zilin@seu.edu.cn
Fixes: 97894f7d3c29 ("md/raid1: use the atomic queue limit update APIs")
Signed-off-by: Zilin Guan <zilin@seu.edu.cn>
Reviewed-by: Li Nan <linan122@huawei.com>
Signed-off-by: Yu Kuai <yukuai@fnnas.com>
|
|
In packet offload, hardware is responsible to check templates. The
result of its operation is forwarded through secpath by relevant
drivers. That secpath is actually removed in __xfrm_policy_check2().
In case packet is forwarded, this secpath is reset in RX, but pushed
again to TX where policy is rechecked again against dummy secpath
in xfrm_policy_ok().
Such situation causes to unexpected XfrmInTmplMismatch increase.
As a solution, simply skip template mismatch check.
Fixes: 600258d555f0 ("xfrm: delete intermediate secpath entry in packet offload mode")
Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
Reviewed-by: Jianbo Liu <jianbol@nvidia.com>
Reviewed-by: Cosmin Ratiu <cratiu@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
|
|
Introduce a new `safety` module containing `unsafe_precondition_assert!`
macro. It is a wrapper around `debug_assert!`, intended for validating
preconditions of unsafe function.
When `CONFIG_RUST_DEBUG_ASSERTIONS` flag is enabled, this macro performs
runtime checks to ensure that the preconditions for unsafe function hold.
Otherwise, the macro is a no-op.
Suggested-by: Miguel Ojeda <ojeda@kernel.org>
Link: https://github.com/Rust-for-Linux/linux/issues/1162
Link: https://rust-for-linux.zulipchat.com/#narrow/channel/291566-Library/topic/.60unsafe_precondition_assert.60.20macro/with/528457452
Signed-off-by: Ritvik Gupta <ritvikfoss@gmail.com>
Reviewed-by: Benno Lossin <lossin@kernel.org>
Link: https://patch.msgid.link/20251007215034.213779-1-ritvikfoss@gmail.com
[ Added trailing periods, intra-doc link, "a" in "is a no-op" and `()`
to function reference. Removed plural in assertion message and title
of macro. Reworded slightly. - Miguel ]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
|
|
We have seen a proliferation of `mod_whatever::foo::Flags` being
defined with essentially the same implementation for `BitAnd`, `BitOr`,
`.contains()` etc.
This macro aims to bring a solution for this, allowing to generate these
methods for user-defined structs. With some use cases in KMS and upcoming
GPU drivers.
Link: https://rust-for-linux.zulipchat.com/#narrow/channel/288089-General/topic/We.20really.20need.20a.20common.20.60Flags.60.20type
Suggested-by: Daniel Almeida <daniel.almeida@collabora.com>
Suggested-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Tested-by: Andreas Hindborg <a.hindborg@kernel.org>
Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org>
Signed-off-by: Filipe Xavier <felipeaggger@gmail.com>
Link: https://patch.msgid.link/20260117-feat-add-bitmask-macro-v9-1-45ea1f00f846@gmail.com
[ Implemented missing `BitXorAssign<$flag> for $flags`. Sorted
`impl`s. Removed prelude addition for now -- I asked the team and they
also felt it wasn't needed. We can always add it later on if needed.
Fixed intra-doc link (by removing the sentence since it was superfluous
anyway). Simplified `empty()` title. Reworded commit slightly. Added
docs to enum variants in example to avoid 'missing_docs' lint when used
in actual code. - Miguel ]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
|
|
xfrm6_get_saddr() does not check the return value of
ipv6_dev_get_saddr(). When ipv6_dev_get_saddr() fails to find a suitable
source address (returns -EADDRNOTAVAIL), saddr->in6 is left
uninitialized, but xfrm6_get_saddr() still returns 0 (success).
This causes the caller xfrm_tmpl_resolve_one() to use the uninitialized
address in xfrm_state_find(), triggering KMSAN warning:
=====================================================
BUG: KMSAN: uninit-value in xfrm_state_find+0x2424/0xa940
xfrm_state_find+0x2424/0xa940
xfrm_resolve_and_create_bundle+0x906/0x5a20
xfrm_lookup_with_ifid+0xcc0/0x3770
xfrm_lookup_route+0x63/0x2b0
ip_route_output_flow+0x1ce/0x270
udp_sendmsg+0x2ce1/0x3400
inet_sendmsg+0x1ef/0x2a0
__sock_sendmsg+0x278/0x3d0
__sys_sendto+0x593/0x720
__x64_sys_sendto+0x130/0x200
x64_sys_call+0x332b/0x3e70
do_syscall_64+0xd3/0xf80
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Local variable tmp.i.i created at:
xfrm_resolve_and_create_bundle+0x3e3/0x5a20
xfrm_lookup_with_ifid+0xcc0/0x3770
=====================================================
Fix by checking the return value of ipv6_dev_get_saddr() and propagating
the error.
Fixes: a1e59abf8249 ("[XFRM]: Fix wildcard as tunnel source")
Reported-by: syzbot+e136d86d34b42399a8b1@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/all/68bf1024.a70a0220.7a912.02c2.GAE@google.com/T/
Signed-off-by: Jiayuan Chen <jiayuan.chen@shopee.com>
Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev>
Reviewed-by: Simon Horman <horms@kernel.org>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
|
|
Rename the xenbus helpers called from the .freeze, .thaw, and .restore
pm ops to have matching names.
Signed-off-by: Jason Andryuk <jason.andryuk@amd.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Message-ID: <20251119224731.61497-3-jason.andryuk@amd.com>
|
|
The goal is to fix s2idle and S3 for Xen PV devices. A domain resuming
from s3 or s2idle disconnects its PV devices during resume. The
backends are not expecting this and do not reconnect.
b3e96c0c7562 ("xen: use freeze/restore/thaw PM events for suspend/
resume/chkpt") changed xen_suspend()/do_suspend() from
PMSG_SUSPEND/PMSG_RESUME to PMSG_FREEZE/PMSG_THAW/PMSG_RESTORE, but the
suspend/resume callbacks remained.
.freeze/restore are used with hiberation where Linux restarts in a new
place in the future. .suspend/resume are useful for runtime power
management for the duration of a boot.
The current behavior of the callbacks works for an xl save/restore or
live migration where the domain is restored/migrated to a new location
and connecting to a not-already-connected backend.
Change xenbus_pm_ops to use .freeze/thaw/restore and drop the
.suspend/resume hook. This matches the use in drivers/xen/manage.c for
save/restore and live migration. With .suspend/resume empty, PV devices
are left connected during s2idle and s3, so PV devices are not changed
and work after resume.
Signed-off-by: Jason Andryuk <jason.andryuk@amd.com>
Acked-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Message-ID: <20251119224731.61497-2-jason.andryuk@amd.com>
|
|
The MCE_GETCLEAR_FLAGS ioctl retrieves xen_mcelog.flags while
atomically clearing it. This was previously implemented using a
cmpxchg() loop.
Replace the cmpxchg() loop with a single xchg(), which provides the
same atomic get-and-clear semantics, avoids retry spinning under
contention, and simplifies the code.
The code on x86_64 improves from:
186: 8b 15 00 00 00 00 mov 0x0(%rip),%edx
18c: 89 d0 mov %edx,%eax
18e: f0 0f b1 0d 00 00 00 lock cmpxchg %ecx,0x0(%rip)
195: 00
196: 39 c2 cmp %eax,%edx
198: 75 ec jne 186 <...>
to just:
186: 87 05 00 00 00 00 xchg %eax,0x0(%rip)
No functional change intended.
Signed-off-by: Uros Bizjak <ubizjak@gmail.com>
Cc: Juergen Gross <jgross@suse.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>
Cc: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Message-ID: <20260122141754.116129-1-ubizjak@gmail.com>
|
|
The dom0 balloon target set by the toolstack is the value returned by
XENMEM_current_reservation. Do the same in the kernel balloon driver and
set the current allocation to the value returned by
XENMEM_current_reservation. On my test system this causes the kernel
balloon driver target to exactly match the value set by the toolstack in
xenstore.
Note this approach can be used by both PV and PVH dom0s, as the toolstack
always uses XENMEM_current_reservation to set the initial target regardless
of the dom0 type.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Message-ID: <20260128110510.46425-3-roger.pau@citrix.com>
|
|
This partially reverts commit 87af633689ce16ddb166c80f32b120e50b1295de so
the current memory target for PV guests is still fetched from
start_info->nr_pages, which matches exactly what the toolstack sets the
initial memory target to.
Using get_num_physpages() is possible on PV also, but needs adjusting to
take into account the ISA hole and the PFN at 0 not considered usable
memory despite being populated, and hence would need extra adjustments.
Instead of carrying those extra adjustments switch back to the previous
code. That leaves Linux with a difference in how current memory target is
obtained for HVM vs PV, but that's better than adding extra logic just for
PV.
However if switching to start_info->nr_pages for PV domains we need to
differentiate between released pages (freed back to the hypervisor) as
opposed to pages in the physmap which are not populated to start with.
Introduce a new xen_unpopulated_pages to account for papges that have
never been populated, and hence in the PV case don't need subtracting.
Fixes: 87af633689ce ("x86/xen: fix balloon target initialization for PVH dom0")
Reported-by: James Dingwall <james@dingwall.me.uk>
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Message-ID: <20260128110510.46425-2-roger.pau@citrix.com>
|
|
An error message in the pata_cypress driver has a typo "mome" for
"mode". Fix it.
Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com>
Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
|
|
This significantly reduces the complexity of the pata_legacy driver.
The VLB bus is very obsolete and last appeared on P5 Pentium-era
hardware. Support for it has been removed from other drivers, and
it is highly unlikely anyone is using it with modern Linux kernels.
Some of these chips were integrated on motherboards, but they
seem to have all been 486-era boards, which are equally obsolete.
Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com>
Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-next
Fix three regressions
. Fix a regression where vidi_connection_ioctl() used the wrong device
to look up the vidi context. It stores the vidi device in exynos_drm_private
and uses it in ioctl(), preventing invalid pointer access and related bugs.
. Fix a security regression where vidi_connection_ioctl() directly dereferenced
a user pointer for EDID data. It copies EDID from user space
with copy_from_user() into kernel memory before use, preventing arbitrary
kernel memory access.
. Fix a concurrency regression where vidi_context members related
to EDID memory were accessed without locking. It protects alloc/free and
state updates with ctx->lock, preventing race conditions and use-after-free bugs.
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Inki Dae <inki.dae@samsung.com>
Link: https://patch.msgid.link/20260201143939.27074-1-inki.dae@samsung.com
|
|
To reduce the amount of spurious interrupts, disable the interrupts that
are not handled in this driver.
Signed-off-by: Otto Pflüger <otto.pflueger@abscue.de>
Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
|
|
Newer Unisoc SoCs such as UMS9230 include a new revision of the mailbox
IP with support for up to 16 channels. Since the new revision has a
similar register layout and many parts have remained unchanged, make the
driver support both revisions.
Signed-off-by: Otto Pflüger <otto.pflueger@abscue.de>
Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
|
|
If there are any pending messages in the mailbox queue, they are sent
as soon as a TX done event arrives from the driver. This may trigger a
new delivery interrupt while the previous one is still being handled.
If the delivery status is cleared after this, the interrupt is lost.
To prevent this from happening, clear the delivery status immediately
after checking it and before any new messages are sent.
Signed-off-by: Otto Pflüger <otto.pflueger@abscue.de>
Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
|
|
Add a compatible string for the mailbox controller found in the UMS9230
SoC.
Signed-off-by: Otto Pflüger <otto.pflueger@abscue.de>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
|
|
request_threaded_irq() is invoked with a primary and a secondary handler
and no flags are passed. The primary handler is the same as
irq_default_primary_handler() so there is no need to have an identical
copy.
The lack of the IRQF_ONESHOT can be dangerous because the interrupt
source is not masked while the threaded handler is active. This means,
especially on LEVEL typed interrupt lines, the interrupt can fire again
before the threaded handler had a chance to run.
Use the default primary interrupt handler by specifying NULL and set
IRQF_ONESHOT so the interrupt source is masked until the secondary
handler is done.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
|
|
mailbox_client.h should be used by mailbox consumer drivers, not mailbox
controller (provider) drivers. The affected drivers do not use any mailbox
client APIs, so the include can be safely removed.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Sudeep Holla <sudeep.holla@kernel.org>
Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
|
|
Commit 05703271c3cd ("PCI/IOV: Add PCI rescan-remove locking when
enabling/disabling SR-IOV") tried to fix a race between the VF removal
inside sriov_del_vfs() and concurrent hot unplug by taking the PCI
rescan/remove lock in sriov_del_vfs(). Similarly the PCI rescan/remove lock
was also taken in sriov_add_vfs() to protect addition of VFs.
This approach however causes deadlock on trying to remove PFs with SR-IOV
enabled because PFs disable SR-IOV during removal and this removal happens
under the PCI rescan/remove lock. So the original fix had to be reverted.
Instead of taking the PCI rescan/remove lock in sriov_add_vfs() and
sriov_del_vfs(), fix the race that occurs with SR-IOV enable and disable vs
hotplug higher up in the callchain by taking the lock in
sriov_numvfs_store() before calling into the driver's sriov_configure()
callback.
Fixes: 05703271c3cd ("PCI/IOV: Add PCI rescan-remove locking when enabling/disabling SR-IOV")
Reported-by: Benjamin Block <bblock@linux.ibm.com>
Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Benjamin Block <bblock@linux.ibm.com>
Reviewed-by: Gerd Bayer <gbayer@linux.ibm.com>
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20251216-revert_sriov_lock-v3-2-dac4925a7621@linux.ibm.com
|
|
This reverts commit 05703271c3cd ("PCI/IOV: Add PCI rescan-remove locking
when enabling/disabling SR-IOV"), which causes a deadlock by recursively
taking pci_rescan_remove_lock when sriov_del_vfs() is called as part of
pci_stop_and_remove_bus_device(). For example with the following sequence
of commands:
$ echo <NUM> > /sys/bus/pci/devices/<pf>/sriov_numvfs
$ echo 1 > /sys/bus/pci/devices/<pf>/remove
A trimmed trace of the deadlock on a mlx5 device is as below:
zsh/5715 is trying to acquire lock:
000002597926ef50 (pci_rescan_remove_lock){+.+.}-{3:3}, at: sriov_disable+0x34/0x140
but task is already holding lock:
000002597926ef50 (pci_rescan_remove_lock){+.+.}-{3:3}, at: pci_stop_and_remove_bus_device_locked+0x24/0x80
...
Call Trace:
[<00000259778c4f90>] dump_stack_lvl+0xc0/0x110
[<00000259779c844e>] print_deadlock_bug+0x31e/0x330
[<00000259779c1908>] __lock_acquire+0x16c8/0x32f0
[<00000259779bffac>] lock_acquire+0x14c/0x350
[<00000259789643a6>] __mutex_lock_common+0xe6/0x1520
[<000002597896413c>] mutex_lock_nested+0x3c/0x50
[<00000259784a07e4>] sriov_disable+0x34/0x140
[<00000258f7d6dd80>] mlx5_sriov_disable+0x50/0x80 [mlx5_core]
[<00000258f7d5745e>] remove_one+0x5e/0xf0 [mlx5_core]
[<00000259784857fc>] pci_device_remove+0x3c/0xa0
[<000002597851012e>] device_release_driver_internal+0x18e/0x280
[<000002597847ae22>] pci_stop_bus_device+0x82/0xa0
[<000002597847afce>] pci_stop_and_remove_bus_device_locked+0x5e/0x80
[<00000259784972c2>] remove_store+0x72/0x90
[<0000025977e6661a>] kernfs_fop_write_iter+0x15a/0x200
[<0000025977d7241c>] vfs_write+0x24c/0x300
[<0000025977d72696>] ksys_write+0x86/0x110
[<000002597895b61c>] __do_syscall+0x14c/0x400
[<000002597896e0ee>] system_call+0x6e/0x90
This alone is not a complete fix as it restores the issue the cited commit
tried to solve. A new fix will be provided as a follow on.
Fixes: 05703271c3cd ("PCI/IOV: Add PCI rescan-remove locking when enabling/disabling SR-IOV")
Reported-by: Benjamin Block <bblock@linux.ibm.com>
Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Benjamin Block <bblock@linux.ibm.com>
Acked-by: Gerd Bayer <gbayer@linux.ibm.com>
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20251216-revert_sriov_lock-v3-1-dac4925a7621@linux.ibm.com
|
|
|
|
This reverts commit 604826acb3f53c6648a7ee99a3914ead680ab7fb.
Apparently there is more to supporting atomic modesetting than
providing atomic_(check|commit) callbacks. Before this revert:
WARNING: [] drivers/gpu/drm/drm_plane.c:389 at .__drm_universal_plane_init+0x13c/0x794 [drm], CPU#1: modprobe/1790
BUG: Kernel NULL pointer dereference on read at 0x00000000
.drm_atomic_get_plane_state+0xd4/0x210 [drm] (unreliable)
.drm_client_modeset_commit_atomic+0xf8/0x338 [drm]
.drm_client_modeset_commit_locked+0x80/0x260 [drm]
.drm_client_modeset_commit+0x40/0x7c [drm]
.__drm_fb_helper_restore_fbdev_mode_unlocked.part.0+0xfc/0x108 [drm_kms_helper]
.drm_fb_helper_set_par+0x8c/0xb8 [drm_kms_helper]
.fbcon_init+0x31c/0x618
[...]
.__drm_fb_helper_initial_config_and_unlock+0x474/0x7f4 [drm_kms_helper]
.drm_fbdev_client_hotplug+0xb0/0x120 [drm_client_lib]
.drm_client_register+0x88/0xe4 [drm]
.drm_fbdev_client_setup+0x12c/0x19b4 [drm_client_lib]
.drm_client_setup+0x15c/0x18c [drm_client_lib]
.nouveau_drm_probe+0x19c/0x268 [nouveau]
Fixes: 604826acb3f5 ("drm/nouveau/disp: Set drm_mode_config_funcs.atomic_(check|commit)")
Reported-by: John Ogness <john.ogness@linutronix.de>
Closes: https://lore.kernel.org/lkml/87ldhf1prw.fsf@jogness.linutronix.de
Signed-off-by: John Ogness <john.ogness@linutronix.de>
Tested-by: Daniel Palmer <daniel@thingy.jp>
Link: https://patch.msgid.link/20260130113230.2311221-1-john.ogness@linutronix.de
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
In the current implementation driver_match_device() expects the device
lock to be held, while driver_match_device_locked() acquires the device
lock.
By convention it should be the other way around, hence swap the name of
both functions.
Fixes: dc23806a7c47 ("driver core: enforce device_lock for driver_match_device()")
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Gui-Dong Han <hanguidong02@gmail.com>
Link: https://patch.msgid.link/20260131014211.12841-1-dakr@kernel.org
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
`MIN_SIZE` and `io_addr_assert` are only ever used for IO types which
implement `IoKnownSize` and do not make sense for types that don't.
It looks like they should have been there since the beginning, so move
them while the code is still fresh.
Also update `IoKnownSize`'s documentation since it is not just a marker
trait anymore.
Fixes: 121d87b28e1d ("rust: io: separate generic I/O helpers from MMIO implementation")
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Link: https://patch.msgid.link/20260130-io-min-size-v1-1-65a546e3104d@nvidia.com
[ Fix typo in commit message. - Danilo ]
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
Re-export ConfigSpace, such that users can refer to the type as
kernel::pci::ConfigSpace, rather than kernel::pci::io::ConfigSpace.
Fixes: 4dc0bacb1d3c ("rust: pci: add config space read/write support")
Reported-by: Gary Guo <gary@garyguo.net>
Closes: https://lore.kernel.org/rust-for-linux/DG2D5ONS18FE.TC7K3O8V8SU1@garyguo.net/
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Zijing Zhang <zijing.zhang@ry.rs>
Link: https://patch.msgid.link/995384df9224283fab185b5e06f519506fff1873.1769877524.git.zijing.zhang@ry.rs
[ Slightly reworded commit message. - Danilo ]
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
