Conversation
ufs1_read_inode() and ufs2_read_inode() copy the untrusted 64-bit on-disk size into inode->i_size. ufs_last_byte() then truncates that value to an unsigned int before calculating the valid extent of a directory folio. A directory size of exactly 4 GiB is truncated to zero. In ufs_find_entry(), subtracting the requested record length from that zero forms an endpoint almost 4 GiB beyond the mapped folio. A crafted UFS2 image produces: BUG: KASAN: use-after-free in ufs_find_entry+0x583/0x6e0 [ufs] Read of size 1 ... ufs_find_entry ufs_inode_by_name ufs_lookup __lookup_slow path_lookupat The KASAN classification reflects that the adjacent physical page was free; the source-level operation is an out-of-folio read. A controlled UFS1 test with CONFIG_UFS_FS_WRITE enabled also made ufs_find_entry() return a directory entry from an adjacent anonymous page. unlink() then passed that pointer to ufs_delete_entry(), which cleared the adjacent page's 32-bit d_ino. This write result reproduced three out of three times. UFS normally requires a privileged mount path. A relevant boundary is a privileged automounter or image-processing service handling an attacker-supplied filesystem. The write primitive additionally requires UFS1 to be mounted read-write with CONFIG_UFS_FS_WRITE enabled; the read is reachable with read-only UFS2. Keep the intermediate size arithmetic at 64 bits so non-final pages are bounded at PAGE_SIZE. With this change, the same controlled tests reach the real on-disk directory entry and produce no adjacent-page write or KASAN report. A reproducer and full validation logs are available on request. The vulnerable helper is present in v7.2-rc3, v7.1, v6.18.38, v6.12.95, v6.6.111, and upstream master at 1229e2e. Runtime reproduction and fix validation were performed in an x86-64 QEMU guest running v7.2-rc3 with generic KASAN. Signed-off-by: YANXIN LI <fadouse@pm.me> Fixes: b71034e ("[PATCH] ufs: directory and page cache: from blocks to pages") Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Christian Brauner <brauner@kernel.org> Cc: Jan Kara <jack@suse.cz> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
panic_print_get() was introduced in commit 2683df6 ("panic: add note that 'panic_print' parameter is deprecated") to print out warning message of the deprecation of 'panic_print' on read access. Since commit 90f3c12 ("panic: only warn about deprecated panic_print on write access"), panic_print_get() wrapper is not needed anymore for read access, so remove it and use param_get_ulong() instead. Link: https://lore.kernel.org/20260902114851.77062-1-feng.tang@linux.alibaba.com Signed-off-by: Feng Tang <feng.tang@linux.alibaba.com> Reviewed-by: Bradley Morgan <brads@mainlining.org> Reviewed-by: Andrew Morton <akpm@linux-foundation.org> Cc: Petr Mladek <pmladek@suse.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Both kmsan and fortify-source replace the memset function. When both are enabled at the same time, the kmsan version gets used, which triggers a warning about fortify-source being nonfunctional: warning: unsafe memset() usage lacked '__write_overflow' symbol in /home/arnd/arm-soc/lib/test_fortify/write_overflow-memset.c warning: unsafe memset() usage lacked '__write_overflow_field' symbol in /home/arnd/arm-soc/lib/test_fortify/write_overflow_field-memset.c Commit 78a498c already tried to address this, but this seems to only have worked for memcpy() and memmove() but not memset(), which is still lacking the macro definition when KMSAN is enabled. Remove the incorrect #ifndef check around the memset() macro. Fixes: ff901d8 ("x86: kmsan: use __msan_ string functions where possible.") Fixes: 78a498c ("x86: fortify: kmsan: fix KMSAN fortify builds") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://patch.msgid.link/20260618142951.1739694-1-arnd@kernel.org Signed-off-by: Kees Cook <kees@kernel.org>
These signals should act like SIGKILL, in that userspace must never dequeue them. But as Kusaram explains, io_uring-driven signalfd_read_iter() called from get_signal() -> task_work_run() paths can do this before get_signal() has a chance to dequeue such a signal and notice SA_IMMUTABLE. Change signalfd_poll() and signalfd_dequeue() to add pending SA_IMMUTABLE signals to ctx->sigmask. TODO: we should probably change force_sig_info_to_task(HANDLER_EXIT) to make fatal_signal_pending() true, or add a fatal_or_forced_signal_pending() helper. Then signalfd_dequeue() could just return -EINTR in this case. This also makes sense for get_signal(), which could prioritize a fatal signal sent by (say) force_sig_seccomp(force_coredump => true), just like it already prioritizes SIGKILL. Cc: stable@kernel.org Reported-by: syzbot+0a4c46806941297fecb9@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=0a4c46806941297fecb9 Tested-by: syzbot+0a4c46806941297fecb9@syzkaller.appspotmail.com Link: https://lore.kernel.org/all/69d122fd.050a0220.2dbe29.001c.GAE@google.com/ Suggested-by: Kusaram Devineni <kusaram@devineni.in> Signed-off-by: Oleg Nesterov <oleg@redhat.com> Reviewed-by: Kees Cook <kees@kernel.org> Link: https://patch.msgid.link/adO3HG8bvwRPcmte@redhat.com Signed-off-by: Kees Cook <kees@kernel.org>
A media scan of a filesystem containing an internal rt volume produced
an error in xfs_scrub phase 6 complaining about a truncated realtime
device. The rt device wasn't truncated, but the media scan code thought
we were trying to start a scan past the end of m_rtdev_targp. That in
turn is an alias for m_ddev_targp, but in xfs_configure_buftarg we set
nr_sectors to the size of the data section. We don't account for an
internal realtime section, so the kernel doesn't scan any part of it.
Oops.
Reproducer:
# mkfs.xfs -f /dev/sda -r zoned=1 -d rtinherit=1
# mount /dev/sda /mnt
# dd if=/dev/zero of=/mnt/a bs=1024k count=100
# sync
# xfs_info /mnt
meta-data=/dev/sda isize=512 agcount=4, agsize=32768 blks
= sectsz=512 attr=2, projid32bit=1
= crc=1 finobt=1, sparse=1, rmapbt=1
= reflink=0 bigtime=1 inobtcount=1 nrext64=1
= exchange=1 metadir=1
data = bsize=4096 blocks=131072, imaxpct=25
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0, ftype=1, parent=1
log =internal log bsize=4096 blocks=16384, version=2
= sectsz=512 sunit=0 blks, lazy-count=1
realtime =internal extsz=4096 blocks=1114112, rtextents=1114112
= rgcount=17 rgsize=65536 extents
= zoned=1 start=131072 reserved=53248
IOWS: 512M data volume, 3.1G internal rt section. Now let's try some
media verification:
# xfs_io -c 'verifymedia -d' -c 'verifymedia -r' /mnt
verified 536870912/536870912 bytes at offset 0
512 MiB, 1 ops; 0.0496 sec (10.067 GiB/sec and 20.1345 ops/sec)
verified 536870912/536870912 bytes at offset 0
512 MiB, 1 ops; 0.0409 sec (12.222 GiB/sec and 24.4439 ops/sec)
Notice how xfs_io says we only verified 512M of the rt volume? If you
run btrace in the background you'll see that we read the first 512M of
the volume (aka the data section) twice and never read anything from the
rt section.
An earlier fix tried messing with the buftarg geometry, but I've decided
on a more targetted fix for the media verification code. All we have to
do is calculate the starting and ending daddr for the device that we're
verifying, and clamp the user's input values to that range. This leads
to some bogosity in the output reporting:
# xfs_io -c 'verifymedia -d' -c 'verifymedia -r' /mnt/t
verified 536870912/536870912 bytes at offset 0
512 MiB, 1 ops; 0.0606 sec (8.248 GiB/sec and 16.4968 ops/sec)
verified 5100273664/5100273664 bytes at offset 0
4.750 GiB, 1 ops; 0.3329 sec (14.267 GiB/sec and 3.0035 ops/sec)
Because we don't have a way to report that we didn't really do anything
at all for that first 512M of address space of the rt "device". But at
least we're no longer ignoring real media.
(Note that the fsmap/bmap/fiemap calls all report physical addresses for
the internal rt volume as offsets from the start of the data device, and
the media verifier call consumes the same. We baked that into the
user-visible behavior in 6.15, so we're stuck with that sparse hole at
the beginning.)
Cc: stable@vger.kernel.org # v6.15
Fixes: bdc03eb ("xfs: allow internal RT devices for zoned mode")
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Carlos Maiolino <cem@kernel.org>
xfs_zoned_add_available() checks whether the reservation list is empty before adding blocks to the available-space counter. This check is not serialized against a task adding itself to the reservation list however. This allows the space provider to observe an empty list, after which a reserver can enqueue itself and retry the counter before the new space is added. The provider then adds the space and returns without waking the now-eligible reserver, leaving it asleep until GC or another event provides a wakeup, potentially adding seconds to max write latency. Take the reservation lock before updating the counter and checking the list. Use list_empty() because the list is now inspected under its lock. Taking a per-mount lock when handing back space is far from ideal, but benchmarking with null_blk showed no measurable performance regression. Fixes: 0bb2193 ("xfs: add support for zoned space reservations") Reported-by: Sashiko <sashiko-bot@kernel.org> Closes: https://sashiko.dev/#/patchset/20260609075655.1698743-1-hch@lst.de?part=2 Signed-off-by: Hans Holmberg <hans.holmberg@wdc.com> Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Carlos Maiolino <cem@kernel.org>
When exchanging two full-file ranges, xmi_can_exchange_reflink_flags() can move the reflink inode flag from the file that currently has it to the other file, as long as exactly one side is marked. This assumes that the file contents, and therefore all shared extents, are exchanged. That assumption is not true when XFS_EXCHMAPS_INO1_WRITTEN is set. xfs_exchmaps_can_skip_mapping() can skip hole and unwritten mappings from file1, so an exchange can complete without moving every mapping that the earlier flag-swap decision accounted for. In that case the post-operation cleanup can clear the reflink flag from an inode that still owns shared written extents. Later writes then take the non-reflink write path and may update blocks that should still have been protected by CoW, which shows up as data corruption between reflink-related files. Fix this by disabling the reflink flag exchange whenever XFS_EXCHMAPS_INO1_WRITTEN is requested. The contents exchange can still proceed; the conservative outcome is that both inodes keep the reflink flag. The regular reflink flag cleanup path can drop the extra flag later once the inode no longer has shared extents. Reported-by: Lin Jiapeng (TencentOS Red Team) <jiapenglin@tencent.com> Fixes: 966ceaf ("xfs: create deferred log items for file mapping exchanges") Cc: stable@vger.kernel.org # v6.10 Reviewed-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Lin Jiapeng <jiapenglin@tencent.com> Signed-off-by: Carlos Maiolino <cem@kernel.org>
The newer clang context analysis requires __releases_shared for the RCU pseudo-lock. Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com> Signed-off-by: Carlos Maiolino <cem@kernel.org>
Name the correct lock. Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com> Signed-off-by: Carlos Maiolino <cem@kernel.org>
Name the actual lock. Unlike sparse, clang wants the annotation to be correct. Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com> Signed-off-by: Carlos Maiolino <cem@kernel.org>
Improve the __acquires and __releases annotations so that the new clang code that is a bit more picky than sparse is happy. This involves passing an explicit struct xlog argument in a few places because alias analysis can't figure out it is the same lock when dereferencing changing iclogs. Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com> Signed-off-by: Carlos Maiolino <cem@kernel.org>
Improve the __acquires and __releases annotations so that the new clang code that is a bit more picky than sparse is happy. Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com> Signed-off-by: Carlos Maiolino <cem@kernel.org>
Sparse used to get away without these despite dropping and reacquiring l_icloglock Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com> Signed-off-by: Carlos Maiolino <cem@kernel.org>
This is required to make the clang context analysis happy, which is more strict than the old sparse lock context tracking. Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com> Signed-off-by: Carlos Maiolino <cem@kernel.org>
Pass up the __must_hold as clang requires it, and also fix the formatting of the __must_hold on xfs_ail_check to match how we do it elsewhere. Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com> Signed-off-by: Carlos Maiolino <cem@kernel.org>
xfs_defer_finish_one() declares error without an initialiser and only assigns it inside the loop over dfp->dfp_work. When that list is empty the loop body never runs, control falls through to the "Done with the dfp, free it" path, and the function returns an indeterminate value. An item-less pending item reaches this through xfs_defer_add_barrier(), which xfs_reap_ag_blocks() uses on any CONFIG_XFS_ONLINE_REPAIR kernel. xfs_defer_finish_noroll() treats any non-EAGAIN return as fatal, so a non-zero stack value turns a successful barrier into a SHUTDOWN_CORRUPT_INCORE in the middle of a repair. Zero is the correct result: reaching the free path means the item loop drained without a non-zero error. Fixes: 3f3cec0 ("xfs: force small EFIs for reaping btree extents") Cc: stable@vger.kernel.org Signed-off-by: Javier Tia <floss@jetm.me> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Carlos Maiolino <cem@kernel.org>
xfs_barrier_defer_type is the only xfs_defer_op_type with no .name. Every other one carries a short string used for tracing and reporting: attr, bmap, extent_free, agfl_free, rtextent_free, refcount, rtrefcount, rmap, rtrmap and exchmaps. That has been harmless because nothing dereferences the field, but it leaves a NULL in a table where every other entry is populated, so the first caller to print it gets "(null)" in the kernel and undefined behaviour in the userspace libxfs build of this file, where xfs_alert lands in fprintf. xfs_defer_add() already treats a missing member of this table as worth shutting the filesystem down for, so an unpopulated one is out of step with how the file handles its own ops tables. Signed-off-by: Javier Tia <floss@jetm.me> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Carlos Maiolino <cem@kernel.org>
When a deferred operation fails and shuts the filesystem down, xfs_defer_finish_noroll() reports neither the errno nor which operation originated it, so the log cannot tell a transient -ENOSPC from real corruption. Report the operation type, errno and remaining reservation. trace_xfs_defer_finish_error() runs after xfs_force_shutdown(), which BUGs under fs.xfs.panic_mask and so never fires for the first failure; move it ahead of the shutdown and mirror it to xfs_alert() for systems without tracing armed. Capture the op name while the item is live (dfp is freed once its work list drains) and suppress the alert once the fs is already down. Signed-off-by: Javier Tia <floss@jetm.me> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Carlos Maiolino <cem@kernel.org>
The comment on xfs_parent_calc_space_res() claims parent pointers are "always the first attr in an attr tree". They are not: a parent pointer is recorded per dirent, so by the Nth hardlink the attr fork is already in leaf or node format. The reservation is still correct, because XFS_DAENTER_SPACE_RES() covers a split at every level of a maximum-depth attr dabtree whatever format the fork is in, but anyone auditing a shortfall here is led by the comment to look for a bug that is not there. Rewrite the comment to state what actually bounds the result, and record why the double split allowance and the extent-add term differ from xfs_attr_calc_size(). Signed-off-by: Javier Tia <floss@jetm.me> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Carlos Maiolino <cem@kernel.org>
xfs_parent_da_args_init() builds an xfs_da_args from a zeroed xfs_parent_args (kmem_cache_zalloc), leaving args->total == 0. xfs_da_grow_inode_int() treats that field as a running block reservation and subtracts from it; because it is an xfs_extlen_t (uint32_t), the first attr-fork growth wraps it to ~0U. That defeats the free-space check in xfs_alloc_space_available(), and when it coincides with an AG that has exactly zero available blocks the allocation is clamped to maxlen 0 and returns -ENOSPC, which xfs_defer_finish_noroll() escalates to a filesystem shutdown. Set args->total the way the log recovery path does (xfs_attri_recover_work(), xfs_attr_item.c:706), in the add and replace paths that can grow the fork. Removals and lookups never grow it, so they leave the field alone, matching that switch. Fixes: b7c62d9 ("xfs: parent pointer attribute creation") Cc: stable@vger.kernel.org # v6.10 Signed-off-by: Javier Tia <floss@jetm.me> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Carlos Maiolino <cem@kernel.org>
xfs_da_grow_inode_int() subtracts the blocks it just allocated from args->total, the caller's remaining block reservation. The subtraction is unsigned, so a caller that reaches it with too small a total wraps the field instead of failing, and every allocation afterwards runs with a bogus reservation. Assert the remaining reservation still covers the step, so an under-reserved or uninitialised total trips in debug builds instead of silently wrapping. Suggested-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Javier Tia <floss@jetm.me> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Carlos Maiolino <cem@kernel.org>
LOLLM noticed that xrep_dir_recover_data can spin forever if it encounters an unused dirent that claims to have length zero. Fix that, and prevent the same thing from happening with a zero-length entry. Cc: stable@vger.kernel.org # v6.10 Fixes: b1991ee ("xfs: online repair of directories") Signed-off-by: Darrick J. Wong <djwong@kernel.org> Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Carlos Maiolino <cem@kernel.org>
LOLLM notices that the behavior of xrep_dir_replay_update changes based on the ftype recorded in the stashed removename information. It also notices that the unlink iops sometimes set that ftype to FT_UNKNOWN because the regular directory tree update code paths don't need to know the ftype of the child. Unfortunately, this results in incorrect link counts, which eventually trips link count errors in later phases of xfs_scrub, or in xfs_repair. Fix this by creating a second xfs_name with the type set correctly. Cc: stable@vger.kernel.org # v6.10 Fixes: 8559b21 ("xfs: implement live updates for directory repairs") Signed-off-by: Darrick J. Wong <djwong@kernel.org> Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Carlos Maiolino <cem@kernel.org>
LOLLM points out that xrep_symlink_swap_prep converts sc->tempip to an extents format file prior to the atomic swap, but incorrectly logs sc->ip immediately afterwards. Fix that, and the other problem that we're supposed to tell xfs_trans_log_inode what to log and don't. Cc: stable@vger.kernel.org # v6.10 Fixes: 2651923 ("xfs: online repair of symbolic links") Signed-off-by: Darrick J. Wong <djwong@kernel.org> Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Carlos Maiolino <cem@kernel.org>
LOLLM notices that xrep_metapath_unlink looks for a parent pointer in the child metafile that it's removing, but initializes the parent handle using the child. This is obviously incorrect, so fix that. Cc: stable@vger.kernel.org # v6.13 Fixes: 0d2c636 ("xfs: repair metadata directory file path connectivity") Signed-off-by: Darrick J. Wong <djwong@kernel.org> Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Carlos Maiolino <cem@kernel.org>
A longstanding weakness of the metapath repair code is that it can only reattach non-directories to the metadata directory tree. Let's fix that by allowing reconnection of subdirectories. Note that with the initial users of metadir (rtgroups and quota), there's no way to mount a filesystem with broken /rtgroups or /quota subdirectories, so this code won't be all that useful until something adds deeper directory trees. But we shouldn't leave a logic bomb for those futures users wherein we get the link count wrong for a subdir. Signed-off-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Carlos Maiolino <cem@kernel.org>
LOLLM complains that xfs_healthmon_unmount does an unlocked insert of the unmount event into the health monitor's event list. Fix that. Cc: stable@vger.kernel.org # v7.0 Fixes: 25ca57f ("xfs: convey filesystem unmount events to the health monitor") Signed-off-by: Darrick J. Wong <djwong@kernel.org> Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Carlos Maiolino <cem@kernel.org>
To obtain nr. of pages in "size" bytes, we need howmany(size, PAGE_SIZE) not howmany(size, PAGE_SHIFT). This over-reports reclaim by orders of magnitude, up to 4096x on a 64k page system. Fixes: e287463 ("xfs: use vmalloc instead of vm_map_area for buffer backing memory") Cc: stable@vger.kernel.org # v6.15+ Signed-off-by: Eric Sandeen <sandeen@redhat.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Carlos Maiolino <cem@kernel.org>
xfs_bufs have a shrinker and are therefore reclaimable, as is the memory backing them. Mark slab-allocated backing memory as __GFP_RECLAIMABLE in the kmalloc path so that it is accounted properly. Signed-off-by: Eric Sandeen <sandeen@redhat.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Carlos Maiolino <cem@kernel.org>
[Why] Chrontel CH7218 found in Ugreen DP -> HDMI 2.1 adapter (model 85564) works perfectly with VRR after testing. VRR and FreeSync compatibility is explicitly advertised as a feature so it's addition is a formality. Support FreeSync info packet passthrough and "generic" HDMI VRR. [How] Add CH7218's ID to dm_helpers_is_vrr_pcon_allowed() Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4773 Signed-off-by: Tomasz Pakuła <tomasz.pakula.oficjalny@gmail.com> (cherry picked from commit 7b2436287ed953496ad1c9eb5820f00b75db597f) (cherry picked from commit a9c7548)
… Block why: HDMI FRL sinks were not parsed for the AMD VSDB and no VTEM info packet was emitted for them, so 2.1 FreeSync over HDMI FRL did not work. It is backward-compatible with 2.0 FreeSync. how: - Accept SIGNAL_TYPE_HDMI_FRL alongside SIGNAL_TYPE_HDMI_TYPE_A when parsing the AMD VSDB in amdgpu_dm_update_freesync_caps(). - Build and send the VTEM info packet via mod_build_infopacket_vtem() when the stream signal is HDMI FRL during the freesync state update. - Set the VTEM Data_Set_Length to 0 when no VTEM feature is enabled. build_infopacket_header_vtem() hardcodes Data_Set_Length = 4, so a VTEM with Data_Set_Length = 4 would be transmitted even when no VTEM feature is enabled (VRR_EN = 0 and no FVA), e.g. when the sink advertises VRRMIN = 0 and vrr_capable is false. This fails HDMI GCTS HF1-58 step 6.2. The VTEM must keep being transmitted every MTW while VRR is enabled (HF1-58 steps 8.1 and 8.3), so it cannot simply be suppressed per frame. Instead, follow the MLDS option in HDMI 2.1 10.10.2.4: keep transmitting the VTEM but set Data_Set_Length = 0 when no feature is enabled. When VRR becomes active the full Data_Set_Length = 4 payload with VRR_EN = 1 is sent as before. Signed-off-by: Fangzhi Zuo <Jerry.Zuo@amd.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> (cherry picked from commit 62ac74defba77c84daee2adc56b19b2c0b4e9afd) (cherry picked from commit 7484e04)
…m HF-VSDB Parse the HDMI 2.1 gaming-related capabilities advertised in the HDMI Forum VSDB (HF-VSDB) and expose them through struct drm_hdmi_info so drivers can consume them. Add struct drm_hdmi_vrr_cap describing the sink's VRR capabilities: Fast VActive (Quick Frame Transport), Negative M VRR, Cinema VRR, MDelta, and the VRRmin/VRRmax range, together with a "supported" flag derived from that range. Add the fapa_start_location and allm (Auto Low Latency Mode) flags to struct drm_hdmi_info. drm_parse_hdmi_gaming_info() reads byte 8 of the HF-VSDB for the FAPA/ALLM/FVA/CNMVRR/CinemaVRR/MDelta flags and bytes 9-10 for VRRmin/VRRmax. Per HDMI 2.1, VRR is considered supported when VRRmin is within 1-48 and VRRmax is either 0 (maximum based on the video mode) or >= 100. It is invoked from drm_parse_hdmi_forum_scds(), and the parsed values are logged for debugging. Signed-off-by: Tomasz Pakuła <tomasz.pakula.oficjalny@gmail.com> Signed-off-by: Fangzhi Zuo <Jerry.Zuo@amd.com> Tested-by: Bernhard Berger <bernhard.berger@gmail.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> (cherry picked from commit 26e1509c3ec24f6314e972edd64d9dc18d8be779) (cherry picked from commit ae43fd6)
why: HDMI 2.1 sinks advertise their VRR range in the HDMI Forum VSDB (HF-VSDB), but amdgpu derived FreeSync capability only from the AMD VSDB. Sinks that expose just the HDMI Forum VRR capability (e.g. HDMI compliance EDIDs) were therefore reported as not VRR capable. how: - In amdgpu_dm_update_freesync_caps(), when the AMD VSDB does not provide a valid FreeSync range, fall back to the HDMI 2.1 VRR range parsed by DRM core from the HF-VSDB (connector->display_info.hdmi.vrr_cap). VRRMAX = 0 means "up to the Base Refresh Rate"; when the EDID provides no monitor range maximum either, fall back to the Base Refresh Rate (the highest refresh-rate mode of the preferred timing) so a valid VRR range is still reported to userspace. - Add VRR debug logging along the FreeSync capability and config paths. Signed-off-by: Fangzhi Zuo <Jerry.Zuo@amd.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> (cherry picked from commit c5010ee089293c52c6489d308f1e659ba74f6ed5) (cherry picked from commit 8c96508)
why: HDMI 2.1 Auto Low-Latency Mode (ALLM) lets a Source request the Sink's low-latency mode through the HF-VSIF. HDMI 2.1 Section 7.6.6 requires that when Gaming-VRR is enabled (VRR_EN=1) and the Sink advertises ALLM in the SCDS, the Source shall transmit the HF-VSIF and set ALLM_Mode=1. amdgpu never set ALLM_Mode, so this requirement was not met. how: - In update_freesync_state_on_stream(), set ALLM_Mode=1 in the HF-VSIF when Gaming-VRR is active (vrr state ACTIVE_VARIABLE/ACTIVE_FIXED, i.e. VRR_EN=1) and the sink advertises ALLM, per HDMI 2.1 Section 7.6.6, and push the updated HF-VSIF (vsp_infopacket) as a stream update. ALLM is driven only by the mandatory Gaming-VRR case. Signed-off-by: Fangzhi Zuo <Jerry.Zuo@amd.com> (cherry picked from commit 7cafa47e65ace3daf0758553da2d6131c4290b5f) (cherry picked from commit 2d28e87)
Enable freesync_on_desktop for HDMI streams so the display can keep FreeSync enabled during normal desktop use. This allows the HDMI VRR path to support fixed-refresh desktop operation while retaining FreeSync signaling for the display. Signed-off-by: Andy East <andy10115@gmail.com> (cherry picked from commit 7e64309)
…acket.c Treat VRR_STATE_INACTIVE as VRR-active when freesync_on_desktop is enabled so HDMI VTEM continues advertising VRR during fixed-refresh desktop use. Use a single vrr_active value for both the VTEM VRR_EN bit and the Data_Set_Length decision. This keeps VTEM signaling consistent while allowing the display to remain in its VRR mode without varying the actual refresh rate. Signed-off-by: Andy East <andy10115@gmail.com> (cherry picked from commit a3020f5)
The detachable keyboard shipped with the ROG Zephyrus Duo GX651AR (0b05:1ce6) is a ROG N-Key keyboard, but it is not listed in asus_devices[], so its interfaces are left to hid-generic and its vendor usages are never mapped by asus_input_mapping(). Add it with QUIRK_USE_KBD_BACKLIGHT | QUIRK_ROG_NKEY_KEYBOARD, matching the other ROG N-Key keyboards. Tested-by: Cymirk <cymirk@icloud.com> Signed-off-by: Ahmed Yaseen <yaseen@ghoul.dev> (cherry picked from commit 8d70b5f)
… interfaces On the ROG Zephyrus Duo GX651AR (0b05:1ce6) the hotkeys live on report 0x5a on an interface whose descriptor holds nothing but two ASUS vendor collections. Neither satisfies IS_INPUT_APPLICATION(), so hidinput_connect() creates no input device, asus_input_mapping() never runs and every hotkey is dropped by asus_event() as unmapped. Set HID_QUIRK_HIDINPUT_FORCE on ROG N-Key interfaces that carry an ASUS vendor input report so those usages get mapped. Interfaces left with no mapped usage are still discarded by hidinput_has_been_populated(). The vendor check reads report_enum[HID_INPUT_REPORT], so interfaces with no input reports, such as the RGB control interface, are unaffected. Tested-by: Cymirk <cymirk@icloud.com> Signed-off-by: Ahmed Yaseen <yaseen@ghoul.dev> (cherry picked from commit 69887e3)
…Bluetooth The GX651AR keyboard enumerates as 0b05:1ce6 over USB but pairs as 0b05:1ce7 in Bluetooth mode, where the keyboard, consumer and both ASUS vendor collections (reports 0x5a and 0x5d) sit on a single HID device. Add it with the same quirks as the USB entry. Bind to HID_GROUP_GENERIC so that hid-multitouch keeps the digitizer. Tested-by: Cymirk <cymirk@icloud.com> Signed-off-by: Ahmed Yaseen <yaseen@ghoul.dev> (cherry picked from commit b0dbc09)
…X651AR Fn+F12 on the GX651AR keyboard emits ASUS vendor code 0x9c, which asus_input_mapping() does not know about, so asus_event() drops it as unmapped. Map it to KEY_F19. F13 to F18 are already used for ASUS toggles that have no generic keycode. Tested-by: Cymirk <cymirk@icloud.com> Signed-off-by: Ahmed Yaseen <yaseen@ghoul.dev> (cherry picked from commit 337a811)
Add support for the AMD IOMMU Performance Optimization (PerfOpt) feature as defined in the AMD I/O Virtualization Technology (IOMMU) Specification, Section 3.4.9 (MMIO Offset 016Ch). This feature allows privileged integrated I/O devices (GPUs) to bypass the IOMMU when directly accessing system memory. The IOMMU only enforces the IR/IW permission bits without GPA->SPA translations. amd_iommu_enable_perfopt() performs a detach/reattach cycle to rehome devices already on the identity domain with ATS/PRI/PASID/GCR3 disabled (skip_caps path). amd_iommu_disable_perfopt() restores those capabilities. The per-device dev_data->perfopt flag tracks state. PERF_OPT_EN is a single control bit per IOMMU, shared by every device behind that IOMMU, while enablement is requested per device. It is therefore reference counted (amd_iommu->perfopt_refcount): armed on the first requesting device and cleared on the last, so one device's teardown never clears the bit while a peer behind the same IOMMU still needs it. The per-device flag is cleared on every teardown path (blocked_domain_attach, release_device, and amd_iommu_disable_perfopt), dropping the reference with it, so a reused dev_data never carries stale PerfOpt state onto its next bind. On suspend/resume the hardware is reprogrammed from scratch: amd_iommu_perfopt_clear() forces the bit off without touching the reference count, and amd_iommu_perfopt_restore() re-asserts it from the count after early_enable_iommu(), so armed devices keep the optimization across resume without relying on each consumer driver to re-arm. The exported amd_iommu_enable_perfopt()/amd_iommu_disable_perfopt() run only from a consumer driver's bind/unbind path. group->mutex is not exposed to drivers, but a device bound to its native driver cannot have its IOMMU domain changed concurrently by the core, which serializes the detach/attach pair against core-driven attach. PerfOpt is opt-in -- only enabled when explicitly requested by a driver. Co-developed-by: Jatin Kataria <jkataria@netflix.com> Signed-off-by: Jatin Kataria <jkataria@netflix.com> Link: https://patch.msgid.link/20260831055108.1893285-2-mario.limonciello@amd.com Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> (cherry picked from commit e946b6e)
… in identity domain Enable PerfOpt via amd_iommu_enable_perfopt() when the GPU's iommu_perfopt module parameter is enabled (default 1) and the GPU resides in the identity domain. The identity domain means the GPU is already performing direct DMA with the IOMMU only enforcing IR/IW permission bits -- no GPA->SPA translations. amd_iommu_enable_perfopt() clears ATS, PRI, PASID and SVA for the device. This is safe in identity domain because DTE[I]=0 means the IOMMU already returns target abort for ATS requests from this peripheral and the GPU manages its own TLB. PerfOpt is a soft, optional latency optimization: failing to arm it (for example on an IOMMU that does not implement the feature, which returns -ENODEV) must not be fatal, so probe and resume warn and continue rather than aborting. PERF_OPT_EN is a per-IOMMU control shared by all devices behind that IOMMU; the IOMMU driver reference counts it so that on systems where multiple devices share one IOMMU, one GPU's teardown does not clear the bit while a peer still requires it. Arming PerfOpt trades IOMMU DMA containment for lower DMA latency. This is enabled by default for GPUs in the identity domain as a deliberate, documented policy and can be disabled with iommu_perfopt=0. The AMD IOMMU spec indicates this is only supported on integrated GPUs so check explicitly for AMD_IS_APU (which is set by amdgpu_device_ip_early_init()). PerfOpt is disabled during GPU init teardown and restored on resume. Link: https://patch.msgid.link/20260831055108.1893285-3-mario.limonciello@amd.com Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> (cherry picked from commit d100bc8)
Commit 0919db9 ("HID: asus: always fully initialize devices") added a loop during asus_probe() to send keyboard feature report initializations (asus_kbd_init) to all ASUS HID devices. On ASUS laptops with I2C/HID touchpads (such as the ASUS E200HA), sending keyboard feature reports (FEATURE_KBD_REPORT_ID) to touchpad endpoints sends invalid feature requests to touchpad hardware, corrupting probe state and causing the touchpad to become unresponsive. Wrap the asus_report_id_init loop in an `if (!drvdata->tp)` check so keyboard feature initialization only runs for actual keyboards. Tested on ASUS E200HA (where touchpad functionality is fully restored) and ASUS VivoBook Flip 14 TP401MA (confirming zero regressions). Fixes: 0919db9 ("HID: asus: always fully initialize devices") Cc: stable@vger.kernel.org Signed-off-by: Panz Dev <panz.development@gmail.com> (cherry picked from commit b3c5876)
The AYANEO 3 handheld has a detachable controller with swappable
modules ("Magic Modules"). The controller exposes three USB HID
interfaces behind 1c4f:0002 (a generic SigmaMicro VID/PID, hence the
DMI gate): a gamepad, a keyboard for the extra buttons, and a vendor
interface accepting 65-byte commands.
Add a driver for the vendor interface providing module identification
(module_left/module_right sysfs attributes), software eject of the
modules (eject sysfs attribute, blocking until the firmware confirms
the release handshake), and RGB control of the joystick rings as a
multicolor LED class device ("<device name>:rgb:joystick_rings";
userspace such as InputPlumber matches the function suffix). The
firmware's fixed breathing pattern is exposed through the hw_pattern
trigger ABI.
This complements the ayaneo-ec platform driver, which exposes module
attach state and controller power. A full physical eject is performed
by writing to eject and then cutting power through ayaneo-ec's
controller_power attribute; that orchestration is deliberately left
to userspace.
The protocol was reverse engineered in the Handheld Daemon project by
Antheas Kapenekakis. Tested on an AYANEO 3: module identification,
RGB solid and breathing, a full eject/reinsert/repower cycle, and
repeated driver unbinds under a concurrent brightness-write load.
Signed-off-by: Matías Martínez <hello@matias.me>
Reviewed-by: Denis Benato <denis.benato@linux.dev>
(cherry picked from commit 4e23d3d)
Lets the build workflow compile the new driver. The real OGC config change is OpenGamingCollective/kernel-packages#35, which lands once the driver merges. Signed-off-by: Matías Martínez <hello@matias.me> (cherry picked from commit 370d86f)
(cherry picked from commit af0e02d)
…eusable workflows build-kernel.yml had grown to ~785 lines (four container jobs plus release plumbing). Split each job into its own reusable workflow and call them from a slim build-kernel.yml entry point via `uses:`: build-arch-packages.yml - Arch .pkg.tar.zst build build-fedora-packages.yml - Fedora RPM build build-debian-packages.yml - Debian .deb build publish-release.yml - collects artifacts, cuts the GitHub release Version strings computed by the prepare job are passed as workflow_call inputs (krel/kbase/kverdot/sha8/tag/kver/next), the KERNEL_PACKAGES_RAW env moves into the workflows that use it, and build workflows now declare contents: read (only the publisher needs contents: write). No behavior change: same containers, steps, caches, artifact names and QEMU boot smoke test gates. Called workflows share the caller run, so the release job still sees the *-packages artifacts and the needs: chain still blocks publishing on the boot tests. Also drops a stray uncommitted local edit in the Debian build step (duplicated LLVM=1 LLVM_IAS=1 WERROR=0 make flags) so the tree matches the committed pipeline.
…log head on banner failure
The smoke test greps the captured serial console log for the kernel
banner ("Linux version <KREL> "), but the banner is printed at
KERN_NOTICE while some distro configs default the console to a quieter
level: Arch ships CONFIG_CONSOLE_LOGLEVEL_DEFAULT=4, which suppresses
notice (and info) messages entirely. The result was a confusing failure
mode: the kernel booted to userspace just fine (BOOT_OK marker, printed
by init directly on /dev/ttyS0), yet the banner check failed because
the console log only carried a few high-priority lines.
Pin loglevel=7 on the test kernel command line so every distro kernel
logs verbosely enough for the banner to be captured, and replace the
useless "^Linux version" grep in the failure path (banner lines are
prefixed with a "[ 0.000000] " timestamp, so that grep could never
match) with a dump of the first serial console lines.
Verified locally against a kernel built with the exact Arch config
pipeline: the run failed identically to CI before the change and passes
both the bios-pc and uefi-q35 legs after it.
Concurrent evaluations of ASUS WMI management methods (from ACPI notify, HID, userspace daemons, and debugfs) enter the BIOS ACPI/SMM interface simultaneously, triggering re-entrant SMIs or EC mailbox buffer corruption. Fix this at the root by introducing a centralized evaluation helper (asus_wmi_evaluate_method_locked()) protected by a global mutex (asus_wmi_eval_lock) using guard(mutex). Route all evaluations of ASUS_WMI_MGMT_GUID (method3, method5, method_buf, and show_call) through this helper. A static mutex is required because asus_wmi_evaluate_method() is an exported symbol used by external modules (such as hid-asus and asus-armoury) that lack access to struct asus_wmi drvdata, and the underlying ASUS ACPI/EC management method is a single physical platform resource. The mutex is non-recursive: nested ACPI/WMI notify handlers must not call back into evaluate on the same task (defer via workqueue, as asus_rfkill_notify already does). Link: OpenGamingCollective/asusctl#328 Fixes: ffb6ce7 ("platform/x86: asus-wmi: export function for evaluating WMI methods") Cc: stable@vger.kernel.org Signed-off-by: Marco Scardovi <scardracs@disroot.org>
…icate rfkill ops With all WMI method evaluations serialized globally by asus_wmi_eval_lock in asus_wmi_evaluate_method_locked(), the per-device wmi_lock in struct asus_wmi is completely redundant. Remove wmi_lock from struct asus_wmi, its initialization in asus_wmi_rfkill_init(), and its manual locking in asus_rfkill_hotplug(). Consequently, asus_rfkill_wlan_set() becomes a simple pass-through to asus_rfkill_set(), rendering asus_rfkill_wlan_ops identical to asus_rfkill_ops. Drop asus_rfkill_wlan_set() and asus_rfkill_wlan_ops, allocating WLAN rfkill devices with &asus_rfkill_ops directly. Signed-off-by: Marco Scardovi <scardracs@disroot.org>
|
Important
This repository does not receive automatic reviews because it has fewer than 10 stars. ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Advanced Run ID: Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
scardracs
force-pushed
the
ci/sync-linux-next
branch
from
September 27, 2026 08:00
f588596 to
9c7f937
Compare
…-next The sync replay stops on the first cherry-pick that linux-next has since rewritten. Skip subjects listed in .github/sync-skip, drop patch-id equivalents and empty cherry-picks, and abort without pushing on the first conflict. Signed-off-by: Marco Scardovi <scardracs@disroot.org>
…INERS Take the AXIADO TSADC entry and the ayaneo-ec ABI path from linux-next, and keep the AYANEO 3 controller entry. Signed-off-by: Marco Scardovi <scardracs@disroot.org>
scardracs
force-pushed
the
ci/sync-linux-next
branch
from
September 27, 2026 08:10
9c7f937 to
904abab
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
18 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
masterstays stuck on next-20260903.MAINTAINERSis the only conflict keep both new entries. Any other conflict still aborts the job and pushes nothing.