summaryrefslogtreecommitdiffstats
AgeCommit message (Collapse)AuthorFilesLines
2025-10-10tpm: use a map for tpm2_calc_ordinal_duration()Jarkko Sakkinen4-99/+37
The current shenanigans for duration calculation introduce too much complexity for a trivial problem, and further the code is hard to patch and maintain. Address these issues with a flat look-up table, which is easy to understand and patch. If leaf driver specific patching is required in future, it is easy enough to make a copy of this table during driver initialization and add the chip parameter back. 'chip->duration' is retained for TPM 1.x. As the first entry for this new behavior address TCG spec update mentioned in this issue: https://github.com/raspberrypi/linux/issues/7054 Therefore, for TPM_SelfTest the duration is set to 3000 ms. This does not categorize a as bug, given that this is introduced to the spec after the feature was originally made. Reviewed-by: Serge Hallyn <serge@hallyn.com> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
2025-10-10tpm_tis: Fix incorrect arguments in tpm_tis_probe_irq_singleGunnar Kudrjavets1-2/+2
The tpm_tis_write8() call specifies arguments in wrong order. Should be (data, addr, value) not (data, value, addr). The initial correct order was changed during the major refactoring when the code was split. Fixes: 41a5e1cf1fe1 ("tpm/tpm_tis: Split tpm_tis driver into a core and TCG TIS compliant phy") Signed-off-by: Gunnar Kudrjavets <gunnarku@amazon.com> Reviewed-by: Justinien Bouron <jbouron@amazon.com> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
2025-10-10tpm: Use HMAC-SHA256 library instead of open-coded HMACEric Biggers1-71/+27
Now that there are easy-to-use HMAC-SHA256 library functions, use these in tpm2-sessions.c instead of open-coding the HMAC algorithm. Note that the new implementation correctly handles keys longer than 64 bytes (SHA256_BLOCK_SIZE), whereas the old implementation handled such keys incorrectly. But it doesn't appear that such keys were being used. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
2025-10-10tpm: Compare HMAC values in constant timeEric Biggers2-3/+4
In tpm_buf_check_hmac_response(), compare the HMAC values in constant time using crypto_memneq() instead of in variable time using memcmp(). This is worthwhile to follow best practices and to be consistent with MAC comparisons elsewhere in the kernel. However, in this driver the side channel seems to have been benign: the HMAC input data is guaranteed to always be unique, which makes the usual MAC forgery via timing side channel not possible. Specifically, the HMAC input data in tpm_buf_check_hmac_response() includes the "our_nonce" field, which was generated by the kernel earlier, remains under the control of the kernel, and is unique for each call to tpm_buf_check_hmac_response(). Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
2025-10-10tpm: Disable TPM2_TCG_HMAC by defaultJarkko Sakkinen1-1/+1
After reading all the feedback, right now disabling the TPM2_TCG_HMAC is the right call. Other views discussed: A. Having a kernel command-line parameter or refining the feature otherwise. This goes to the area of improvements. E.g., one example is my own idea where the null key specific code would be replaced with a persistent handle parameter (which can be *unambigously* defined as part of attestation process when done correctly). B. Removing the code. I don't buy this because that is same as saying that HMAC encryption cannot work at all (if really nitpicking) in any form. Also I disagree on the view that the feature could not be refined to something more reasoable. Also, both A and B are worst options in terms of backporting. Thuss, this is the best possible choice. Cc: stable@vger.kernel.or # v6.10+ Fixes: d2add27cf2b8 ("tpm: Add NULL primary creation") Suggested-by: Chris Fenner <cfenn@google.com> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
2025-10-09cifs: Add comments for DeletePending assignments in open functionsPali Rohár3-4/+4
On more places is set DeletePending member to 0. Add comments why is 0 the correct value. Paths in DELETE_PENDING state cannot be opened by new calls. So if the newly issued open for that path succeed then it means that the path cannot be in DELETE_PENDING state. Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Steve French <stfrench@microsoft.com>
2025-10-09cifs: Add fallback code path for cifs_mkdir_setinfo()Pali Rohár1-0/+5
Use SMBSetInformation() as a fallback function (when CIFSSMBSetPathInfo() fails) which can set attribudes on the directory, including changing read-only attribute. Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Steve French <stfrench@microsoft.com>
2025-10-09cifs: Allow fallback code in smb_set_file_info() also for directoriesPali Rohár1-1/+1
On NT systems, it is possible to do SMB open call also for directories. Open argument CREATE_NOT_DIR disallows opening directories. So in fallback code path in smb_set_file_info() remove CREATE_NOT_DIR restriction to allow it also for directories. Similar fallback is implemented also in CIFSSMBSetPathInfoFB() function and this function already allows to call operation for directories. Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Steve French <stfrench@microsoft.com>
2025-10-09cifs: Query EA $LXMOD in cifs_query_path_info() for WSL reparse pointsPali Rohár1-2/+60
EA $LXMOD is required for WSL non-symlink reparse points. Fixes: ef86ab131d91 ("cifs: Fix querying of WSL CHR and BLK reparse points over SMB1") Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Steve French <stfrench@microsoft.com>
2025-10-10fbdev: Fix logic error in "offb" name matchFinn Thain1-1/+1
A regression was reported to me recently whereby /dev/fb0 had disappeared from a PowerBook G3 Series "Wallstreet". The problem shows up when the "video=ofonly" parameter is passed to the kernel, which is what the bootloader does when "no video driver" is selected. The cause of the problem is the "offb" string comparison, which got mangled when it got refactored. Fix it. Cc: stable@vger.kernel.org Fixes: 93604a5ade3a ("fbdev: Handle video= parameter in video/cmdline.c") Reported-and-tested-by: Stan Johnson <userm57@yahoo.com> Signed-off-by: Finn Thain <fthain@linux-m68k.org> Signed-off-by: Helge Deller <deller@gmx.de>
2025-10-09parisc: Fix iodc and device path return values on old machinesHelge Deller1-0/+6
Older machines may not fully initialize the return values when asking for IODC and device path data when building the inventory. Work around possible firmware leaks by proper initialization of the variables. Signed-off-by: Helge Deller <deller@gmx.de>
2025-10-09parisc: Firmware: Fix returned path for PDC_MODULE_FIND on older machinesHelge Deller1-1/+2
Older machines (like my 715/64) don't correctly initialize the device path when returning from the PDC_MODULE_FIND firmware call. Work around that shortcoming by initializing the path with the known values. Signed-off-by: Helge Deller <deller@gmx.de>
2025-10-09rtc: interface: Ensure alarm irq is enabled when UIE is enabledEsben Haabendal1-0/+4
When setting a normal alarm, user-space is responsible for using RTC_AIE_ON/RTC_AIE_OFF to control if alarm irq should be enabled. But when RTC_UIE_ON is used, interrupts must be enabled so that the requested irq events are generated. When RTC_UIE_OFF is used, alarm irq is disabled if there are no other alarms queued, so this commit brings symmetry to that. Signed-off-by: Esben Haabendal <esben@geanix.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20250516-rtc-uie-irq-fixes-v2-5-3de8e530a39e@geanix.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2025-10-09rtc: tps6586x: Fix initial enable_irq/disable_irq balanceEsben Haabendal1-0/+1
Interrupts are automatically enabled when requested, so we need to initialize irq_en accordingly to avoid causing an unbalanced enable warning. Signed-off-by: Esben Haabendal <esben@geanix.com> Link: https://lore.kernel.org/r/20250516-rtc-uie-irq-fixes-v2-4-3de8e530a39e@geanix.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2025-10-09rtc: cpcap: Fix initial enable_irq/disable_irq balanceEsben Haabendal1-0/+1
Interrupts are automatically enabled when requested, so we need to initialize alarm_enabled accordingly to avoid causing an unbalanced enable warning. Signed-off-by: Esben Haabendal <esben@geanix.com> Link: https://lore.kernel.org/r/20250516-rtc-uie-irq-fixes-v2-3-3de8e530a39e@geanix.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2025-10-09rtc: isl12022: Fix initial enable_irq/disable_irq balanceEsben Haabendal1-0/+1
Interrupts are automatically enabled when requested, so we need to initialize irq_enabled accordingly to avoid causing an unbalanced enable warning. Fixes: c62d658e5253 ("rtc: isl12022: Add alarm support") Signed-off-by: Esben Haabendal <esben@geanix.com> Link: https://lore.kernel.org/r/20250516-rtc-uie-irq-fixes-v2-2-3de8e530a39e@geanix.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2025-10-09rtc: interface: Fix long-standing race when setting alarmEsben Haabendal1-0/+23
As described in the old comment dating back to commit 6610e0893b8b ("RTC: Rework RTC code to use timerqueue for events") from 2010, we have been living with a race window when setting alarm with an expiry in the near future (i.e. next second). With 1 second resolution, it can happen that the second ticks after the check for the timer having expired, but before the alarm is actually set. When this happen, no alarm IRQ is generated, at least not with some RTC chips (isl12022 is an example of this). With UIE RTC timer being implemented on top of alarm irq, being re-armed every second, UIE will occasionally fail to work, as an alarm irq lost due to this race will stop the re-arming loop. For now, I have limited the additional expiry check to only be done for alarms set to next seconds. I expect it should be good enough, although I don't know if we can now for sure that systems with loads could end up causing the same problems for alarms set 2 seconds or even longer in the future. I haven't been able to reproduce the problem with this check in place. Cc: stable@vger.kernel.org Signed-off-by: Esben Haabendal <esben@geanix.com> Link: https://lore.kernel.org/r/20250516-rtc-uie-irq-fixes-v2-1-3de8e530a39e@geanix.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2025-10-10Merge tag 'amd-drm-next-6.18-2025-10-09' of ↵Dave Airlie28-174/+276
https://gitlab.freedesktop.org/agd5f/linux into drm-next amd-drm-next-6.18-2025-10-09: amdgpu: - DC DCE6 fixes - GPU reset fixes - Secure diplay messaging cleanup - MES fix - GPUVM locking fixes - PMFW messaging cleanup - PCI US/DS switch handling fix - VCN queue reset fix - DC FPU handling fix - DCN 3.5 fix - DC mirroring fix amdkfd: - Fix kfd process ref leak - mmap write lock handling fix - Fix comments in IOCTL Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexander.deucher@amd.com> Link: https://lore.kernel.org/r/20251009162915.981503-1-alexander.deucher@amd.com
2025-10-09Merge tag 'trace-v6.18-2' of ↵Linus Torvalds5-79/+241
git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace Pull tracing clean up and fixes from Steven Rostedt: - Have osnoise tracer use memdup_user_nul() The function osnoise_cpus_write() open codes a kmalloc() and then a copy_from_user() and then adds a nul byte at the end which is the same as simply using memdup_user_nul(). - Fix wakeup and irq tracers when failing to acquire calltime When the wakeup and irq tracers use the function graph tracer for tracing function times, it saves a timestamp into the fgraph shadow stack. It is possible that this could fail to be stored. If that happens, it exits the routine early. These functions also disable nesting of the operations by incremeting the data "disable" counter. But if the calltime exits out early, it never increments the counter back to what it needs to be. Since there's only a couple of lines of code that does work after acquiring the calltime, instead of exiting out early, reverse the if statement to be true if calltime is acquired, and place the code that is to be done within that if block. The clean up will always be done after that. - Fix ring_buffer_map() return value on failure of __rb_map_vma() If __rb_map_vma() fails in ring_buffer_map(), it does not return an error. This means the caller will be working against a bad vma mapping. Have ring_buffer_map() return an error when __rb_map_vma() fails. - Fix regression of writing to the trace_marker file A bug fix was made to change __copy_from_user_inatomic() to copy_from_user_nofault() in the trace_marker write function. The trace_marker file is used by applications to write into it (usually with a file descriptor opened at the start of the program) to record into the tracing system. It's usually used in critical sections so the write to trace_marker is highly optimized. The reason for copying in an atomic section is that the write reserves space on the ring buffer and then writes directly into it. After it writes, it commits the event. The time between reserve and commit must have preemption disabled. The trace marker write does not have any locking nor can it allocate due to the nature of it being a critical path. Unfortunately, converting __copy_from_user_inatomic() to copy_from_user_nofault() caused a regression in Android. Now all the writes from its applications trigger the fault that is rejected by the _nofault() version that wasn't rejected by the _inatomic() version. Instead of getting data, it now just gets a trace buffer filled with: tracing_mark_write: <faulted> To fix this, on opening of the trace_marker file, allocate per CPU buffers that can be used by the write call. Then when entering the write call, do the following: preempt_disable(); cpu = smp_processor_id(); buffer = per_cpu_ptr(cpu_buffers, cpu); do { cnt = nr_context_switches_cpu(cpu); migrate_disable(); preempt_enable(); ret = copy_from_user(buffer, ptr, size); preempt_disable(); migrate_enable(); } while (!ret && cnt != nr_context_switches_cpu(cpu)); if (!ret) ring_buffer_write(buffer); preempt_enable(); This works similarly to seqcount. As it must enabled preemption to do a copy_from_user() into a per CPU buffer, if it gets preempted, the buffer could be corrupted by another task. To handle this, read the number of context switches of the current CPU, disable migration, enable preemption, copy the data from user space, then immediately disable preemption again. If the number of context switches is the same, the buffer is still valid. Otherwise it must be assumed that the buffer may have been corrupted and it needs to try again. Now the trace_marker write can get the user data even if it has to fault it in, and still not grab any locks of its own. * tag 'trace-v6.18-2' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace: tracing: Have trace_marker use per-cpu data to read user space ring buffer: Propagate __rb_map_vma return value to caller tracing: Fix irqoff tracers on failure of acquiring calltime tracing: Fix wakeup tracers on failure of acquiring calltime tracing/osnoise: Replace kmalloc + copy_from_user with memdup_user_nul
2025-10-09Merge tag '9p-for-6.18-rc1' of https://github.com/martinetd/linuxLinus Torvalds6-28/+70
Pull 9p updates from Dominique Martinet: "A bunch of unrelated fixes: - polling fix for trans fd that ought to have been fixed otherwise back in March, but apparently came back somewhere else... - USB transport buffer overflow fix - Some dentry lifetime rework to handle metadata update for currently opened files in uncached mode, or inode type change in cached mode - a double-put on invalid flush found by syzbot - and finally /sys/fs/9p/caches not advancing buffer and overwriting itself for large contents Thanks to everyone involved!" * tag '9p-for-6.18-rc1' of https://github.com/martinetd/linux: 9p: sysfs_init: don't hardcode error to ENOMEM 9p: fix /sys/fs/9p/caches overwriting itself 9p: clean up comment typos 9p/trans_fd: p9_fd_request: kick rx thread if EPOLLIN net/9p: fix double req put in p9_fd_cancelled net/9p: Fix buffer overflow in USB transport layer fs/9p: Add p9_debug(VFS) in d_revalidate fs/9p: Invalidate dentry if inode type change detected in cached mode fs/9p: Refresh metadata in d_revalidate for uncached mode too
2025-10-09Merge tag 'net-6.18-rc1' of ↵Linus Torvalds77-596/+1113
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net Pull networking fixes from Paolo Abeni: "Including fixes from netfilter. Current release - regressions: - mlx5: fix pre-2.40 binutils assembler error Current release - new code bugs: - net: psp: don't assume reply skbs will have a socket - eth: fbnic: fix missing programming of the default descriptor Previous releases - regressions: - page_pool: fix PP_MAGIC_MASK to avoid crashing on some 32-bit arches - tcp: - take care of zero tp->window_clamp in tcp_set_rcvlowat() - don't call reqsk_fastopen_remove() in tcp_conn_request() - eth: - ice: release xa entry on adapter allocation failure - usb: asix: hold PM usage ref to avoid PM/MDIO + RTNL deadlock Previous releases - always broken: - netfilter: validate objref and objrefmap expressions - sctp: fix a null dereference in sctp_disposition sctp_sf_do_5_1D_ce() - eth: - mlx4: prevent potential use after free in mlx4_en_do_uc_filter() - mlx5: prevent tunnel mode conflicts between FDB and NIC IPsec tables - ocelot: fix use-after-free caused by cyclic delayed work Misc: - add support for MediaTek PCIe 5G HP DRMR-H01" * tag 'net-6.18-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (38 commits) net: airoha: Fix loopback mode configuration for GDM2 port selftests: drv-net: pp_alloc_fail: add necessary optoins to config selftests: drv-net: pp_alloc_fail: lower traffic expectations selftests: drv-net: fix linter warnings in pp_alloc_fail eth: fbnic: fix reporting of alloc_failed qstats selftests: drv-net: xdp: add test for interface level qstats selftests: drv-net: xdp: rename netnl to ethnl eth: fbnic: fix saving stats from XDP_TX rings on close eth: fbnic: fix accounting of XDP packets eth: fbnic: fix missing programming of the default descriptor selftests: netfilter: query conntrack state to check for port clash resolution selftests: netfilter: nft_fib.sh: fix spurious test failures bridge: br_vlan_fill_forward_path_pvid: use br_vlan_group_rcu() netfilter: nft_objref: validate objref and objrefmap expressions net: pse-pd: tps23881: Fix current measurement scaling net/mlx5: fix pre-2.40 binutils assembler error net/mlx5e: Do not fail PSP init on missing caps net/mlx5e: Prevent tunnel reformat when tunnel mode not allowed net/mlx5: Prevent tunnel mode conflicts between FDB and NIC IPsec tables net: usb: asix: hold PM usage ref to avoid PM/MDIO + RTNL deadlock ...
2025-10-09Merge tag 's390-6.18-2' of ↵Linus Torvalds42-191/+223
git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux Pull more s390 updates from Alexander Gordeev: - Compile the decompressor with -Wno-pointer-sign flag to avoid a clang warning - Fix incomplete conversion to flag output macros in __xsch(), to avoid always zero return value instead of the expected condition code - Remove superfluous newlines from inline assemblies to improve compiler inlining decisions - Expose firmware provided UID Checking state in sysfs regardless of the device presence or state - CIO does not unregister subchannels when the attached device is invalid or unavailable. Update the purge function to remove I/O subchannels if the device number is found on cio_ignore list - Consolidate PAI crypto allocation and cleanup paths - The uv_get_secret_metadata() function has been removed some few months ago, remove also the function mention it in a comment * tag 's390-6.18-2' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux: s390/uv: Fix comment of uv_find_secret() function s390/pai_crypto: Consolidate PAI crypto allocation and cleanup paths s390/cio: Update purge function to unregister the unused subchannels s390/pci: Expose firmware provided UID Checking state in sysfs s390: Remove superfluous newlines from inline assemblies s390/cio/ioasm: Fix __xsch() condition code handling s390: Add -Wno-pointer-sign to KBUILD_CFLAGS_DECOMPRESSOR
2025-10-09Merge tag 'slab-for-6.18-rc1' of ↵Linus Torvalds1-4/+13
git://git.kernel.org/pub/scm/linux/kernel/git/vbabka/slab Pull slab fixes from Vlastimil Babka: - Fixes for several corner cases in error paths and debugging options, related to the new kmalloc_nolock() functionality (Kuniyuki Iwashima, Ran Xiaokai) * tag 'slab-for-6.18-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/vbabka/slab: slub: Don't call lockdep_unregister_key() for immature kmem_cache. slab: Fix using this_cpu_ptr() in preemptible context slab: Add allow_spin check to eliminate kmemleak warnings
2025-10-09smb: client: remove cfids_invalidation_workerEnzo Matsumiya2-29/+9
We can do the same cleanup on laundromat. On invalidate_all_cached_dirs(), run laundromat worker with 0 timeout and flush it for immediate + sync cleanup. Signed-off-by: Enzo Matsumiya <ematsumiya@suse.de> Signed-off-by: Steve French <stfrench@microsoft.com>
2025-10-09smb: client: remove redudant assignment in cifs_strict_fsync()Paulo Alcantara1-9/+4
Remove redudant assignment of @rc as it will be overwritten by the following cifs_file_flush() call. Reported-by: Steve French <stfrench@microsoft.com> Addresses-Coverity: 1665925 Fixes: 210627b0aca9 ("smb: client: fix missing timestamp updates with O_TRUNC") Signed-off-by: Paulo Alcantara (Red Hat) <pc@manguebit.org> Cc: linux-cifs@vger.kernel.org Signed-off-by: Steve French <stfrench@microsoft.com>
2025-10-09smb: client: fix race with fallocate(2) and AIO+DIOPaulo Alcantara3-15/+26
AIO+DIO may extend the file size, hence we need to make sure ->i_size is stable across the entire fallocate(2) operation, otherwise it would become a truncate and then inode size reduced back down when it finishes. Fix this by calling netfs_wait_for_outstanding_io() right after acquiring ->i_rwsem exclusively in cifs_fallocate() and then guarantee a stable ->i_size across fallocate(2). Also call netfs_wait_for_outstanding_io() after truncating pagecache to avoid any potential races with writeback. Signed-off-by: Paulo Alcantara (Red Hat) <pc@manguebit.org> Reviewed-by: David Howells <dhowells@redhat.com> Fixes: 210627b0aca9 ("smb: client: fix missing timestamp updates with O_TRUNC") Cc: Frank Sorenson <sorenson@redhat.com> Cc: linux-cifs@vger.kernel.org Signed-off-by: Steve French <stfrench@microsoft.com>
2025-10-09smb: client: fix missing timestamp updates after utime(2)Paulo Alcantara1-10/+12
Don't reuse open handle when changing timestamps to prevent the server from disabling automatic timestamp updates as per MS-FSA 2.1.4.17. ---8<--- import os import time filename = '/mnt/foo' def print_stat(prefix): st = os.stat(filename) print(prefix, ': ', time.ctime(st.st_atime), time.ctime(st.st_ctime)) fd = os.open(filename, os.O_CREAT|os.O_TRUNC|os.O_WRONLY, 0o644) print_stat('old') os.utime(fd, None) time.sleep(2) os.write(fd, b'foo') os.close(fd) time.sleep(2) print_stat('new') ---8<--- Before patch: $ mount.cifs //srv/share /mnt -o ... $ python3 run.py old : Fri Oct 3 14:01:21 2025 Fri Oct 3 14:01:21 2025 new : Fri Oct 3 14:01:21 2025 Fri Oct 3 14:01:21 2025 After patch: $ mount.cifs //srv/share /mnt -o ... $ python3 run.py old : Fri Oct 3 17:03:34 2025 Fri Oct 3 17:03:34 2025 new : Fri Oct 3 17:03:36 2025 Fri Oct 3 17:03:36 2025 Fixes: b6f2a0f89d7e ("cifs: for compound requests, use open handle if possible") Signed-off-by: Paulo Alcantara (Red Hat) <pc@manguebit.org> Cc: Frank Sorenson <sorenson@redhat.com> Reviewed-by: David Howells <dhowells@redhat.com> Cc: linux-cifs@vger.kernel.org Signed-off-by: Steve French <stfrench@microsoft.com>
2025-10-09smb: client: fix missing timestamp updates after ftruncate(2)Paulo Alcantara1-10/+8
Mask off ATTR_MTIME|ATTR_CTIME bits on ATTR_SIZE (e.g. ftruncate(2)) to prevent the client from sending set info calls and then disabling automatic timestamp updates on server side as per MS-FSA 2.1.4.17. ---8<--- import os import time filename = '/mnt/foo' def print_stat(prefix): st = os.stat(filename) print(prefix, ': ', time.ctime(st.st_atime), time.ctime(st.st_ctime)) fd = os.open(filename, os.O_CREAT|os.O_TRUNC|os.O_WRONLY, 0o644) print_stat('old') os.ftruncate(fd, 10) time.sleep(2) os.write(fd, b'foo') os.close(fd) time.sleep(2) print_stat('new') ---8<--- Before patch: $ mount.cifs //srv/share /mnt -o ... $ python3 run.py old : Fri Oct 3 13:47:03 2025 Fri Oct 3 13:47:03 2025 new : Fri Oct 3 13:47:00 2025 Fri Oct 3 13:47:03 2025 After patch: $ mount.cifs //srv/share /mnt -o ... $ python3 run.py old : Fri Oct 3 13:48:39 2025 Fri Oct 3 13:48:39 2025 new : Fri Oct 3 13:48:41 2025 Fri Oct 3 13:48:41 2025 Signed-off-by: Paulo Alcantara (Red Hat) <pc@manguebit.org> Cc: Frank Sorenson <sorenson@redhat.com> Reviewed-by: David Howells <dhowells@redhat.com> Cc: linux-cifs@vger.kernel.org Signed-off-by: Steve French <stfrench@microsoft.com>
2025-10-09smb: client: fix missing timestamp updates with O_TRUNCPaulo Alcantara3-92/+159
Don't call ->set_file_info() on open handle to prevent the server from stopping [cm]time updates automatically as per MS-FSA 2.1.4.17. Fix this by checking for ATTR_OPEN bit earlier in cifs_setattr() to prevent ->set_file_info() from being called when opening a file with O_TRUNC. Do the truncation in ->open() instead. This also saves two roundtrips when opening a file with O_TRUNC and there are currently no open handles to be reused. Before patch: $ mount.cifs //srv/share /mnt -o ... $ cd /mnt $ exec 3>foo; stat -c 'old: %z %y' foo; sleep 2; echo test >&3; exec 3>&-; sleep 2; stat -c 'new: %z %y' foo old: 2025-10-03 13:26:23.151030500 -0300 2025-10-03 13:26:23.151030500 -0300 new: 2025-10-03 13:26:23.151030500 -0300 2025-10-03 13:26:23.151030500 -0300 After patch: $ mount.cifs //srv/share /mnt -o ... $ cd /mnt $ exec 3>foo; stat -c 'old: %z %y' foo; sleep 2; echo test >&3; exec 3>&-; sleep 2; stat -c 'new: %z %y' foo $ exec 3>foo; stat -c 'old: %z %y' foo; sleep 2; echo test >&3; exec 3>&-; sleep 2; stat -c 'new: %z %y' foo old: 2025-10-03 13:28:13.911933800 -0300 2025-10-03 13:28:13.911933800 -0300 new: 2025-10-03 13:28:26.647492700 -0300 2025-10-03 13:28:26.647492700 -0300 Reported-by: Frank Sorenson <sorenson@redhat.com> Signed-off-by: Paulo Alcantara (Red Hat) <pc@manguebit.org> Reviewed-by: David Howells <dhowells@redhat.com> Cc: linux-cifs@vger.kernel.org Signed-off-by: Steve French <stfrench@microsoft.com>
2025-10-09cifs: Fix copy_to_iter return value checkFushuai Wang1-5/+5
The return value of copy_to_iter() function will never be negative, it is the number of bytes copied, or zero if nothing was copied. Update the check to treat 0 as an error, and return -1 in that case. Fixes: d08089f649a0 ("cifs: Change the I/O paths to use an iterator rather than a page list") Acked-by: Tom Talpey <tom@talpey.com> Reviewed-by: David Howells <dhowells@redhat.com> Signed-off-by: Fushuai Wang <wangfushuai@baidu.com> Signed-off-by: Steve French <stfrench@microsoft.com>
2025-10-09smb: client: batch SRV_COPYCHUNK entries to cut round tripsHenrique Carvalho3-117/+207
smb2_copychunk_range() used to send a single SRV_COPYCHUNK per SRV_COPYCHUNK_COPY IOCTL. Implement variable Chunks[] array in struct copychunk_ioctl and fill it with struct copychunk (MS-SMB2 2.2.31.1.1), bounded by server-advertised limits. This reduces the number of IOCTL requests for large copies. While we are at it, rename a couple variables to follow the terminology used in the specification. Signed-off-by: Henrique Carvalho <henrique.carvalho@suse.com> Signed-off-by: Steve French <stfrench@microsoft.com>
2025-10-09smb: client: Omit an if branch in smb2_find_smb_tcon()Markus Elfring1-5/+0
Statements from an if branch and the end of this function implementation were equivalent. Thus delete duplicate source code. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> Signed-off-by: Steve French <stfrench@microsoft.com>
2025-10-09dt-bindings: i2c: hisilicon,hix5hd2: convert to DT schemaKael D'Alcamo2-24/+51
Convert the Devicetree binding documentation for hisilicon,hix5hd2-i2c from plain text to DT binding schema. Signed-off-by: Kael D'Alcamo <dev@kael-k.io> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
2025-10-09gpio: usbio: Add ACPI device-id for MTL-CVF devicesHans de Goede1-0/+1
Add "INTC10D1" ACPI device-id for MTL-CVF devices, like the Dell Latitude 7450. Closes: https://bugzilla.redhat.com/show_bug.cgi?id=2368506 Signed-off-by: Hans de Goede <hansg@kernel.org> Acked-by: Israel Cepeda <israel.a.cepeda.lopez@intel.com> Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-10-09net: airoha: Fix loopback mode configuration for GDM2 portLorenzo Bianconi2-1/+6
Add missing configuration for loopback mode in airhoha_set_gdm2_loopback routine. Fixes: 9cd451d414f6e ("net: airoha: Add loopback support for GDM2") Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://patch.msgid.link/20251008-airoha-loopback-mode-fix-v2-1-045694fe7f60@kernel.org Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-10-09Merge branch 'eth-fbnic-fix-xdp_tx-and-xdp-vs-qstats'Paolo Abeni9-49/+209
Jakub Kicinski says: ==================== eth: fbnic: fix XDP_TX and XDP vs qstats Fix XDP_TX hangs and adjust the XDP statistics to match the definition of qstats. The three problems are somewhat distinct. XDP_TX hangs is a simple coding bug (patch 1). The accounting of XDP packets is all over the place. Fix it to obey qstat rules (packets seen by XDP always counted as Rx packets). Patch 2 fixes the basic accounting, patch 3 touches up saving the stats when rings are freed. Patch 6 corrects reporting of alloc_fail stats which prevented the pp_alloc_fail test from passing. Patches 4, 5, 7, 8, 9 add or fix related test cases. v2: - [patch 2] remove now unnecessary byte adjustment - [patch 8] use seen_fails more v1: https://lore.kernel.org/20251003233025.1157158-1-kuba@kernel.org Testing on fbnic below: $ ./tools/testing/selftests/drivers/net/hw/pp_alloc_fail.py TAP version 13 1..1 fbnic-err: bad MMIO read address 0x80074 fbnic-err: bad MMIO read address 0x80074 # Seen: pkts:20605 fails:40 (pass thrs:12) # ethtool -G change retval: success ok 1 pp_alloc_fail.test_pp_alloc # Totals: pass:1 fail:0 xfail:0 xpass:0 skip:0 error:0 $ ./tools/testing/selftests/drivers/net/xdp.py TAP version 13 1..13 ok 1 xdp.test_xdp_native_pass_sb ok 2 xdp.test_xdp_native_pass_mb ok 3 xdp.test_xdp_native_drop_sb ok 4 xdp.test_xdp_native_drop_mb ok 5 xdp.test_xdp_native_tx_sb ok 6 xdp.test_xdp_native_tx_mb # Failed run: pkt_sz 2048, offset 1. Last successful run: pkt_sz 1024, offset 256. Reason: Adjustment failed ok 7 xdp.test_xdp_native_adjst_tail_grow_data ok 8 xdp.test_xdp_native_adjst_tail_shrnk_data # Failed run: pkt_sz 512, offset -256. Last successful run: pkt_sz 512, offset -128. Reason: Adjustment failed ok 9 xdp.test_xdp_native_adjst_head_grow_data # Failed run: pkt_sz (2048) > HDS threshold (1536) and offset 64 > 48 ok 10 xdp.test_xdp_native_adjst_head_shrnk_data ok 11 xdp.test_xdp_native_qstats_pass ok 12 xdp.test_xdp_native_qstats_drop ok 13 xdp.test_xdp_native_qstats_tx # Totals: pass:13 fail:0 xfail:0 xpass:0 skip:0 error:0 ==================== Link: https://patch.msgid.link/20251007232653.2099376-1-kuba@kernel.org Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-10-09selftests: drv-net: pp_alloc_fail: add necessary optoins to configJakub Kicinski1-0/+4
Add kernel config for error injection as needed by pp_alloc_fail.py Reviewed-by: Simon Horman <horms@kernel.org> Fixes: 9da271f825e4 ("selftests: drv-net-hw: add test for memory allocation failures with page pool") Signed-off-by: Jakub Kicinski <kuba@kernel.org> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://patch.msgid.link/20251007232653.2099376-10-kuba@kernel.org Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-10-09selftests: drv-net: pp_alloc_fail: lower traffic expectationsJakub Kicinski1-5/+11
Lower the expected level of traffic in the pp_alloc_fail test and calculate failure counter thresholds based on the traffic rather than using a fixed constant. We only have "QEMU HW" in NIPA right now, and the test (due to debug dependencies) only works on debug kernels in the first place. We need some place for it to pass otherwise it seems to be bit rotting. So lower the traffic threshold so that it passes on QEMU and with a debug kernel... Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://patch.msgid.link/20251007232653.2099376-9-kuba@kernel.org Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-10-09selftests: drv-net: fix linter warnings in pp_alloc_failJakub Kicinski1-6/+14
Fix linter warnings, it's a bit hard to check for new ones otherwise. W0311: Bad indentation. Found 16 spaces, expected 12 (bad-indentation) C0114: Missing module docstring (missing-module-docstring) W1514: Using open without explicitly specifying an encoding (unspecified-encoding) C0116: Missing function or method docstring (missing-function-docstring) Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://patch.msgid.link/20251007232653.2099376-8-kuba@kernel.org Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-10-09eth: fbnic: fix reporting of alloc_failed qstatsJakub Kicinski5-11/+58
Rx processing under normal circumstances has 3 rings - 2 buffer rings (heads, payloads) and a completion ring. All the rings have a struct fbnic_ring. Make sure we expose alloc_failed counter from the buffer rings, previously only the alloc_failed from the completion ring was reported, even tho all ring types may increment this counter (buffer rings in __fbnic_fill_bdq()). This makes the pp_alloc_fail.py test pass, it expects the qstat to be incrementing as page pool injections happen. Reviewed-by: Simon Horman <horms@kernel.org> Fixes: 67dc4eb5fc92 ("eth: fbnic: report software Rx queue stats") Signed-off-by: Jakub Kicinski <kuba@kernel.org> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://patch.msgid.link/20251007232653.2099376-7-kuba@kernel.org Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-10-09selftests: drv-net: xdp: add test for interface level qstatsJakub Kicinski1-2/+89
Send a non-trivial number of packets and make sure that they are counted correctly in qstats. Per qstats specification XDP is the first layer of the stack so we should see Rx and Tx counters go up for packets which went thru XDP. Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://patch.msgid.link/20251007232653.2099376-6-kuba@kernel.org Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-10-09selftests: drv-net: xdp: rename netnl to ethnlJakub Kicinski1-4/+4
Test uses "netnl" for the ethtool family which is quite confusing (one would expect netdev family would use this name). No functional changes. Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://patch.msgid.link/20251007232653.2099376-5-kuba@kernel.org Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-10-09eth: fbnic: fix saving stats from XDP_TX rings on closeJakub Kicinski3-6/+6
When rings are freed - stats get added to the device level stat structs. Save the stats from the XDP_TX ring just as Tx stats. Previously they would be saved to Rx and Tx stats. So we'd not see XDP_TX packets as Rx during runtime but after an down/up cycle the packets would appear in stats. Correct the helper used by ethtool code which does a runtime config switch. Reviewed-by: Simon Horman <horms@kernel.org> Fixes: 5213ff086344 ("eth: fbnic: Collect packet statistics for XDP") Signed-off-by: Jakub Kicinski <kuba@kernel.org> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://patch.msgid.link/20251007232653.2099376-4-kuba@kernel.org Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-10-09eth: fbnic: fix accounting of XDP packetsJakub Kicinski1-15/+15
Make XDP-handled packets appear in the Rx stats. The driver has been counting XDP_TX packets on the Tx ring, but there wasn't much accounting on the Rx side (the Rx bytes appear to be incremented on XDP_TX but XDP_DROP / XDP_ABORT are only counted as Rx drops). Counting XDP_TX packets (not just bytes) in Rx stats looks like a simple bug of omission. The XDP_DROP handling appears to be intentional. Whether XDP_DROP packets should be counted in interface-level Rx stats is a bit unclear historically. When we were defining qstats, however, we clarified based on operational experience that in this context: name: rx-packets doc: | Number of wire packets successfully received and passed to the stack. For drivers supporting XDP, XDP is considered the first layer of the stack, so packets consumed by XDP are still counted here. fbnic does not obey this requirement. Since XDP support has been added in current release cycle, instead of splitting interface and qstat handling - make them both follow the qstat definition. Another small tweak here is that we count bytes as received on the wire rather than post-XDP bytes (xdp_get_buff_len() vs skb->len). Reviewed-by: Simon Horman <horms@kernel.org> Fixes: 5213ff086344 ("eth: fbnic: Collect packet statistics for XDP") Signed-off-by: Jakub Kicinski <kuba@kernel.org> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://patch.msgid.link/20251007232653.2099376-3-kuba@kernel.org Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-10-09eth: fbnic: fix missing programming of the default descriptorJakub Kicinski1-0/+8
XDP_TX typically uses no offloads. To optimize XDP we added a "default descriptor" feature to the chip, which allows us to send XDP frames with just the buffer descriptors (DMA address + length). All the metadata descriptors are derived from the queue config. Commit under Fixes missed adding setting the defaults up when transplanting the code from the prototype driver. Importantly after reset the "request completion" bit is not set. Packets still get sent but there's no completion, so ring is not cleaned up. We can send one ring's worth of packets and then will start dropping all frames that got the XDP_TX action from the XDP prog. Reviewed-by: Simon Horman <horms@kernel.org> Fixes: 168deb7b31b2 ("eth: fbnic: Add support for XDP_TX action") Signed-off-by: Jakub Kicinski <kuba@kernel.org> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://patch.msgid.link/20251007232653.2099376-2-kuba@kernel.org Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-10-09Merge tag 'nf-25-10-08' of ↵Paolo Abeni4-23/+89
https://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf Florian Westphal says: ==================== netfilter: updates for net The following patchset contains Netfilter fixes for *net*: 1) Fix crash (call recursion) when nftables synproxy extension is used in an object map. When this feature was added in v5.4 the required hook call validation was forgotten. Fix from Fernando Fernandez Mancera. 2) bridge br_vlan_fill_forward_path_pvid uses incorrect rcu_dereference_protected(); we only have rcu read lock but not RTNL. Fix from Eric Woudstra. Last two patches address flakes in two existing selftests. netfilter pull request nf-25-10-08 * tag 'nf-25-10-08' of https://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf: selftests: netfilter: query conntrack state to check for port clash resolution selftests: netfilter: nft_fib.sh: fix spurious test failures bridge: br_vlan_fill_forward_path_pvid: use br_vlan_group_rcu() netfilter: nft_objref: validate objref and objrefmap expressions ==================== Link: https://patch.msgid.link/20251008125942.25056-1-fw@strlen.de Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-10-09crypto: essiv - Check ssize for decryption and in-place encryptionHerbert Xu1-8/+6
Move the ssize check to the start in essiv_aead_crypt so that it's also checked for decryption and in-place encryption. Reported-by: Muhammad Alifa Ramdhan <ramdhan@starlabs.sg> Fixes: be1eb7f78aa8 ("crypto: essiv - create wrapper template for ESSIV generation") Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2025-10-08Merge tag 'perf-tools-for-v6.18-1-2025-10-08' of ↵Linus Torvalds278-6056/+16020
git://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools Pull perf tools updates from Arnaldo Carvalho de Melo: - Extended 'perf annotate' with DWARF type information (--code-with-type) integration in the TUI, including a 'T' hotkey to toggle it - Enhanced 'perf bench mem' with new mmap() workloads and control over page/chunk sizes - Fix 'perf stat' error handling to correctly display unsupported events - Improved support for Clang cross-compilation - Refactored LLVM and Capstone disasm for modularity - Introduced the :X modifier to exclude an event from automatic regrouping - Adjusted KVM sampling defaults to use the "cycles" event to prevent failures - Added comprehensive support for decoding PowerPC Dispatch Trace Log (DTL) - Updated Arm SPE tracing logic for better analysis of memory and snoop details - Synchronized Intel PMU events and metrics with TMA 5.1 across multiple processor generations - Converted dependencies like libperl and libtracefs to be opt-in - Handle more Rust symbols in kallsyms ('N', debugging) - Improve the python binding to allow for python based tools to use more of the libraries, add a 'ilist' utility to test those new bindings - Various 'perf test' fixes - Kan Liang no longer a perf tools reviewer * tag 'perf-tools-for-v6.18-1-2025-10-08' of git://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools: (192 commits) perf tools: Fix arm64 libjvmti build by generating unistd_64.h perf tests: Don't retest sections in "Object code reading" perf docs: Document building with Clang perf build: Support build with clang perf test coresight: Dismiss clang warning for unroll loop thread perf test coresight: Dismiss clang warning for thread loop perf test coresight: Dismiss clang warning for memcpy thread perf build: Disable thread safety analysis for perl header perf build: Correct CROSS_ARCH for clang perf python: split Clang options when invoking Popen tools build: Align warning options with perf perf disasm: Remove unused evsel from 'struct annotate_args' perf srcline: Fallback between addr2line implementations perf disasm: Make ins__scnprintf() and ins__is_nop() static perf dso: Clean up read_symbol() error handling perf dso: Support BPF programs in dso__read_symbol() perf dso: Move read_symbol() from llvm/capstone to dso perf llvm: Reduce LLVM initialization perf check: Add libLLVM feature perf parse-events: Fix parsing of >30kb event strings ...
2025-10-08Merge tag 'pci-v6.18-fixes-1' of ↵Linus Torvalds1-2/+3
git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci Pull pci fix from Bjorn Helgaas: - Fix a resource lookup regression that broke enumeration of hotplugged Thunderbolt devices on several platforms (Yangyu Chen) * tag 'pci-v6.18-fixes-1' of git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci: PCI: Fix regression in pci_bus_distribute_available_resources()
2025-10-08tracing: Have trace_marker use per-cpu data to read user spaceSteven Rostedt1-48/+220
It was reported that using __copy_from_user_inatomic() can actually schedule. Which is bad when preemption is disabled. Even though there's logic to check in_atomic() is set, but this is a nop when the kernel is configured with PREEMPT_NONE. This is due to page faulting and the code could schedule with preemption disabled. Link: https://lore.kernel.org/all/20250819105152.2766363-1-luogengkun@huaweicloud.com/ The solution was to change the __copy_from_user_inatomic() to copy_from_user_nofault(). But then it was reported that this caused a regression in Android. There's several applications writing into trace_marker() in Android, but now instead of showing the expected data, it is showing: tracing_mark_write: <faulted> After reverting the conversion to copy_from_user_nofault(), Android was able to get the data again. Writes to the trace_marker is a way to efficiently and quickly enter data into the Linux tracing buffer. It takes no locks and was designed to be as non-intrusive as possible. This means it cannot allocate memory, and must use pre-allocated data. A method that is actively being worked on to have faultable system call tracepoints read user space data is to allocate per CPU buffers, and use them in the callback. The method uses a technique similar to seqcount. That is something like this: preempt_disable(); cpu = smp_processor_id(); buffer = this_cpu_ptr(&pre_allocated_cpu_buffers, cpu); do { cnt = nr_context_switches_cpu(cpu); migrate_disable(); preempt_enable(); ret = copy_from_user(buffer, ptr, size); preempt_disable(); migrate_enable(); } while (!ret && cnt != nr_context_switches_cpu(cpu)); if (!ret) ring_buffer_write(buffer); preempt_enable(); It's a little more involved than that, but the above is the basic logic. The idea is to acquire the current CPU buffer, disable migration, and then enable preemption. At this moment, it can safely use copy_from_user(). After reading the data from user space, it disables preemption again. It then checks to see if there was any new scheduling on this CPU. If there was, it must assume that the buffer was corrupted by another task. If there wasn't, then the buffer is still valid as only tasks in preemptable context can write to this buffer and only those that are running on the CPU. By using this method, where trace_marker open allocates the per CPU buffers, trace_marker writes can access user space and even fault it in, without having to allocate or take any locks of its own. Cc: stable@vger.kernel.org Cc: Masami Hiramatsu <mhiramat@kernel.org> Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Cc: Luo Gengkun <luogengkun@huaweicloud.com> Cc: Wattson CI <wattson-external@google.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Link: https://lore.kernel.org/20251008124510.6dba541a@gandalf.local.home Fixes: 3d62ab32df065 ("tracing: Fix tracing_marker may trigger page fault during preempt_disable") Reported-by: Runping Lai <runpinglai@google.com> Tested-by: Runping Lai <runpinglai@google.com> Closes: https://lore.kernel.org/linux-trace-kernel/20251007003417.3470979-2-runpinglai@google.com/ Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>