summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2025-12-24tools headers: Sync UAPI linux/mount.h with kernel sourcesNamhyung Kim
To pick up changes from: 78f0e33cd6c939a5 ("fs/namespace: correctly handle errors returned by grab_requested_mnt_ns") This should be used to beautify mount syscall arguments and it addresses these tools/perf build warnings: Warning: Kernel ABI header differences: diff -u tools/perf/trace/beauty/include/uapi/linux/mount.h include/uapi/linux/mount.h Please see tools/include/uapi/README. Cc: linux-fsdevel@vger.kernel.org Signed-off-by: Namhyung Kim <namhyung@kernel.org>
2025-12-24tools headers: Sync UAPI linux/fs.h with kernel sourcesNamhyung Kim
To pick up changes from: b30ffcdc0c15a88f ("block: introduce BLKREPORTZONESV2 ioctl") 0d8627cc936de8ea ("blktrace: add definitions for blk_user_trace_setup2") This should be used to beautify ioctl syscall arguments and it addresses these tools/perf build warnings: Warning: Kernel ABI header differences: diff -u tools/perf/trace/beauty/include/uapi/linux/fs.h include/uapi/linux/fs.h Please see tools/include/uapi/README. Cc: linux-fsdevel@vger.kernel.org Signed-off-by: Namhyung Kim <namhyung@kernel.org>
2025-12-24tools headers: Sync UAPI linux/fcntl.h with kernel sourcesNamhyung Kim
To pick up changes from: fe93446b5ebdaa89 ("vfs: use UAPI types for new struct delegation definition") 4be9e04ebf75a5c4 ("vfs: add needed headers for new struct delegation definition") 1602bad16d7df82f ("vfs: expose delegation support to userland") This should be used to beautify fcntl syscall arguments and it addresses these tools/perf build warnings: Warning: Kernel ABI header differences: diff -u tools/perf/trace/beauty/include/uapi/linux/fcntl.h include/uapi/linux/fcntl.h Please see tools/include/uapi/README. Cc: linux-fsdevel@vger.kernel.org Signed-off-by: Namhyung Kim <namhyung@kernel.org>
2025-12-24tools headers: Sync UAPI KVM headers with kernel sourcesNamhyung Kim
To pick up changes from: ad9c62bd8946621e ("KVM: arm64: VM exit to userspace to handle SEA") 8e8678e740ecde2a ("KVM: s390: Add capability that forwards operation exceptions") e0c26d47def7382d ("Merge tag 'kvm-s390-next-6.19-1' of https://git.kernel.org/pub/scm/linux/kernel/git/kvms390/linux into HEAD") 7a61d61396b97fd6 ("KVM: SEV: Publish supported SEV-SNP policy bits") This should be used to beautify DRM syscall arguments and it addresses these tools/perf build warnings: Warning: Kernel ABI header differences: diff -u tools/include/uapi/linux/kvm.h include/uapi/linux/kvm.h diff -u tools/arch/x86/include/uapi/asm/kvm.h arch/x86/include/uapi/asm/kvm.h Please see tools/include/uapi/README. Cc: kvm@vger.kernel.org Signed-off-by: Namhyung Kim <namhyung@kernel.org>
2025-12-24tools headers: Sync UAPI drm/drm.h with kernel sourcesNamhyung Kim
To pick up changes from: 179ab8e7d7b378f1 ("drm/colorop: Introduce DRM_CLIENT_CAP_PLANE_COLOR_PIPELINE") This should be used to beautify DRM syscall arguments and it addresses these tools/perf build warnings: Warning: Kernel ABI header differences: diff -u tools/include/uapi/drm/drm.h include/uapi/drm/drm.h Please see tools/include/uapi/README. Cc: dri-devel@lists.freedesktop.org Signed-off-by: Namhyung Kim <namhyung@kernel.org>
2025-12-24Merge tag 'nfsd-6.19-1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/cel/linux Pull nfsd fixes from Chuck Lever: "A set of NFSD fixes that arrived just a bit late for the 6.19 merge window. Regression fixes: - Mark variable __maybe_unused to avoid W=1 build break Stable fixes: - NFSv4 file creation neglects setting ACL - Clear TIME_DELEG in the suppattr_exclcreat bitmap - Clear SECLABEL in the suppattr_exclcreat bitmap - Fix memory leak in nfsd_create_serv error paths - Bound check rq_pages index in inline path - Return 0 on success from svc_rdma_copy_inline_range - Use rc_pageoff for memcpy byte offset - Avoid NULL deref on zero length gss_token in gss_read_proxy_verf" * tag 'nfsd-6.19-1' of git://git.kernel.org/pub/scm/linux/kernel/git/cel/linux: NFSD: NFSv4 file creation neglects setting ACL NFSD: Clear TIME_DELEG in the suppattr_exclcreat bitmap NFSD: Clear SECLABEL in the suppattr_exclcreat bitmap nfsd: fix memory leak in nfsd_create_serv error paths nfsd: Mark variable __maybe_unused to avoid W=1 build break svcrdma: bound check rq_pages index in inline path svcrdma: return 0 on success from svc_rdma_copy_inline_range svcrdma: use rc_pageoff for memcpy byte offset SUNRPC: svcauth_gss: avoid NULL deref on zero length gss_token in gss_read_proxy_verf
2025-12-24Merge tag 'erofs-for-6.19-rc3-fixes' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs Pull erofs fix from Gao Xiang: "Junbeom reported that synchronous reads could hit unintended EIOs under memory pressure due to incorrect error propagation in z_erofs_decompress_queue(), where earlier physical clusters in the same decompression queue may be served for another readahead. This addresses the issue by decompressing each physical cluster independently as long as disk I/Os succeed, rather than being impacted by the error status of previous physical clusters in the same queue. Summary: - Fix unexpected EIOs under memory pressure caused by recent incorrect error propagation logic" * tag 'erofs-for-6.19-rc3-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs: erofs: fix unexpected EIO under memory pressure
2025-12-24cifs: Fix memory and information leak in smb3_reconfigure()Zilin Guan
In smb3_reconfigure(), if smb3_sync_session_ctx_passwords() fails, the function returns immediately without freeing and erasing the newly allocated new_password and new_password2. This causes both a memory leak and a potential information leak. Fix this by calling kfree_sensitive() on both password buffers before returning in this error case. Fixes: 0f0e357902957 ("cifs: during remount, make sure passwords are in sync") Signed-off-by: Zilin Guan <zilin@seu.edu.cn> Reviewed-by: ChenXiaoSong <chenxiaosong@kylinos.cn> Signed-off-by: Steve French <stfrench@microsoft.com>
2025-12-24drm/xe: Improve rebar log messagesLucas De Marchi
Some minor improvements to the log messages in the rebar logic: use xe-oriented printk, switch unit from M to MiB in a few places for consistency and use ilog2(SZ_1M) for clarity. Suggested-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Suggested-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patch.msgid.link/20251219211650.1908961-6-matthew.d.roper@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2025-12-24drm/xe: Move rebar to its own fileLucas De Marchi
Now that xe_pci.c calls the rebar directly, it doesn't make sense to keep it in xe_vram.c since it's closer to the PCI initialization than to the VRAM. Move it to its own file. While at it, add a better comment to document the possible values for the vram_bar_size module parameter. Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patch.msgid.link/20251219211650.1908961-5-matthew.d.roper@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2025-12-24drm/msm: Replace unsafe snprintf usage with scnprintfEvan Lambert
The refill_buf function uses snprintf to append to a fixed-size buffer. snprintf returns the length that would have been written, which can exceed the remaining buffer size. If this happens, ptr advances beyond the buffer and rem becomes negative. In the 2nd iteration, rem is treated as a large unsigned integer, causing snprintf to write oob. While this behavior is technically mitigated by num_perfcntrs being locked at 5, it's still unsafe if num_perfcntrs were ever to change/a second source was added. Signed-off-by: Evan Lambert <veyga@veygax.dev> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/696358/ Link: https://lore.kernel.org/r/20251224124254.17920-3-veyga@veygax.dev Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2025-12-24vhost/vsock: improve RCU read sections around vhost_vsock_get()Stefano Garzarella
vhost_vsock_get() uses hash_for_each_possible_rcu() to find the `vhost_vsock` associated with the `guest_cid`. hash_for_each_possible_rcu() should only be called within an RCU read section, as mentioned in the following comment in include/linux/rculist.h: /** * hlist_for_each_entry_rcu - iterate over rcu list of given type * @pos: the type * to use as a loop cursor. * @head: the head for your list. * @member: the name of the hlist_node within the struct. * @cond: optional lockdep expression if called from non-RCU protection. * * This list-traversal primitive may safely run concurrently with * the _rcu list-mutation primitives such as hlist_add_head_rcu() * as long as the traversal is guarded by rcu_read_lock(). */ Currently, all calls to vhost_vsock_get() are between rcu_read_lock() and rcu_read_unlock() except for calls in vhost_vsock_set_cid() and vhost_vsock_reset_orphans(). In both cases, the current code is safe, but we can make improvements to make it more robust. About vhost_vsock_set_cid(), when building the kernel with CONFIG_PROVE_RCU_LIST enabled, we get the following RCU warning when the user space issues `ioctl(dev, VHOST_VSOCK_SET_GUEST_CID, ...)` : WARNING: suspicious RCU usage 6.18.0-rc7 #62 Not tainted ----------------------------- drivers/vhost/vsock.c:74 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by rpc-libvirtd/3443: #0: ffffffffc05032a8 (vhost_vsock_mutex){+.+.}-{4:4}, at: vhost_vsock_dev_ioctl+0x2ff/0x530 [vhost_vsock] stack backtrace: CPU: 2 UID: 0 PID: 3443 Comm: rpc-libvirtd Not tainted 6.18.0-rc7 #62 PREEMPT(none) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-7.fc42 06/10/2025 Call Trace: <TASK> dump_stack_lvl+0x75/0xb0 dump_stack+0x14/0x1a lockdep_rcu_suspicious.cold+0x4e/0x97 vhost_vsock_get+0x8f/0xa0 [vhost_vsock] vhost_vsock_dev_ioctl+0x307/0x530 [vhost_vsock] __x64_sys_ioctl+0x4f2/0xa00 x64_sys_call+0xed0/0x1da0 do_syscall_64+0x73/0xfa0 entry_SYSCALL_64_after_hwframe+0x76/0x7e ... </TASK> This is not a real problem, because the vhost_vsock_get() caller, i.e. vhost_vsock_set_cid(), holds the `vhost_vsock_mutex` used by the hash table writers. Anyway, to prevent that warning, add lockdep_is_held() condition to hash_for_each_possible_rcu() to verify that either the caller is in an RCU read section or `vhost_vsock_mutex` is held when CONFIG_PROVE_RCU_LIST is enabled; and also clarify the comment for vhost_vsock_get() to better describe the locking requirements and the scope of the returned pointer validity. About vhost_vsock_reset_orphans(), currently this function is only called via vsock_for_each_connected_socket(), which holds the `vsock_table_lock` spinlock (which is also an RCU read-side critical section). However, add an explicit RCU read lock there to make the code more robust and explicit about the RCU requirements, and to prevent issues if the calling context changes in the future or if vhost_vsock_reset_orphans() is called from other contexts. Fixes: 834e772c8db0 ("vhost/vsock: fix use-after-free in network stack callers") Cc: stefanha@redhat.com Signed-off-by: Stefano Garzarella <sgarzare@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Message-Id: <20251126133826.142496-1-sgarzare@redhat.com> Message-ID: <20251126210313.GA499503@fedora> Acked-by: Jason Wang <jasowang@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2025-12-24tools/virtio: add device, device_driver stubsMichael S. Tsirkin
Add stubs needed by virtio.h Message-ID: <0fabf13f6ea812ebc73b1c919fb17d4dec1545db.1764873799.git.mst@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2025-12-24tools/virtio: fix up oot buildMichael S. Tsirkin
oot build tends to help uncover bugs so it's worth keeping around, as long as it's low effort. add stubs for a couple of macros virtio gained recently, and disable vdpa in the test build. Message-ID: <33968faa7994b86d1f78057358a50b8f460c7a23.1764873799.git.mst@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2025-12-24virtio_features: make it self-containedMichael S. Tsirkin
virtio_features.h uses WARN_ON_ONCE and memset so it must include linux/bug.h and linux/string.h Message-ID: <579986aa9b8d023844990d2a0e267382f8ad85d5.1764873799.git.mst@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2025-12-24tools/virtio: switch to kernel's virtio_config.hMichael S. Tsirkin
Drops stubs in virtio_config.h, use the kernel's version instead - we are now activly developing it, so the stub became too hard to maintain. Message-ID: <8e5c85dc8aad001f161f7e2d8799ffbccfc31381.1764873799.git.mst@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2025-12-24tools/virtio: stub might_sleep and synchronize_rcuMichael S. Tsirkin
Add might_sleep() and synchronize_rcu() stubs needed by virtio_config.h. might_sleep() is a no-op, synchronize_rcu doesn't work but we don't need it to. Created using Cursor CLI. Message-ID: <5557e026335d808acd7b890693ee1382e73dd33a.1764873799.git.mst@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2025-12-24tools/virtio: add struct cpumask to cpumask.hMichael S. Tsirkin
Add struct cpumask stub used by virtio_config.h. Created using Cursor CLI. Message-ID: <eacf56399ba220513ebcd610f4a5115dc768db80.1764873799.git.mst@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2025-12-24tools/virtio: pass KCFLAGS to module buildMichael S. Tsirkin
Update the mod target to pass KCFLAGS with the in-tree vhost driver include path. This way vhost_test can find vhost headers. Created using Cursor CLI. Message-ID: <5473e5a5dfd2fcd261a778f2017cac669c031f23.1764873799.git.mst@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2025-12-24tools/virtio: add ucopysize.h stubMichael S. Tsirkin
Add ucopysize.h with stub implementations of check_object_size, copy_overflow, and check_copy_size. Created using Cursor CLI. Message-ID: <5046df90002bb744609248404b81d33b559fe813.1764873799.git.mst@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2025-12-24tools/virtio: add dev_WARN_ONCE and is_vmalloc_addr stubsMichael S. Tsirkin
Add dev_WARN_ONCE and is_vmalloc_addr stubs needed by virtio_ring.c. is_vmalloc_addr stub always returns false - that's fine since it's merely a sanity check. Created using Cursor CLI. Message-ID: <749e7a03b7cd56baf50a27efc3b05e50cf8f36b6.1764873799.git.mst@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2025-12-24tools/virtio: stub DMA mapping functionsMichael S. Tsirkin
Add dma_map_page_attrs and dma_unmap_page_attrs stubs. Follow the same pattern as existing DMA mapping stubs. Created using Cursor CLI. Message-ID: <3512df1fe0e2129ea493434a21c940c50381cc93.1764873799.git.mst@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2025-12-24tools/virtio: add struct module forward declarationMichael S. Tsirkin
Declarate struct module in our linux/module.h stub. Created using Cursor CLI. Message-ID: <c01b8d24159664cc8c49354088efa342ae9e7321.1764873799.git.mst@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2025-12-24tools/virtio: use kernel's virtio.hMichael S. Tsirkin
Replace virtio stubs with an include of the kernel header. Message-ID: <33daf1033fc447eb8e3e54d21013ccfd99550e37.1764873799.git.mst@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2025-12-24virtio: make it self-containedMichael S. Tsirkin
virtio.h uses struct module, add a forward declaration to make the header self-contained. Message-ID: <9171b5cac60793eb59ab044c96ee038bf1363bee.1764873799.git.mst@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2025-12-24tools/virtio: fix up compiler.h stubMichael S. Tsirkin
Add #undef __user before and after including compiler_types.h to avoid redefinition warnings when compiling with system headers that also define __user. This allows tools/virtio to build without warnings. Additionally, stub out __must_check Created using Cursor CLI. Message-ID: <56424ce95c72cb4957070a7cd3c3c40ad5addaee.1764873799.git.mst@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2025-12-24select: store end_time as timespec64 in restart blockThomas Weißschuh
Storing the end time seconds as 'unsigned long' can lead to truncation on 32-bit architectures if assigned from the 64-bit timespec64::tv_sec. As the select() core uses timespec64 consistently, also use that in the restart block. This also allows the simplification of the accessors. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Link: https://patch.msgid.link/20251223-restart-block-expiration-v2-1-8e33e5df7359@linutronix.de Reviewed-by: Jan Kara <jack@suse.cz> Signed-off-by: Christian Brauner <brauner@kernel.org>
2025-12-24Merge patch series "Fix two regressions from ↵Christian Brauner
start_creating()/start_removing() conversion" Tyler Hicks <code@tyhicks.com> says: When running the eCryptfs test suite on v6.19-rc2, I noticed BUG splats from every test and that the umount utility was segfaulting when tearing down after a test. Bisection led me to commit f046fbb4d81d ("ecryptfs: use new start_creating/start_removing APIs"). This patch series addresses that regression and also a mknod problem spotted during code review. * patches from https://patch.msgid.link/20251223194153.2818445-1-code@tyhicks.com: ecryptfs: Release lower parent dentry after creating dir ecryptfs: Fix improper mknod pairing of start_creating()/end_removing() Link: https://patch.msgid.link/20251223194153.2818445-1-code@tyhicks.com Signed-off-by: Christian Brauner <brauner@kernel.org>
2025-12-24ecryptfs: Release lower parent dentry after creating dirTyler Hicks
Fix a mkdir-induced usage count imbalance that tripped a umount_check() BUG while unmounting the lower filesystem. Commit f046fbb4d81d ("ecryptfs: use new start_creating/start_removing APIs") added a new dget() of the lower parent dir, in ecryptfs_mkdir(), but did not dput() the dentry before returning from that function. The BUG output as seen while running the eCryptfs test suite: $ ./run_tests.sh -b 131072 -c safe,destructive -f ext4 -K -t lp-926292.sh ... Running eCryptfs filesystem tests on ext4 lp-926292 ------------[ cut here ]------------ BUG: Dentry ffff8e6692d11988{i=c,n=ECRYPTFS_FNEK_ENCRYPTED.FXZuRGZL7QAFtER.JeA46DtdKqkkQx9H2Vpmv234J5CU8YSsrUwZJK4AbXbrN5WkZ348wnqstovKKxA-} still in use (1) [unmount of ext4 loop0] WARNING: CPU: 7 PID: 950 at fs/dcache.c:1590 umount_check+0x5e/0x80 Modules linked in: md5 libmd5 ecryptfs encrypted_keys ext4 crc16 mbcache jbd2 CPU: 7 UID: 0 PID: 950 Comm: umount Not tainted 6.18.0-rc1-00013-gf046fbb4d81d #17 PREEMPT(full) Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 RIP: 0010:umount_check+0x5e/0x80 Code: 88 38 06 00 00 48 8b 40 28 4c 8b 08 48 8b 46 68 48 85 c0 74 04 48 8b 50 38 51 48 c7 c7 60 32 9c b5 48 89 f1 e8 43 5e ca ff 90 <0f> 0b 90 90 58 31 c0 e9 46 9d 6c 00 41 83 f8 01 75 b8 eb a3 66 66 RSP: 0018:ffffa19940c4bdd0 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffff8e6692fad4c0 RCX: 0000000000000000 RDX: 0000000000000004 RSI: ffffa19940c4bc70 RDI: 00000000ffffffff RBP: ffffffffb4eb5930 R08: 00000000ffffdfff R09: 0000000000000001 R10: 00000000ffffdfff R11: ffffffffb5c8a9e0 R12: ffff8e6692fad4c0 R13: ffff8e6692fad4c0 R14: ffff8e6692d11a40 R15: ffff8e6692d11988 FS: 00007f6b4b491800(0000) GS:ffff8e670506e000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f6b4b5f8d40 CR3: 0000000114eb7001 CR4: 0000000000772ef0 PKRU: 55555554 Call Trace: <TASK> d_walk+0xfd/0x370 shrink_dcache_for_umount+0x4d/0x140 generic_shutdown_super+0x20/0x160 kill_block_super+0x1a/0x40 ext4_kill_sb+0x22/0x40 [ext4] deactivate_locked_super+0x33/0xa0 cleanup_mnt+0xba/0x150 task_work_run+0x5c/0xa0 exit_to_user_mode_loop+0xac/0xb0 do_syscall_64+0x2ab/0xfa0 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f6b4b6c2a2b Code: c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 f3 0f 1e fa 31 f6 e9 05 00 00 00 0f 1f 44 00 00 f3 0f 1e fa b8 a6 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 05 c3 0f 1f 40 00 48 8b 15 b9 83 0d 00 f7 d8 RSP: 002b:00007ffcd5b8b498 EFLAGS: 00000246 ORIG_RAX: 00000000000000a6 RAX: 0000000000000000 RBX: 000055b84af0b9e0 RCX: 00007f6b4b6c2a2b RDX: 0000000000000000 RSI: 0000000000000000 RDI: 000055b84af0bdf0 RBP: 00007ffcd5b8b570 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000103 R11: 0000000000000246 R12: 000055b84af0bae0 R13: 0000000000000000 R14: 000055b84af0bdf0 R15: 0000000000000000 </TASK> ---[ end trace 0000000000000000 ]--- EXT4-fs (loop0): unmounting filesystem 00d9ea41-f61e-43d0-a449-6be03e7e8428. EXT4-fs (loop0): sb orphan head is 12 sb_info orphan list: inode loop0:12 at ffff8e66950e1df0: mode 40700, nlink 0, next 0 Assertion failure in ext4_put_super() at fs/ext4/super.c:1345: 'list_empty(&sbi->s_orphan)' Fixes: f046fbb4d81d ("ecryptfs: use new start_creating/start_removing APIs") Signed-off-by: Tyler Hicks <code@tyhicks.com> Link: https://patch.msgid.link/20251223194153.2818445-3-code@tyhicks.com Reviewed-by: Amir Goldstein <amir73il@gmail.com> Signed-off-by: Christian Brauner <brauner@kernel.org>
2025-12-24ecryptfs: Fix improper mknod pairing of start_creating()/end_removing()Tyler Hicks
The ecryptfs_start_creating_dentry() function must be paired with the end_creating() function. Fix ecryptfs_mknod() so that end_creating() is properly called in the return path, instead of end_removing(). Fixes: f046fbb4d81d ("ecryptfs: use new start_creating/start_removing APIs") Signed-off-by: Tyler Hicks <code@tyhicks.com> Link: https://patch.msgid.link/20251223194153.2818445-2-code@tyhicks.com Reviewed-by: Amir Goldstein <amir73il@gmail.com> Signed-off-by: Christian Brauner <brauner@kernel.org>
2025-12-24chardev: Switch to guard(mutex) and __free(kfree)chen zhang
Instead of using the 'goto label; mutex_unlock()' pattern use 'guard(mutex)' which will release the mutex when it goes out of scope. Use the __free(kfree) cleanup to replace instances of manually calling kfree(). Also make some code path simplifications that this allows. Signed-off-by: chen zhang <chenzhang@kylinos.cn> Link: https://patch.msgid.link/20251215111500.159243-1-chenzhang@kylinos.cn Reviewed-by: Jan Kara <jack@suse.cz> Signed-off-by: Christian Brauner <brauner@kernel.org>
2025-12-24get rid of bogus __user in struct xattr_args::valueAl Viro
The first member of struct xattr_args is declared as __aligned_u64 __user value; which makes no sense whatsoever; __user is a qualifier and what that declaration says is "all struct xattr_args instances have .value _stored_ in user address space, no matter where the rest of the structure happens to be". Something like "int __user *p" stands for "value of p is a pointer to an instance of int that happens to live in user address space"; it says nothing about location of p itself, just as const char *p declares a pointer to unmodifiable char rather than an unmodifiable pointer to char. With xattr_args the intent clearly had been "the 64bit value represents a _pointer_ to object in user address space", but __user has nothing to do with that. All it gets us is a couple of bogus warnings in fs/xattr.c where (userland) instance of xattr_args is copied to local variable of that type (in kernel address space), followed by access to its members. Since we've told sparse that args.value must somehow be located in userland memory, we get warned that looking at that 64bit unsigned integer (in a variable already on kernel stack) is not allowed. Note that sparse has no way to express "this integer shall never be cast into a pointer to be dereferenced directly" and I don't see any way to assign a sane semantics to that. In any case, __user is not it. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Link: https://patch.msgid.link/20251216081939.GQ1712166@ZenIV Signed-off-by: Christian Brauner <brauner@kernel.org>
2025-12-24namespace: Replace simple_strtoul with kstrtoul to parse boot paramsThorsten Blum
Replace simple_strtoul() with the recommended kstrtoul() for parsing the 'mhash_entries=' and 'mphash_entries=' boot parameters. Check the return value of kstrtoul() and reject invalid values. This adds error handling while preserving behavior for existing values, and removes use of the deprecated simple_strtoul() helper. Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev> Link: https://patch.msgid.link/20251214153141.218953-2-thorsten.blum@linux.dev Reviewed-by: Jan Kara <jack@suse.cz> Signed-off-by: Christian Brauner <brauner@kernel.org>
2025-12-24dcache: Replace simple_strtoul with kstrtoul in set_dhash_entriesThorsten Blum
Replace simple_strtoul() with the recommended kstrtoul() for parsing the 'dhash_entries=' boot parameter. Check the return value of kstrtoul() and reject invalid values. This adds error handling while preserving behavior for existing values, and removes use of the deprecated simple_strtoul() helper. Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev> Link: https://patch.msgid.link/20251216145236.44520-2-thorsten.blum@linux.dev Reviewed-by: Jan Kara <jack@suse.cz> Signed-off-by: Christian Brauner <brauner@kernel.org>
2025-12-24fs: Replace simple_strtoul with kstrtoul in set_ihash_entriesThorsten Blum
Replace simple_strtoul() with the recommended kstrtoul() for parsing the 'ihash_entries=' boot parameter. Check the return value of kstrtoul() and reject invalid values. This adds error handling while preserving behavior for existing valid values, and removes use of the deprecated simple_strtoul() helper. Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev> Link: https://patch.msgid.link/20251218112144.225301-2-thorsten.blum@linux.dev Reviewed-by: Jan Kara <jack@suse.cz> Signed-off-by: Christian Brauner <brauner@kernel.org>
2025-12-24VFS: fix __start_dirop() kernel-doc warningsBagas Sanjaya
Sphinx report kernel-doc warnings: WARNING: ./fs/namei.c:2853 function parameter 'state' not described in '__start_dirop' WARNING: ./fs/namei.c:2853 expecting prototype for start_dirop(). Prototype was for __start_dirop() instead Fix them up. Fixes: ff7c4ea11a05c8 ("VFS: add start_creating_killable() and start_removing_killable()") Signed-off-by: Bagas Sanjaya <bagasdotme@gmail.com> Link: https://patch.msgid.link/20251219024620.22880-3-bagasdotme@gmail.com Reviewed-by: Jeff Layton <jlayton@kernel.org> Reviewed-by: Jan Kara <jack@suse.cz> Signed-off-by: Christian Brauner <brauner@kernel.org>
2025-12-24fs: Describe @isnew parameter in ilookup5_nowait()Bagas Sanjaya
Sphinx reports kernel-doc warning: WARNING: ./fs/inode.c:1607 function parameter 'isnew' not described in 'ilookup5_nowait' Describe the parameter. Fixes: a27628f4363435 ("fs: rework I_NEW handling to operate without fences") Signed-off-by: Bagas Sanjaya <bagasdotme@gmail.com> Link: https://patch.msgid.link/20251219024620.22880-2-bagasdotme@gmail.com Reviewed-by: Jeff Layton <jlayton@kernel.org> Reviewed-by: Jan Kara <jack@suse.cz> Signed-off-by: Christian Brauner <brauner@kernel.org>
2025-12-24fs: make sure to fail try_to_unlazy() and try_to_unlazy() for LOOKUP_CACHEDMateusz Guzik
Otherwise the slowpath can be taken by the caller, defeating the flag. This regressed after calls to legitimize_links() started being conditionally elided and stems from the routine always failing after seeing the flag, regardless if there were any links. In order to address both the bug and the weird semantics make it illegal to call legitimize_links() with LOOKUP_CACHED and handle the problem at the two callsites. Fixes: 7c179096e77eca21 ("fs: add predicts based on nd->depth") Reported-by: Chris Mason <clm@meta.com> Signed-off-by: Mateusz Guzik <mjguzik@gmail.com> Link: https://patch.msgid.link/20251220054023.142134-1-mjguzik@gmail.com Signed-off-by: Christian Brauner <brauner@kernel.org>
2025-12-24netfs: Fix early read unlock of page with EOF in middleDavid Howells
The read result collection for buffered reads seems to run ahead of the completion of subrequests under some circumstances, as can be seen in the following log snippet: 9p_client_res: client 18446612686390831168 response P9_TREAD tag 0 err 0 ... netfs_sreq: R=00001b55[1] DOWN TERM f=192 s=0 5fb2/5fb2 s=5 e=0 ... netfs_collect_folio: R=00001b55 ix=00004 r=4000-5000 t=4000/5fb2 netfs_folio: i=157f3 ix=00004-00004 read-done netfs_folio: i=157f3 ix=00004-00004 read-unlock netfs_collect_folio: R=00001b55 ix=00005 r=5000-5fb2 t=5000/5fb2 netfs_folio: i=157f3 ix=00005-00005 read-done netfs_folio: i=157f3 ix=00005-00005 read-unlock ... netfs_collect_stream: R=00001b55[0:] cto=5fb2 frn=ffffffff netfs_collect_state: R=00001b55 col=5fb2 cln=6000 n=c netfs_collect_stream: R=00001b55[0:] cto=5fb2 frn=ffffffff netfs_collect_state: R=00001b55 col=5fb2 cln=6000 n=8 ... netfs_sreq: R=00001b55[2] ZERO SUBMT f=000 s=5fb2 0/4e s=0 e=0 netfs_sreq: R=00001b55[2] ZERO TERM f=102 s=5fb2 4e/4e s=5 e=0 The 'cto=5fb2' indicates the collected file pos we've collected results to so far - but we still have 0x4e more bytes to go - so we shouldn't have collected folio ix=00005 yet. The 'ZERO' subreq that clears the tail happens after we unlock the folio, allowing the application to see the uncleared tail through mmap. The problem is that netfs_read_unlock_folios() will unlock a folio in which the amount of read results collected hits EOF position - but the ZERO subreq lies beyond that and so happens after. Fix this by changing the end check to always be the end of the folio and never the end of the file. In the future, I should look at clearing to the end of the folio here rather than adding a ZERO subreq to do this. On the other hand, the ZERO subreq can run in parallel with an async READ subreq. Further, the ZERO subreq may still be necessary to, say, handle extents in a ceph file that don't have any backing store and are thus implicitly all zeros. This can be reproduced by creating a file, the size of which doesn't align to a page boundary, e.g. 24998 (0x5fb2) bytes and then doing something like: xfs_io -c "mmap -r 0 0x6000" -c "madvise -d 0 0x6000" \ -c "mread -v 0 0x6000" /xfstest.test/x The last 0x4e bytes should all be 00, but if the tail hasn't been cleared yet, you may see rubbish there. This can be reproduced with kafs by modifying the kernel to disable the call to netfs_read_subreq_progress() and to stop afs_issue_read() from doing the async call for NETFS_READAHEAD. Reproduction can be made easier by inserting an mdelay(100) in netfs_issue_read() for the ZERO-subreq case. AFS and CIFS are normally unlikely to show this as they dispatch READ ops asynchronously, which allows the ZERO-subreq to finish first. 9P's READ op is completely synchronous, so the ZERO-subreq will always happen after. It isn't seen all the time, though, because the collection may be done in a worker thread. Reported-by: Christian Schoenebeck <linux_oss@crudebyte.com> Link: https://lore.kernel.org/r/8622834.T7Z3S40VBb@weasel/ Signed-off-by: David Howells <dhowells@redhat.com> Link: https://patch.msgid.link/938162.1766233900@warthog.procyon.org.uk Fixes: e2d46f2ec332 ("netfs: Change the read result collector to only use one work item") Tested-by: Christian Schoenebeck <linux_oss@crudebyte.com> Acked-by: Dominique Martinet <asmadeus@codewreck.org> Suggested-by: Dominique Martinet <asmadeus@codewreck.org> cc: Dominique Martinet <asmadeus@codewreck.org> cc: Christian Schoenebeck <linux_oss@crudebyte.com> cc: v9fs@lists.linux.dev cc: netfs@lists.linux.dev cc: linux-fsdevel@vger.kernel.org Signed-off-by: Christian Brauner <brauner@kernel.org>
2025-12-24ASoC: rt1320: fix size_t format stringArnd Bergmann
Printing a size_t portably requires the use of %z instead of %l: sound/soc/codecs/rt1320-sdw.c:1494:30: error: format '%lx' expects argument of type 'long unsigned int', but argument 5 has type 'size_t' {aka 'unsigned int'} [-Werror=format=] 1494 | dev_dbg(dev, "%s, rae_fw size=0x%lx\n", __func__, rae_fw->size); | ^~~~~~~~~~~~~~~~~~~~~~~~~ Fixes: 22937af75abb ("ASoC: rt1320: support RAE parameters loading") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://patch.msgid.link/20251223215322.694265-1-arnd@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2025-12-24ASoC: rt1320: fix 32-bit link failureArnd Bergmann
A plain 64-bit division causes a link failure in some configurations: ERROR: modpost: "__aeabi_uldivmod" [sound/soc/codecs/snd-soc-rt1320-sdw.ko] undefined! Since this divides by a constant, using the div_u64() macro ends up turning this into an efficient multiply/shift operation where possible. In rt1320_calc_r0(), the open-coded shift seems a litle simpler. Fixes: da1682d5e8b5 ("ASoC: rt1320: support calibration and temperature/r0 loading") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://patch.msgid.link/20251223215259.677762-1-arnd@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2025-12-24regulator: fp9931: fix regulator node pointerAndreas Kemnade
Sync the driver with the binding. During review process a regulators subnode was requested but neither driver nor test setup was updated. Fixes: 12d821bd13d4 ("regulator: Add FP9931/JD9930 driver") Signed-off-by: Andreas Kemnade <andreas@kemnade.info> Link: https://patch.msgid.link/20251223-fp9931-fix-v1-1-b19b4c1e7056@kemnade.info Signed-off-by: Mark Brown <broonie@kernel.org>
2025-12-24drm/msm/dpu: Add missing NULL pointer check for pingpong interfaceNikolay Kuratov
It is checked almost always in dpu_encoder_phys_wb_setup_ctl(), but in a single place the check is missing. Also use convenient locals instead of phys_enc->* where available. Cc: stable@vger.kernel.org Fixes: d7d0e73f7de33 ("drm/msm/dpu: introduce the dpu_encoder_phys_* for writeback") Signed-off-by: Nikolay Kuratov <kniv@yandex-team.ru> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/693860/ Link: https://lore.kernel.org/r/20251211093630.171014-1-kniv@yandex-team.ru Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2025-12-24Revert "drm/msm/dpu: Enable quad-pipe for DSC and dual-DSI case"Abel Vesa
This reverts commit d7ec9366b15cd04508fa015cb94d546b1c01edfb. The dual-DSI dual-DSC scenario seems to be broken by this commit. Reported-by: Marijn Suijten <marijn.suijten@somainline.org> Closes: https://lore.kernel.org/r/aUR2b3FOSisTfDFj@SoMainline.org Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com> Fixes: d7ec9366b15c ("drm/msm/dpu: Enable quad-pipe for DSC and dual-DSI case") Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/695550/ Link: https://lore.kernel.org/r/20251219-drm-msm-dpu-revert-quad-pipe-broken-v1-2-654b46505f84@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2025-12-24Revert "drm/msm/dpu: support plane splitting in quad-pipe case"Abel Vesa
This reverts commit 5978864e34b66bdae4d7613834c03dd5d0a0c891. At least on Hamoa based devices, there are IOMMU faults: arm-smmu 15000000.iommu: Unhandled context fault: fsr=0x402, iova=0x00000000, fsynr=0x3d0023, cbfrsynra=0x1c00, cb=13 arm-smmu 15000000.iommu: FSR = 00000402 [Format=2 TF], SID=0x1c00 arm-smmu 15000000.iommu: FSYNR0 = 003d0023 [S1CBNDX=61 PNU PLVL=3] While on some of these devices, there are also all sorts of artifacts on eDP. Reverting this fixes these issues. Closes: https://lore.kernel.org/r/z75wnahrp7lrl5yhfdysr3np3qrs6xti2i4otkng4ex3blfgrx@xyiucge3xykb/ Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com> Reviewed-by: Marijn Suijten <marijn.suijten@somainline.org> Fixes: 5978864e34b6 ("drm/msm/dpu: support plane splitting in quad-pipe case") Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/695549/ Link: https://lore.kernel.org/r/20251219-drm-msm-dpu-revert-quad-pipe-broken-v1-1-654b46505f84@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2025-12-24drm/msm: msm_iommu.c: fix all kernel-doc warningsRandy Dunlap
Correct or add kernel-doc comments to eliminate all warnings: Warning: ../drivers/gpu/drm/msm/msm_iommu.c:381 expecting prototype for alloc_pt(). Prototype was for msm_iommu_pagetable_alloc_pt() instead Warning: ../drivers/gpu/drm/msm/msm_iommu.c:426 expecting prototype for free_pt(). Prototype was for msm_iommu_pagetable_free_pt() instead Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/695675/ Link: https://lore.kernel.org/r/20251219184638.1813181-20-rdunlap@infradead.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2025-12-24drm/msm: msm_gpu.h: fix all kernel-doc warningsRandy Dunlap
Correct or add kernel-doc comments to eliminate all warnings: Warning: drivers/gpu/drm/msm/msm_gpu.h:119 Incorrect use of kernel-doc format: * devfreq: devfreq instance Warning: drivers/gpu/drm/msm/msm_gpu.h:125 Incorrect use of kernel-doc format: * idle_freq: Warning: drivers/gpu/drm/msm/msm_gpu.h:136 Incorrect use of kernel-doc format: * boost_constraint: Warning: drivers/gpu/drm/msm/msm_gpu.h:144 Incorrect use of kernel-doc format: * busy_cycles: Last busy counter value, for calculating elapsed busy Warning: drivers/gpu/drm/msm/msm_gpu.h:156 Incorrect use of kernel-doc format: * idle_work: Warning: drivers/gpu/drm/msm/msm_gpu.h:163 Incorrect use of kernel-doc format: * boost_work: Warning: drivers/gpu/drm/msm/msm_gpu.h:170 struct member 'devfreq' not described in 'msm_gpu_devfreq' Warning: drivers/gpu/drm/msm/msm_gpu.h:170 struct member 'boost_freq' not described in 'msm_gpu_devfreq' Warning: drivers/gpu/drm/msm/msm_gpu.h:172 struct member 'devfreq' not described in 'msm_gpu_devfreq' Warning: drivers/gpu/drm/msm/msm_gpu.h:172 struct member 'lock' not described in 'msm_gpu_devfreq' Warning: drivers/gpu/drm/msm/msm_gpu.h:172 struct member 'governor' not described in 'msm_gpu_devfreq' Warning: drivers/gpu/drm/msm/msm_gpu.h:172 struct member 'we are continuing to sample busyness and * adjust frequency while the GPU is idle' not described in 'msm_gpu_devfreq' Warning: drivers/gpu/drm/msm/msm_gpu.h:172 struct member 'boost_freq' not described in 'msm_gpu_devfreq' Warning: drivers/gpu/drm/msm/msm_gpu.h:172 struct member 'busy_cycles' not described in 'msm_gpu_devfreq' Warning: drivers/gpu/drm/msm/msm_gpu.h:172 struct member 'time' not described in 'msm_gpu_devfreq' Warning: drivers/gpu/drm/msm/msm_gpu.h:172 struct member 'idle_time' not described in 'msm_gpu_devfreq' Warning: drivers/gpu/drm/msm/msm_gpu.h:172 struct member 'idle_work' not described in 'msm_gpu_devfreq' Warning: drivers/gpu/drm/msm/msm_gpu.h:172 struct member 'boost_work' not described in 'msm_gpu_devfreq' Warning: drivers/gpu/drm/msm/msm_gpu.h:172 struct member 'suspended' not described in 'msm_gpu_devfreq' Warning: drivers/gpu/drm/msm/msm_gpu.h:472 No description found for return value of 'msm_context_is_vmbind' Warning: drivers/gpu/drm/msm/msm_gpu.h:476 struct member 'ref' not described in 'msm_context' Warning: drivers/gpu/drm/msm/msm_gpu.h:476 struct member 'elapsed_ns' not described in 'msm_context' Warning: drivers/gpu/drm/msm/msm_gpu.h:492 expecting prototype for msm_context_is_vm_bind(). Prototype was for msm_context_is_vmbind() instead Warning: drivers/gpu/drm/msm/msm_gpu.h:523 No description found for return value of 'msm_gpu_convert_priority' Warning: drivers/gpu/drm/msm/msm_gpu.h:583 expecting prototype for struct msm_gpu_submitqueues. Prototype was for struct msm_gpu_submitqueue instead Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/695671/ Link: https://lore.kernel.org/r/20251219184638.1813181-19-rdunlap@infradead.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2025-12-24drm/msm: msm_gem_vma.c: fix all kernel-doc warningsRandy Dunlap
Correct or add kernel-doc comments to eliminate all warnings: Warning: ../drivers/gpu/drm/msm/msm_gem_vma.c:96 expecting prototype for struct msm_vma_op. Prototype was for struct msm_vm_op instead Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/695679/ Link: https://lore.kernel.org/r/20251219184638.1813181-18-rdunlap@infradead.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2025-12-24drm/msm: msm_fence.h: fix all kernel-doc warningsRandy Dunlap
Correct or add kernel-doc comments to eliminate all warnings: Warning: drivers/gpu/drm/msm/msm_fence.h:27 Incorrect use of kernel-doc format: * last_fence: Warning: drivers/gpu/drm/msm/msm_fence.h:36 Incorrect use of kernel-doc format: * completed_fence: Warning: drivers/gpu/drm/msm/msm_fence.h:44 Incorrect use of kernel-doc format: * fenceptr: Warning: drivers/gpu/drm/msm/msm_fence.h:65 Incorrect use of kernel-doc format: * next_deadline_fence: Warning: drivers/gpu/drm/msm/msm_fence.h:74 struct member 'dev' not described in 'msm_fence_context' Warning: drivers/gpu/drm/msm/msm_fence.h:74 struct member 'name' not described in 'msm_fence_context' Warning: drivers/gpu/drm/msm/msm_fence.h:74 struct member 'context' not described in 'msm_fence_context' Warning: drivers/gpu/drm/msm/msm_fence.h:74 struct member 'index' not described in 'msm_fence_context' Warning: drivers/gpu/drm/msm/msm_fence.h:74 struct member 'fence' not described in 'msm_fence_context' Warning: drivers/gpu/drm/msm/msm_fence.h:74 struct member 'there is no remaining pending work */ uint32_t last_fence' not described in 'msm_fence_context' Warning: drivers/gpu/drm/msm/msm_fence.h:74 struct member 'updated from the CPU after interrupt * from GPU */ uint32_t completed_fence' not described in 'msm_fence_context' Warning: drivers/gpu/drm/msm/msm_fence.h:74 struct member 'fenceptr' not described in 'msm_fence_context' Warning: drivers/gpu/drm/msm/msm_fence.h:74 struct member 'spinlock' not described in 'msm_fence_context' Warning: drivers/gpu/drm/msm/msm_fence.h:74 struct member 'next_deadline' not described in 'msm_fence_context' Warning: drivers/gpu/drm/msm/msm_fence.h:74 struct member 'next_deadline_fence' not described in 'msm_fence_context' Warning: drivers/gpu/drm/msm/msm_fence.h:74 struct member 'deadline_timer' not described in 'msm_fence_context' Warning: drivers/gpu/drm/msm/msm_fence.h:74 struct member 'deadline_work' not described in 'msm_fence_context' Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/695667/ Link: https://lore.kernel.org/r/20251219184638.1813181-17-rdunlap@infradead.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2025-12-24drm/msm/dpu: dpu_hw_wb.h: fix all kernel-doc warningsRandy Dunlap
Correct or add kernel-doc comments to eliminate all warnings: Warning: drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.h:24 Cannot find identifier on line: * Warning: drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.h:57 struct member 'setup_roi' not described in 'dpu_hw_wb_ops' Warning: drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.h:75 struct member 'caps' not described in 'dpu_hw_wb' Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/695672/ Link: https://lore.kernel.org/r/20251219184638.1813181-16-rdunlap@infradead.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>