| Age | Commit message (Collapse) | Author |
|---|
|
Pull xfs fixes from Carlos Maiolino:
"This contains a few fixes for the zoned storage support, a possible
deadlock vector fix, some code refactoring patches and a quota evasion
fix on XFS while exporting it via NFS.
Please note that for the quota evasion fix, a couple patches for the
capability subsystem are included in the pull request. Those have been
ack'ed by the respective maintainer which also agreed to have them
going through the xfs tree.
This also includes a patch for the quota subsystem to stop issuing
audit messages during quota enforcing. Quota maintainer also ack'ed
and agreed with this going through xfs tree"
* tag 'xfs-fixes-7.3-rc2' of gitolite.kernel.org:/pub/scm/fs/xfs/xfs-linux:
capability: unexport has_capability_noaudit
xfs: replace ns_capable_noaudit
quota: Don't issue audit messages on quota enforcing
capability: Add new capable_noaudit
xfs: fix capability check in xfs
xfs: restore bi_bdev in xfs_zone_gc_write_chunk
xfs: split ioend handling into a separate source file
xfs: factor out a xfs_iomap_set_anon_write helper
xfs: fix zoned write iomap flags assignments
xfs: fix racy open zone caching
xfs: handle NULL open_zone for merged ioends in xfs_ioend_put_open_zones
xfs: use inode_init_always_gfp with __GFP_NOFAIL in xfs_inode_alloc
xfs: remove kmem_to_page()
xfs: don't flush and invalidate internal RT device twice in xfs_shutdown_devices
xfs: split an assert in xfs_trans_log_buf
xfs: don't hold buffer locks across sync transaction commit in xfs_sync_sb_buf
|
|
Convert the ioctl macros to kernel-doc format to avoid kernel-doc
warnings:
Warning: include/uapi/linux/rpmsg.h:26 This comment starts with '/**',
but isn't a kernel-doc comment.
* Instantiate a new rmpsg char device endpoint.
Warning: include/uapi/linux/rpmsg.h:31 This comment starts with '/**',
but isn't a kernel-doc comment.
* Destroy a rpmsg char device endpoint created by the RPMSG_CREATE_EPT_IOCTL.
Warning: include/uapi/linux/rpmsg.h:36 This comment starts with '/**',
but isn't a kernel-doc comment.
* Instantiate a new local rpmsg service device.
Warning: include/uapi/linux/rpmsg.h:41 This comment starts with '/**',
but isn't a kernel-doc comment.
* Release a local rpmsg device.
Warning: include/uapi/linux/rpmsg.h:46 This comment starts with '/**',
but isn't a kernel-doc comment.
* Get the flow control state of the remote rpmsg char device.
Warning: include/uapi/linux/rpmsg.h:51 This comment starts with '/**',
but isn't a kernel-doc comment.
* Set the flow control state of the local rpmsg char device.
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Link: https://lore.kernel.org/r/20260730052922.1610116-1-rdunlap@infradead.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
Update the IPQ5424 LLCC slice configuration table to give the PPE
and Wi-Fi datapaths dedicated slices.
Assign slice IDs 1 and 5 to the PPE RX descriptor and RX fill use cases,
slice IDs 6 and 7 to the Wi-Fi radios connected over PCIe, and slice ID
2 to the CPU subsystem. Adjust the corresponding capacities, priorities,
and way masks for these consumers.
These slice assignments are based on recommendations from the
performance team, following throughput measurements on IPQ5424.
Having the dedicated slice configuration for each of these use cases
helps to improve the networking throughput by more than 1 Gbps.
Rename the usecase IDs for slice IDs 1 and 2 because LLCC_CPUSS and
LLCC_VIDSC0 do not describe the actual users of those slices.
Assisted-by: LLM
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260819-ipq5424_llcc_updates-v3-1-42b48451481d@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
Since commit b69bb476dee9 ("cgroup: fix race between fork and
cgroup.kill"), the fork path snapshots the kill_seq of the child's
future cgroup into kargs->kill_seq, and cgroup_post_fork() SIGKILLs
the child if that cgroup's kill_seq has changed in the meantime, to
catch forks racing with a cgroup.kill sweep.
For CLONE_INTO_CGROUP, however, the snapshot in cgroup_css_set_fork()
is taken before the target cgroup has been resolved: kargs->cgrp is
always NULL at this point (it is only set at the end of the function).
So the "if (kargs->cgrp)" branch is dead code and the snapshot always
records the kill_seq of the parent's cgroup. cgroup_post_fork() then
compares it with the kill_seq of the target cgroup, so the child gets
SIGKILLed whenever the two cgroups have been killed a different number
of times.
As a result, once cgroup.kill has been written to a cgroup, every
child subsequently cloned into it with clone3(CLONE_INTO_CGROUP) is
killed on the spot, for as long as the cgroup exists: kill_seq is not
exposed to userspace and never resets.
Re-snapshot kill_seq from the target cgroup once it has been resolved,
and drop the dead branch at the early snapshot site.
This does not reopen the race fixed by b69bb476dee9. For
CLONE_INTO_CGROUP, everything from the snapshot to the check in
cgroup_post_fork() runs with cgroup_mutex held, and kill_seq is
only ever incremented under cgroup_mutex.
tj: Updated the comment above kill_seq to reflect the new serialization
rules as suggested by Shakeel Butt.
Fixes: b69bb476dee9 ("cgroup: fix race between fork and cgroup.kill")
Cc: stable@vger.kernel.org
Cc: Shakeel Butt <shakeel.butt@linux.dev>
Assisted-by: LLM
Signed-off-by: Etienne Perot <eperot@google.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
|
|
While the GCC and Clang compilers already define __ASSEMBLER__
automatically when compiling assembly code, __ASSEMBLY__ is a
macro that only gets defined by the Makefiles in the kernel.
This can be very confusing when switching between userspace
and kernelspace coding, or when dealing with uapi headers that
rather should use __ASSEMBLER__ instead. So let's standardize now
on the __ASSEMBLER__ macro that is provided by the compilers.
This is a completely mechanical patch (done with a simple "sed -i"
statement).
Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
|
|
ap_device_id::driver_info is not used in the kernel. The structure is
also not part of API/ABI, so the unused member can just be dropped.
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
Acked-by: Holger Dengler <dengler@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
|
|
The mipi-dbi crtc implementation uses the deprecated
drm_atomic_helper_crtc_reset() as its reset hook.
Switch to drm_atomic_helper_crtc_create_state() instead.
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patch.msgid.link/20260821-drm-no-more-crtc-reset-v1-41-fb793475c05a@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
|
|
The reset_crtc hook in drm_simple_display_pipe_funcs allows simple
KMS drivers to provide a custom CRTC reset implementation. However,
no driver ever implemented it.
Remove the hook and the wrapper function, and use
drm_atomic_helper_crtc_reset() directly.
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patch.msgid.link/20260821-drm-no-more-crtc-reset-v1-21-fb793475c05a@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
|
|
Updating drm-misc-fixes to the state of v7.2.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
|
|
The simple KMS helpers are deprecated because they only add an
intermediate layer between drivers and atomic modesetting.
All driver users of drm_simple_encoder_init() have been converted to
drm_encoder_init(). Drop the helper and open-code its remaining internal
use in drm_simple_display_pipe_init() to prevent new users.
Signed-off-by: Diogo Silva <diogompaissilva@gmail.com>
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patch.msgid.link/20260720-drm_simple_encoder_init-v2-14-5020b630668a@gmail.com
|
|
Memory failures (such as unrecoverable ECCs errors) are getting more and
more common. The kernel knows how to handle it while running, marking it
as poisoned (and SIGBUS user tasks).
Poisoned memory is removed from the buddy allocator, but, not from
other places. A current problem is that kexec will load new kernel
on top of a bad/poisoned memory, which is undesirable.
If the next kernel's image, initrd or purgatory lands on a poisoned
frame, the relocation copy puts it on memory that is known bad. The
error happens on the first read from a bad page, and that is what we
want to avoid.
Skip hardware-poisoned frames that were detected by the memory failure
subsystem earlier when placing kexec segments.
To do so, add a helper that reports the first or the last poisoned page
in a range: memory is walked top-down by locate_mem_hole_top_down() and
bottom-up by locate_mem_hole_bottom_up(), so each direction needs a
different answer to stay clear of the poison.
kexec_load() gets its destinations from userspace and cannot move them,
so there sanity_check_segment_list() just rejects a segment that happens
to have a poisoned page.
is_page_hwpoison() also covers hugetlb, so a poisoned hugetlb folio is
skipped as a whole.
Suggested-by: Kiryl Shutsemau <kas@kernel.org>
Signed-off-by: Breno Leitao <leitao@debian.org>
Reviewed-by: Kiryl Shutsemau (Meta) <kas@kernel.org>
Reviewed-by: Pratyush Yadav <pratyush@kernel.org>
Reviewed-by: Bradley Morgan <include@grrlz.net>
Reviewed-by: Miaohe Lin <linmiaohe@huawei.com>
Link: https://patch.msgid.link/20260812-kexec_posioned-v6-2-e477887086f0@debian.org
Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
|
|
- drop Excess description of @lock from kernel-doc
- add missing function/macro short descriptions
WARNING: include/linux/dma-fence-array.h:47 Excess struct member 'lock' description in 'dma_fence_array'
WARNING: include/linux/dma-fence-chain.h:48 Excess struct member 'lock' description in 'dma_fence_chain'
Warning: include/linux/dma-fence-chain.h:82 missing initial short description on line:
* dma_fence_chain_alloc
Warning: include/linux/dma-fence-chain.h:94 missing initial short description on line:
* dma_fence_chain_free
Fixes: 5943243914b9 ("dma-buf: use inline lock for the dma-fence-array")
Fixes: a408c0ca0c41 ("dma-buf: use inline lock for the dma-fence-chain")
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Christian König <christian.koenig@amd.com>
Link: https://lore.kernel.org/r/20260831031956.3410813-1-rdunlap@infradead.org
|
|
Currently there is no way to race-freely create and open a directory.
For regular files we have open(O_CREAT) for creating a new file inode,
and returning a pinning fd to it. The lack of such functionality for
directories means that when populating a directory tree there's always
a race involved: the inodes first need to be created, and then opened
to adjust their permissions/ownership/labels/timestamps/acls/xattrs/...,
but in the time window between the creation and the opening they might
be replaced by something else.
Addressing this race without a proper API is only partially possible:
the caller can immediately fstat() what was opened to verify that it
has the expected inode type, owner and mode. But besides being easy to
get wrong, this cannot establish who created the directory: a directory
created by another process with identical credentials is
indistinguishable from one the caller created itself, so the caller
cannot tell whether the directory is its own to manage.
Historically, the O_CREAT|O_DIRECTORY behaviour was to return ENOTDIR if
a regular file exists at the open path; EISDIR if a directory exists at
the path; and to create a regular file if no file exists at the path.
This behaviour changed accidentally with 973d4b73fbaf ("do_last(): rejoin
the common path even earlier in FMODE_{OPENED,CREATED} case") causing
ENOTDIR to return in the last case while still creating the file. As
this change was not detected for a long time, Brauner proposed to adopt
the more consistent NetBSD behaviour, i.e. to return EINVAL on the
O_CREAT|O_DIRECTORY combination. This change was applied in 43b450632676
("open: return EINVAL for O_DIRECTORY | O_CREAT") in March, 2023. As
the EINVAL behaviour has been in the kernel for about 3 years now, no
rollback is expected as a result of userspace reliance on old
behaviour, leaving us free to reassign the O_CREAT|O_DIRECTORY semantics.
O_CREAT|O_DIRECTORY is made to reduce to a lookup on ->atomic_open()
filesystems. These filesystems currenly cannot handle
O_CREAT|O_DIRECTORY without protocol extensions and therefore are forced
into a fallback mode by stripping the O_CREAT bit. This causes existing
directories to be succesfully opened, while for targets that should have
been created, -ENOENT is returned. The other option of simply returning
-EINVAL leads to inconsistent behaviour: before ->atomic_open() is
called in lookup_open(), the dcache is queried. So returning -EINVAL
there would make O_CREAT|O_DIRECTORY dependent on the cache state of the
dentry.
There is no separate sysctl for directory creation implemented currently.
Therefore, for the S_ISDIR case, disabling sysctl_protected_regular is
not enough to allow creating a directory in a sticky folder, because that
may surprise users not expecting that O_CREAT|O_DIRECTORY is possible on
newer kernels.
This feature idea (and some of its description) is taken from the
UAPI group:
https://github.com/uapi-group/kernel-features?tab=readme-ov-file#race-free-creation-and-opening-of-non-file-inodes
Signed-off-by: Jori Koolstra <jkoolstra@xs4all.nl>
Link: https://patch.msgid.link/20260823160706.358293-7-jkoolstra@xs4all.nl
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
|
|
Variable naming of val and val1 should match register macro naming.
Historically, corresponding macros were named GEN6_PCODE_DATA and
GEN6_PCODE_DATA1.
Rename register macro GEN6_PCODE_DATA to GEN6_PCODE_DATA0 since spec
appended '0' to the register name. Rename val into val0 in functions
declaring val1 for both i915-specific and shared display code.
v4->v5
- clean changelog's versioning
v3->v4
- split i915 changes from xe (Jani)
- apply the rename to the read()'s signature as well (Sashiko)
v2->v3
- resolve conflict from rebase
v1->v2
- rebase onto drm-tip (Jani)
Bspec: 19978
Suggested-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Michał Grzelak <michal.grzelak@intel.com>
Link: https://patch.msgid.link/20260828190956.2622350-2-michal.grzelak@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
cad_pid is a single kernel-wide struct pid pointer. proc_do_cad_pid()
reads it and passes it to pid_vnr() without protecting the lifetime of
the referenced struct pid. A concurrent writer can replace cad_pid and
drop the final reference to the old struct pid after the reader has
loaded the pointer but before pid_vnr() has finished dereferencing it,
causing a use-after-free.
kill_cad_pid() has the same lifetime race when it passes cad_pid to
kill_pid().
At the time this issue was reported, an unprivileged user could reach the
sysctl through user and PID namespaces because cad_pid was registered in
pid_table[]. Moving cad_pid back to the global reboot sysctl table
corrected that namespace and permission mismatch, but did not fix the
underlying lifetime race.
Fix this by treating cad_pid as an RCU-protected pointer at both read
sites and by waiting for a grace period before dropping the old reference
on the write side.
call_rcu(&old_pid->rcu, ...) cannot be used here because free_pid()
also queues pid->rcu; queueing the same rcu_head twice can corrupt the
RCU callback list.
Original KASAN crash stack:
kernel/pid.c:545 pid_nr_ns() # reads freed pid->level
kernel/pid.c:556 pid_vnr() # calls pid_nr_ns()
kernel/pid.c:775 proc_do_cad_pid() # calls pid_vnr(cad_pid)
Fixes: 9ec52099e4b8 ("[PATCH] replace cad_pid by a struct pid")
Reported-by: AutonomousCodeSecurity@microsoft.com
Closes: https://lore.kernel.org/all/20260717210143.4734-1-blbllhy@gmail.com/
Link: https://lore.kernel.org/all/alz5ZYLE4kaq_v2P@redhat.com/
Link: https://lore.kernel.org/all/al4ICz9biJKtdZc4@redhat.com/
Suggested-by: Mateusz Guzik <mjguzik@gmail.com>
Suggested-by: Bradley Morgan <include@grrlz.net>
Suggested-by: Oleg Nesterov <oleg@redhat.com>
Suggested-by: Eric W. Biederman <ebiederm@xmission.com>
Suggested-by: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>
Cc: stable@vger.kernel.org
Signed-off-by: Cen Zhang (Microsoft) <blbllhy@gmail.com>
Link: https://patch.msgid.link/20260814040944.16561-1-blbllhy@gmail.com
Reviewed-by: Bradley Morgan <include@grrlz.net>
Reviewed-by: Oleg Nesterov <oleg@redhat.com>
Reviewed-by: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
|
|
TIF_NOTIFY_SIGNAL is used to kick a task in uninterruptible sleep to
return to userspace and run task work and then go back to sleep. This
mechanism works well but breaks e.g., coredumps. dump_interrupted() only
allows fatal signals to interrupt a coredump and the whole regular write
path going to actual filesystems is impervious to TIF_NOTIFY_SIGNAL as
well.
Add PF_NO_NOTIFY_SIGNAL and helpers to raise and restore it. This is the
same approach as memalloc_nofs_save(). signal_pending() will not report
a fake pending signal via TIF_NOTIFY_SIGNAL if inside a
PF_NO_NOTIFY_SIGNAL section.
No functional changes.
Link: https://patch.msgid.link/20260824-work-tif_notify_signal-v2-1-6609e42b3157@kernel.org
Reviewed-by: Oleg Nesterov <oleg@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
|
|
Currently, trace_cachefiles_coherency() is being passed a pointer to a
__be64 lain over the coherency data in struct cachefiles_xattr so that it
can display the first 8 bytes. However, the data is of variable length and
could even be 0 bytes. This could lead to a UAF or KASAN warning.
Fix this by making sure the buffer has room for at least 8 bytes and that
those 8 bytes are pre-cleared.
Further, those bytes are not 8-byte aligned, so fix the tracepoint to
extract the data as four 2-byte words (they are 2-byte aligned) and
reassemble the __be64. The compiler will convert this into a single 8-byte
load where the CPU supports it.
Fixes: 229105e5cfd9 ("cachefiles: Add auxiliary data trace")
Link: https://sashiko.dev/#/patchset/20260810144746.574036-1-dhowells%40redhat.com
Signed-off-by: David Howells <dhowells@redhat.com>
Link: https://patch.msgid.link/20260827134304.2075713-11-dhowells@redhat.com
Acked-by: Paulo Alcantara <pc@manguebit.org>
cc: Paulo Alcantara <pc@manguebit.org>
cc: netfs@lists.linux.dev
cc: linux-fsdevel@vger.kernel.org
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
|
|
For really big read RPC ops that span multiple folios, netfslib allows the
filesystem to give progress notifications to wake up the collector thread
to do a collection of folios that have now been fetched, even if the RPC is
still ongoing, thereby allowing the application to make progress.
This works by taking the current rreq->cleaned_to value (which indicates
which folios have been unlocked) and adding the stashed size of the next
folio to it. cleaned_to, however, is subject to 64-bit tearing on a 32-bit
arch.
Fix this by stashing the next progress notification point as a size_t
(which won't tear) to be added to rreq->start (which won't change), with
the collector thread calculating that from cleaned_to plus the next folio
size.
Further, however, if the folios are small, the collector thread gets
constantly woken up - which has a negative performance impact on the
system.
Fix that too by setting a minimum trigger of 256KiB or the size of the
folio at the front of the queue, whichever is larger. Note that this has
an issue that different subreqs have different need-to-be-cached
properties; this is solved by a preceding patch that marks the property on
the folios whilst issuing subreqs rather than when collecting them.
Also, make sure rreq->cleaned_to is initialised up front, along with
rreq->collected_to and stream->collected_to.
Fixes: e2d46f2ec332 ("netfs: Change the read result collector to only use one work item")
Link: https://sashiko.dev/#/patchset/20260804100224.2748935-1-dhowells%40redhat.com
Signed-off-by: David Howells <dhowells@redhat.com>
Link: https://patch.msgid.link/20260827134304.2075713-10-dhowells@redhat.com
Acked-by: Paulo Alcantara <pc@manguebit.org>
cc: Paulo Alcantara <pc@manguebit.org>
cc: netfs@lists.linux.dev
cc: linux-fsdevel@vger.kernel.org
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
|
|
Mark folios with NETFS_FOLIO_COPY_TO_CACHE whilst issuing subreqs rather than
when collecting them. This means that the collector thread doesn't have to
try and keep track of which subreqs contribute to which folios - and thus
which folios will need to be copied to the cache because at least one byte
wasn't in the cache. Instead, this is marked on the folios up front and the
collector need only consider the folios.
For PG_private_2-using filesystems, PG_private_2 is set instead of
NETFS_FOLIO_COPY_TO_CACHE, but otherwise it works the same.
The NETFS_RREQ_COPY_TO_CACHE is replaced with NETFS_RREQ_CANCEL_CACHING, which
is now set if caching fails somewhere, thereby causing the collection thread
to cancel the copy-to-cache marks on the remaining folios.
Signed-off-by: David Howells <dhowells@redhat.com>
Link: https://patch.msgid.link/20260827134304.2075713-9-dhowells@redhat.com
Acked-by: Paulo Alcantara <pc@manguebit.org>
cc: Paulo Alcantara (Red Hat) <pc@manguebit.org>
cc: Matthew Wilcox <willy@infradead.org>
cc: netfs@lists.linux.dev
cc: linux-mm@kvack.org
cc: linux-fsdevel@vger.kernel.org
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
|
|
There are some synchronisation issues that derive from the app thread
adding more folios to the rolling buffer whilst the collector thread is
looking at them or trying to clear them, such as determining the setting of
front_folio_order when the next folio hasn't been added yet,
The reason for the rolling buffer approach is that loading the buffer
upfront and then dropping all the refs just acquired is quite a slow
operation, and loading progressively allows some of the cost to be deferred
until after at least some of the I/O is started.
Instead, a better way is to load all the folios into the rolling buffer
upfront - and then drop the refs later, once the I/O is in progress. (Even
better would be for the refs not to be there at all.)
Fix this by changing the rolling buffer loader to load all the folios
selected by the VM for readahead upfront into the folio queue. The folio
queue is allocated a batch worth at a time as we don't know how many folios
are involved (the readahead_control struct, alas, has a page count, not a
folio count).
The folio refs acquired from readahead are then dropped in bulk once the
first subrequest is dispatched as it's quite a slow operation. The
collector waits for NETFS_RREQ_NEED_PUT_RA_REFS to be cleared so that it
doesn't unlock folios before the xarray has been scanned for them.
This simplifies the buffer handling later and isn't noticeably slower as
the xarray doesn't need to be modified and the folios are all already
pre-locked.
Fixes: ee4cdf7ba857 ("netfs: Speed up buffered reading")
Link: https://sashiko.dev/#/patchset/20260824120224.504575-1-dhowells%40redhat.com
Signed-off-by: David Howells <dhowells@redhat.com>
Link: https://patch.msgid.link/20260827134304.2075713-8-dhowells@redhat.com
Acked-by: Paulo Alcantara <pc@manguebit.org>
cc: Paulo Alcantara (Red Hat) <pc@manguebit.org>
cc: Matthew Wilcox <willy@infradead.org>
cc: netfs@lists.linux.dev
cc: linux-mm@kvack.org
cc: linux-fsdevel@vger.kernel.org
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
|
|
reset_all_zones_managed_pages() is only called from memblock_free_all(),
which runs once during boot.
So remove the reset_managed_pages_done guard, make the function static
and drop its declaration.
No functional change.
Signed-off-by: Sang-Heon Jeon <ekffu200098@gmail.com>
Link: https://patch.msgid.link/20260819154436.3225746-1-ekffu200098@gmail.com
Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
|
|
Getting drm-misc-next up to v7.3-rc1.
In exynos, there was a conflict in exynos_dbi_bind(). The merge resolves
it to the state of commit 3cc8eee9f346 ("drm/exynos: remove dependency
on DRM simple helpers").
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
|
|
Sync host command header with the ChromeOS EC firmware.
This primarily adds the host command, MKBP event, and related data
structures for power monitoring so that the API is available for other
drivers.
Signed-off-by: Daniel Balint <dbalint@google.com>
Link: https://lore.kernel.org/r/20260824155554.1046334-1-dbalint@google.com
Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
|
|
Both industrialio-gts-helper.c and iio-gts-helper.h use error codes
defined in <asm-generic/errno-base.h> (usually included via
<linux/errno.h>), but only industrialio-gts-helper.c includes it. On the
other hand, that file also uses error macros like IS_ERR() and
PTR_ERR(), which are included in <linux/err.h>.
Add the right includes to provide the used elements from the error
headers:
- <linux/errno.h> in iio-gts-helper.h
- <linux/err.h> in industrialio-gts-helper.c, which in turn includes
<asm/errno.h>, which only includes <asm-generic/errno-base.h>
Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
Reviewed-by: Matti Vaittinen <mazziesaccount@gmail.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Signed-off-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
|
|
The PCA9450 uses each regulator's ENMODE field to control whether the
regulator remains enabled when the PMIC transitions from RUN to STANDBY
mode.
The driver does not currently implement set_suspend_disable(), so a
regulator configured with regulator-off-in-suspend remains enabled
during system suspend.
Implement set_suspend_disable() for the buck regulators and LDO3-LDO5.
The suspend and runtime controls share ENMODE, so first read the field
and leave it unchanged when it is 00b. This preserves the state of a
regulator that was already disabled at runtime. For an enabled regulator,
program 10b to keep it on in RUN and turn it off while PMIC_STBY_REQ is
asserted.
Most buck descriptors set enable_val to 01b, while BUCK2 uses 10b. When
enable_val is nonzero, regulator_is_enabled_regmap() checks for an exact
match. It would therefore report most bucks as disabled after their ENMODE
is changed from 01b to 10b, even though all valid nonzero ENMODE values
enable the regulator in RUN. Use a custom is_enabled() helper for the buck
operation tables that considers a nonzero ENMODE enabled. The LDO
descriptors leave enable_val at zero, for which the generic helper already
performs this nonzero check, so keep using it for the LDOs.
Runtime enable and disable operations remain unchanged: disable writes
00b and enable writes the regulator's default mode. The suspend callback
reapplies 10b on each suspend after any intervening runtime operation.
Keep LDO1 and LDO2 on regulator operations without
set_suspend_disable(), because these regulators supply the SNVS domain
and must remain enabled in STANDBY mode.
Measured on a custom i.MX8MP board, turning off NVCC_SD2 (LDO5) during
system suspend reduced power consumption by approximately 64 mW.
Signed-off-by: Fabio Estevam <festevam@nabladev.com>
Link: https://patch.msgid.link/20260818014059.351152-2-festevam@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
LDO5 has voltage-selection fields in both LDO5CTRL_L and LDO5CTRL_H,
selected by the SD_VSEL pin. Its ENMODE field, however, is only in
LDO5CTRL_L.
The regulator descriptors correctly use LDO5CTRL_L as enable_reg, but
use the misleading LDO5H_EN_MASK name for enable_mask. Both mask
definitions have the same value, so this causes no functional problem.
Use LDO5L_EN_MASK in all LDO5 descriptors and remove the unused
LDO5H_EN_MASK definition.
Signed-off-by: Fabio Estevam <festevam@nabladev.com>
Link: https://patch.msgid.link/20260818014059.351152-1-festevam@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
This patch extends the existing tas2781 codec driver to add full support
for the TAS2573 integrated DSP feature.
Signed-off-by: Shenghao Ding <shenghao-ding@ti.com>
Link: https://patch.msgid.link/20260815025510.1815-1-shenghao-ding@ti.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
raw_v4_match() reads inet_daddr, inet_rcv_saddr and
sk_bound_dev_if locklessly under RCU. Bind and connect writers are
annotated, but __udp_disconnect() still clears the same fields using
plain stores.
Commit 18f116931f52e ("raw: annotate lockless match fields in
raw_v4_match()") added the lockless readers and annotated the raw bind
and datagram connect writers. Its v4 revision intentionally left the
shared disconnect-side IPv4 writers for follow-up cleanup.
Complete that follow-up by using WRITE_ONCE() for the disconnect-side
stores, including the inet_rcv_saddr reset in inet_reset_saddr(), to
pair with the lockless raw socket matcher.
Fixes: 0daf07e52709 ("raw: convert raw sockets to RCU")
Link: https://lore.kernel.org/netdev/20260716142958.3064224-1-runyu.xiao@seu.edu.cn/
Suggested-by: Runyu Xiao <runyu.xiao@seu.edu.cn>
Signed-off-by: Jackie Liu <liuyun01@kylinos.cn>
Signed-off-by: Xuanqiang Luo <luoxuanqiang@kylinos.cn>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Link: https://patch.msgid.link/20260828012918.1461-1-xuanqiang.luo@linux.dev
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
It turns out the previous usage of hardirq_disable_count() in
__irq_exit_rcu() would cause softirq pending issues. Without that usage,
hardirq_disable_count() doesn't need to exist, so remove it.
Also move hardirq_disable_enter/exit() into the Rust specific interrupt_rc
header.
[ tglx: Move the helpers over ]
Signed-off-by: Boqun Feng <boqun@kernel.org>
Signed-off-by: Thomas Gleixner <tglx@kernel.org>
Link: https://patch.msgid.link/20260827194835.38968-1-boqun@kernel.org
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull locking fix from Ingo Molnar:
- Revert a commit to spinlock cleanup guards that got caught up
in the subtle limitations & fragility of guards (again...) and
caused a regression (Peter Zijlstra)
* tag 'locking-urgent-2026-08-30' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
locking: Revert switching guards to _irq_{disable,enable}()
|
|
Currently a softirq may be pending longer then expected if the
triggering interrupt happens in-between hardirq_disable_enter() and
_local_interrupt_disable() in local_interrupt_disable():
local_interrupt_disable():
hardirq_disable_enter();
<interrupt>
...
__irq_exit_rcu():
// false because hardirq_disable_count() is not 0
if (.. && !hardirq_disable_count() && ..) {
invoke_softirq();
}
_local_interrupt_disable();
, it'll defer the softirq to the next interrupt which can be forever.
The order between hardirq_disable_enter() and _local_interrupt_disable()
is to optimize re-disabling interrupts if they are already disabled, but
as 1) local_interrupt_disable() is not widely used yet and 2) the proper
way to achieve this optimization may need fixing up the counter at
entry/exit time [1], so reverse the order for now to avoid the softirq
pending issue.
Because of this fix, the part of saving the current state is separated
from irq disabling, and the logic of local_interrupt_disable() becomes:
local_irq_save(flags);
if (counter++ == 0) {
this_cpu(local_interrupt_disable_state) = flags;
}
Therefore change the helper function _local_interrupt_disable() to
_local_interrupt_save_state() which only saves the current irqflags
(when interrupts get disabled the first time).
Fixes: e901c1510e24 ("irq,spin_lock: Add counted interrupt disabling/enabling")
Reported-by: Thomas Gleixner <tglx@kernel.org>
Signed-off-by: Boqun Feng <boqun@kernel.org>
Signed-off-by: Thomas Gleixner <tglx@kernel.org>
Reviewed-by: Bradley Morgan <brads@mainlining.org>
Link: https://patch.msgid.link/20260829213412.14303-1-boqun@kernel.org
Link: https://lore.kernel.org/lkml/87v78wezid.ffs@fw13/ [1]
Closes: https://lore.kernel.org/lkml/87jypbfu1t.ffs@fw13/
|
|
Nothing changes for systems that do not use the bpf keyring. Without
bpf.keyring_unsealed=1 a caller-supplied keyring behaves exactly as
before, which also lets it serve as the staging step for software
installed onto a running system whose signing key is not enrolled
anywhere yet.
Passing bpf.keyring_unsealed=1 states that the bpf keyring is the trust
anchor for this boot, so from the first program load onwards a caller-
supplied keyring is refused with -EPERM. Deriving this from the boot
flag rather than from the keyring's runtime state keeps the decision
immutable from userspace.
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Link: https://lore.kernel.org/r/20260828175227.1537793-3-daniel@iogearbox.net
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
|
|
BPF program signatures can currently be verified against one of the
system keyrings (builtin, secondary, platform) or against an arbitrary
user/session caller-supplied keyring named through keyring_id. There
is nothing in between: the system keyrings need a kernel rebuild or a
vouched-for enrollment to rotate a key, while a caller-supplied keyring
is fully controlled by the loader and therefore carries no trust on
its own (unless explicitly combined with BPF LSM to protect against
key tampering).
Add a dedicated bpf keyring to fill that gap, modelled after the
dm-verity keyring which was added in commit 033724b1c627 ("dm-verity:
add dm-verity keyring") and which can eventually be used also via
systemd [0] through the same enrollment method as in dm-verity's case.
It is selected with the new KEY_SPEC_BPF_KEYRING special key id and
gives an operator a place to enroll a BPF-only signing key at boot,
specifically scoped to BPF program loading and nothing else in the
kernel's trust hierarchy.
The id is reserved from the KEY_SPEC space so that the latter is not
linked into any process keyring, and lookup_user_key() resolves
KEY_SPEC_BPF_KEYRING constant instead of having to look it up via
/proc/keys first.
By default the keyring is sealed empty at init. Systems that want to
provision keys pass bpf.keyring_unsealed=1, which leaves the keyring
open for the initrd to add keys to. The keyring is only ever consulted
once it is both non-empty and restricted. An unrestricted keyring is
ignored.
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Link: https://github.com/systemd/systemd/pull/43549 [0]
Link: https://lore.kernel.org/r/20260828175227.1537793-2-daniel@iogearbox.net
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
|
|
btf_struct_member_walk() hardcodes that every member of a struct returned
by value must be a scalar. A later patch needs the same walk to also
accept arena pointers, so give it a mask of the member kinds it allows.
The mask reaches callers through btf_struct_is_composed_of(), which
replaces btf_type_is_scalar_struct() as the entry point exported to
btf.c. btf_type_is_scalar_struct() stays as a verifier-local wrapper for
the call sites that only ever ask about scalars.
There is no functional change: btf_member_kind_allowed() is exactly
btf_type_is_scalar() when the mask is BTF_MEMBER_SCALAR alone, and the
shared check is the last statement of the loop body, so dropping the array
branch's continue neither skips a member nor checks one twice.
Signed-off-by: Yonghong Song <yonghong.song@linux.dev>
Link: https://lore.kernel.org/r/20260829061534.1693789-1-yonghong.song@linux.dev
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
|
|
Add btf_type_is_arena_ptr() to test whether a BTF type is a pointer
carrying the "arena" type tag, and use it to simplify both
btf_scan_type_tags() and btf_validate_return_type(). The helper has
external linkage because a later patch calls it from verifier.c to
decide whether a struct member returned by value may be an arena
pointer.
btf_scan_type_tags() drove btf_type_tag_walk() with a one-entry match
table, so the "multiple type tags" error it checked for could never
fire: btf_type_tag_walk() only fails when the walk sets more than one
flag. Dropping that error path, and with it the int return, is
therefore no functional change.
Signed-off-by: Yonghong Song <yonghong.song@linux.dev>
Link: https://lore.kernel.org/r/20260829061529.1693266-1-yonghong.song@linux.dev
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
|
|
btf_type_is_scalar_struct() recurses into nested struct members and
carries the nesting depth in a @rec argument, so every caller has to
spell out the 0 that starts the walk.
Move the recursion into btf_struct_member_walk() and leave
btf_type_is_scalar_struct() as a thin wrapper over it. This is
groundwork for the later patches, which give the walk further state
that callers should not have to supply: the kinds of member it accepts,
and a record of the member that made it fail.
No functional change.
Signed-off-by: Yonghong Song <yonghong.song@linux.dev>
Link: https://lore.kernel.org/r/20260829061524.1692957-1-yonghong.song@linux.dev
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
|
|
Pull more SCSI updates from Martin Petersen:
"Remaining updates for the 7.3 merge window. The only core change is
enabling context analysis for the SCSI layer and UFS.
The remaining changes are either bug fixes or hardening"
* tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi: (26 commits)
scsi: snic: Fix SCSI host leak on workqueue allocation failure
scsi: MAINTAINERS: Update my email address
scsi: MAINTAINERS: Leave the cumana_1 and oak drivers to the RISCPC maintainers
scsi: leapraid: Standardize NCQ priority sysfs attributes
scsi: leapraid: Serialize firmware log mmap with teardown
scsi: leapraid: Balance host references for firmware log VMAs
scsi: lpfc: Remove unnnecessary NULL check
scsi: qla2xxx: Fix an loop timeout test
scsi: qla2xxx: Fix an error code in qla_get_tmf()
scsi: ibmvfc: Fix use of uninitialized rport in ibmvfc_do_work()
scsi: core: Enable context analysis for hosts.o
scsi: lpfc: Replace strlcat() with sysfs_emit_at() in the sysfs show functions
scsi: lpfc: Replace strlcat() with seq_buf in the debugfs dump helpers
scsi: lpfc: Replace strlcat() with seq_buf in lpfc_rx_monitor_report()
scsi: lpfc: Replace strlcat() with scnprintf() in lpfc_vport_symbolic_node_name()
scsi: lpfc: Replace strlcat() with seq_buf in lpfc_info()
scsi: core: Enable context analysis
scsi: core: Protect host state changes with the host lock
scsi: core: Add lock context annotations
scsi: core: Pass the SCSI host pointer directly to scanning functions
...
|
|
Pull more drm updates from Dave Airlie:
"As mentioned last week, an msm pull request fell down the side of the
couch or whatever the email equivalent of that is. This has the msm
next stuff + the usual fixes for amd/intel.
core:
- use drm_warn instead of warn
msm:
- Bindings:
- Added Shikra support
- Document a840, a704, a722
- Core:
- Use drm_client buffers for fbdev emulation
- teardown fixes
- ARM32 DMA fixup
- Remove objects from evict list when re-validated
- Bunch of corner case and error path fixes
- DPU:
- Dropped dev_pm_opp_set_rate(0) preventing burnout
- Fixed SSPP offsets of Kaanapali
- DP:
- Dropped dev_pm_opp_set_rate(0) preventing burnout
- Cleaned up core code in preparation for MST support
- Fixed prepare() to let Pipewire continue in case of the unplugged cable
- GPU:
- Add support for a704
- Add support for a722
- HDMI:
- Simplifed register access
amdgpu:
- eGPU fixes
- Runtime PM fix
- UserQ fixes
- Backlight fix
- Discovery sysfs fix
- Reset handling fixes
- Buffer func handling fix for xgmi
- VCN boundary check fix
- DC lut handling fixes
- MES fixes
- UVD fix
- VCE 3 fix
- Enforce isolation fix
- HPD fix for VGA/LVDS
- DML fix
- DCN 6 fixes
- DC gpu reset fix
amdkfd:
- Fix return value
- CU occupancy for GFX 11
- CU occupancy for GFX 12/12.1
- Queue bounds checking fix
- SVM fixes
- CRIU bounds checking fix
radeon:
- iMac display fix
xe:
- error message cleanups
- i2c global register definitions as dependency for xe/i2c fixes
- Media workardound
- Add CCS to gt_idle debugfs print
- Page fault related fix
- i2c related fixes
- System Controller mailbox bit fix"
* tag 'drm-next-2026-08-29' of https://gitlab.freedesktop.org/drm/kernel: (121 commits)
drm/xe/sysctrl: Read mailbox phase bit from hardware
drm/xe/i2c: Keep the i2c controller always enabled
drm/xe/i2c: Fix the interrupt handling
i2c: designware: Global register definitions
drm/xe: Reject page faults from non-fault-mode scratch VMs
drm/xe/xe_gt_idle: Add CCS to the powergating info print
drm/xe: Do not apply WA 14025883347 to media 3503
drm/amd/display: fix dc_lock leak on GPU reset error paths
drm/amd/display: Fix redundant GPUVMEnable checks in dcn6 flip schedule
drm/amd/display: Fix wrong bytes-per-pixel value for dml2_422_packed_10
drm/amdkfd: guard against NULL restore_mqd in CRIU queue restore
drm/amdgpu/userq: fix lock missing for userq fence error set
drm/amdkfd: Fix the case that vm range is hole at svm_migrate_copy_to_vram
drm/amdkfd: Fix error path at svm_migrate_copy_to_ram
drm/amd/display: Log details when failing to register HPD IRQ
drm/amd/display: Fix HPD consideration for VGA/LVDS connectors on DCE
drm/amdgpu: clamp the isolation index for rings outside a partition
drm/amdkfd: Reject zero-sized AQL queue allocations after size halving
drm/amdgpu: Fix VCE 3 ring align_mask
drm/kfd: Add CU occupancy support to GFX12.1
...
|
|
Syzbot reported a crash in qdisc_pkt_len_segs_init() caused by a stale
transport_header offset after tunnel decapsulation.
BUG: unable to handle page fault for address: ffffed102091a42e
Oops: Oops: 0000 [#1] SMP KASAN NOPTI
CPU: 0 UID: 0 PID: 340 Comm: qdisc_uaf_repro Not tainted 7.2.0-rc4-00061-g248951ddc14d #256 PREEMPT(full)
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
RIP: 0010:__asan_load2
<IRQ>
qdisc_pkt_len_segs_init (net/core/dev.c:4145)
__dev_queue_xmit (net/core/dev.c:4787)
br_dev_queue_push_xmit (net/bridge/br_forward.c:53)
br_handle_frame_finish (net/bridge/br_input.c:229)
br_handle_frame (net/bridge/br_input.c:315)
__netif_receive_skb_core.constprop.0 (net/core/dev.c:6099)
__netif_receive_skb_list_core (net/core/dev.c:6287)
netif_receive_skb_list_internal (net/core/dev.c:6445)
napi_complete_done (net/core/dev.c:6813)
gro_cell_poll (net/core/gro_cells.c:74)
__napi_poll (net/core/dev.c:7735)
net_rx_action (net/core/dev.c:7798 net/core/dev.c:7955)
handle_softirqs (kernel/softirq.c:622)
do_softirq (kernel/softirq.c:523 kernel/softirq.c:510 )
__local_bh_enable_ip (kernel/softirq.c:450)
tun_get_user (drivers/net/tun.c:1986 (discriminator 1))
tun_chr_write_iter (drivers/net/tun.c:2032)
The issue is completely latent until qdisc read transport header in
commit 7fb4c1967011 ("net: pull headers in qdisc_pkt_len_segs_init()").
The crash requires four conditions to line up:
1. The incoming packet is encapsulated and carries GSO metadata. The outer
transport header offset is stored in skb->transport_header while the
packet is still in the outer tunnel context.
2. The tunnel receiver strips the outer headers. skb->data is advanced to
the inner frame, but skb->transport_header is left pointing to the
now-removed outer L4 header, so it becomes a negative offset relative to
the new data.
3. The inner frame is not delivered to the local IP stack. Instead, it
is forwarded at L2 by a bridge or HSR, so ip_rcv_core() never runs and
the transport header is not reset to the inner L4 offset.
4. The forwarding path calls __dev_queue_xmit(), which enters
qdisc_pkt_len_segs_init(). That function computes the GSO header length
from skb_transport_offset(skb). Because the offset is negative, the
unsigned cast overflows and pskb_may_pull(skb, hdr_len +
sizeof(struct tcphdr)) reads past the end of the skb, triggering a
KASAN fault or page fault.
The issue specifically requires GSO packets (shinfo->gso_size != 0), which
are processed/aggregated through gro_cells. Fix this by clearing
transport_header to the ~0U sentinel in gro_cell for all tunnnel driver.
GTP does not support GRO/GSO, drop the evil GSO packets in GTP directly.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Reported-by: syzbot+83181a31faf9455499c5@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/all/69de2bee.a00a0220.475f0.0041.GAE@google.com/T/
Suggested-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Dong Chenchen <dongchenchen2@huawei.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Link: https://patch.msgid.link/20260825123909.1463121-1-dongchenchen2@huawei.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
tcp_send_active_reset() can be called from contexts where gfp_any()
(in tcp_disconnect()) or sk->sk_allocation (in __tcp_close() and
mptcp_do_fastclose()) evaluates to GFP_KERNEL, which includes
__GFP_FS and __GFP_DIRECT_RECLAIM.
Allocating with GFP_KERNEL while holding the socket lock (sk_lock) creates
a lockdep dependency:
sk_lock -> fs_reclaim
This causes false-positive lockdep circular locking warnings with storage
subsystems (such as nvme-tcp) that acquire socket locks in block I/O paths
and invoke tcp_disconnect() or close sockets upon teardown:
set->srcu -> sk_lock -> fs_reclaim -> elevator_lock -> set->srcu
Active resets are small RST packet headers that should never
enter direct reclaim or block while holding socket locks.
Use sk_gfp_mask(sk, GFP_ATOMIC | __GFP_NOWARN) inside tcp_send_active_reset()
and remove its priority argument. This preserves __GFP_MEMALLOC access
for SOCK_MEMALLOC sockets, suppresses allocation failure warnings,
and aligns with other control packet allocations (e.g. tcp_send_fin(),
__tcp_send_ack(), tcp_xmit_probe_skb()).
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Acked-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20260827095936.551524-1-edumazet@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
syzbot reported a WARNING triggered by DEBUG_NET_WARN_ON_ONCE():
WARNING: at skb_transport_header include/linux/skbuff.h:3087 [inline]
WARNING: at udp_hdr include/linux/udp.h:23 [inline]
WARNING: at do_trace_event_raw_event_icmp_send include/trace/events/icmp.h:30 [inline]
WARNING: at trace_event_raw_event_icmp_send+0x48c/0x6ec include/trace/events/icmp.h:11
Call trace:
skb_transport_header include/linux/skbuff.h:3087 [inline]
udp_hdr include/linux/udp.h:23 [inline]
do_trace_event_raw_event_icmp_send include/trace/events/icmp.h:30 [inline]
trace_event_raw_event_icmp_send+0x48c/0x6ec include/trace/events/icmp.h:11
__traceiter_icmp_send include/trace/events/icmp.h:11 [inline]
__do_trace_icmp_send include/trace/events/icmp.h:11 [inline]
trace_icmp_send+0x320/0x49c include/trace/events/icmp.h:11
__icmp_send+0xcfc/0x11d8 net/ipv4/icmp.c:1013
ipv4_send_dest_unreach net/ipv4/route.c:1280 [inline]
ipv4_link_failure+0x57c/0x8dc net/ipv4/route.c:1287
dst_link_failure include/net/dst.h:438 [inline]
vti_tunnel_xmit+0xe40/0x17a4 net/ipv4/ip_vti.c:307
TP_fast_assign() unconditionally calls udp_hdr(skb) before checking
whether the packet is UDP. Furthermore, __icmp_send() can be invoked
from paths (e.g., link failures, ARP errors, forwarding, AF_PACKET)
where skb->transport_header was never initialized (~0U).
Under CONFIG_DEBUG_NET=y, calling skb_transport_header(skb) triggers
DEBUG_NET_WARN_ON_ONCE(!skb_transport_header_was_set(skb)).
Fix this by:
1. Only parsing transport info when iph->protocol == IPPROTO_UDP.
2. Using skb_header_pointer() at skb_network_offset(skb) + (iph->ihl << 2)
to safely fetch the UDP header without assuming transport_header is set.
Fixes: db3efdcf70c7 ("net/ipv4: add tracepoint for icmp_send")
Reported-by: syzbot+6d2762674103618994b0@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/netdev/6a8d5538.91706f20.ef82.0009.GAE@google.com/T/#u
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Peilin He <he.peilin@zte.com.cn>
Cc: xu xin <xu.xin16@zte.com.cn>
Cc: Steven Rostedt <rostedt@goodmis.org>
Reviewed-by: Jiayuan Chen <jiayuan.chen@linux.dev>
Reviewed-by: David Ahern <dsahern@kernel.org>
Link: https://patch.msgid.link/20260825084551.1562967-1-edumazet@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Pull ceph updates from Ilya Dryomov:
"A wide variety of mostly CephFS fixes and cleanups, split between
changes that address edge cases (Sam, Xiubo, Matthew), efficiency
improvements (Max) and AI-assisted hardening (Michael, Jeremy).
One thing that stands out is Alex's change to how CephFS behaves in
NEARFULL scenarios: the long-standing "make all writes synchronous"
behavior has become opt-in. It was always somewhat controversial and
doesn't make much sense for modern deployments; the new default is to
continue normal operation (i.e. buffer writes as MDS allows, etc). The
behavior in case the cluster reaches any FULL state remains the same
as before"
* tag 'ceph-for-7.3-rc1' of https://github.com/ceph/ceph-client: (32 commits)
ceph: force a cap message when a deferred revoke can't be acked immediately
libceph: reject buckets with mismatched CRUSH ids
ceph: reject export_targets ranks >= CEPH_MAX_MDS in mdsmap decode
ceph: fix leaked inode reference on writeback abort at umount
libceph: remove ceph_put_page_vector()
libceph: validate banner payload length
ceph: make nearfull sync writes opt-in
ceph: do not repeat ceph_trim_dentries() if no progress possible
ceph: drop mdsc->mutex before decoding the MDS reply
ceph: fix UAF in check_new_map() on session freed during unlock
ceph: fix UAF in __kick_flushing_caps() on cf entry freed during unlock
ceph: pass inode pointer around instead of reloading it
ceph: mark cap remove with RB_CLEAR_NODE() instead of setting ci=NULL
ceph: add helper function ceph_cap_is_removed()
ceph: make __ceph_remove_cap() static
ceph: cap delegated inode count in ceph_parse_deleg_inos()
ceph: bound num_export_targets array for mds info v2/v3
ceph: bound MDSCapAuth path and fs_name decode in handle_session()
ceph: bound xattr value length in __build_xattrs()
ceph: bound copied dentry name length in NFS export get_name
...
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/rw/ubifs
Pull UBI and UBIFS updates from Richard Weinberger:
"UBI:
- Support for a per-device wear-leveling threshold
- Various fixes and cleanups of error paths
- Correctly preserve torture flag up wear-leveling
UBIFS:
- Various fixes and cleanups of error paths and kernel-doc"
* tag 'ubifs-for-linus-7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rw/ubifs:
UBI: support per-device wear-leveling threshold
UBI: fix two issues in the ubi.mtd MODULE_PARM_DESC
mtd: ubi: Release device reference on busy detach
ubi: Fix rollback for explicit UBI device numbers
ubifs: fix out-of-bounds read in signature length check
UBI: fastmap: Pass to_be_tortured when reusing old fastmap PEBs
UBI: Preserve torture flag when rescheduling failed erasures
ubifs: ubifs.h: clean up kernel-doc comments
ubifs: key.h: use correct function parameter name
ubifs: debug.h: fix kernel-doc struct prototypes
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs
Pull f2fs updates from Jaegeuk Kim:
"In this round, key enhancements focus on reducing inode management
memory overhead, introducing resizable tail sections with unified
pinned allocation, and boosting I/O throughput via parallel
multi-device flushes and asynchronous f2fs_write_end_io() execution.
We also add dynamic device alias reservations to allow on-the-fly
space donation from user partitions.
Alongside these features, critical bug fixes resolve folio race
conditions, lingering dirty flags, dentry and block counter leaks, and
potential deadloops in f2fs_fsync_node_pages(). Additional stability
patches address error-path handling across symlink, sync, and
rename/unlink operations, prevent pinned file fragmentation, and
correct segment migration and free section accounting in
free_segment_range.
Enhancements:
- reduce memory footprint of ino management
- support dynamic reserve/release for device aliasing
- issue multi-device flushes in parallel
- add a way to run f2fs_write_end_io() asynchronously
- support resizable tail section and unify pinned allocation
Bug fixes:
- fix to pass folio->index to f2fs_sanity_check_node_footer()
- fix folio_nr_pages() race after put in large folio invalidate
- fix to clear dirty flag on folio in error path
- accurately adjust free_sections during free_segment_range
- fix to avoid potential deadloop in f2fs_fsync_node_pages()
- fix the error path in symlink, device alias in rename/unlink,
f2fs_sync_fs
- fix to migrate all curseg types during free_segment_range
- fix to avoid pinfile fragment on fragment:{block, segment} mode
- fix valid block count leak on data block allocation failure
- fix dentry folio leak in find_in_level
- reject overlapping move range after len expansion
- fix some bugs related to file pinning, GC functions, i_size
And, the series includes a number of minor bug fixes"
* tag 'f2fs-for-7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs: (51 commits)
f2fs: support resizable tail section and unify pinned allocation
f2fs: don't leave the hashed inode while it's unlinked
f2fs: accurately adjust free_sections during free_segment_range
f2fs: fix to avoid potential deadloop in f2fs_fsync_node_pages()
f2fs: use adjusted write range after f2fs_write_checks()
f2fs: fix to propagate error from f2fs_sync_fs()
f2fs: return symlink writeback errors
f2fs: fix error handling on device alias check in rename and unlink
f2fs: fix to reset all pinned status during fggc
f2fs: use f2fs_{down, up}_(read, write}_trace() for nat_tree_lock
f2fs: reduce memory footprint of ino management
f2fs: fix i_size when pinned fallocate partially fails
f2fs: fix to migrate all curseg types during free_segment_range
f2fs: avoid setting SBI_NEED_FSCK on transient resize failure
f2fs: fix to avoid pinfile fragment on fragment:{block, segment} mode
f2fs: cleanup w/ f2fs_need_rand_{blk, seg, seg_blk}
f2fs: fix to shrink gc_lock coverage in f2fs_gc_range()
f2fs: fix to reclaim space in f2fs_allocate_pinning_section()
f2fs: unify add/remove ino entry API for all ino types
f2fs: fix to zero post-EOF data when extending file size
...
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
Pull sound fixes from Takashi Iwai:
"A collection of various small fixes since the last PR. Most changes
are device-specific fixes, while there are a few fixes addressing the
issues reported recently by fuzzers.
Here are highlights:
ALSA Core:
- Prevent adding invalid kcontrols to the LED layer
- Workaround for a false-positive mutex lockdep warning in rawmidi
USB-audio:
- Relaxed the sticky mixer behavior check that caused regressions
- Fix an OOB write in Novation MIDI output
- Proper cleanup after system-resume errors
- Quirk updates for M-Audio Venom, Audient iD14 MkI, Logitech PRO X
Wireless, SMSL USB DAC, and Creative Sound Blaster Play! 3
HD-audio:
- Conexant headset plugin fixes
- Quirk additions and fixes for HP Laptop 15, Lenovo IdeaPad Slim 3,
TongFang XxAF5xxx, Lenovo Legion Pro 7, and Lenovo Yoga Pro 9
ASoC:
- DAPM: Fix off-by-one check on the second enum channel
- Tegra: Fix and sort register defaults
- AMD quirk updates for ASUS FA401EA, HP OmniBook X Flip 16,
HVY-WXX9/M1060, Alienware m18 R1, and MSI Thin A15 B7UC
- Fixes Qualcomm TDM handling
- Fix double put_device() on SoundWire
- Codec fixes for rt766, tac5xx2, rt712, tas2783, and max98926
Misc:
- Fix card leak on probe error on ice1712 driver
- Hardening for legacy aoa, mtpav and pcxhr drivers"
* tag 'sound-fix-7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: (53 commits)
ALSA: control: Don't add invalid kcontrols to LED layer
ASoC: amd: acp-config: change quirks to cover all ASUS FA401EA variants
ALSA: hda/conexant: Always enable the headset-mic pin on plugin
ASoC: dapm: Fix off-by-one check on the second enum channel
ASoC: amd: acp-config: force SoundWire probe on HP OmniBook X Flip 16
ASoC: amd: acp3x-es83xx: Add HVY-WXX9/M1060 DMI quirk
ASoC: amd: acp-config: Add HVY-WXX9/M1060 DMI quirk
ASoC: soc-generic-dmaengine: Fix DMA channel request warning
ALSA: rawmidi: Another workaround for false-positive mutex lockdep warning
ASoC: amd: yc: Add DMI entry for Alienware m18 R1 AMD
ASoC: amd: yc: Add DMI entry for MSI Thin A15 B7UC
ALSA: hda/realtek: Fix speaker mute LED for HP Laptop 15-fd0039nt
ALSA: usb-audio: Complete cleanup after system-resume errors
ALSA: hda/realtek: Add quirk for Lenovo IdeaPad Slim 3 15ABR8
ALSA: aoa: i2sbus: Check IRQ before requesting it
ALSA: usb-audio: Skip mixer creation on M-Audio Venom
ALSA: usb-audio: Skip reading sample rate on M-Audio Venom
ASoC: rt766: add RT766/RT767 VA1 device IDs
ALSA: hda/realtek: Add quirk for TongFang XxAF5xxx
ALSA: usb-audio: fix OOB write in snd_usbmidi_novation_output()
...
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd
Pull TPM updates from Jarkko Sakkinen:
"The bulk of this is Ross Philipson's TPM enablement for Trenchboot.
That exposes TPM constants, and decouple and improve robustness of
tpm_buf a bit in order to implement a minimal early TPM driver.
Early boot code will call either SKINIT on AMD or GETSEC[SENTER] on
Intel before jumping into kernel's entry point. They re-initalize TPM
PCRs but leave up to the early boot code measure initrd, boot_params
and Trenchboot associated metadata.
The motivation here is just that we would want in future iterations of
the series put our full focus to the x86 part of the review, and call
it a day as per TPM changes. Further, even if Trenchboot turned out to
be empty lottery the worst possible outcome for TPM driver is that
things get cleaned up a bit"
* tag 'for-next-tpm-7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd:
tpm-buf: Add TPM buffer support header for standalone reuse
tpm-buf: Memory-safe allocations
tpm-buf: Remove chip parameter from tpm_buf_append_handle()
tpm-buf: Merge TPM_BUF_BOUNDARY_ERROR and TPM_BUF_OVERFLOW
tpm: Remove main TPM header from TPM event log header
tpm: Move platform specific definitions to the new PTP header
tpm: Move TPM common base definitions to the command header
tpm: Move TPM2 specific definitions to the command header
tpm: Move TPM1 specific definitions to the command header
tpm: Initial step to reorganize TPM public headers
tpm: st33zp24: Validate locality read result
tpm: st33zp24: Return zero on status read failure
tpm: tpm_tis_spi: fix nodef CR50 tpm_tis_spi_resume is null
tpm: atmel: depend on X86
tpm: Remove redundant dev_err()
tpm: tpm_i2c_nuvoton: disable IRQ on wait timeout
|
|
Add get-error-threshold and set-error-threshold command support which
allows querying/setting error threshold of the counter. Threshold in RAS
context means the number of errors the hardware is expected to accumulate
before it raises them to software. This is to have a fine grained control
over error notifications that are raised by the hardware.
Signed-off-by: Raag Jadav <raag.jadav@intel.com>
Reviewed-by: Riana Tauro <riana.tauro@intel.com>
Acked-by: Joshua Santhosh Ranjan <joshua.santosh.ranjan@intel.com>
Link: https://patch.msgid.link/20260818135304.497098-3-raag.jadav@intel.com
Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net
Pull networking fixes from Jakub Kicinski:
"Including fixes from Bluetooth, IPSec and Netfilter.
Current release - fix to a fix:
- netfilter: ipset: remove need to allocate memory on delete operations
Current release - regressions:
- macb: drop CONFIG_OF #if block, fix build
Previous releases - always broken:
- stream of fixes for SCTP continues
- inet: frags: strip GSO state from fragments before reassembly
- virtio-net: ensure that TCP packets don't overflow gso_segs
- tcp-ao: fix use-after-free of current_key on reconnect to another
peer
- page_pool: remove zone/policy GFP flags when allocating XArray
entries
- Bluetooth: L2CAP: reject accept queue add unless BT_LISTEN
- tls: device: fix out-of-bounds write in tls_append_frag()
- eth: bnxt:
- ring the doorbell when SW USO exits early, avoid packets stuck
in Tx
- gate TPH enablement behind BNXT_SUPPORTS_QUEUE_API check, avoid
users of older NICs seeing non-actionable warning messages
- eth: qede: fix NULL pointer dereference in TPA fragment processing"
* tag 'net-7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (216 commits)
inet: frags: strip GSO state from fragments before reassembly
net/sched: sch_htb: limit htb_classify inner-class filter hops
selftests/net: packetdrill: add tcp_urg_ptr_retransmit
tcp: fix corruption of urgent data on multi-segment retransmit
usb: atm: usbatm: fix invalid ci_range initialization
net: fec: only stop PTP if it was initialized
slip: remove slip_hangup() to fix use-after-free in slip_receive_buf()
net: bridge: mcast: fix use-after-free of a master VLAN's multicast context
net/sched: bound qdisc_pkt_len to prevent qdisc soft lockup
net: dsa: mxl862xx: enable assisted learning on CPU port
net: stmmac: restore NET_IP_ALIGN in the RX DMA offset
net: stmmac: drop gso_enabled_types and rely on netdev features
net: stmmac: selftests: Don't test flow control for small rx fifos
net: stmmac: selftests: Account for the UC filter list for filtering tests
net: stmmac: dwxgmac: Account for the primary MAC address for UC filtering
net: stmmac: dwmac4: Account for the primary MAC address for UC filtering
net: stmmac: dwmac1000: Account for the primary MAC address for UC filtering
net: stmmac: selftests: Check multiple MMC counters
selftests: net: Fix slow configurations in big_tcp_tunnels.sh
selftests: net: Lower threshold with csum offload off in big_tcp_tunnels.sh
...
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf
Pablo Neira Ayuso says:
====================
Netfilter fixes for net
The following patchset contains Netfilter fixes for net:
1) Use DEBUG_NET_WARN_ON_ONCE() instead of WARN_ON() from the tproxy
datapath, a recent bug found a way to reach WARN_ON from datapath
due to insufficient validation of xt_TPROTO checkentry.
From Fernando F. Mancera.
2) Similar to previous patch to replace WARN_ON_ONCE by
DEBUG_NET_WARN_ON_ONCE() for connlimit. Not known issue, but
since this patch has been around for a while, let's merge it.
Also from Fernando.
3) Move nf_tables harware offload commit path after chain blob
and audit to reduce chances of leaving the hardware in
inconsistent state.
4) Add missing vzeroupper to nf_tables pipapo AVX2 to address
performace degradation to later user of SSE code,
from Eric Biggers.
5) Remove pr_debug() in x_tables extensions, a recent bogus found a
way to print a unsanitized string in xt_IDLETIMER, many of these
pr_debug() calls are there for historical reasons.
6) Use pr_info_ratelimited() in x_tables .checkentry.
7) Fix an imbalance in module refcount due to incorrect override
expression logic with sets. Remove unnecessary clone in control
plane, use the existing expressions provided by set or dynset
expression. Release override expressions only.
8) Tigthen nf_tables device name removal, it is possible to remove
prefix strings with exact device name. From Fernando F. Mancera.
9) Set on the set dead bit earlier, otherwise it is possible to
call .commit on deleted sets. This also addresses the
re-introduction of a bug.
* tag 'nf-26-08-27' of git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf:
netfilter: nf_tables: remove leftover set_update_list
netfilter: nf_tables: set on dead bit when performing early element removal
netfilter: nf_tables: skip double clone set expressions on element insert
netfilter: x_tables: replace pr_{info,err}() by pr_info_ratelimited()
netfilter: x_tables: remove pr_debug
netfilter: nft_set_pipapo_avx2: add missing vzeroupper
netfilter: nf_tables: move hardware offload step after building the chain blob
netfilter: conncount: use DEBUG_NET_WARN_ON_ONCE on reaching count limit
netfilter: tproxy: use DEBUG_NET_WARN_ON_ONCE for protocol fallbacks
====================
Link: https://patch.msgid.link/20260827141733.423453-1-pablo@netfilter.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
qdisc_get_stab() accepts a user-supplied size table, and
__qdisc_calculate_pkt_len() amplifies qdisc_pkt_len() through the
overhead, the size-table data (u16), and size_log (up to
STAB_SIZE_LOG_MAX). A crafted stab can therefore set qdisc_pkt_len()
to ~1 GiB for an ordinary skb. Per-flow deficit schedulers such as
DRR and ETS replenish one quantum per loop iteration; with a tiny
quantum (1) they spin billions of times under the qdisc lock,
producing a soft lockup / RCU stall as illustrated by vega@nebusec.ai.
Cap the final qdisc_pkt_len() to QDISC_PKT_LEN_MAX so the size-table
amplification cannot drive deficit schedulers into an unbounded loop.
A legitimate size table (e.g. qfq's overhead 999999999, which is
handled by dropping) is still accepted.
Introduce cap QDISC_PKT_LEN_MAX (1 << 20) = 1 MiB which is well above
any legitimate single-skb wire length: the largest current skb->len
is GSO_MAX_SIZE (524280), and an ATM-style size table (53/48 cell tax)
amplifies that to ~578 KB, both comfortably below 1 MiB. At the same
time, 1 MiB bounds the deficit refill loop to ~1M iterations per
packet with quantum=1, which completes in a few milliseconds well
under the demonstrated softlockup threshold (~10^9 iterations).
Conditions to recreate the bug:
- CONFIG_NET_SCHED=y, CONFIG_NET_SCH_DRR=y (or CONFIG_NET_SCH_ETS=y).
- Attach a DRR (or ETS) root qdisc with a crafted TCA_STAB that
amplifies qdisc_pkt_len to ~1 GiB (e.g. size_log=15, data=[32768]).
- Add a class with a tiny quantum of 1 and send one small packet; the
deficit loop spins billions of times under the qdisc lock and trips
the softlockup detector (panic with kernel.softlockup_panic=1).
- Reachable as root or from an unprivileged user in a fresh user+net
namespace (unshare -Urn) with namespace-local CAP_NET_ADMIN.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Reported-by: vega@nebusec.ai
Tested-by: Victor Nogueira <victor@mojatatu.com>
Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
Link: https://patch.msgid.link/20260825081403.133992-1-jhs@mojatatu.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
