aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2024-03-18btrfs: do not skip re-registration for the mounted deviceAnand Jain1-11/+47
There are reports that since version 6.7 update-grub fails to find the device of the root on systems without initrd and on a single device. This looks like the device name changed in the output of /proc/self/mountinfo: 6.5-rc5 working 18 1 0:16 / / rw,noatime - btrfs /dev/sda8 ... 6.7 not working: 17 1 0:15 / / rw,noatime - btrfs /dev/root ... and "update-grub" shows this error: /usr/sbin/grub-probe: error: cannot find a device for / (is /dev mounted?) This looks like it's related to the device name, but grub-probe recognizes the "/dev/root" path and tries to find the underlying device. However there's a special case for some filesystems, for btrfs in particular. The generic root device detection heuristic is not done and it all relies on reading the device infos by a btrfs specific ioctl. This ioctl returns the device name as it was saved at the time of device scan (in this case it's /dev/root). The change in 6.7 for temp_fsid to allow several single device filesystem to exist with the same fsid (and transparently generate a new UUID at mount time) was to skip caching/registering such devices. This also skipped mounted device. One step of scanning is to check if the device name hasn't changed, and if yes then update the cached value. This broke the grub-probe as it always read the device /dev/root and couldn't find it in the system. A temporary workaround is to create a symlink but this does not survive reboot. The right fix is to allow updating the device path of a mounted filesystem even if this is a single device one. In the fix, check if the device's major:minor number matches with the cached device. If they do, then we can allow the scan to happen so that device_list_add() can take care of updating the device path. The file descriptor remains unchanged. This does not affect the temp_fsid feature, the UUID of the mounted filesystem remains the same and the matching is based on device major:minor which is unique per mounted filesystem. This covers the path when the device (that exists for all mounted devices) name changes, updating /dev/root to /dev/sdx. Any other single device with filesystem and is not mounted is still skipped. Note that if a system is booted and initial mount is done on the /dev/root device, this will be the cached name of the device. Only after the command "btrfs device scan" it will change as it triggers the rename. The fix was verified by users whose systems were affected. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=218353 Link: https://lore.kernel.org/lkml/CAKLYgeJ1tUuqLcsquwuFqjDXPSJpEiokrWK2gisPKDZLs8Y2TQ@mail.gmail.com/ Fixes: bc27d6f0aa0e ("btrfs: scan but don't register device on single device filesystem") CC: [email protected] # 6.7+ Tested-by: Alex Romosan <[email protected]> Tested-by: [email protected] Signed-off-by: Anand Jain <[email protected]> Reviewed-by: David Sterba <[email protected]> Signed-off-by: David Sterba <[email protected]>
2024-03-18Merge tag 'ovl-fixes-6.9-rc1' of ↵Linus Torvalds2-4/+4
git://git.kernel.org/pub/scm/linux/kernel/git/overlayfs/vfs Pull overlayfs fixes from Amir Goldstein: "Only minor fixes: - Fix uncalled for WARN_ON from v6.8-rc1 - Fix the overlayfs MAINTAINERS entry" * tag 'ovl-fixes-6.9-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/overlayfs/vfs: ovl: relax WARN_ON in ovl_verify_area() MAINTAINERS: update overlayfs git tree
2024-03-18ARM64: Dynamically allocate cpumasks and increase supported CPUs to 512Christoph Lameter (Ampere)1-1/+2
[ a.k.a. Revert "Revert "ARM64: Dynamically allocate cpumasks and increase supported CPUs to 512""; originally reverted because of a bug in the cpufreq-dt code not using zalloc_cpumask_var() ] Currently defconfig selects NR_CPUS=256, but some vendors (e.g. Ampere Computing) are planning to ship systems with 512 CPUs. So that all CPUs on these systems can be used with defconfig, we'd like to bump NR_CPUS to 512. Therefore this patch increases the default NR_CPUS from 256 to 512. As increasing NR_CPUS will increase the size of cpumasks, there's a fear that this might have a significant impact on stack usage due to code which places cpumasks on the stack. To mitigate that concern, we can select CPUMASK_OFFSTACK. As that doesn't seem to be a problem today with NR_CPUS=256, we only select this when NR_CPUS > 256. CPUMASK_OFFSTACK configures the cpumasks in the kernel to be dynamically allocated. This was used in the X86 architecture in the past to enable support for larger CPU configurations up to 8k cpus. With that is becomes possible to dynamically size the allocation of the cpu bitmaps depending on the quantity of processors detected on bootup. Memory used for cpumasks will increase if the kernel is run on a machine with more cores. Further increases may be needed if ARM processor vendors start supporting more processors. Given the current inflationary trends in core counts from multiple processor manufacturers this may occur. There are minor regressions for hackbench. The kernel data size for 512 cpus is smaller with offstack than with onstack. Benchmark results using hackbench average over 10 runs of hackbench -s 512 -l 2000 -g 15 -f 25 -P on Altra 80 Core Support for 256 CPUs on stack. Baseline 7.8564 sec Support for 512 CUs on stack. 7.8713 sec + 0.18% 512 CPUS offstack 7.8916 sec + 0.44% Kernel size comparison: text data filename Difference to onstack256 baseline 25755648 9589248 vmlinuz-6.8.0-rc4-onstack256 25755648 9607680 vmlinuz-6.8.0-rc4-onstack512 +0.19% 25755648 9603584 vmlinuz-6.8.0-rc4-offstack512 +0.14% Tested-by: Eric Mackay <[email protected]> Reviewed-by: Russell King (Oracle) <[email protected]> Signed-off-by: Christoph Lameter (Ampere) <[email protected]> Acked-by: Mark Rutland <[email protected]> Link: https://lore.kernel.org/r/[email protected] Link: https://lore.kernel.org/r/[email protected] [[email protected]: use 'select' instead of duplicating 'config CPUMASK_OFFSTACK'] Signed-off-by: Catalin Marinas <[email protected]>
2024-03-19kbuild: rpm-pkg: add dtb files in kernel rpmJose Ignacio Tornos Martinez1-0/+13
Some architectures, like aarch64 ones, need a dtb file to configure the hardware. The default dtb file can be preloaded from u-boot, but the final and/or more complete dtb file needs to be able to be loaded later from rootfs. Add the possible dtb files to the kernel rpm and mimic Fedora shipping process, storing the dtb files in the module directory. These dtb files will be copied to /boot directory by the install scripts, but add fallback just in case, checking if the content in /boot directory is correct. Mark the files installed to /boot as %ghost to make sure they will be removed when the package is uninstalled. Tested with Fedora Rawhide (x86_64 and aarch64) with dnf and rpm tools. In addition, fallback was also tested after modifying the install scripts. Signed-off-by: Jose Ignacio Tornos Martinez <[email protected]> Tested-by: Nathan Chancellor <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]>
2024-03-19kconfig: remove unneeded menu_is_visible() call in conf_write_defconfig()Masahiro Yamada1-4/+1
When the condition 'sym == NULL' is met, the code will reach the 'next_menu' label regardless of the return value from menu_is_visible(). menu_is_visible() calculates some symbol values as a side-effect, for instance by calling expr_calc_value(menu->visibility), but all the symbol values will be calculated eventually. Signed-off-by: Masahiro Yamada <[email protected]>
2024-03-19kconfig: check prompt for choice while parsingMasahiro Yamada2-3/+6
This can be checked on-the-fly. Signed-off-by: Masahiro Yamada <[email protected]>
2024-03-19kconfig: lxdialog: remove unused dialog colorsMasahiro Yamada2-22/+0
Remove inputbox_order, searchbox, searchbox_title, searchbox_border because they are initialized, but not used anywhere. Signed-off-by: Masahiro Yamada <[email protected]>
2024-03-19kconfig: lxdialog: fix button color for blackbg themeMasahiro Yamada1-1/+1
For MENUCONFIG_COLOR=blackbg, the text in inactive buttons is invisible because both the foreground and background are black. Change the foreground color to white and remove the highlighting. Signed-off-by: Masahiro Yamada <[email protected]>
2024-03-18spi: Merge up v6.8 releaseMark Brown1514-7611/+14865
An i.MX fix depends on other fixes that were sent to v6.8.
2024-03-19modpost: fix null pointer dereferenceMax Kellermann1-1/+3
If the find_fromsym() call fails and returns NULL, the warn() call will dereference this NULL pointer and cause the program to crash. This happened when I tried to build with "test_user_copy" module. With this fix, it prints lots of warnings like this: WARNING: modpost: lib/test_user_copy: section mismatch in reference: (unknown)+0x4 (section: .text.fixup) -> (unknown) (section: .init.text) [email protected]: The issue is reproduced with ARCH=arm allnoconfig + CONFIG_MODULES=y + CONFIG_RUNTIME_TESTING_MENU=y + CONFIG_TEST_USER_COPY=m Signed-off-by: Max Kellermann <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]>
2024-03-18Merge tag 'vfs-6.9-rc1.fixes' of ↵Linus Torvalds7-35/+51
git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs Pull vfs fixes from Christian Brauner: "This contains a few small fixes for this merge window: - Undo the hiding of silly-rename files in afs. If they're hidden they can't be deleted by rm manually anymore causing regressions - Avoid caching the preferred address for an afs server to avoid accidently overriding an explicitly specified preferred server address - Fix bad stat() and rmdir() interaction in afs - Take a passive reference on the superblock when opening a block device so the holder is available to concurrent callers from the block layer - Clear private data pointer in fscache_begin_operation() to avoid it being falsely treated as valid" * tag 'vfs-6.9-rc1.fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs: fscache: Fix error handling in fscache_begin_operation() fs,block: get holder during claim afs: Fix occasional rmdir-then-VNOVNODE with generic/011 afs: Don't cache preferred address afs: Revert "afs: Hide silly-rename files from userspace"
2024-03-18Merge tag 'irq-urgent-2024-03-17' of ↵Linus Torvalds1-5/+8
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull irq fix from Ingo Molnar: "A RISC-V irqchip driver fix" * tag 'irq-urgent-2024-03-17' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: irqchip/riscv-intc: Fix use of AIA interrupts 32-63 on riscv32
2024-03-18Merge tag 'sound-fix-6.9-rc1' of ↵Linus Torvalds4-36/+42
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound Pull sound fixes from Takashi Iwai: "Two regression fixes that had been introduced in this merge window, additional HD-audio quirks, and a further enhancement for the new kunit" * tag 'sound-fix-6.9-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: ALSA: core: add kunitconfig ALSA: hda/realtek: add in quirk for Acer Swift Go 16 - SFG16-71 Revert "ALSA: usb-audio: Name feature ctl using output if input is PCM" ALSA: timer: Fix missing irq-disable at closing ALSA: hda/realtek: Add quirk for Lenovo Yoga 9 14IMH9
2024-03-18spi: lm70llp: fix links in doc and commentsKousik Sanagavarapu2-4/+4
Update links in the documentation and in-code comments which point to the datasheet and schematic. The current links don't work because National Semiconductor (which is the manufacturer of this board and lm70) has been a part of Texas Instruments since 2011 and hence http://www.national.com/ doesn't work anymore. Fixes: 78961a574037 ("spi_lm70llp parport adapter driver") Fixes: 2b7300513b98 ("hwmon: (lm70) Code streamlining and cleanup") Signed-off-by: Kousik Sanagavarapu <[email protected]> Link: https://msgid.link/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2024-03-18drm/dp: Fix divide-by-zero regression on DP MST unplug with nouveauChris Bainbridge1-0/+7
Fix a regression when using nouveau and unplugging a StarTech MSTDP122DP DisplayPort 1.2 MST hub (the same regression does not appear when using a Cable Matters DisplayPort 1.4 MST hub). Trace: divide error: 0000 [#1] PREEMPT SMP PTI CPU: 7 PID: 2962 Comm: Xorg Not tainted 6.8.0-rc3+ #744 Hardware name: Razer Blade/DANA_MB, BIOS 01.01 08/31/2018 RIP: 0010:drm_dp_bw_overhead+0xb4/0x110 [drm_display_helper] Code: c6 b8 01 00 00 00 75 61 01 c6 41 0f af f3 41 0f af f1 c1 e1 04 48 63 c7 31 d2 89 ff 48 8b 5d f8 c9 48 0f af f1 48 8d 44 06 ff <48> f7 f7 31 d2 31 c9 31 f6 31 ff 45 31 c0 45 31 c9 45 31 d2 45 31 RSP: 0018:ffffb2c5c211fa30 EFLAGS: 00010206 RAX: ffffffffffffffff RBX: 0000000000000000 RCX: 0000000000f59b00 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffb2c5c211fa48 R08: 0000000000000001 R09: 0000000000000020 R10: 0000000000000004 R11: 0000000000000000 R12: 0000000000023b4a R13: ffff91d37d165800 R14: ffff91d36fac6d80 R15: ffff91d34a764010 FS: 00007f4a1ca3fa80(0000) GS:ffff91d6edbc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000559491d49000 CR3: 000000011d180002 CR4: 00000000003706f0 Call Trace: <TASK> ? show_regs+0x6d/0x80 ? die+0x37/0xa0 ? do_trap+0xd4/0xf0 ? do_error_trap+0x71/0xb0 ? drm_dp_bw_overhead+0xb4/0x110 [drm_display_helper] ? exc_divide_error+0x3a/0x70 ? drm_dp_bw_overhead+0xb4/0x110 [drm_display_helper] ? asm_exc_divide_error+0x1b/0x20 ? drm_dp_bw_overhead+0xb4/0x110 [drm_display_helper] ? drm_dp_calc_pbn_mode+0x2e/0x70 [drm_display_helper] nv50_msto_atomic_check+0xda/0x120 [nouveau] drm_atomic_helper_check_modeset+0xa87/0xdf0 [drm_kms_helper] drm_atomic_helper_check+0x19/0xa0 [drm_kms_helper] nv50_disp_atomic_check+0x13f/0x2f0 [nouveau] drm_atomic_check_only+0x668/0xb20 [drm] ? drm_connector_list_iter_next+0x86/0xc0 [drm] drm_atomic_commit+0x58/0xd0 [drm] ? __pfx___drm_printfn_info+0x10/0x10 [drm] drm_atomic_connector_commit_dpms+0xd7/0x100 [drm] drm_mode_obj_set_property_ioctl+0x1c5/0x450 [drm] ? __pfx_drm_connector_property_set_ioctl+0x10/0x10 [drm] drm_connector_property_set_ioctl+0x3b/0x60 [drm] drm_ioctl_kernel+0xb9/0x120 [drm] drm_ioctl+0x2d0/0x550 [drm] ? __pfx_drm_connector_property_set_ioctl+0x10/0x10 [drm] nouveau_drm_ioctl+0x61/0xc0 [nouveau] __x64_sys_ioctl+0xa0/0xf0 do_syscall_64+0x76/0x140 ? do_syscall_64+0x85/0x140 ? do_syscall_64+0x85/0x140 entry_SYSCALL_64_after_hwframe+0x6e/0x76 RIP: 0033:0x7f4a1cd1a94f Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10 00 00 00 48 89 44 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00 0f 05 <41> 89 c0 3d 00 f0 ff ff 77 1f 48 8b 44 24 18 64 48 2b 04 25 28 00 RSP: 002b:00007ffd2f1df520 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007ffd2f1df5b0 RCX: 00007f4a1cd1a94f RDX: 00007ffd2f1df5b0 RSI: 00000000c01064ab RDI: 000000000000000f RBP: 00000000c01064ab R08: 000056347932deb8 R09: 000056347a7d99c0 R10: 0000000000000000 R11: 0000000000000246 R12: 000056347938a220 R13: 000000000000000f R14: 0000563479d9f3f0 R15: 0000000000000000 </TASK> Modules linked in: rfcomm xt_conntrack nft_chain_nat xt_MASQUERADE nf_nat nf_conntrack_netlink nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xfrm_user xfrm_algo xt_addrtype nft_compat nf_tables nfnetlink br_netfilter bridge stp llc ccm cmac algif_hash overlay algif_skcipher af_alg bnep binfmt_misc snd_sof_pci_intel_cnl snd_sof_intel_hda_common snd_soc_hdac_hda snd_sof_pci snd_sof_xtensa_dsp snd_sof_intel_hda snd_sof snd_sof_utils snd_soc_acpi_intel_match snd_soc_acpi snd_soc_core snd_compress snd_sof_intel_hda_mlink snd_hda_ext_core iwlmvm intel_rapl_msr intel_rapl_common intel_tcc_cooling x86_pkg_temp_thermal intel_powerclamp mac80211 coretemp kvm_intel snd_hda_codec_hdmi kvm snd_hda_codec_realtek snd_hda_codec_generic uvcvideo libarc4 snd_hda_intel snd_intel_dspcfg snd_hda_codec iwlwifi videobuf2_vmalloc videobuf2_memops uvc irqbypass btusb videobuf2_v4l2 snd_seq_midi crct10dif_pclmul hid_multitouch crc32_pclmul snd_seq_midi_event btrtl snd_hwdep videodev polyval_clmulni polyval_generic snd_rawmidi ghash_clmulni_intel aesni_intel btintel crypto_simd snd_hda_core cryptd snd_seq btbcm ee1004 8250_dw videobuf2_common btmtk rapl nls_iso8859_1 mei_hdcp thunderbolt bluetooth intel_cstate wmi_bmof intel_wmi_thunderbolt cfg80211 snd_pcm mc snd_seq_device i2c_i801 r8169 ecdh_generic snd_timer i2c_smbus ecc snd mei_me intel_lpss_pci mei ahci intel_lpss soundcore realtek libahci idma64 intel_pch_thermal i2c_hid_acpi i2c_hid acpi_pad sch_fq_codel msr parport_pc ppdev lp parport efi_pstore ip_tables x_tables autofs4 dm_crypt raid10 raid456 libcrc32c async_raid6_recov async_memcpy async_pq async_xor xor async_tx raid6_pq raid1 raid0 joydev input_leds hid_generic usbhid hid nouveau i915 drm_ttm_helper gpu_sched drm_gpuvm drm_exec i2c_algo_bit drm_buddy ttm drm_display_helper drm_kms_helper cec rc_core drm nvme nvme_core mxm_wmi xhci_pci xhci_pci_renesas video wmi pinctrl_cannonlake mac_hid ---[ end trace 0000000000000000 ]--- Fix this by avoiding the divide if bpp is 0. Fixes: c1d6a22b7219 ("drm/dp: Add helpers to calculate the link BW overhead") Cc: [email protected] Acked-by: Imre Deak <[email protected]> Signed-off-by: Chris Bainbridge <[email protected]> Signed-off-by: Imre Deak <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-03-18ALSA: hda/realtek: fix the hp playback volume issue for LG machinesHui Wang1-0/+26
Recently we tested the headphone playback on 2 LG machines, if we set the volume to the max value or near to the max value, the sound is too loud, it could even bring harm to listeners. A workaround is to decrease the max volume to a reasonable value for the headphone's amplifier, then the users couldn't set the volume bigger than that value from the userspace. Signed-off-by: Hui Wang <[email protected]> Message-ID: <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
2024-03-18Revert "drm/bridge: Select DRM_KMS_HELPER for DRM_PANEL_BRIDGE"Neil Armstrong1-1/+0
This reverts commit e3f18b0dd1db242791afbc3bd173026163ce0ccc. Selecting DRM_KMS_HELPER for DRM_PANEL_BRIDGE leads to: WARNING: unmet direct dependencies detected for DRM_KMS_HELPER Depends on [m]: HAS_IOMEM [=y] && DRM [=m] ... and builds with CONFIG_DRM=m will fail with the above kconfig warns and then multiple linker error. Reported-by: Imre Deak <[email protected]> Reported-by: Jani Nikula <[email protected]> Reported-by: Ville Syrjälä <[email protected]> Fixes: e3f18b0dd1db ("drm/bridge: Select DRM_KMS_HELPER for DRM_PANEL_BRIDGE") Acked-by: Lucas De Marchi <[email protected]> Acked-by: Jani Nikula <[email protected]> Tested-by: Jani Nikula <[email protected]> Link: https://lore.kernel.org/r/20240318-revert-select-drm_kms_helper-for-drm_panel_bridge-v1-1-52a42a116286@linaro.org Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20240318-revert-select-drm_kms_helper-for-drm_panel_bridge-v1-1-52a42a116286@linaro.org
2024-03-18ASoC: soc-compress: Fix and add DPCM lockingShalini Manjunatha1-0/+4
We find mising DPCM locking inside soc_compr_set_params_fe before calling dpcm_be_dai_hw_params() and dpcm_be_dai_prepare() which cause lockdep assert for DPCM lock not held in __soc_pcm_hw_params() and __soc_pcm_prepare() Signed-off-by: Shalini Manjunatha <[email protected]> Link: https://msgid.link/r/d985beeafdd32316eb45f20811eb7926da7a796e.1709720380.git.quic_c_shalma@quicinc.com Signed-off-by: Mark Brown <[email protected]>
2024-03-18tracing: Add __string_src() helper to help compilers not to get confusedSteven Rostedt (Google)1-2/+12
The __string() helper macro of the TRACE_EVENT() macro is used to determine how much of the ring buffer needs to be allocated to fit the given source string. Some trace events have a string that is dependent on another variable that could be NULL, and in those cases the string is passed in to be NULL. The __string() macro can handle being passed in a NULL pointer for which it will turn it into "(null)". It does that with: strlen((src) ? (const char *)(src) : "(null)") + 1 But if src itself has the same conditional type it can confuse the compiler. That is: __string(r ? dev(r)->name : NULL) Would turn into: strlen((r ? dev(r)->name : NULL) ? (r ? dev(r)->name : NULL) : "(null)" + 1 For which the compiler thinks that NULL is being passed to strlen() and gives this kind of warning: ./include/trace/stages/stage5_get_offsets.h:50:21: warning: argument 1 null where non-null expected [-Wnonnull] 50 | strlen((src) ? (const char *)(src) : "(null)") + 1) Instead, create a static inline function that takes the src string and will return the string if it is not NULL and will return "(null)" if it is. This will then make the strlen() line: strlen(__string_src(src)) + 1 Where the compiler can see that strlen() will not end up with NULL and does not warn about it. Note that this depends on commit 51270d573a8d ("tracing/net_sched: Fix tracepoints that save qdisc_dev() as a string") being applied, as passing the qdisc_dev() into __string_src() will give an error. Link: https://lore.kernel.org/all/ZfNmfCmgCs4Nc+EH@aschofie-mobl2/ Link: https://lore.kernel.org/linux-trace-kernel/[email protected] Cc: Masami Hiramatsu <[email protected]> Cc: Mathieu Desnoyers <[email protected]> Reported-by: Alison Schofield <[email protected]> Signed-off-by: Steven Rostedt (Google) <[email protected]>
2024-03-18tracing: Use strcmp() in __assign_str() WARN_ON() checkSteven Rostedt (Google)1-1/+3
The WARN_ON() check in __assign_str() to catch where the source variable to the macro doesn't match the source variable to __string() gives an error in clang: >> include/trace/events/sunrpc.h:703:4: warning: result of comparison against a string literal is unspecified (use an explicit string comparison function instead) [-Wstring-compare] 670 | __assign_str(progname, "unknown"); That's because the __assign_str() macro has: WARN_ON_ONCE((src) != __data_offsets.dst##_ptr_); Where "src" is a string literal. Clang warns when comparing a string literal directly as it is undefined to what the value of the literal is. Since this is still to make sure the same string that goes to __string() is the same as __assign_str(), for string literals do a test for that and then use strcmp() in those cases Note that this depends on commit 51270d573a8d ("tracing/net_sched: Fix tracepoints that save qdisc_dev() as a string") being applied, as this was what found that bug. Link: https://lore.kernel.org/linux-trace-kernel/[email protected] Cc: Masami Hiramatsu <[email protected]> Cc: Mathieu Desnoyers <[email protected]> Cc: Nathan Chancellor <[email protected]> Reported-by: kernel test robot <[email protected]> Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/ Fixes: 433e1d88a3be ("tracing: Add warning if string in __assign_str() does not match __string()") Signed-off-by: Steven Rostedt (Google) <[email protected]>
2024-03-18tracepoints: Use WARN() and not WARN_ON() for warningsSteven Rostedt (Google)1-2/+4
There are two WARN_ON*() warnings in tracepoint.h that deal with RCU usage. But when they trigger, especially from using a TRACE_EVENT() macro, the information is not very helpful and is confusing: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 0 at include/trace/events/lock.h:24 lock_acquire+0x2b2/0x2d0 Where the above warning takes you to: TRACE_EVENT(lock_acquire, <<<--- line 24 in lock.h TP_PROTO(struct lockdep_map *lock, unsigned int subclass, int trylock, int read, int check, struct lockdep_map *next_lock, unsigned long ip), [..] Change the WARN_ON_ONCE() to WARN_ONCE() and add a string that allows someone to search for exactly where the bug happened. Link: https://lore.kernel.org/linux-trace-kernel/[email protected] Cc: Masami Hiramatsu <[email protected]> Cc: Mathieu Desnoyers <[email protected]> Cc: Thomas Gleixner <[email protected]> Reported-by: Borislav Petkov <[email protected]> Tested-by: Borislav Petkov (AMD) <[email protected]> Reviewed-by: Paul E. McKenney <[email protected]> Signed-off-by: Steven Rostedt (Google) <[email protected]>
2024-03-18tracing: Use div64_u64() instead of do_div()Thorsten Blum1-3/+2
Fixes Coccinelle/coccicheck warnings reported by do_div.cocci. Compared to do_div(), div64_u64() does not implicitly cast the divisor and does not unnecessarily calculate the remainder. Link: https://lore.kernel.org/linux-trace-kernel/[email protected] Cc: Mathieu Desnoyers <[email protected]> Signed-off-by: Thorsten Blum <[email protected]> Acked-by: Masami Hiramatsu (Google) <[email protected]> Signed-off-by: Steven Rostedt (Google) <[email protected]>
2024-03-18tracing: Support to dump instance traces by ftrace_dump_on_oopsHuang Yiwei7-55/+168
Currently ftrace only dumps the global trace buffer on an OOPs. For debugging a production usecase, instance trace will be helpful to check specific problems since global trace buffer may be used for other purposes. This patch extend the ftrace_dump_on_oops parameter to dump a specific or multiple trace instances: - ftrace_dump_on_oops=0: as before -- don't dump - ftrace_dump_on_oops[=1]: as before -- dump the global trace buffer on all CPUs - ftrace_dump_on_oops=2 or =orig_cpu: as before -- dump the global trace buffer on CPU that triggered the oops - ftrace_dump_on_oops=<instance_name>: new behavior -- dump the tracing instance matching <instance_name> - ftrace_dump_on_oops[=2/orig_cpu],<instance1_name>[=2/orig_cpu], <instrance2_name>[=2/orig_cpu]: new behavior -- dump the global trace buffer and multiple instance buffer on all CPUs, or only dump on CPU that triggered the oops if =2 or =orig_cpu is given Also, the sysctl node can handle the input accordingly. Link: https://lore.kernel.org/linux-trace-kernel/[email protected] Cc: Ross Zwisler <[email protected]> Cc: <[email protected]> Cc: <[email protected]> Cc: <[email protected]> Cc: <[email protected]> Cc: <[email protected]> Cc: <[email protected]> Cc: <[email protected]> Signed-off-by: Huang Yiwei <[email protected]> Signed-off-by: Steven Rostedt (Google) <[email protected]>
2024-03-18tracing: Remove second parameter to __assign_rel_str()Steven Rostedt (Google)2-2/+2
The second parameter of __assign_rel_str() is no longer used. It can be removed. Note, the only real users of rel_string is user events. This code is just in the sample code for testing purposes. This makes __assign_rel_str() different than __assign_str() but that's fine. __assign_str() is used over 700 places and has a larger impact. That change will come later. Link: https://lore.kernel.org/linux-trace-kernel/[email protected] Cc: Mathieu Desnoyers <[email protected]> Reviewed-by: Masami Hiramatsu (Google) <[email protected]> Signed-off-by: Steven Rostedt (Google) <[email protected]>
2024-03-18tracing: Add warning if string in __assign_str() does not match __string()Steven Rostedt (Google)1-0/+1
In preparation to remove the second parameter of __assign_str(), make sure it is really a duplicate of __string() by adding a WARN_ON_ONCE(). Link: https://lore.kernel.org/linux-trace-kernel/[email protected] Cc: Mathieu Desnoyers <[email protected]> Reviewed-by: Masami Hiramatsu (Google) <[email protected]> Signed-off-by: Steven Rostedt (Google) <[email protected]>
2024-03-18tracing: Add __string_len() exampleSteven Rostedt (Google)1-2/+5
There's no example code that uses __string_len(), and since the sample code is used for testing the event logic, add a use case. Link: https://lore.kernel.org/linux-trace-kernel/[email protected] Cc: Masami Hiramatsu <[email protected]> Cc: Mathieu Desnoyers <[email protected]> Signed-off-by: Steven Rostedt (Google) <[email protected]>
2024-03-18tracing: Remove __assign_str_len()Steven Rostedt (Google)3-25/+20
Now that __assign_str() gets the length from the __string() (and __string_len()) macros, there's no reason to have a separate __assign_str_len() macro as __assign_str() can get the length of the string needed. Also remove __assign_rel_str() although it had no users anyway. Link: https://lore.kernel.org/linux-trace-kernel/[email protected] Cc: Jeff Layton <[email protected]> Acked-by: Chuck Lever <[email protected]> Signed-off-by: Steven Rostedt (Google) <[email protected]>
2024-03-18ftrace: Fix most kernel-doc warningsRandy Dunlap1-44/+46
Reduce the number of kernel-doc warnings from 52 down to 10, i.e., fix 42 kernel-doc warnings by (a) using the Returns: format for function return values or (b) using "@var:" instead of "@var -" for function parameter descriptions. Fix one return values list so that it is formatted correctly when rendered for output. Spell "non-zero" with a hyphen in several places. Link: https://lore.kernel.org/linux-trace-kernel/[email protected] Cc: Mathieu Desnoyers <[email protected]> Cc: Mark Rutland <[email protected]> Link: https://lore.kernel.org/oe-kbuild-all/[email protected]/ Reported-by: kernel test robot <[email protected]> Acked-by: Masami Hiramatsu (Google) <[email protected]> Signed-off-by: Randy Dunlap <[email protected]> Signed-off-by: Steven Rostedt (Google) <[email protected]>
2024-03-18tracing: Decrement the snapshot if the snapshot trigger fails to registerSteven Rostedt (Google)1-1/+4
Running the ftrace selftests caused the ring buffer mapping test to fail. Investigating, I found that the snapshot counter would be incremented every time a snapshot trigger was added, even if that snapshot trigger failed. # cd /sys/kernel/tracing # echo "snapshot" > events/sched/sched_process_fork/trigger # echo "snapshot" > events/sched/sched_process_fork/trigger -bash: echo: write error: File exists That second one that fails increments the snapshot counter but doesn't decrement it. It needs to be decremented when the snapshot fails. Link: https://lore.kernel.org/linux-trace-kernel/[email protected] Cc: Masami Hiramatsu <[email protected]> Cc: Mark Rutland <[email protected]> Cc: Mathieu Desnoyers <[email protected]> Cc: Andrew Morton <[email protected]> Cc: Vincent Donnefort <[email protected]> Fixes: 16f7e48ffc53a ("tracing: Add snapshot refcount") Signed-off-by: Steven Rostedt (Google) <[email protected]>
2024-03-18tracing: Fix snapshot counter going between two tracers that use itSteven Rostedt (Google)1-1/+1
Running the ftrace selftests caused the ring buffer mapping test to fail. Investigating, I found that the snapshot counter would be incremented every time a tracer that uses the snapshot is enabled even if the snapshot was used by the previous tracer. That is: # cd /sys/kernel/tracing # echo wakeup_rt > current_tracer # echo wakeup_dl > current_tracer # echo nop > current_tracer would leave the snapshot counter at 1 and not zero. That's because the enabling of wakeup_dl would increment the counter again but the setting the tracer to nop would only decrement it once. Do not arm the snapshot for a tracer if the previous tracer already had it armed. Link: https://lore.kernel.org/linux-trace-kernel/[email protected] Cc: Masami Hiramatsu <[email protected]> Cc: Mark Rutland <[email protected]> Cc: Mathieu Desnoyers <[email protected]> Cc: Andrew Morton <[email protected]> Cc: Vincent Donnefort <[email protected]> Fixes: 16f7e48ffc53a ("tracing: Add snapshot refcount") Signed-off-by: Steven Rostedt (Google) <[email protected]>
2024-03-18tracing: Use EVENT_NULL_STR macro instead of open coding "(null)"Steven Rostedt (Google)4-12/+15
The TRACE_EVENT macros has some dependency if a __string() field is NULL, where it will save "(null)" as the string. This string is also used by __assign_str(). It's better to create a single macro instead of having something that will not be caught by the compiler if there is an unfortunate typo. Link: https://lore.kernel.org/linux-trace-kernel/[email protected] Cc: Masami Hiramatsu <[email protected]> Cc: Mark Rutland <[email protected]> Cc: Andrew Morton <[email protected]> Cc: Ville Syrjälä <[email protected]> Cc: Rodrigo Vivi <[email protected]> Cc: Chuck Lever <[email protected]> Suggested-by: Mathieu Desnoyers <[email protected]> Signed-off-by: Steven Rostedt (Google) <[email protected]>
2024-03-18tracing: Use ? : shortcut in trace macrosSteven Rostedt (Google)2-10/+8
Instead of having: #define __assign_str(dst, src) \ memcpy(__get_str(dst), __data_offsets.dst##_ptr_ ? \ __data_offsets.dst##_ptr_ : "(null)", \ __get_dynamic_array_len(dst)) Use the ? : shortcut and compact it down to: #define __assign_str(dst, src) \ memcpy(__get_str(dst), __data_offsets.dst##_ptr_ ? : "(null)", \ __get_dynamic_array_len(dst)) Link: https://lore.kernel.org/linux-trace-kernel/[email protected] Cc: Masami Hiramatsu <[email protected]> Cc: Mark Rutland <[email protected]> Cc: Andrew Morton <[email protected]> Cc: Ville Syrjälä <[email protected]> Cc: Rodrigo Vivi <[email protected]> Cc: Chuck Lever <[email protected]> Suggested-by: Mathieu Desnoyers <[email protected]> Signed-off-by: Steven Rostedt (Google) <[email protected]>
2024-03-18tracing: Do not calculate strlen() twice for __string() fieldsSteven Rostedt (Google)1-4/+6
The TRACE_EVENT() macro handles dynamic strings by having: TP_PROTO(struct some_struct *s), TP_ARGS(s), TP_STRUCT__entry( __string(my_string, s->string) ), TP_fast_assign( __assign_str(my_string, s->string); ) TP_printk("%s", __get_str(my_string)) There's even some code that may call a function helper to find the s->string value. The problem with the above is that the work to get the s->string is done twice. Once at the __string() and again in the __assign_str(). The length of the string is calculated via a strlen(), not once, but twice. Once during the __string() macro and again in __assign_str(). But the length is actually already recorded in the data location and here's no reason to call strlen() again. Just use the saved length that was saved in the __string() code for the __assign_str() code. Link: https://lore.kernel.org/linux-trace-kernel/[email protected] Cc: Masami Hiramatsu <[email protected]> Cc: Mark Rutland <[email protected]> Cc: Mathieu Desnoyers <[email protected]> Cc: Andrew Morton <[email protected]> Cc: Ville Syrjälä <[email protected]> Cc: Rodrigo Vivi <[email protected]> Cc: Chuck Lever <[email protected]> Signed-off-by: Steven Rostedt (Google) <[email protected]>
2024-03-18tracing: Rework __assign_str() and __string() to not duplicate getting the ↵Steven Rostedt (Google)3-11/+20
string The TRACE_EVENT() macro handles dynamic strings by having: TP_PROTO(struct some_struct *s), TP_ARGS(s), TP_STRUCT__entry( __string(my_string, s->string) ), TP_fast_assign( __assign_str(my_string, s->string); ) TP_printk("%s", __get_str(my_string)) There's even some code that may call a function helper to find the s->string value. The problem with the above is that the work to get the s->string is done twice. Once at the __string() and again in the __assign_str(). But the __string() uses dynamic_array() which has a helper structure that is created holding the offsets and length of the string fields. Instead of finding the string twice, just save it off in another field from that helper structure, and have __assign_str() use that instead. Note, this also means that the second parameter of __assign_str() isn't even used anymore, and may be removed in the future. Link: https://lore.kernel.org/linux-trace-kernel/[email protected] Cc: Masami Hiramatsu <[email protected]> Cc: Mark Rutland <[email protected]> Cc: Mathieu Desnoyers <[email protected]> Cc: Andrew Morton <[email protected]> Cc: Ville Syrjälä <[email protected]> Cc: Rodrigo Vivi <[email protected]> Cc: Chuck Lever <[email protected]> Signed-off-by: Steven Rostedt (Google) <[email protected]>
2024-03-18cxl/trace: Properly initialize cxl_poison region nameAlison Schofield1-7/+7
The TP_STRUCT__entry that gets assigned the region name, or an empty string if no region is present, is erroneously initialized to the cxl_region pointer. It needs to be properly initialized otherwise it's length is wrong and garbage chars can appear in the kernel trace output: /sys/kernel/tracing/trace The bad initialization was due in part to a naming conflict with the parameter: struct cxl_region *region. The field 'region' is already exposed externally as the region name, so changing that to something logical, like 'region_name' is not an option. Instead rename the internal only struct cxl_region to the commonly used 'cxlr'. Impact is that tooling depending on that trace data can miss picking up a valid event when searching by region name. The TP_printk() output, if enabled, does emit the correct region names in the dmesg log. This was found during testing of the cxl-list option to report media-errors for a region. Cc: Davidlohr Bueso <[email protected]> Cc: Jonathan Cameron <[email protected]> Cc: Dave Jiang <[email protected]> Cc: Vishal Verma <[email protected]> Cc: [email protected] Fixes: ddf49d57b841 ("cxl/trace: Add TRACE support for CXL media-error records") Signed-off-by: Alison Schofield <[email protected]> Reviewed-by: Ira Weiny <[email protected]> Acked-by: Dan Williams <[email protected]> Signed-off-by: Steven Rostedt (Google) <[email protected]>
2024-03-18net: hns3: tracing: fix hclgevf trace event stringsSteven Rostedt (Google)2-8/+8
The __string() and __assign_str() helper macros of the TRACE_EVENT() macro are going through some optimizations where only the source string of __string() will be used and the __assign_str() source will be ignored and later removed. To make sure that there's no issues, a new check is added between the __string() src argument and the __assign_str() src argument that does a strcmp() to make sure they are the same string. The hclgevf trace events have: __assign_str(devname, &hdev->nic.kinfo.netdev->name); Which triggers the warning: hclgevf_trace.h:34:39: error: passing argument 1 of ‘strcmp’ from incompatible pointer type [-Werror=incompatible-pointer-types] 34 | __assign_str(devname, &hdev->nic.kinfo.netdev->name); [..] arch/x86/include/asm/string_64.h:75:24: note: expected ‘const char *’ but argument is of type ‘char (*)[16]’ 75 | int strcmp(const char *cs, const char *ct); | ~~~~~~~~~~~~^~ Because __assign_str() now has: WARN_ON_ONCE(__builtin_constant_p(src) ? \ strcmp((src), __data_offsets.dst##_ptr_) : \ (src) != __data_offsets.dst##_ptr_); \ The problem is the '&' on hdev->nic.kinfo.netdev->name. That's because that name is: char name[IFNAMSIZ] Where passing an address '&' of a char array is not compatible with strcmp(). The '&' is not necessary, remove it. Link: https://lore.kernel.org/linux-trace-kernel/[email protected] Cc: netdev <[email protected]> Cc: Yisen Zhuang <[email protected]> Cc: Salil Mehta <[email protected]> Cc: "David S. Miller" <[email protected]> Cc: Eric Dumazet <[email protected]> Cc: Jakub Kicinski <[email protected]> Cc: Yufeng Mo <[email protected]> Cc: Huazhong Tan <[email protected]> Cc: [email protected] Acked-by: Paolo Abeni <[email protected]> Reviewed-by: Jijie Shao <[email protected]> Fixes: d8355240cf8fb ("net: hns3: add trace event support for PF/VF mailbox") Signed-off-by: Steven Rostedt (Google) <[email protected]>
2024-03-18drm/i915: Add missing ; to __assign_str() macros in tracepoint codeSteven Rostedt (Google)1-3/+3
I'm working on improving the __assign_str() and __string() macros to be more efficient, and removed some unneeded semicolons. This triggered a bug in the build as some of the __assign_str() macros in intel_display_trace was missing a terminating semicolon. Link: https://lore.kernel.org/linux-trace-kernel/[email protected] Cc: Daniel Vetter <[email protected]> Cc: David Airlie <[email protected]> Cc: [email protected] Fixes: 2ceea5d88048b ("drm/i915: Print plane name in fbc tracepoints") Reviewed-by: Ville Syrjälä <[email protected]> Acked-by: Rodrigo Vivi <[email protected]> Signed-off-by: Steven Rostedt (Google) <[email protected]>
2024-03-18NFSD: Fix nfsd_clid_class use of __string_len() macroSteven Rostedt (Google)1-1/+1
I'm working on restructuring the __string* macros so that it doesn't need to recalculate the string twice. That is, it will save it off when processing __string() and the __assign_str() will not need to do the work again as it currently does. Currently __string_len(item, src, len) doesn't actually use "src", but my changes will require src to be correct as that is where the __assign_str() will get its value from. The event class nfsd_clid_class has: __string_len(name, name, clp->cl_name.len) But the second "name" does not exist and causes my changes to fail to build. That second parameter should be: clp->cl_name.data. Link: https://lore.kernel.org/linux-trace-kernel/[email protected] Cc: Neil Brown <[email protected]> Cc: Olga Kornievskaia <[email protected]> Cc: Dai Ngo <[email protected]> Cc: Tom Talpey <[email protected]> Cc: [email protected] Fixes: d27b74a8675ca ("NFSD: Use new __string_len C macros for nfsd_clid_class") Acked-by: Chuck Lever <[email protected]> Acked-by: Jeff Layton <[email protected]> Signed-off-by: Steven Rostedt (Google) <[email protected]>
2024-03-18tracing: Use init_utsname()->releaseJohn Garry1-2/+2
Instead of using UTS_RELEASE, use init_utsname()->release, which means that we don't need to rebuild the code just for the git head commit changing. Link: https://lore.kernel.org/linux-trace-kernel/[email protected] Signed-off-by: John Garry <[email protected]> Signed-off-by: Steven Rostedt (Google) <[email protected]>
2024-03-18tracing/user_events: Document multi-format flagBeau Belgrave1-1/+26
User programs can now ask user_events to handle the synchronization of multiple different formats for an event with the same name via the new USER_EVENT_REG_MULTI_FORMAT flag. Add a section for USER_EVENT_REG_MULTI_FORMAT that explains the intended purpose and caveats of using it. Explain how deletion works in these cases and how to use /sys/kernel/tracing/dynamic_events for per-version deletion. Link: https://lore.kernel.org/linux-trace-kernel/[email protected] Signed-off-by: Beau Belgrave <[email protected]> Signed-off-by: Steven Rostedt (Google) <[email protected]>
2024-03-18selftests/user_events: Test multi-format eventsBeau Belgrave1-0/+134
User_events now has multi-format events which allow for the same register name, but with different formats. When this occurs, different tracepoints are created with unique names. Add a new test that ensures the same name can be used for two different formats. Ensure they are isolated from each other and that name and arg matching still works if yet another register comes in with the same format as one of the two. Link: https://lore.kernel.org/linux-trace-kernel/[email protected] Signed-off-by: Beau Belgrave <[email protected]> Signed-off-by: Steven Rostedt (Google) <[email protected]>
2024-03-18tracing/user_events: Introduce multi-format eventsBeau Belgrave2-13/+95
Currently user_events supports 1 event with the same name and must have the exact same format when referenced by multiple programs. This opens an opportunity for malicious or poorly thought through programs to create events that others use with different formats. Another scenario is user programs wishing to use the same event name but add more fields later when the software updates. Various versions of a program may be running side-by-side, which is prevented by the current single format requirement. Add a new register flag (USER_EVENT_REG_MULTI_FORMAT) which indicates the user program wishes to use the same user_event name, but may have several different formats of the event. When this flag is used, create the underlying tracepoint backing the user_event with a unique name per-version of the format. It's important that existing ABI users do not get this logic automatically, even if one of the multi format events matches the format. This ensures existing programs that create events and assume the tracepoint name will match exactly continue to work as expected. Add logic to only check multi-format events with other multi-format events and single-format events to only check single-format events during find. Change system name of the multi-format event tracepoint to ensure that multi-format events are isolated completely from single-format events. This prevents single-format names from conflicting with multi-format events if they end with the same suffix as the multi-format events. Add a register_name (reg_name) to the user_event struct which allows for split naming of events. We now have the name that was used to register within user_events as well as the unique name for the tracepoint. Upon registering events ensure matches based on first the reg_name, followed by the fields and format of the event. This allows for multiple events with the same registered name to have different formats. The underlying tracepoint will have a unique name in the format of {reg_name}.{unique_id}. For example, if both "test u32 value" and "test u64 value" are used with the USER_EVENT_REG_MULTI_FORMAT the system would have 2 unique tracepoints. The dynamic_events file would then show the following: u:test u64 count u:test u32 count The actual tracepoint names look like this: test.0 test.1 Both would be under the new user_events_multi system name to prevent the older ABI from being used to squat on multi-formatted events and block their use. Deleting events via "!u:test u64 count" would only delete the first tracepoint that matched that format. When the delete ABI is used all events with the same name will be attempted to be deleted. If per-version deletion is required, user programs should either not use persistent events or delete them via dynamic_events. Link: https://lore.kernel.org/linux-trace-kernel/[email protected] Signed-off-by: Beau Belgrave <[email protected]> Signed-off-by: Steven Rostedt (Google) <[email protected]>
2024-03-18tracing/user_events: Prepare find/delete for same name eventsBeau Belgrave1-48/+59
The current code for finding and deleting events assumes that there will never be cases when user_events are registered with the same name, but different formats. Scenarios exist where programs want to use the same name but have different formats. An example is multiple versions of a program running side-by-side using the same event name, but with updated formats in each version. This change does not yet allow for multi-format events. If user_events are registered with the same name but different arguments the programs see the same return values as before. This change simply makes it possible to easily accommodate for this. Update find_user_event() to take in argument parameters and register flags to accommodate future multi-format event scenarios. Have find validate argument matching and return error pointers to cover when an existing event has the same name but different format. Update callers to handle error pointer logic. Move delete_user_event() to use hash walking directly now that find_user_event() has changed. Delete all events found that match the register name, stop if an error occurs and report back to the user. Update user_fields_match() to cover list_empty() scenarios now that find_user_event() uses it directly. This makes the logic consistent across several callsites. Link: https://lore.kernel.org/linux-trace-kernel/[email protected] Signed-off-by: Beau Belgrave <[email protected]> Signed-off-by: Steven Rostedt (Google) <[email protected]>
2024-03-18tracing: Add snapshot refcountVincent Donnefort3-36/+129
When a ring-buffer is memory mapped by user-space, no trace or ring-buffer swap is possible. This means the snapshot feature is mutually exclusive with the memory mapping. Having a refcount on snapshot users will help to know if a mapping is possible or not. Instead of relying on the global trace_types_lock, a new spinlock is introduced to serialize accesses to trace_array->snapshot. This intends to allow access to that variable in a context where the mmap lock is already held. Link: https://lore.kernel.org/linux-trace-kernel/[email protected] Signed-off-by: Vincent Donnefort <[email protected]> Signed-off-by: Steven Rostedt (Google) <[email protected]>
2024-03-18ring-buffer: Make wake once of ring_buffer_wait() more robustSteven Rostedt (Google)1-13/+21
The default behavior of ring_buffer_wait() when passed a NULL "cond" parameter is to exit the function the first time it is woken up. The current implementation uses a counter that starts at zero and when it is greater than one it exits the wait_event_interruptible(). But this relies on the internal working of wait_event_interruptible() as that code basically has: if (cond) return; prepare_to_wait(); if (!cond) schedule(); finish_wait(); That is, cond is called twice before it sleeps. The default cond of ring_buffer_wait() needs to account for that and wait for its counter to increment twice before exiting. Instead, use the seq/atomic_inc logic that is used by the tracing code that calls this function. Add an atomic_t seq to rb_irq_work and when cond is NULL, have the default callback take a descriptor as its data that holds the rbwork and the value of the seq when it started. The wakeups will now increment the rbwork->seq and the cond callback will simply check if that number is different, and no longer have to rely on the implementation of wait_event_interruptible(). Link: https://lore.kernel.org/linux-trace-kernel/[email protected] Cc: Masami Hiramatsu <[email protected]> Cc: Mathieu Desnoyers <[email protected]> Fixes: 7af9ded0c2ca ("ring-buffer: Use wait_event_interruptible() in ring_buffer_wait()") Signed-off-by: Steven Rostedt (Google) <[email protected]>
2024-03-18Revert "net: Re-use and set mono_delivery_time bit for userspace tstamp packets"Abhishek Chauhan6-10/+6
This reverts commit 885c36e59f46375c138de18ff1692f18eff67b7f. The patch currently broke the bpf selftest test_tc_dtime because uapi field __sk_buff->tstamp_type depends on skb->mono_delivery_time which does not necessarily mean mono with the original fix as the bit was re-used for userspace timestamp as well to avoid tstamp reset in the forwarding path. To solve this we need to keep mono_delivery_time as is and introduce another bit called user_delivery_time and fall back to the initial proposal of setting the user_delivery_time bit based on sk_clockid set from userspace. Fixes: 885c36e59f46 ("net: Re-use and set mono_delivery_time bit for userspace tstamp packets") Link: https://lore.kernel.org/netdev/[email protected]/ Signed-off-by: Abhishek Chauhan <[email protected]> Acked-by: Daniel Borkmann <[email protected]> Acked-by: Martin KaFai Lau <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-03-18net: dsa: mt7530: prevent possible incorrect XTAL frequency selectionArınç ÜNAL1-10/+4
On MT7530, the HT_XTAL_FSEL field of the HWTRAP register stores a 2-bit value that represents the frequency of the crystal oscillator connected to the switch IC. The field is populated by the state of the ESW_P4_LED_0 and ESW_P4_LED_0 pins, which is done right after reset is deasserted. ESW_P4_LED_0 ESW_P3_LED_0 Frequency ----------------------------------------- 0 0 Reserved 0 1 20MHz 1 0 40MHz 1 1 25MHz On MT7531, the XTAL25 bit of the STRAP register stores this. The LAN0LED0 pin is used to populate the bit. 25MHz when the pin is high, 40MHz when it's low. These pins are also used with LEDs, therefore, their state can be set to something other than the bootstrapping configuration. For example, a link may be established on port 3 before the DSA subdriver takes control of the switch which would set ESW_P3_LED_0 to high. Currently on mt7530_setup() and mt7531_setup(), 1000 - 1100 usec delay is described between reset assertion and deassertion. Some switch ICs in real life conditions cannot always have these pins set back to the bootstrapping configuration before reset deassertion in this amount of delay. This causes wrong crystal frequency to be selected which puts the switch in a nonfunctional state after reset deassertion. The tests below are conducted on an MT7530 with a 40MHz crystal oscillator by Justin Swartz. With a cable from an active peer connected to port 3 before reset, an incorrect crystal frequency (0b11 = 25MHz) is selected: [1] [3] [5] : : : _____________________________ __________________ ESW_P4_LED_0 |_______| _____________________________ ESW_P3_LED_0 |__________________________ : : : : : : [4]...: : : [2]................: [1] Reset is asserted. [2] Period of 1000 - 1100 usec. [3] Reset is deasserted. [4] Period of 315 usec. HWTRAP register is populated with incorrect XTAL frequency. [5] Signals reflect the bootstrapped configuration. Increase the delay between reset_control_assert() and reset_control_deassert(), and gpiod_set_value_cansleep(priv->reset, 0) and gpiod_set_value_cansleep(priv->reset, 1) to 5000 - 5100 usec. This amount ensures a higher possibility that the switch IC will have these pins back to the bootstrapping configuration before reset deassertion. With a cable from an active peer connected to port 3 before reset, the correct crystal frequency (0b10 = 40MHz) is selected: [1] [2-1] [3] [5] : : : : _____________________________ __________________ ESW_P4_LED_0 |_______| ___________________ _______ ESW_P3_LED_0 |_________| |__________________ : : : : : : [2-2]...: [4]...: [2]................: [1] Reset is asserted. [2] Period of 5000 - 5100 usec. [2-1] ESW_P3_LED_0 goes low. [2-2] Remaining period of 5000 - 5100 usec. [3] Reset is deasserted. [4] Period of 310 usec. HWTRAP register is populated with bootstrapped XTAL frequency. [5] Signals reflect the bootstrapped configuration. ESW_P3_LED_0 low period before reset deassertion: 5000 usec - 5100 usec TEST RESET HOLD # (usec) --------------------- 1 5410 2 5440 3 4375 4 5490 5 5475 6 4335 7 4370 8 5435 9 4205 10 4335 11 3750 12 3170 13 4395 14 4375 15 3515 16 4335 17 4220 18 4175 19 4175 20 4350 Min 3170 Max 5490 Median 4342.500 Avg 4466.500 Revert commit 2920dd92b980 ("net: dsa: mt7530: disable LEDs before reset"). Changing the state of pins via reset assertion is simpler and more efficient than doing so by setting the LED controller off. Fixes: b8f126a8d543 ("net-next: dsa: add dsa support for Mediatek MT7530 switch") Fixes: c288575f7810 ("net: dsa: mt7530: Add the support of MT7531 switch") Co-developed-by: Justin Swartz <[email protected]> Signed-off-by: Justin Swartz <[email protected]> Signed-off-by: Arınç ÜNAL <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-03-18Merge branch 'veth-xdp-gro'David S. Miller3-21/+25
Ignat Korchagin says: ==================== net: veth: ability to toggle GRO and XDP independently It is rather confusing that GRO is automatically enabled, when an XDP program is attached to a veth interface. Moreover, it is not possible to disable GRO on a veth, if an XDP program is attached (which might be desirable in some use cases). Make GRO and XDP independent for a veth interface. ==================== Signed-off-by: David S. Miller <[email protected]>
2024-03-18selftests: net: veth: test the ability to independently manipulate GRO and XDPIgnat Korchagin2-3/+25
We should be able to independently flip either XDP or GRO states and toggling one should not affect the other. Adjust other tests as well that had implicit expectation that GRO would be automatically enabled. Signed-off-by: Ignat Korchagin <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-03-18net: veth: do not manipulate GRO when using XDPIgnat Korchagin1-18/+0
Commit d3256efd8e8b ("veth: allow enabling NAPI even without XDP") tried to fix the fact that GRO was not possible without XDP, because veth did not use NAPI without XDP. However, it also introduced the behaviour that GRO is always enabled, when XDP is enabled. While it might be desired for most cases, it is confusing for the user at best as the GRO flag suddenly changes, when an XDP program is attached. It also introduces some complexities in state management as was partially addressed in commit fe9f801355f0 ("net: veth: clear GRO when clearing XDP even when down"). But the biggest problem is that it is not possible to disable GRO at all, when an XDP program is attached, which might be needed for some use cases. Fix this by not touching the GRO flag on XDP enable/disable as the code already supports switching to NAPI if either GRO or XDP is requested. Link: https://lore.kernel.org/lkml/[email protected]/ Fixes: d3256efd8e8b ("veth: allow enabling NAPI even without XDP") Fixes: fe9f801355f0 ("net: veth: clear GRO when clearing XDP even when down") Signed-off-by: Ignat Korchagin <[email protected]> Reviewed-by: Toke Høiland-Jørgensen <[email protected]> Signed-off-by: David S. Miller <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.