| Age | Commit message (Collapse) | Author |
|---|
|
Reorder the HDA_CODEC_QUIRK entries for 0x17aa:0x38a7 and 0x17aa:0x38a8
so that the AMD variant (TAS2781) is matched before the Intel variant's
PCI SSID (0x386f) which uses a different amplifier. This ensures the
correct fixup (ALC287_FIXUP_TAS2781_I2C) is applied to the AMD model,
restoring internal speaker functionality.
Signed-off-by: Zhang Heng <zhangheng@kylinos.cn>
Link: https://patch.msgid.link/20260820130644.76093-2-zhangheng@kylinos.cn
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The Lenovo Yoga Pro 9 16IAH10 (PCI SSID 17aa:3846, codec SSID 17aa:3920)
uses a TAS2781 smart amplifier driven via the ALC287 codec. On this
machine the bass speaker pin (NID 0x17) is by default routed to DAC 0x03,
which has no volume amplifier capability, resulting in the right-side
woofer being barely audible while only the tweeter plays. The Windows
driver configures NID 0x17 to DAC 0x02, which is shared with the main
speaker and carries proper amp control.
Currently this machine has no PCI SSID quirk, so it falls through to the
codec SSID fallback and matches the existing 0x17aa:0x3920 entry intended
for the Yoga S990-16, applying only the TAS2781 I2C init without the DAC
routing fix.
Add a dedicated quirk for PCI SSID 17aa:3846 that forces NID 0x17 to DAC
0x02 via alc285_fixup_speaker2_to_dac1() and chains to
ALC287_FIXUP_TXNW2781_I2C so the TAS2781 amplifier initialization is
preserved.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=220540
Signed-off-by: Zhang Heng <zhangheng@kylinos.cn>
Link: https://patch.msgid.link/20260820130644.76093-1-zhangheng@kylinos.cn
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
snd_mtpav_output_timer() rearms chip->timer while holding
chip->spinlock and accesses the card-private mtpav state.
snd_mtpav_free() currently takes the same lock and calls
timer_delete() when the timer is active. This only removes a
pending timer; it does not wait for a callback that is already
running and does not prevent the callback from rearming the timer.
A callback running on another CPU can therefore continue after
snd_mtpav_free() releases the lock and access the card-private
state while the card is being torn down. It can also rearm the
timer after timer_delete() has returned.
Call timer_shutdown_sync() without holding chip->spinlock. This
waits for any running callback to finish and prevents further
rearming before the card-private mtpav state is released.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Runyu Xiao <runyu.xiao@seu.edu.cn>
Link: https://patch.msgid.link/20260820112749.9195-1-runyu.xiao@seu.edu.cn
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
igt@xe_wedged@wedged-at-any-timeout wedges the device in mode 2
(UPON_ANY_HANG_NO_RESET) and then rebinds the driver. During unbind,
a GSC proxy kernel submission can still time out; with the device wedged
and the GuC CT stopped it can never complete, so its kernel job times out.
Tile0: GT1: Kernel-submitted job timed out
WARNING: drivers/gpu/drm/xe/xe_guc_submit.c:...
at guc_exec_queue_timedout_job()
Workqueue: gt-ordered-wq drm_sched_job_timedout
Killed queues skip guc_submit_hint_wedged(), leaving 'wedged' false even
though the device is already wedged. The timeout handler then treats the
kernel queue timeout as unexpected and taints the kernel.
Honour an already-wedged device even for killed queues so the expected
teardown timeout no longer trips the WARN.
Fixes: 5a2f117a80c2 ("drm/xe: Do not wedge device on killed exec queues")
Cc: Matthew Brost <matthew.brost@intel.com>
Signed-off-by: Nitin Gote <nitin.r.gote@intel.com>
Reviewed-by: Tejas Upadhyay <tejas.upadhyay@intel.com>
Link: https://patch.msgid.link/20260814074106.92670-2-nitin.r.gote@intel.com
Signed-off-by: Tejas Upadhyay <tejas.upadhyay@intel.com>
(cherry picked from commit a1c1dbd0f047bb05de6aaf6abe9103031179bf19)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
|
Add a patch setting to prevent ALC712 from entering TV mode which
may cause unexpected issues.
Signed-off-by: Jack Yu <jack.yu@realtek.com>
Link: https://patch.msgid.link/20260820092415.2979641-1-jack.yu@realtek.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
after execute s4, the spi error,
[ 1104.754246][ 4] [ T1] tpm_tis_spi spi-SMO0768:00: SPI transfer failed: -110
[ 1104.761503][ 4] [ T1] spi_master spi1: failed to transfer one message from queue
[ 1104.769201][ 4] [ T1] spi_master spi1: noqueue transfer failed
[ 1104.776344][ 4] [ T1] tpm_tis_spi spi-SMO0768:00: SPI transfer failed: -110
[ 1104.783609][ 4] [ T1] spi_master spi1: failed to transfer one message from queue
[ 1104.791308][ 4] [ T1] spi_master spi1: noqueue transfer failed
[ 1104.797446][ 4] [ T1] gttadd tpm_chip_start1 ret = -110
and in s4 the loongson_spi_resume&suspend are not
called at all. use DEFINE_SIMPLE_DEV_PM_OPS() add .freeze .poweroff
.thaw .restore, after s4 the spi communication is normal.
Signed-off-by: Li Jun <lijun01@kylinos.cn>
Link: https://patch.msgid.link/20260820092351.101605-1-lijun01@kylinos.cn
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The clk_init_data structure contains several mutually-exclusive members
for different methods to specify the possible parents of a clock,
prompting drivers to initialize only the members they need. However,
not initializing all members may cause subtle issues, which are only
exposed when CONFIG_INIT_STACK_ALL_PATTERN or CONFIG_INIT_STACK_NONE is
enabled.
aml_spisg_clk_init() fills in init.parent_data, and assumes that
init.parent_names is NULL. However, the latter in uninitialized, and
thus may cause a crash.
Make sure all members are fully initialized, to fix such bugs, and to
avoid future breakage when converting drivers to a different method for
specifying the parents.
Fixes: cef9991e04aed330 ("spi: Add Amlogic SPISG driver")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Brian Masney <bmasney@redhat.com>
Reviewed-by: Xianwei Zhao <xianwei.zhao@amlogic.com>
Link: https://patch.msgid.link/9fb35ae0aedb7a6db0db6c78a8193c7602dd9d44.1787165329.git.geert+renesas@glider.be
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Ravi reports that statfs() may be called by unprivileged users on the
efivarfs mount point, which may result in a flood of calls to the
QueryVariableInfo() runtime service. These calls are disproportionately
costly on x86 systems where the variable store is backed by SMM, as each
SMM entry requires a rendez-vous of all the CPUs.
So rate limit the calls to QueryVariableInfo() at twice per second, and
return the most recently obtained value for calls that are elided.
Cc: <stable@vger.kernel.org>
Reported-by: Ravi Bangoria <ravi.bangoria@amd.com>
Fixes: d86ff3333cb1 ("efivarfs: expose used and total size")
Reviewed-by: Anisse Astier <anisse@astier.eu>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
|
map_properties() remaps the Apple properties setup_data payload
and then reads the properties header fields.
Reject a truncated payload before checking the header version and length
fields.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
Reviewed-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
|
efi_guid_to_str() only formats the GUID through the byte array passed to
the UUID printf formatter. It does not modify the GUID contents.
Make the input pointer const so callers can stringify GUIDs from const
data without a cast.
Signed-off-by: Vincent Mailhol <mailhol@kernel.org>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
|
ucma_query_path() emits a path record only when the remaining output
buffer is strictly larger than struct ib_path_rec_data. A buffer sized
exactly for the response header and N complete records therefore gets
only N - 1 records, while resp->num_paths still advertises N. A caller
sizing its buffer for a single record gets a header claiming one path
and no path data at all.
ucma_query_ib_service() in the same file computes the record count with
a plain division and so accepts an exact fit; make ucma_query_path()
behave the same way.
Current librdmacm is unaffected because it always sizes the response for
six records while the kernel currently reports at most two paths. Other
users of the UAPI that provide an exactly sized buffer can observe the
truncated response.
Fixes: ac53b264b2f3 ("RDMA/ucma: Support querying when IB paths are not reversible")
Signed-off-by: Serhat Kumral <serhatkumral1@gmail.com>
Link: https://patch.msgid.link/20260806201358.147478-1-serhatkumral1@gmail.com
Signed-off-by: Leon Romanovsky <leon@kernel.org>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
|
|
When __efi_queue_work() times out it disables runtime services and
returns, but the kworker is still blocked inside firmware. If the
firmware eventually unblocks, efi_call_rts() would run its tail on an
efi_rts_work that the timed-out caller has long abandoned: signalling a
stale completion and clearing efi_runtime_lock_owner that may by then
belong to another caller.
If runtime services have been disabled by the time the call returns,
park the worker with efi_rts_park_worker() instead, so it never touches
efi_rts_work again or returns to the workqueue.
Suggested-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Breno Leitao <leitao@debian.org>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
|
Three wrappers call firmware directly instead of going through
__efi_queue_work(), and none of them check whether runtime services are
still enabled: virt_efi_set_variable_nb(),
virt_efi_query_variable_info_nb() and virt_efi_reset_system(). Once a
hang has cleared EFI_RUNTIME_SERVICES - or efi_recover_from_page_fault()
has cleared it on a firmware page fault - these paths still enter the
(possibly wedged) firmware, e.g. an EFI pstore write through the
non-blocking SetVariable() variant, in violation of UEFI's
non-reentrancy rules. reset_system() is reachable too: efi_reboot()
only gates it on the static efi_rt_services_supported() mask, which does
not track the runtime disable.
Check efi_enabled(EFI_RUNTIME_SERVICES) in each before calling into
firmware. Test it after taking efi_runtime_lock rather than before: the
bit is only ever cleared at runtime while that lock is held, so checking
it under the lock avoids racing with a concurrent timeout that clears the
bit and drops the lock.
Suggested-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Breno Leitao <leitao@debian.org>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
|
When an EFI runtime service hangs in firmware, the efi_rts_wq worker is
stuck inside the call and cannot be cancelled. __efi_queue_work() then
waits on the completion forever while holding efi_runtime_lock, so every
later EFI caller is wedged until reboot; the only symptom is a "workqueue
lockup" and tasks piling up on the semaphore.
Replace wait_for_completion() with wait_for_completion_timeout() bounded
by EFI_RTS_TIMEOUT (120 seconds). On timeout, clear EFI_RUNTIME_SERVICES
and return EFI_ABORTED so later callers fail fast at the entry check
instead of each paying another 120 seconds. The wedged worker is
intentionally leaked and keeps ownership of efi_rts_work.
A worker that only starts running after the timeout would otherwise
dereference efi_rts_work.args, now pointing into the caller's freed stack
frame, and hand stale pointers to firmware. Park it with
efi_rts_park_worker() at the entry of efi_call_rts() when runtime
services are already disabled, before it touches args or enters firmware.
Known limitation: a worker already inside firmware when the timeout fires
still holds efi_rts_args pointing into the caller's stack frame; if
firmware unblocks afterwards and writes the output buffers, they land in
reused memory. Firmware hung this long rarely recovers; a follow-up could
bounce the buffers through kmalloc.
Signed-off-by: Breno Leitao <leitao@debian.org>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
|
Move the EFI_RUNTIME_SERVICES check to the top of __efi_queue_work() and
return directly, so a caller that finds runtime services disabled returns
without touching the shared efi_rts_work. No functional change.
This prepares for bounding the wait, where a timeout will clear
EFI_RUNTIME_SERVICES while the leaked worker still owns efi_rts_work; a
later caller must then bail out before reinitialising it.
Signed-off-by: Breno Leitao <leitao@debian.org>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
|
Convert the queue_work() failure path in __efi_queue_work() to a
goto exit instead of falling through to the wait and the
WARN_ON_ONCE(status == EFI_ABORTED) below it. A failed queue_work()
leaves the status at its initial EFI_ABORTED, so that warning would
fire even though no call ran; it is meant for a completed call that
returned EFI_ABORTED.
No change for the common (successful enqueue) path. This also prepares
__efi_queue_work() for the timeout handling added later.
Signed-off-by: Breno Leitao <leitao@debian.org>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
|
x86's efi_crash_gracefully_on_page_fault() ends in an infinite
schedule() loop so the kworker that faulted in firmware never runs
efi_rts_wq again. A later change needs the same "park this worker
forever" primitive on the runtime service timeout path, so factor the
loop into a shared efi_rts_park_worker() and call it from the x86
page-fault handler.
No functional change.
Signed-off-by: Breno Leitao <leitao@debian.org>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
|
Reject an attribute with empty mapping pairs if it has inconsistent
highest VCN and size.
Fixes: 11ccc9107dc4 ("ntfs: update runlist handling and cluster allocator")
Reported-by: Robert Morris <rtm@csail.mit.edu>
Closes: https://lore.kernel.org/all/9519.1786907182@localhost/
Cc: stable@vger.kernel.org
Signed-off-by: Hyunchul Lee <hyc.lee@gmail.com>
Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>
|
|
When handling resident attributes that don't need sparse/compressed
changes, ntfs_new_attr_flags() returns 0 directly at line 678 without
calling unmap_mft_record() or ntfs_attr_put_search_ctx(). This leaks
the MFT record mapping and attribute search context.
An unprivileged user can cause a denial of service by repeatedly
calling setxattr(2) with system.ntfs_attrib on files with resident
attributes, eventually exhausting kernel memory.
Fix by replacing the direct return with goto err_out to ensure proper
cleanup of resources via the existing cleanup code.
Fixes: e791930240a5 ("ntfs: fix resident conversion in ntfs_new_attr_flags")
Cc: stable@vger.kernel.org
Signed-off-by: Hongling Zeng <zenghongling@kylinos.cn>
Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>
|
|
When ntfs_mft_record_alloc() reuses a free mft record it reads the old
update sequence number straight from the on-disk record:
usn = *(__le16 *)((u8 *)m + le16_to_cpu(m->usa_ofs));
Here m points into the raw $MFT page-cache folio, which still holds
unvalidated, MST-protected bytes: the folio is read by a plain
iomap_read_folio() and neither post_read_mst_fixup() nor
ntfs_mft_record_check() has run on it (both work on private copies).
m->usa_ofs is therefore an untrusted u16, and a corrupted record can put
it past the end of the record so the two-byte read lands outside the
folio. Reading such a record while creating a file gives, under KASAN:
BUG: KASAN: use-after-free in ntfs_mft_record_alloc+...
Read of size 2 at addr ...
ntfs_mft_record_alloc -> __ntfs_create -> ntfs_create -> path_openat
Only preserve the old update sequence number when usa_ofs is even and in
range, mirroring the check ntfs_mft_record_check() already applies;
otherwise leave usn zero, which the existing restore below skips.
Fixes: 495e90fa3348 ("ntfs: update attrib operations")
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: Dennis Tighe <dennis.tighe@gmail.com>
Reviewed-by: Hyunchul Lee <hyc.lee@gmail.com>
Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>
|
|
The per-token range check in ntfs_decompress() uses
if (cb >= cb_sb_end || dp_addr > dp_sb_end)
break;
so dp_addr == dp_sb_end falls through to the symbol copy
`*dp_addr++ = *cb++`, writing one byte past the destination page. Since
NTFS_SB_SIZE == PAGE_SIZE the destination is a single page, so the byte
lands in the adjacent page, and *dest_ofs is left one past the sub-block
end (the later `*dest_ofs &= ~PAGE_MASK` then yields 1, not 0, so the page
is never finalized and later sub-blocks keep writing further past it). A
corrupted compressed $DATA attribute thus produces a bounded run of
out-of-bounds writes when the file is read.
Break as soon as dp_addr reaches dp_sb_end; a full sub-block still
completes, as its final copy advances dp_addr to exactly dp_sb_end.
Fixes: 1e9ea7e04472 ("Revert "fs: Remove NTFS classic"")
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: Dennis Tighe <dennis.tighe@gmail.com>
Reviewed-by: Hyunchul Lee <hyc.lee@gmail.com>
Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>
|
|
After commit dfc256dac54c ("calibrate: Rework delay timer calibration"),
certain ARM configurations (such as multi_v5_defconfig) hang during
boot. The use of read_current_timer() in arch/arm's get_cycles() was
improperly converted to delay_read_timer(), resulting in get_cycles()
returning 0 even when the timer has been read or an uninitialized stack
value when delay_read_timer() returns false.
Flip the branches of the ternary condition to fix get_cycles().
Fixes: dfc256dac54c ("calibrate: Rework delay timer calibration")
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Thomas Gleixner <tglx@kernel.org>
Reviewed-by: Jinjie Ruan <ruanjinjie@huawei.com>
Cc: Thomas Gleixner <tglx@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org
Link: https://patch.msgid.link/20260819-fix-arm-get_cycles-v1-1-208bf07ac540@kernel.org
|
|
tg_cpus() returns cpuset_num_cpus() unfloored, while its sibling
tg_tasks() already floors its result at 1. calc_concur_shares() feeds
nr = min(tg_tasks(tg), tg_cpus(tg))
into __calc_smp_shares() as shares_max, so an nr of 0 makes shares_max 0.
__calc_smp_shares() ends with
return clamp_t(long, shares, MIN_SHARES, shares_max);
and clamp() yields hi when hi < lo, so a zero shares_max silently defeats
the MIN_SHARES floor and returns 0 -- the exact case the comment above
that line says must return MIN_SHARES instead of 0.
That leaves a group sched_entity with load.weight == 0, and
__calc_prop_weight() then divides by cfs_rq->load.weight:
weight *= se->load.weight;
if (parent_entity(se))
weight /= cfs_rq->load.weight;
which takes a #DE inside enqueue_task_fair():
Oops: divide error: 0000 [#1] SMP NOPTI
RIP: 0010:enqueue_task_fair+0x422/0x950
Call Trace:
<TASK>
enqueue_task+0x8e/0x250
wake_up_new_task+0x148/0x2e0
kernel_clone+0x1c6/0x390
__x64_sys_clone+0xcc/0x100
do_syscall_64+0x147/0x3c0
</TASK>
This is not survivable in practice: with panic_on_oops=0 the kernel took
the first #DE and continued for 476 ms, then faulted at the same RIP with
identical register state and an identical RSP, because the oops recovery
path (kill task -> schedule()) re-enters the same enqueue while the rq
lock is held mid-enqueue. The second fault escalates to a panic.
Flooring tg_cpus() at 1 makes it symmetric with tg_tasks() and keeps
shares_max >= tg_shares, so the MIN_SHARES floor in __calc_smp_shares()
can no longer be bypassed.
Note this only removes the division hazard. Whether cpuset_num_cpus() can
legitimately return 0 -- via the cpu hotplug/suspend path where a v2
cpuset may transiently become empty, or via an RCU race -- is a separate
question still open on the report thread.
Fixes: 90ac22ffef48 ("sched/fair: Add cgroup_mode: max")
Signed-off-by: Jake Steinman <j@metarealtyinc.ca>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lore.kernel.org/all/20260818231333.1441757-1-j@metarealtyinc.ca/
Link: https://patch.msgid.link/20260819132104.2148918-1-j@metarealtyinc.ca
|
|
A read from /proc/sys/kernel/sched_rt_runtime_us leads to backtrace due
to missing cpu_hotplug_lock with CONFIG_CPUSETS=n. The callchain is
sched_rt_handler() -> partition_sched_domains() -> sched_cache_set() ->
static_key_enable_cpuslocked(&sched_cache_present).
sched_cache_set() itself is also invoked from sched_init_domains() which
is early during the boot, holding just the sched_domains_mutex_lock().
Here is no warning because it happens before user space is running (and
hotplug operations are not possible).
There is also sched_cache_active_set() which acquires the hotplug lock
before invoking any of the _cpuslocked() functions.
This is only a problem with CONFIG_CPUSETS=n because in the =y case the
other implementation of rebuild_sched_domains acquires the CPU-hotplug
lock.
Acquire CPU hotplug lock before in rebuild_sched_domains(), before
partition_sched_domains() is invoked for the CONFIG_CPUSETS=n case.
Fixes: a7660ce1590fc ("sched/cache: Fix has_multi_llcs iff at least one partition has multiple LLCs")
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Reivewed-by: Ridong Chen <ridong.chen@linux.dev>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Chen Yu <yu.c.chen@intel.com>
Reviewed-by: Tim Chen <tim.c.chen@linux.intel.com>
Reviewed-by: Waiman Long <longman@redhat.com>
Reviewed-by: Valentin Schneider <vschneid@redhat.com>
Reviewed-by: Shrikanth Hegde <sshegde@linux.ibm.com>
Reviewed-by: Aaron Tomlin <atomlin@atomlin.com>
Tested-by: Dietmar Eggemann <dietmar.eggemann@arm.com>
Link: https://patch.msgid.link/20260813073855.ji2UrtVh@linutronix.de
|
|
Both the CTIA and OMTP branches of cx_process_headset_plugin() write the
same value to the headset-mic pin, differing only in the debug message.
Merge the two branches into a single one, leaving the codec write
unchanged.
No functional change.
Signed-off-by: Zhang Heng <zhangheng@kylinos.cn>
Link: https://patch.msgid.link/20260820073744.521680-1-zhangheng@kylinos.cn
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
This patch adds a quirk for the HP Laptop 15-fd0039nt (SSID 103c:8bb6)
to fix the micmute LED functionality.
The micmute LED is controlled via GPIO 0 with active-low polarity.
Tested-by: Habil Eren Türker <habilerenturker@hotmail.com>
Signed-off-by: Habil Eren Türker <habilerenturker@hotmail.com>
Link: https://patch.msgid.link/20260819170919.3172-1-habilerenturker@hotmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
snd_ice1712_probe() performs multiple initialization steps after
snd_card_new(), but directly returns on failures from later steps
without releasing the ALSA card, causing resource leaks when
probing fails.
Use snd_devm_card_new() together with scope-based cleanup
via __free(snd_card_unref), and clear the card pointer after
successful registration to keep it alive.
Fixes: ca642da4b33d ("ALSA: ice1712: Allocate resources with device-managed APIs")
Suggested-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Haotian Zhang <vulab@iscas.ac.cn>
Link: https://patch.msgid.link/20260820014117.14044-1-vulab@iscas.ac.cn
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
SPI and LPI interrupts do not have an architected default value for their
IAFFID (interrupt affinity ID) - the property that determines an IRQ
affinity.
Current code awkwardly tries to set a default IAFFID value corresponding
to the logical cpu executing the gicv5_hwirq_init() function at SPI/LPI
allocation time.
There are two issues with this approach:
- gicv5_hwirq_init() is called in preemptible context and current code
uses smp_processor_id() to check the logical cpu executing the function.
Whilst that's harmless, it can spit a splat on DEBUG_PREEMPT kernels
- Setting the default SPI/LPI IAFFID to the one belonging to the cpu
executing the IRQ allocation is a completely arbitrary choice
It is saner to remove the SPI/LPI IAFFID set-up in the SPI/LPI domain IRQ
allocation code and flag SPI/LPI irqchips as IRQCHIP_AFFINITY_PRE_STARTUP
so that the SPI/LPI affinity is initialized by IRQ core to a sane value
before an IRQ is started up using the respective irq_chip
irq_set_affinity() callback.
Fixes: 5cb1b6dab2de ("irqchip/gic-v5: Add GICv5 IRS/SPI support")
Fixes: 0f0101325876 ("irqchip/gic-v5: Add GICv5 LPI/IPI support")
Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
Signed-off-by: Thomas Gleixner <tglx@kernel.org>
Link: https://patch.msgid.link/20260812-gicv5-7-2-fixes-v1-7-3743e82c69a4@kernel.org
|
|
In set-ups with a 2-level IST, L1 table entries are created dynamically
when LPIs are allocated.
The L1 allocation and mapping, implemented in gicv5_irs_iste_alloc() is
carried out in preemtible context and can be carried out on any IRS in
the system.
Current code indexes the per_cpu_irs_data per cpu array using
smp_processor_id() to retrieve the IRS that is local to the core
executing gicv5_irs_iste_alloc().
Since that's preemptible context, the core executing that function can
change on preemption. Given that every IRS in the system is equivalent
to each core, this is not really an issue in that even if the thread
is preempted and resumed on a different cpu, the table allocation and
mapping to an IRS would work seamlessly regardless.
On the other hand, smp_processor_id() spits a legitimate splat on
DEBUG_PREEMPT kernels when used in preemtible context and this should
be fixed.
Given that all IRSes are equivalent from a core perspective in terms of
IST initialization, always choose as a policy the IRS local to logical
cpu 0, preventing the smp_processor_id() splat.
Fixes: 0f0101325876 ("irqchip/gic-v5: Add GICv5 LPI/IPI support")
Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
Signed-off-by: Thomas Gleixner <tglx@kernel.org>
Link: https://sashiko.dev/#/message/20260810104747.E5CE71F000E9%40smtp.kernel.org
Link: https://patch.msgid.link/20260812-gicv5-7-2-fixes-v1-6-3743e82c69a4@kernel.org
|
|
In gicv5_irs_of_init(), an IRS is set-up using of_io_request_and_map() to
request its memory region (corresponding to the configuration frame) and
map the IRS configuration frame.
On gicv5_irs_of_init() failure, the driver unmaps the IRS iomem region but
does not release the requested memory region leaving it allocated in the
iomem resource tree.
Fix it by releasing the iomem region on gicv5_irs_of_init() probe failure.
Likewise, on both OF and ACPI driver init failure, IRS iomem regions are
requested but never released in gicv5_irs_remove().
Stash a copy of the IRS iomem region in a struct resource in
struct gicv5_irs_chip_data and use it to release the requested region in
gicv5_irs_remove() if the driver probe fails.
Fixes: 5cb1b6dab2de ("irqchip/gic-v5: Add GICv5 IRS/SPI support")
Fixes: 35866efa52fe ("irqchip/gic-v5: Add ACPI IRS probing")
Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
Signed-off-by: Thomas Gleixner <tglx@kernel.org>
Link: https://sashiko.dev/#/message/20260810104747.E5CE71F000E9%40smtp.kernel.org
Link: https://patch.msgid.link/20260812-gicv5-7-2-fixes-v1-5-3743e82c69a4@kernel.org
|
|
Current code fails to disable interrupts on gicv5_starting_cpu() failure
and to set the handle_arch_irq pointer to NULL if gicv5_irs_enable() fails.
Update the respective error paths to fix them.
Fixes: 7ec80fb3f025 ("irqchip/gic-v5: Add GICv5 PPI support")
Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
Signed-off-by: Thomas Gleixner <tglx@kernel.org>
Link: https://patch.msgid.link/20260812-gicv5-7-2-fixes-v1-4-3743e82c69a4@kernel.org
|
|
GICv5 driver probe failures cause IRSes initialized by the kernel to be
unmapped and their data structures to be destroyed but the current driver
leaves the probed IRSes enabled, whereas they should be disabled.
Disable IRSes on driver probe failures so that the IRSes are brought back
to their quiescent HW state.
Fixes: 5cb1b6dab2de ("irqchip/gic-v5: Add GICv5 IRS/SPI support")
Fixes: 35866efa52fe ("irqchip/gic-v5: Add ACPI IRS probing")
Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
Signed-off-by: Thomas Gleixner <tglx@kernel.org>
Link: https://sashiko.dev/#/message/20260810104747.E5CE71F000E9%40smtp.kernel.org
Link: https://patch.msgid.link/20260812-gicv5-7-2-fixes-v1-3-3743e82c69a4@kernel.org
|
|
In gicv5_free_lpi_domain() the LPI domain being freed can be NULL.
Check it and return before trying to free it if it is.
Fixes: 0f0101325876 ("irqchip/gic-v5: Add GICv5 LPI/IPI support")
Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
Signed-off-by: Thomas Gleixner <tglx@kernel.org>
Link: https://sashiko.dev/#/message/20260810104747.E5CE71F000E9%40smtp.kernel.org
Link: https://patch.msgid.link/20260812-gicv5-7-2-fixes-v1-2-3743e82c69a4@kernel.org
|
|
In gic_acpi_parse_iaffid() a given MADT GICC entry might not correspond
to a logical cpu recognized by the kernel, resulting in the cpu variable
initialization to an error value.
Currently, the get_logical_index() return value is not checked for failure,
which might result in out-of-bounds memory corruption while trying to
index a per_cpu variable array.
Add a check to evaluate get_logical_index() return value.
Fixes: 35866efa52fe ("irqchip/gic-v5: Add ACPI IRS probing")
Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
Signed-off-by: Thomas Gleixner <tglx@kernel.org>
Link: https://sashiko.dev/#/message/20260810104747.E5CE71F000E9%40smtp.kernel.org
Link: https://patch.msgid.link/20260812-gicv5-7-2-fixes-v1-1-3743e82c69a4@kernel.org
|
|
The write disabling the GICv5 CPU interface is only guaranteed to take
effect after a context synchronization event. Without one, execution can
return from gicv5_cpu_disable_interrupts() while an interrupt is still
able to be taken.
Add an ISB after the ICC_CR0_EL1 write to ensure interrupts are
disabled before the function returns. No corresponding ISB is added
when enabling the interface, as interrupt delivery is asynchronous and
there is no obvious benefit to waiting for it.
Fixes: 7ec80fb3f025 ("irqchip/gic-v5: Add GICv5 PPI support")
Signed-off-by: Sascha Bischoff <sascha.bischoff@arm.com>
Signed-off-by: Thomas Gleixner <tglx@kernel.org>
Reviewed-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
Link: https://sashiko.dev/#/patchset/20260724104819.1296803-1-sascha.bischoff@arm.com?part=6
Link: https://patch.msgid.link/20260811152630.942023-3-sascha.bischoff@arm.com
|
|
IRS affinity setup publishes an IRS pointer and IAFFID state in the
per-CPU data before the remaining IRS initialization can fail. The
error path then frees the IRS data without clearing that published
state, leaving CPUs associated with freed memory.
On initialization failure and normal IRS teardown, clear the per-CPU
IRS association by removing the stale pointer to irs_data. Also
invalidate the per-CPU IAFFID state for any CPUs that were tied to the
IRS before it was freed.
Fixes: 5cb1b6dab2de ("irqchip/gic-v5: Add GICv5 IRS/SPI support")
Fixes: 35866efa52fe ("irqchip/gic-v5: Add ACPI IRS probing")
Signed-off-by: Sascha Bischoff <sascha.bischoff@arm.com>
Signed-off-by: Thomas Gleixner <tglx@kernel.org>
Reviewed-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
Link: https://sashiko.dev/#/patchset/20260724104819.1296803-1-sascha.bischoff@arm.com?part=2
Link: https://patch.msgid.link/20260811152630.942023-2-sascha.bischoff@arm.com
|
|
The INTC0 interrupt-merge (INTM) space has 50 sources at 10 per bank, i.e.
INTC0_INTM_NUM / INTM_IRQS_PER_BANK = 5 banks. This is reflected everywhere
the banks are indexed: the aspeed_intc0_intm_routes[] table has 5 valid
entries, and the mask/unmask/eoi paths compute the bank as (hwirq -
INTM_BASE) / INTM_IRQS_PER_BANK, spanning banks 0-4.
However, INTC0_INTM_BANK_NUM is hardcoded to 3, so
aspeed_intc0_disable_intm() only clears IER for banks 0-2 at probe. Banks 3
and 4 are left in whatever state the firmware configured them , which can
leave interrupts enabled before a handler is installed.
Derive the bank count from the source count so the probe-time disable
covers every bank.
Fixes: 07825e41519a ("irqchip/ast2700-intc: Add AST2700-A2 support")
Signed-off-by: Michael Pesa <michael.pesa@icloud.com>
Signed-off-by: Thomas Gleixner <tglx@kernel.org>
Link: https://patch.msgid.link/20260722050243.298355-1-michael.pesa@icloud.com
|
|
mpfs_cfg_clk_set_rate() passes the mask and value arguments to
regmap_update_bits() in the wrong order. The resulting write becomes
reg = orig_reg | val, causing bits to not be cleared if the clock
divider changes.
Pass the arguments in the correct order so the divider field is updated
as intended.
Fixes: c6f2dddfa7f9 ("clk: microchip: mpfs: use regmap for clocks")
Signed-off-by: Pedro Kopper <pedro.kopper@microchip.com>
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Cc: stable@vger.kernel.org
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
|
|
The clk_init_data structure contains several mutually-exclusive members
for different methods to specify the possible parents of a clock,
prompting drivers to initialize only the members they need. However,
not initializing all members may cause subtle issues, which are only
exposed when CONFIG_INIT_STACK_ALL_PATTERN or CONFIG_INIT_STACK_NONE is
enabled.
visconti_clk_register_gate() fills in init.parent_data, and assumes that
init.parent_names is NULL. However, the latter in uninitialized, and
thus may cause a crash.
Make sure all members are fully initialized, to fix such bugs, and to
avoid future breakage when converting drivers to a different method for
specifying the parents.
Fixes: b4cbe606dc3674b2 ("clk: visconti: Add support common clock driver and reset driver")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Brian Masney <bmasney@redhat.com>
Reviewed-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.x90@mail.toshiba>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
|
|
The clk_init_data structure contains several mutually-exclusive members
for different methods to specify the possible parents of a clock,
prompting drivers to initialize only the members they need. However,
not initializing all members may cause subtle issues, which are only
exposed when CONFIG_INIT_STACK_ALL_PATTERN or CONFIG_INIT_STACK_NONE is
enabled.
_register_mux() fills in init.parent_data, and assumes that
init.parent_names is NULL. However, the latter is uninitialized, and
thus may cause a crash.
Make sure all members are fully initialized, to fix such bugs, and to
avoid future breakage when converting drivers to a different method for
specifying the parents.
Fixes: 667f420c09f1417c ("clk: ti: mux: resolve parent clocks by DT index, not by name")
Closes: https://lore.kernel.org/CAMuHMdU3yVqoyHC4eNF2NuYo8wy+6ODLoYat4R71X99Mxc_=kw@mail.gmail.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Brian Masney <bmasney@redhat.com>
Reviewed-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
|
|
The quic_username@quicinc.com emails have been deprecated inside Qualcomm
for a while now in favor of firstname.lastname@oss.qualcomm.com Re-route
the emails to Taniya's current OSS email address to avoid Outlook bounces
("recipient's inbox is full").
Link: https://lore.kernel.org/20260817-topic-taniya_email_bounce-v1-1-d7af1f113d64@oss.qualcomm.com
Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Cc: Taniya Das <taniya.das@oss.qualcomm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
|
|
ocfs2_dir_foreach_blk_id() re-scans the inline data area the same way
ocfs2_dir_foreach_blk_el() re-scans a directory block, and is missing the
same two bounds:
for (i = 0; i < i_size_read(inode) && i < offset; ) {
de = (struct ocfs2_dir_entry *)(data->id_data + i);
if (le16_to_cpu(de->rec_len) < OCFS2_DIR_REC_LEN(1))
break;
i += le16_to_cpu(de->rec_len);
}
ocfs2_validate_inode_block() keeps i_size inside the inline area:
if (le16_to_cpu(data->id_count) >
ocfs2_max_inline_data_with_xattr(sb, di))
if (le64_to_cpu(di->i_size) > le16_to_cpu(data->id_count))
and that area runs to the end of the inode block, so for a full inline
directory data->id_data + i_size is the end of di_bh->b_data. A bogus
rec_len leaves i in the last OCFS2_DIR_REC_LEN(1) - 1 bytes of it, and
de->rec_len, at byte offset 8 within the entry, is then read past the
block.
The emit loop below hands i_size_read(inode) to ocfs2_check_dir_entry(),
which refuses both an entry that close to the end and one whose rec_len
runs past it. Apply the same two bounds to the re-validation scan,
reading i_size once into a local as ocfs2_check_dir_entry() takes it as
@size.
Unlike the extent case there is no mask to corrupt here: an unbounded i
only sets ctx->pos past i_size, which ends the readdir early rather than
moving it to the wrong place.
Link: https://lore.kernel.org/20260811024337.3972976-3-zhanxusheng@xiaomi.com
Signed-off-by: Zhan Xusheng <zhanxusheng@xiaomi.com>
Reviewed-by: Joseph Qi <joseph.qi@linux.alibaba.com>
Cc: Mark Fasheh <mark@fasheh.com>
Cc: Joel Becker <jlbec@evilplan.org>
Cc: Junxiao Bi <junxiao.bi@oracle.com>
Cc: Changwei Ge <gechangwei@live.cn>
Cc: Jun Piao <piaojun@huawei.com>
Cc: Heming Zhao <heming.zhao@suse.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
|
|
Patch series "ocfs2: bound-check both readdir re-validation scans", v2.
This patch (of 2):
When the inode version changed since the last readdir(),
ocfs2_dir_foreach_blk_el() re-scans the directory block from its start to
relocate the current position:
for (i = 0; i < sb->s_blocksize && i < offset; ) {
de = (struct ocfs2_dir_entry *)(bh->b_data + i);
if (le16_to_cpu(de->rec_len) < OCFS2_DIR_REC_LEN(1))
break;
i += le16_to_cpu(de->rec_len);
}
i walks the block on rec_len values taken from the block itself and the
only thing tested is that rec_len is not too small, so a single bogus
rec_len leaves i anywhere in the block, including its last
OCFS2_DIR_REC_LEN(1) - 1 bytes. @offset comes from ctx->pos, which
userspace moves with lseek() on the directory fd, and decides how far the
walk gets.
Two bounds are missing, both of which ocfs2_check_dir_entry() applies for
the emit loop below.
de->rec_len sits at byte offset 8 within the entry, so dereferencing de in
that tail reads past the s_blocksize buffer. ocfs2_check_dir_entry()
declines to look at an entry that close to the end:
size - buf_offset < OCFS2_DIR_REC_LEN(1)
Nothing bounds i += rec_len either, so i can end up past the block. The
emit loop that follows is guarded by offset < sb->s_blocksize and does not
run, but
offset = i;
ctx->pos = (ctx->pos & ~((loff_t)sb->s_blocksize - 1)) | offset;
runs first and ORs a value with bits above the block mask into ctx->pos,
corrupting the block number readdir() resumes from.
ocfs2_check_dir_entry() rejects that as "directory entry overrun":
next_offset = buf_offset + rlen;
... next_offset > size
Apply both bounds. For a consistent directory this changes nothing:
entries are at least OCFS2_DIR_REC_LEN(1) bytes and do not cross the end
of the block, so no valid entry is skipped.
Found by the sashiko review tool; fix approach suggested by Joseph Qi.
Link: https://lore.kernel.org/20260811024337.3972976-1-zhanxusheng@xiaomi.com
Link: https://sashiko.dev/#/patchset/20260806022044.167962-1-zhanxusheng@xiaomi.com
Link: https://lore.kernel.org/20260811024337.3972976-2-zhanxusheng@xiaomi.com
Signed-off-by: Zhan Xusheng <zhanxusheng@xiaomi.com>
Suggested-by: Joseph Qi <joseph.qi@linux.alibaba.com>
Reviewed-by: Joseph Qi <joseph.qi@linux.alibaba.com>
Cc: Mark Fasheh <mark@fasheh.com>
Cc: Joel Becker <jlbec@evilplan.org>
Cc: Junxiao Bi <junxiao.bi@oracle.com>
Cc: Changwei Ge <gechangwei@live.cn>
Cc: Jun Piao <piaojun@huawei.com>
Cc: Heming Zhao <heming.zhao@suse.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
|
|
squashfs_cache_get() puts a task to sleep when its block is not cached and
every cache entry is busy. Those sleeps are non-exclusive, so the
nr_exclusive == 1 budget squashfs_cache_put() has always passed to
wake_up() is inert and one release makes every waiter runnable. A wakee
only returns to squashfs_cache_get() if it observes cache->unused before
the entry is reclaimed; later wakees see zero and re-queue inside
wait_event() without rescanning. One freed entry satisfies exactly one
capacity waiter, so waking the rest is waste.
On a Meta production host serving a Python web application from a packaged
squashfs image, a 30-second trace caught 1,045,132 cache-release wake
calls and 19,511,556 wakeups: 18.7 per release, although each release
added only one reusable cache entry. This was causing significant spikes
in CPU usage.
Make the waits exclusive, enqueueing while still holding cache->lock so
that a concurrent lookup either sees the waiter queued or the waiter sees
the block that lookup publishes. Two things follow.
A wakee cannot be assumed to consume the entry it was woken for: it may
find its own block published meanwhile, share that entry, and leave the
freed one unclaimed. So a wakee which shares hands its wakeup on to the
next waiter, as commit 0ddad21d3e99 ("pipe: use exclusive waits when
reading or writing") does with wake_next_reader.
And a waiter can now sleep through a publication of the very block it
wants, which the old broadcast gave it repeated chances to notice. So
waiters are keyed by block: publishing wakes every waiter for that block
(nr_exclusive == 0), freeing an entry wakes one. That needs a custom wake
callback, like wake_page_function() in mm/filemap.c, which also records
which wakeup arrived so the handoff only fires for a capacity wakee.
Broadcast is kept where more than one task can proceed - every waiter for
a published block, and the wake_up_all() on entry->wait_queue - at the
cost of walking the queue under wait_queue.lock to test the key. Waiters
are now served FIFO with a scheduling round trip per handoff hop, so
per-waiter latency changes; the filebench run below is 4x oversubscribed,
where that should hurt most.
Measured on a 32-CPU VM against a read-only squashfs (gzip,
DECOMP_MULTI_PERCPU, FILE_DIRECT, default 8 metadata / 3 fragment cache
entries) staged in tmpfs, page cache dropped each iteration to force cold
decompression:
elbencho, 64 threads
metadata stat 700 -> 1320 files/s 1.9x
small-file read 40 -> 60 MiB/s 1.5x
filebench, 128 threads, open+read+stat+close (mean of 3x 30s)
throughput 11,314 -> 25,186 ops/s 2.2x
sched:sched_wakeup 27.0 -> 4.55 per op 5.9x fewer
context switches 37.2 -> 7.64 per op 4.9x fewer
Wakeups and context switches are per operation, since the two runs did
2.2x different amounts of work. Workloads which never queue for a cache
entry gain no wakeups.
Link: https://lore.kernel.org/20260807172421.3875982-1-usama.arif@linux.dev
Signed-off-by: Usama Arif <usama.arif@linux.dev>
Reviewed-by: Phillip Lougher <phillip@squashfs.org.uk>
Cc: Boris Burkov <boris@bur.io>
Cc: Christian Brauner <brauner@kernel.org>
Cc: Jeff Layton <jlayton@kernel.org>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Rik van Riel <riel@surriel.com>
Cc: Shakeel Butt <shakeel.butt@linux.dev>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
|
|
prctl_set_auxv() copies the user vector into a stack buffer, forces
AT_NULL on the last two entries there, and then copies only len bytes into
mm->saved_auxv. Which is fine until the vector is shorter than the
buffer, because then the forced terminator sits past the end of the copy
and never lands in saved_auxv at all.
The code even says
/* Make sure the last entry is always AT_NULL */
and it does, just not in the part that gets copied.
So mm->saved_auxv keeps the stale tail from exec. Reproducing it is easy:
from a process with CAP_SYS_RESOURCE (just run it as root), call
prctl(PR_SET_MM, PR_SET_MM_AUXV, ...) with a vector that has a couple of
entries and no AT_NULL inside len (32 bytes on arm64), and then hexdump
/proc/self/auxv, or gcore the process and look at the AUXV note with
readelf -n. This is arm64, the new vector was just { AT_UID, 0x1111,
AT_GID, 0x2222 }:
idx before (from exec) after the prctl
[0] AT_SYSINFO_EHDR 0x7ed1d6e000 AT_UID 0x1111 <- new
[1] AT_MINSIGSTKSZ 0x1270 AT_GID 0x2222 <- new
[2] AT_HWCAP 0x119fff AT_HWCAP 0x119fff <- stale
[3] AT_PAGESZ 0x1000 AT_PAGESZ 0x1000 <- stale
... 16 more entries ... <- stale
[20] AT_NULL 0x0 AT_NULL 0x0
21 entries before the prctl, still 21 after: the two new ones plus all 19
left over from exec.
Every consumer walks the vector until AT_NULL, so what they get now is a
vector that never existed at exec, the head from the prctl glued onto the
tail of the old binary. gdb and crash pull the AUXV note out of coredumps
to find AT_PHDR, AT_ENTRY, AT_SYSINFO_EHDR and friends, and a mixed vector
points them at the wrong layout. /proc/<pid>/auxv and PR_GET_AUXV hand
the same mess out to live processes too. Nothing crashes, everything just
quietly reads a frankenstein auxv.
And callers that terminate their own vector hide the whole thing, which is
likely why nobody noticed since PR_SET_MM_AUXV landed in 2012. Nothing
exciting security wise either, I mean it needs CAP_SYS_RESOURCE to begin
with.
prctl_set_mm_map() right above already copies the whole buffer for exactly
this reason, so just do the same here. user_auxv is zero initialized and
only partially filled from userspace, so the rest is zeros and nothing
leaks.
Link: https://lore.kernel.org/20260809002901.32591-1-include@grrlz.net
Fixes: fe8c7f5cbf91 ("c/r: prctl: extend PR_SET_MM to set up more mm_struct entries")
Signed-off-by: Bradley Morgan <include@grrlz.net>
Cc: Alexey Dobriyan <adobriyan@gmail.com>
Cc: Cyrill Gorcuno <gorcunov@openvz.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
|
|
1. Update my university email to my personal Gmail, as the former will
expire after graduation.
2. Fix a typo in my Gmail domain.
Link: https://lore.kernel.org/20260810073235.22980-1-linfeng.sun.dev@gmail.com
Signed-off-by: Linfeng Sun <linfeng.sun.dev@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
|
|
WARN_ON_ONCE() takes a condition, not a message. The string literals are
always true, so the warnings still trigger but the messages are never
printed.
Use WARN_ONCE(1, ...) instead to print the messages and keep the once-only
behavior.
Found with a Coccinelle script. Clang's -Wstring-conversion also flags
such calls but is not enabled in kernel builds.
Link: https://lore.kernel.org/20260808123608.73613-1-kmehltretter@gmail.com
Fixes: 82114e45131f ("lib/interval_tree: add test case for interval_tree_iter_xxx() helpers")
Assisted-by: Claude:claude-fable-5 coccinelle
Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
Reviewed-by: Andrew Morton <akpm@linux-foundation.org>
Reviewed-by: Wei Yang <richard.weiyang@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
|
|
Linux 7.2
There was a lot of conflicts this round between fixes and next,
and I'd like to get the merge resolutions that we have in drm-tip.
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6
Pull crypto update from Herbert Xu:
"API:
- Add af_alg_restrict sysctl and white list
- Fix potential suspend/resume races in hwrng
Algorithms:
- Optimize vli additive operations using compiler builtins in ecc
Drivers:
- Remove unsafe/deprecated algorithms from qce
- Mark qce as BROKEN
- Add runtime PM and interconnect bandwidth scaling support to qce
- Remove crypto_rng from qcom, sun8i and caam
- Fix SG list issues in iaa
- Fix SEV init path bugs in ccp"
* tag 'v7.3-p1' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6: (122 commits)
crypto: lskcipher - propagate errors from unaligned crypt
crypto: keembay - use crypto_memneq() to compare CCM AEAD tags
crypto: keembay - use crypto_memneq() to compare GCM AEAD tags
crypto: sa2ul - use crypto_memneq() to compare AEAD tag
hwrng: drivers - use named initializers for acpi_device_id
crypto: qce - fix CCM AAD buffer underallocation
crypto: iaa - unmap dst before software fallback on decompress
crypto: iaa - use bounce buffer for multi-sg decompress input
crypto: iaa - avoid counting fallback decompression bytes
crypto: iaa - fall back to software for multi-entry scatterlists
hwrng: core - Stop/start hwrng_fillfn() kthread before/after suspend-resume
crypto: hisilicon/sec2 - fix CCM algorithm long packet failure
crypto: eip93 - use struct_size() and flexible array for ring allocation
crypto: krb5 - use kfree_sensitive() for derived key buffers
crypto: af_alg - Stop after finding name in allowlist
crypto: af_alg - Replace 'bool privileged' with flags
crypto: af_alg - Make cbc(paes) privileged-only
hwrng: imx-rngc - Disable clock on registration failure
crypto: qat - remove dead ADF_HEX code
crypto: qce - simplify qce_handle_request
...
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity
Pull integrity updates from Mimi Zohar:
- TPM initialization is sometimes delayed until deferred_probe_initcall
Since ordering is not guaranteed within the same initcall level, IMA
may initialize before the TPM and fall back to TPM-bypass mode. A new
config option, CONFIG_IMA_INIT_LATE_SYNC, allows those building the
kernel to defer IMA initialization to late_initcall_sync, accepting
the integrity risk of missing early measurements in exchange for
avoiding TPM-bypass mode.
- The raw policy rules are now measured, as well as the complete
policy, closing a gap in integrity measurement coverage
* tag 'integrity-v7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity:
ima: measure userspace policy writes before parsing
ima: add critical data measurement for loaded policy
security: ima: rename boot_aggregate when ima is initialised at late_sync
security: ima: introduce IMA_INIT_LATE_SYNC option
security: lsm: allow LSMs to register for late_initcall_sync init
|
