v6.9-scx1-rc7 #23
Merged
v6.9-scx1-rc7 #23
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…m/kernel Pull drm fixes from Dave Airlie: "Regular weekly merge request, mostly amdgpu and misc bits in xe/etnaviv/gma500 and some core changes. Nothing too outlandish, seems to be about normal for this time of release. atomic-helpers: - Fix memory leak in drm_format_conv_state_copy() fbdev: - fbdefio: Fix address calculation amdgpu: - Suspend/resume fix - Don't expose gpu_od directory if it's empty - SDMA 4.4.2 fix - VPE fix - BO eviction fix - UMSCH fix - SMU 13.0.6 reset fixes - GPUVM flush accounting fix - SDMA 5.2 fix - Fix possible UAF in mes code amdkfd: - Eviction fence handling fix - Fix memory leak when GPU memory allocation fails - Fix dma-buf validation - Fix rescheduling of restore worker - SVM fix gma500: - Fix crash during boot etnaviv: - fix GC7000 TX clock gating - revert NPU UAPI changes xe: - Fix error paths on managed allocations - Fix PF/VF relay messages" * tag 'drm-fixes-2024-04-26' of https://gitlab.freedesktop.org/drm/kernel: (23 commits) Revert "drm/etnaviv: Expose a few more chipspecs to userspace" drm/etnaviv: fix tx clock gating on some GC7000 variants drm/xe/guc: Fix arguments passed to relay G2H handlers drm/xe: call free_gsc_pkt only once on action add failure drm/xe: Remove sysfs only once on action add failure fbdev: fix incorrect address computation in deferred IO drm/amdgpu/mes: fix use-after-free issue drm/amdgpu/sdma5.2: use legacy HDP flush for SDMA2/3 drm/amdgpu: Fix the ring buffer size for queue VM flush drm/amdkfd: Add VRAM accounting for SVM migration drm/amd/pm: Restore config space after reset drm/amdgpu/umsch: don't execute umsch test when GPU is in reset/suspend drm/amdkfd: Fix rescheduling of restore worker drm/amdgpu: Update BO eviction priorities drm/amdgpu/vpe: fix vpe dpm setup failed drm/amdgpu: Assign correct bits for SDMA HDP flush drm/amdgpu/pm: Remove gpu_od if it's an empty directory drm/amdkfd: make sure VM is ready for updating operations drm/amdgpu: Fix leak when GPU memory allocation fails drm/amdkfd: Fix eviction fence handling ...
…ux/kernel/git/ukleinek/linux Pull maintainer entry update from Uwe Kleine-König: "This is just an update to my maintainer entries as I will switch jobs soon. Getting a contact email address into the MAINTAINERS file that will work also after my switch will hopefully reduce people mailing to the then non-existing address. I also drop my co-maintenance for SIOX, but that continues to be in good hands" * tag 'pwm/for-6.9-rc6-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/ukleinek/linux: MAINTAINERS: Update Uwe's email address, drop SIOX maintenance
…ux/kernel/git/chenhuacai/linux-loongson Pull LoongArch fixes from Huacai Chen: "Fix some build errors and some trivial runtime bugs" * tag 'loongarch-fixes-6.9-2' of git://git.kernel.org/pub/scm/linux/kernel/git/chenhuacai/linux-loongson: LoongArch: Lately init pmu after smp is online LoongArch: Fix callchain parse error with kernel tracepoint events LoongArch: Fix access error when read fault on a write-only VMA LoongArch: Fix a build error due to __tlb_remove_tlb_entry() LoongArch: Fix Kconfig item and left code related to CRASH_CORE
…ernel/git/vfs/vfs
Pull vfs fixes from Christian Brauner:
"This contains a few small fixes for this merge window and the attempt
to handle the ntfs removal regression that was reported a little while
ago:
- After the removal of the legacy ntfs driver we received reports
about regressions for some people that do mount "ntfs" explicitly
and expect the driver to be available. Since ntfs3 is a drop-in for
legacy ntfs we alias legacy ntfs to ntfs3 just like ext3 is aliased
to ext4.
We also enforce legacy ntfs is always mounted read-only and give it
custom file operations to ensure that ioctl()'s can't be abused to
perform write operations.
- Fix an unbalanced module_get() in bdev_open().
- Two smaller fixes for the netfs work done earlier in this cycle.
- Fix the errno returned from the new FS_IOC_GETUUID and
FS_IOC_GETFSSYSFSPATH ioctls. Both commands just pull information
out of the superblock so there's no need to call into the actual
ioctl handlers.
So instead of returning ENOIOCTLCMD to indicate to fallback we just
return ENOTTY directly avoiding that indirection"
* tag 'vfs-6.9-rc6.fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs:
netfs: Fix the pre-flush when appending to a file in writethrough mode
netfs: Fix writethrough-mode error handling
ntfs3: add legacy ntfs file operations
ntfs3: enforce read-only when used as legacy ntfs driver
ntfs3: serve as alias for the legacy ntfs driver
block: fix module reference leakage from bdev_open_by_dev error path
fs: Return ENOTTY directly if FS_IOC_GETUUID or FS_IOC_GETFSSYSFSPATH fail
…kernel/git/device-mapper/linux-dm Pull device mapper fixes from Mike Snitzer: - Fix 6.9 regression so that DM device removal is performed synchronously by default. Asynchronous removal has always been possible but it isn't the default. It is important that synchronous removal be preserved, otherwise it is an interface change that breaks lvm2. - Remove errant semicolon in drivers/md/dm-vdo/murmurhash3.c * tag 'for-6.9/dm-fixes-3' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm: dm: restore synchronous close of device mapper block device dm vdo murmurhash: remove unneeded semicolon
…ernel/git/cxl/cxl Pull cxl fix from Dave Jiang: - Fix potential payload size confusion in cxl_mem_get_poison() * tag 'cxl-fixes-6.9-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/cxl/cxl: cxl/core: Fix potential payload size confusion in cxl_mem_get_poison()
…inux/kernel/git/brgl/linux Pull gpio fixes from Bartosz Golaszewski: - fix a regression in pin access control in gpio-tegra186 - make data pointer dereference robust in Intel Tangier driver * tag 'gpio-fixes-for-v6.9-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux: gpio: tegra186: Fix tegra186_gpio_is_accessible() check gpio: tangier: Use correct type for the IRQ chip data
Fix extract_user_to_sg() so that it will break out of the loop if iov_iter_extract_pages() returns 0 rather than looping around forever. [Note that I've included two fixes lines as the function got moved to a different file and renamed] Fixes: 85dd2c8 ("netfs: Add a function to extract a UBUF or IOVEC into a BVEC iterator") Fixes: f5f82cd ("Move netfs_extract_iter_to_sg() to lib/scatterlist.c") Signed-off-by: David Howells <[email protected]> cc: Jeff Layton <[email protected]> cc: Steve French <[email protected]> cc: Herbert Xu <[email protected]> cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
…ux/kernel/git/mtd/linux Pull MTD fixes from Miquel Raynal: "There has been OTP support improvements in the NVMEM subsystem, and later also improvements of OTP support in the NAND subsystem. This lead to situations that we currently cannot handle, so better prevent this situation from happening in order to avoid canceling device's probe. In the raw NAND subsystem, two runtime fixes have been shared, one fixing two important commands in the Qcom driver since it got reworked and a NULL pointer dereference happening on STB chips. Arnd also fixed a UBSAN link failure on diskonchip" * tag 'mtd/fixes-for-6.9-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux: mtd: limit OTP NVMEM cell parse to non-NAND devices mtd: diskonchip: work around ubsan link failure mtd: rawnand: qcom: Fix broken OP_RESET_DEVICE command in qcom_misc_cmd_type_exec() mtd: rawnand: brcmnand: Fix data access violation for STB chip
…l/git/vgupta/arc Pull ARC fixes from Vineet Gupta: - Incorrect VIPT aliasing assumption - Misc build warning fixes and some typos * tag 'arc-6.9-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc: ARC: [plat-hsdk]: Remove misplaced interrupt-cells property ARC: Fix typos ARC: mm: fix new code about cache aliasing ARC: Fix -Wmissing-prototypes warnings
…/git/ulfh/mmc Pull MMC host fixes from Ulf Hansson: - moxart: Fix regression for sg_miter for PIO mode - sdhci-msm: Avoid hang by preventing access to suspended controller - sdhci-of-dwcmshc: Fix SD card tuning error for th1520 * tag 'mmc-v6.9-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc: mmc: moxart: fix handling of sgm->consumed, otherwise WARN_ON triggers mmc: sdhci-of-dwcmshc: th1520: Increase tuning loop count to 128 mmc: sdhci-msm: pervent access to suspended controller
…rg/pub/scm/linux/kernel/git/akpm/mm Pull misc fixes from Andrew Morton: "11 hotfixes. 8 are cc:stable and the remaining 3 (nice ratio!) address post-6.8 issues or aren't considered suitable for backporting. All except one of these are for MM. I see no particular theme - it's singletons all over" * tag 'mm-hotfixes-stable-2024-04-26-13-30' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm: mm/hugetlb: fix DEBUG_LOCKS_WARN_ON(1) when dissolve_free_hugetlb_folio() selftests: mm: protection_keys: save/restore nr_hugepages value from launch script stackdepot: respect __GFP_NOLOCKDEP allocation flag hugetlb: check for anon_vma prior to folio allocation mm: zswap: fix shrinker NULL crash with cgroup_disable=memory mm: turn folio_test_hugetlb into a PageType mm: support page_mapcount() on page_has_type() pages mm: create FOLIO_FLAG_FALSE and FOLIO_TYPE_OPS macros mm/hugetlb: fix missing hugetlb_lock for resv uncharge selftests: mm: fix unused and uninitialized variable warning selftests/harness: remove use of LINE_MAX
…nel/git/soc/soc
Pull ARM SoC fixes from Arnd Bergmann:
"There are a lot of minor DT fixes for Mediatek, Rockchip, Qualcomm and
Microchip and NXP, addressing both build-time warnings and bugs found
during runtime testing.
Most of these changes are machine specific fixups, but there are a few
notable regressions that affect an entire SoC:
- The Qualcomm MSI support that was improved for 6.9 ended up being
wrong on some chips and now gets fixed.
- The i.MX8MP camera interface broke due to a typo and gets updated
again.
The main driver fix is also for Qualcomm platforms, rewriting an
interface in the QSEECOM firmware support that could lead to crashing
the kernel from a trusted application.
The only other code changes are minor fixes for Mediatek SoC drivers"
* tag 'soc-fixes-6.9-2' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (50 commits)
ARM: dts: imx6ull-tarragon: fix USB over-current polarity
soc: mediatek: mtk-socinfo: depends on CONFIG_SOC_BUS
soc: mediatek: mtk-svs: Append "-thermal" to thermal zone names
arm64: dts: imx8mp: Fix assigned-clocks for second CSI2
ARM: dts: microchip: at91-sama7g54_curiosity: Replace regulator-suspend-voltage with the valid property
ARM: dts: microchip: at91-sama7g5ek: Replace regulator-suspend-voltage with the valid property
arm64: dts: rockchip: Fix USB interface compatible string on kobol-helios64
arm64: dts: qcom: sc8180x: Fix ss_phy_irq for secondary USB controller
arm64: dts: qcom: sm8650: Fix the msi-map entries
arm64: dts: qcom: sm8550: Fix the msi-map entries
arm64: dts: qcom: sm8450: Fix the msi-map entries
arm64: dts: qcom: sc8280xp: add missing PCIe minimum OPP
arm64: dts: qcom: x1e80100: Fix the compatible for cluster idle states
arm64: dts: qcom: Fix type of "wdog" IRQs for remoteprocs
arm64: dts: rockchip: regulator for sd needs to be always on for BPI-R2Pro
dt-bindings: rockchip: grf: Add missing type to 'pcie-phy' node
arm64: dts: rockchip: drop redundant disable-gpios in Lubancat 2
arm64: dts: rockchip: drop redundant disable-gpios in Lubancat 1
arm64: dts: rockchip: drop redundant pcie-reset-suspend in Scarlet Dumo
arm64: dts: rockchip: mark system power controller and fix typo on orangepi-5-plus
...
…/git/bpf/bpf Daniel Borkmann says: ==================== pull-request: bpf 2024-04-26 We've added 12 non-merge commits during the last 22 day(s) which contain a total of 14 files changed, 168 insertions(+), 72 deletions(-). The main changes are: 1) Fix BPF_PROBE_MEM in verifier and JIT to skip loads from vsyscall page, from Puranjay Mohan. 2) Fix a crash in XDP with devmap broadcast redirect when the latter map is in process of being torn down, from Toke Høiland-Jørgensen. 3) Fix arm64 and riscv64 BPF JITs to properly clear start time for BPF program runtime stats, from Xu Kuohai. 4) Fix a sockmap KCSAN-reported data race in sk_psock_skb_ingress_enqueue, from Jason Xing. 5) Fix BPF verifier error message in resolve_pseudo_ldimm64, from Anton Protopopov. 6) Fix missing DEBUG_INFO_BTF_MODULES Kconfig menu item, from Andrii Nakryiko. * tag 'for-netdev' of https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf: selftests/bpf: Test PROBE_MEM of VSYSCALL_ADDR on x86-64 bpf, x86: Fix PROBE_MEM runtime load check bpf: verifier: prevent userspace memory access xdp: use flags field to disambiguate broadcast redirect arm32, bpf: Reimplement sign-extension mov instruction riscv, bpf: Fix incorrect runtime stats bpf, arm64: Fix incorrect runtime stats bpf: Fix a verifier verbose message bpf, skmsg: Fix NULL pointer dereference in sk_psock_skb_ingress_enqueue MAINTAINERS: bpf: Add Lehui and Puranjay as riscv64 reviewers MAINTAINERS: Update email address for Puranjay Mohan bpf, kconfig: Fix DEBUG_INFO_BTF_MODULES Kconfig definition ==================== Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
Baruch reported an OOPS when using the designware controller as target only. Target-only modes break the assumption of one transfer function always being available. Fix this by always checking the pointer in __i2c_transfer. Reported-by: Baruch Siach <[email protected]> Closes: https://lore.kernel.org/r/4269631780e5ba789cf1ae391eec1b959def7d99.1712761976.git.baruch@tkos.co.il Fixes: 4b1acc4 ("i2c: core changes for slave support") [wsa: dropped the simplification in core-smbus to avoid theoretical regressions] Signed-off-by: Wolfram Sang <[email protected]> Tested-by: Baruch Siach <[email protected]>
…l/git/phy/linux-phy Pull phy fixes from Vinod Koul: - static checker (array size, bounds) fix for marvel driver - Rockchip rk3588 pcie fixes for bifurcation and mux - Qualcomm qmp-compbo fix for VCO, register base and regulator name for m31 driver - charger det crash fix for ti driver * tag 'phy-fixes-6.9' of git://git.kernel.org/pub/scm/linux/kernel/git/phy/linux-phy: phy: ti: tusb1210: Resolve charger-det crash if charger psy is unregistered phy: qcom: qmp-combo: fix VCO div offset on v5_5nm and v6 phy: phy-rockchip-samsung-hdptx: Select CONFIG_RATIONAL phy: qcom: m31: match requested regulator name with dt schema phy: qcom: qmp-combo: Fix register base for QSERDES_DP_PHY_MODE phy: qcom: qmp-combo: Fix VCO div offset on v3 phy: rockchip: naneng-combphy: Fix mux on rk3588 phy: rockchip-snps-pcie3: fix clearing PHP_GRF_PCIESEL_CON bits phy: rockchip-snps-pcie3: fix bifurcation on rk3588 phy: freescale: imx8m-pcie: fix pcie link-up instability phy: marvell: a3700-comphy: Fix hardcoded array size phy: marvell: a3700-comphy: Fix out of bounds read
…ernel/git/vkoul/dmaengine Pull dmaengine fixes from Vinod Koul: - Revert pl330 issue_pending waits until WFP state due to regression reported in Bluetooth loading - Xilinx driver fixes for synchronization, buffer offsets, locking and kdoc - idxd fixes for spinlock and preventing the migration of the perf context to an invalid target - idma driver fix for interrupt handling when powered off - Tegra driver residual calculation fix - Owl driver register access fix * tag 'dmaengine-fix-6.9' of git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/dmaengine: dmaengine: idxd: Fix oops during rmmod on single-CPU platforms dmaengine: xilinx: xdma: Clarify kdoc in XDMA driver dmaengine: xilinx: xdma: Fix synchronization issue dmaengine: xilinx: xdma: Fix wrong offsets in the buffers addresses in dma descriptor dma: xilinx_dpdma: Fix locking dmaengine: idxd: Convert spinlock to mutex to lock evl workqueue idma64: Don't try to serve interrupts when device is powered off dmaengine: tegra186: Fix residual calculation dmaengine: owl: fix register access functions dmaengine: Revert "dmaengine: pl330: issue_pending waits until WFP state"
…/kernel/git/vkoul/soundwire Pull soundwire fix from Vinod Koul: - Single AMD driver fix for wake interrupt handling in clockstop mode * tag 'soundwire-6.9-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/soundwire: soundwire: amd: fix for wake interrupt handling for clockstop mode
create_prof_cpu_mask() is no longer used after commit 1f44a22 ("s390: convert interrupt handling to use generic hardirq"). Signed-off-by: Tetsuo Handa <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
…nel/git/wsa/linux Pull i2c fixes from Wolfram Sang: "Fix a race condition in the at24 eeprom handler, a NULL pointer exception in the I2C core for controllers only using target modes, drop a MAINTAINERS entry, and fix an incorrect DT binding for at24" * tag 'i2c-for-6.9-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux: i2c: smbus: fix NULL function pointer dereference MAINTAINERS: Drop entry for PCA9541 bus master selector eeprom: at24: fix memory corruption race condition dt-bindings: eeprom: at24: Fix ST M24C64-D compatible schema
…ifs-2.6 Pull smb client fixes from Steve French: "Three smb3 client fixes, all also for stable: - two small locking fixes spotted by Coverity - FILE_ALL_INFO and network_open_info packing fix" * tag '6.9-rc5-cifs-fixes-part2' of git://git.samba.org/sfrench/cifs-2.6: smb3: fix lock ordering potential deadlock in cifs_sync_mid_result smb3: missing lock when picking channel smb: client: Fix struct_group() usage in __packed structs
…inux/kernel/git/riscv/linux Pull RISC-V fixes from Palmer Dabbelt: - A fix for TASK_SIZE on rv64/NOMMU, to reflect the lack of user/kernel separation - A fix to avoid loading rv64/NOMMU kernel past the start of RAM - A fix for RISCV_HWPROBE_EXT_ZVFHMIN on ilp32 to avoid signed integer overflow in the bitmask - The sud_test kselftest has been fixed to properly swizzle the syscall number into the return register, which are not the same on RISC-V - A fix for a build warning in the perf tools on rv32 - A fix for the CBO selftests, to avoid non-constants leaking into the inline asm - A pair of fixes for T-Head PBMT errata probing, which has been renamed MAE by the vendor * tag 'riscv-for-linus-6.9-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux: RISC-V: selftests: cbo: Ensure asm operands match constraints, take 2 perf riscv: Fix the warning due to the incompatible type riscv: T-Head: Test availability bit before enabling MAE errata riscv: thead: Rename T-Head PBMT to MAE selftests: sud_test: return correct emulated syscall value on RISC-V riscv: hwprobe: fix invalid sign extension for RISCV_HWPROBE_EXT_ZVFHMIN riscv: Fix loading 64-bit NOMMU kernels past the start of RAM riscv: Fix TASK_SIZE on 64-bit NOMMU
Pull Rust fixes from Miguel Ojeda: - Soundness: make internal functions generated by the 'module!' macro inaccessible, do not implement 'Zeroable' for 'Infallible' and require 'Send' for the 'Module' trait. - Build: avoid errors with "empty" files and workaround 'rustdoc' ICE. - Kconfig: depend on '!CFI_CLANG' and avoid selecting 'CONSTRUCTORS'. - Code docs: remove non-existing key from 'module!' macro example. - Docs: trivial rendering fix in arch table. * tag 'rust-fixes-6.9' of https://github.com/Rust-for-Linux/linux: rust: remove `params` from `module` macro example kbuild: rust: force `alloc` extern to allow "empty" Rust files kbuild: rust: remove unneeded `@rustc_cfg` to avoid ICE rust: kernel: require `Send` for `Module` implementations rust: phy: implement `Send` for `Registration` rust: make mutually exclusive with CFI_CLANG rust: macros: fix soundness issue in `module!` macro rust: init: remove impl Zeroable for Infallible docs: rust: fix improper rendering in Arch Support page rust: don't select CONSTRUCTORS
Documentation/timers/no_hz.rst states that the "nohz_full=" mask must not include the boot CPU, which is no longer true after: 08ae95f ("nohz_full: Allow the boot CPU to be nohz_full"). However after: aae17eb ("workqueue: Avoid using isolated cpus' timers on queue_delayed_work") the kernel will crash at boot time in this case; housekeeping_any_cpu() returns an invalid CPU number until smp_init() brings the first housekeeping CPU up. Change housekeeping_any_cpu() to check the result of cpumask_any_and() and return smp_processor_id() in this case. This is just the simple and backportable workaround which fixes the symptom, but smp_processor_id() at boot time should be safe at least for type == HK_TYPE_TIMER, this more or less matches the tick_do_timer_boot_cpu logic. There is no worry about cpu_down(); tick_nohz_cpu_down() will not allow to offline tick_do_timer_cpu (the 1st online housekeeping CPU). Fixes: aae17eb ("workqueue: Avoid using isolated cpus' timers on queue_delayed_work") Reported-by: Chris von Recklinghausen <[email protected]> Signed-off-by: Oleg Nesterov <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Signed-off-by: Ingo Molnar <[email protected]> Reviewed-by: Phil Auld <[email protected]> Acked-by: Frederic Weisbecker <[email protected]> Link: https://lore.kernel.org/r/[email protected] Closes: https://lore.kernel.org/all/[email protected]/
housekeeping_setup() checks cpumask_intersects(present, online) to ensure that the kernel will have at least one housekeeping CPU after smp_init(), but this doesn't work if the maxcpus= kernel parameter limits the number of processors available after bootup. For example, a kernel with "maxcpus=2 nohz_full=0-2" parameters crashes at boot time on a virtual machine with 4 CPUs. Change housekeeping_setup() to use cpumask_first_and() and check that the returned CPU number is valid and less than setup_max_cpus. Another corner case is "nohz_full=0" on a machine with a single CPU or with the maxcpus=1 kernel argument. In this case non_housekeeping_mask is empty and tick_nohz_full_setup() makes no sense. And indeed, the kernel hits the WARN_ON(tick_nohz_full_running) in tick_sched_do_timer(). And how should the kernel interpret the "nohz_full=" parameter? It should be silently ignored, but currently cpulist_parse() happily returns the empty cpumask and this leads to the same problem. Change housekeeping_setup() to check cpumask_empty(non_housekeeping_mask) and do nothing in this case. Signed-off-by: Oleg Nesterov <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Signed-off-by: Ingo Molnar <[email protected]> Reviewed-by: Phil Auld <[email protected]> Acked-by: Frederic Weisbecker <[email protected]> Link: https://lore.kernel.org/r/[email protected]
While there are two separate IRQ status bits for dock attach and detach, the hardware appears to mix them up more or less randomly, making them useless for tracking what actually happened. It is much safer to check the dock status separately and proceed based on that, as the old polling code did. Note that the code assumes that only the dock can be hot-plugged - if other option card bits changed, the logic would break. Fixes: fbb64ee ("ALSA: emu10k1: make E-MU dock monitoring interrupt-driven") Link: https://bugzilla.kernel.org/show_bug.cgi?id=218584 Signed-off-by: Oswald Buddenhagen <[email protected]> Signed-off-by: Takashi Iwai <[email protected]> Message-ID: <[email protected]>
Pulled out of the next patch to improve its legibility. As the function is now available, call it directly from snd_emu10k1_emu1010_init(), thus making the MicroDock firmware loading synchronous - there isn't really a reason not to. Note that this does not affect the AudioDocks of rev1 cards, as these have no independent power supplies, and thus come up only a while after the main card is initialized. As a drive-by, adjust the priorities of two messages to better reflect their impact. Signed-off-by: Oswald Buddenhagen <[email protected]> Signed-off-by: Takashi Iwai <[email protected]> Message-ID: <[email protected]>
The actual event processing was already done by workqueue items. We can
move the event dispatching there as well, rather than doing it already
in the interrupt handler callback.
This change has a rather profound "side effect" on the reliability of
the FPGA programming: once we enter programming mode, we must not issue
any snd_emu1010_fpga_{read,write}() calls until we're done, as these
would badly mess up the programming protocol. But exactly that would
happen when trying to program the dock, as that triggers GPIO interrupts
as a side effect. This is mitigated by deferring the actual interrupt
handling, as workqueue items are not re-entrant.
To avoid scheduling the dispatcher on non-events, we now explicitly
ignore GPIO IRQs triggered by "uninteresting" pins, which happens a lot
as a side effect of calling snd_emu1010_fpga_{read,write}().
Fixes: fbb64ee ("ALSA: emu10k1: make E-MU dock monitoring interrupt-driven")
Link: https://bugzilla.kernel.org/show_bug.cgi?id=218584
Signed-off-by: Oswald Buddenhagen <[email protected]>
Signed-off-by: Takashi Iwai <[email protected]>
Message-ID: <[email protected]>
The FPGA access through the GPIO port does not interfere with other sound processor register access, so there is no need to subject it to emu_lock. And after moving all FPGA access out of the interrupt handler, it does not need to be IRQ-safe, either. What's more, attaching the dock causes a firmware upload, which takes several seconds. We really don't want to disable IRQs for this long, and even less also have someone else spin with IRQs disabled waiting for us. Therefore, use a mutex for FPGA access locking. This makes the code somewhat more noisy, as we need to wrap bigger sections into the mutex, as it needs to enclose the spinlocks. The latter has the "side effect" of fixing dock FPGA programming in a corner case: a really badly timed mixer access right between entering FPGA programming mode and uploading the netlist would mess up the protocol. Signed-off-by: Oswald Buddenhagen <[email protected]> Signed-off-by: Takashi Iwai <[email protected]> Message-ID: <[email protected]>
A side effect of making the dock monitoring interrupt-driven was that we'd be very quick to program a freshly connected dock. However, for unclear reasons, the dock does not work when we do that - despite the FPGA netlist upload going just fine. We work around this by adding a delay before programming the dock; for safety, the value is several times as much as was determined empirically. Note that a badly timed dock hot-plug would have triggered the problem even before the referenced commit - but now it would happen 100% instead of about 3% of the time, thus making it impossible to work around by re-plugging. Fixes: fbb64ee ("ALSA: emu10k1: make E-MU dock monitoring interrupt-driven") Link: https://bugzilla.kernel.org/show_bug.cgi?id=218584 Signed-off-by: Oswald Buddenhagen <[email protected]> Signed-off-by: Takashi Iwai <[email protected]> Message-ID: <[email protected]>
set_next_task_scx() can call ops.running() which can update p->scx.slice. Check and warn zero slice after set_next_task_scx(), not before. (cherry picked from commit ef638e6)
(cherry picked from commit 89b7ecc)
(cherry picked from commit 7a3bce8)
CI seems to require bc and gcc-multilib. Let's add those to the list of Ubuntu packages we install. Signed-off-by: David Vernet <[email protected]> (cherry picked from commit 1524224)
We're currently invoking vng only when iterating over the schedulers in tools/sched_ext. We should also be running our selftests in CI, so let's refactor that logic to a new, separate runtest() bash function. Along the way, remove some extra, unnecessary scx_layered-specific logic. We no longer ship scx_layered in the sched_ext repo, so we can remove it. Signed-off-by: David Vernet <[email protected]> (cherry picked from commit 92505bf)
We no longer have UEI_KIND or UEI_ECODE. Adjust the hotplug selftest accordingly. We'll update CI to run these tests in a subsequent patch. Signed-off-by: David Vernet <[email protected]> (cherry picked from commit 1ea92e2)
We have a fairly comprehensive set of selftests in tools/selftests/sched_ext. Let's run them in CI. Signed-off-by: David Vernet <[email protected]> (cherry picked from commit 1ef9ac4)
(cherry picked from commit e15b351)
(cherry picked from commit d22cb10)
With this and the latest libbpf fix which hasn't landed yet, scx_qmap can run on compat-base too. (cherry picked from commit 0421c75)
Implement ops.dump(), dump_cpu() and dump_task() which allows the BPF
scheduler to include scheduler specific information in debug dump.
The below example output from scx_qmap shows full dump of qmap's FIFO queues
and per-CPU and per-task contexts.
$ scx_qmap -e 3
stats : enq=9 dsp=0 delta=9 reenq=5 deq=9 core=0 exp=0
cpuperf: cur min/avg/max=0/0/0 target min/avg/max=0/0/0
DEBUG DUMP
================================================================================
scx_qmap[1627] triggered exit kind 1025:
scx_bpf_error (test triggering error)
Backtrace:
scx_bpf_error_bstr+0x60/0x80
bpf_prog_5ab320c9dc9e846d_qmap_enqueue+0xd1/0x283
QMAP FIFO[0]:
QMAP FIFO[1]:
QMAP FIFO[2]: 1581 1583 1584 1585 1586 1588 1593 1594 1595
QMAP FIFO[3]:
QMAP FIFO[4]:
CPU states
----------
CPU 0 : nr_run=2 flags=0x0 cpu_rel=1 ops_qseq=4 pnt_seq=12
curr=stress[1590] class=ext_sched_class
QMAP: dsp_idx=0 dsp_cnt=0 avg_weight=0 cpuperf_target=0
*R stress[1590] +0ms
scx_state/flags=3/0x5 dsq_flags=0x0 ops_state/qseq=0/0
sticky/holding_cpu=-1/-1 dsq_id=(n/a)
cpus=ff
QMAP: force_local=0 core_sched_seq=0
R stress[1585] +0ms
scx_state/flags=3/0x1 dsq_flags=0x0 ops_state/qseq=2/3
sticky/holding_cpu=-1/-1 dsq_id=(n/a)
cpus=ff
QMAP: force_local=0 core_sched_seq=3
irqentry_exit+0x31/0x80
sysvec_apic_timer_interrupt+0x44/0x80
asm_sysvec_apic_timer_interrupt+0x1b/0x20
...
(cherry picked from commit ec7e3b0)
Enable kvm acceleration and qemu microvm to speed up CI tests inside virtme-ng. Also adjust the regex to catch potential errors excluding a false positive triggered by the new configuration. Link: https://github.blog/changelog/2023-02-23-hardware-accelerated-android-virtualization-on-actions-windows-and-linux-larger-hosted-runners/ Link: https://github.blog/2024-01-17-github-hosted-runners-double-the-power-for-open-source/ Signed-off-by: Andrea Righi <[email protected]> (cherry picked from commit 0caf6fc)
This fixes a bug introduced by 34c6075 ("scx: Fix scx_ops_bypass_depth going out of sync"). It added mutex_lock(scx_ops_enable_mutex) to scx_ops_bypass(), which can obviously lead to problem if scx_ops_bypass() is invoked from the disable path while someone is holding the mutex and scheduled out. [ 246.906433] INFO: task sched_ext_ops_h:1531 blocked for more than 122 seconds. [ 246.907862] Not tainted 6.9.0-rc5-work-02067-g7f2a15fc2eb2-dirty #34 [ 246.909213] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 246.910973] task:sched_ext_ops_h state:D stack:0 pid:1531 tgid:1531 ppid:2 flags:0x00004000 [ 246.913004] Sched_ext: qmap (enabled+all) [ 246.913007] Call Trace: [ 246.914486] <TASK> [ 246.914956] __schedule+0x750/0xcd0 [ 246.915770] schedule+0x41/0xb0 [ 246.916503] schedule_preempt_disabled+0x15/0x20 [ 246.917542] __mutex_lock+0x511/0xb00 [ 246.918379] ? scx_ops_bypass+0x54/0x1a0 [ 246.919232] mutex_lock_nested+0x1b/0x20 [ 246.920110] scx_ops_bypass+0x54/0x1a0 [ 246.920961] ? irqentry_exit+0x59/0x80 [ 246.921814] ? sysvec_irq_work+0x41/0x80 [ 246.922705] scx_ops_disable_workfn+0xd1/0x920 [ 246.923714] ? lock_acquire+0xcb/0x230 [ 246.924567] ? kthread_worker_fn+0x80/0x2a0 [ 246.925504] ? lock_release+0xd8/0x2d0 [ 246.926355] ? kthread_worker_fn+0xbe/0x2a0 [ 246.927262] kthread_worker_fn+0x10a/0x2a0 [ 246.928182] ? scx_dump_task+0x2f0/0x2f0 [ 246.929080] kthread+0xec/0x110 [ 246.929814] ? __kthread_init_worker+0x100/0x100 [ 246.930855] ? kthread_blkcg+0x40/0x40 [ 246.931718] ret_from_fork+0x36/0x40 [ 246.932545] ? kthread_blkcg+0x40/0x40 [ 246.933411] ret_from_fork_asm+0x11/0x20 [ 246.934311] </TASK> [ 246.934798] [ 246.934798] Showing all locks held in the system: [ 246.936169] 1 lock held by khungtaskd/60: [ 246.937081] #0: ffffffff8335b128 (rcu_read_lock){....}-{1:2}, at: debug_show_all_locks+0x30/0x190 [ 246.939051] 1 lock held by scx_qmap/1529: [ 246.939963] 1 lock held by sched_ext_ops_h/1531: [ 246.940999] #0: ffffffff83272e28 (scx_ops_enable_mutex){+.+.}-{3:3}, at: scx_ops_bypass+0x54/0x1a0 There's no reason to grab the mutex there. We can just test scx_enabled() without holding the mutex. Drop the broken locking. (cherry picked from commit a95e0bf)
In sched_ext, there's currently a corner case on the hotplug path wherein a CPU may be onlined and begin scheduling _before_ we've invoked ops.cpu_online() to the scheduler. This can cause confusion by e.g. causing a scheduler to error out if it receives an ops.dispatch() call and accidentally dispatches to an invalid DSQ. To avoid this scenario, this patch adds a per-CPU boolean variable that tracks when a CPU has been onlined from the perspective of sched_ext. Note that this patch does not prevent _any_ callback from being invoked on that CPU. It simply prevents us from invoking ops.dispatch(), and forces us to dispatch directly to the local DSQ. We can still, however, receive e.g. ops.runnable() if a per-CPU task is dispatched to the local DSQ of the onlined CPU before the hotplug event is received. Signed-off-by: David Vernet <[email protected]> (cherry picked from commit 57845b3)
In commit 57845b3 ("scx: Dispatch locally until ops.cpu_online() invoked"), we updated ext.c to only issue dispatch callbacks if we know that a CPU has been fully onlined. There were a couple of small issues with this commit, including: 1. The documentation wasn't quite right -- it said that we choose to dispatch locally, but that was a stale comment. 2. We now have two places where we're checking CPU online / offline status, which is unnecessarily confusing. scx_cpu_online matches exactly where the hotplug callbacks are invoked, so we can just use those everywhere. Note that we can still invoke callbacks for e.g. per-CPU tasks that run on onlining CPUs before the CPU has been fully onlined. We'll update our documenation in the next patch to clarify this. Signed-off-by: David Vernet <[email protected]> (cherry picked from commit ed5ff6f)
During hotplug events, ext.c prevents certain callbacks and kfuncs from being invoked on CPUs. For example, we don't invoke ops.enqueue() or ops.dispatch() on an onlining CPU that didn't associate itself with a DSQ on the init path. That said, there are _some_ semantics we do which may confuse schedulers. For example, we will invoke ops.runnable() on a per-CPU kthread that's required for CPU hotplug to run (cpuhp), but we then won't invoke ops.enqueue() on it. While this isn't that weird, it's probably best that we document the semantics. This commit does that. Signed-off-by: David Vernet <[email protected]> (cherry picked from commit 1bb91a4)
In a recent commit, we refactored bpf_exit_bstr_common() into bstr_format(). This unfortunately regressed printing output passed from BPF, as we incorrectly invoked bpf_exit_bstr_common() in the caller. Fix it. Signed-off-by: David Vernet <[email protected]> (cherry picked from commit b46212c)
Signed-off-by: David Vernet <[email protected]>
htejun
approved these changes
May 8, 2024
Merged
htejun
pushed a commit
that referenced
this pull request
May 22, 2024
SCX: test_and_clear_cpu_idle() should always clear SMT mask
htejun
pushed a commit
that referenced
this pull request
May 22, 2024
Andrii Nakryiko says: ==================== BPF register bounds logic and testing improvements This patch set adds a big set of manual and auto-generated test cases validating BPF verifier's register bounds tracking and deduction logic. See details in the last patch. We start with building a tester that validates existing <range> vs <scalar> verifier logic for range bounds. To make all this work, BPF verifier's logic needed a bunch of improvements to handle some cases that previously were not covered. This had no implications as to correctness of verifier logic, but it was incomplete enough to cause significant disagreements with alternative implementation of register bounds logic that tests in this patch set implement. So we need BPF verifier logic improvements to make all the tests pass. This is what we do in patches #3 through #9. The end goal of this work, though, is to extend BPF verifier range state tracking such as to allow to derive new range bounds when comparing non-const registers. There is some more investigative work required to investigate and fix existing potential issues with range tracking as part of ALU/ALU64 operations, so <range> x <range> part of v5 patch set ([0]) is dropped until these issues are sorted out. For now, we include preparatory refactorings and clean ups, that set up BPF verifier code base to extend the logic to <range> vs <range> logic in subsequent patch set. Patches #10-#16 perform preliminary refactorings without functionally changing anything. But they do clean up check_cond_jmp_op() logic and generalize a bunch of other pieces in is_branch_taken() logic. [0] https://patchwork.kernel.org/project/netdevbpf/list/?series=797178&state=* v5->v6: - dropped <range> vs <range> patches (original patches #18 through #23) to add more register range sanity checks and fix preexisting issues; - comments improvements, addressing other feedback on first 17 patches (Eduard, Alexei); v4->v5: - added entirety of verifier reg bounds tracking changes, now handling <range> vs <range> cases (Alexei); - added way more comments trying to explain why deductions added are correct, hopefully they are useful and clarify things a bit (Daniel, Shung-Hsi); - added two preliminary selftests fixes necessary for RELEASE=1 build to work again, it keeps breaking. v3->v4: - improvements to reg_bounds tester (progress report, split 32-bit and 64-bit ranges, fix various verbosity output issues, etc); v2->v3: - fix a subtle little-endianness assumption inside parge_reg_state() (CI); v1->v2: - fix compilation when building selftests with llvm-16 toolchain (CI). ==================== Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alexei Starovoitov <[email protected]>
Byte-Lab
pushed a commit
that referenced
this pull request
Jun 21, 2024
[ Upstream commit 769e6a1 ] ui_browser__show() is capturing the input title that is stack allocated memory in hist_browser__run(). Avoid a use after return by strdup-ing the string. Committer notes: Further explanation from Ian Rogers: My command line using tui is: $ sudo bash -c 'rm /tmp/asan.log*; export ASAN_OPTIONS="log_path=/tmp/asan.log"; /tmp/perf/perf mem record -a sleep 1; /tmp/perf/perf mem report' I then go to the perf annotate view and quit. This triggers the asan error (from the log file): ``` ==1254591==ERROR: AddressSanitizer: stack-use-after-return on address 0x7f2813331920 at pc 0x7f28180 65991 bp 0x7fff0a21c750 sp 0x7fff0a21bf10 READ of size 80 at 0x7f2813331920 thread T0 #0 0x7f2818065990 in __interceptor_strlen ../../../../src/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:461 #1 0x7f2817698251 in SLsmg_write_wrapped_string (/lib/x86_64-linux-gnu/libslang.so.2+0x98251) #2 0x7f28176984b9 in SLsmg_write_nstring (/lib/x86_64-linux-gnu/libslang.so.2+0x984b9) #3 0x55c94045b365 in ui_browser__write_nstring ui/browser.c:60 #4 0x55c94045c558 in __ui_browser__show_title ui/browser.c:266 #5 0x55c94045c776 in ui_browser__show ui/browser.c:288 #6 0x55c94045c06d in ui_browser__handle_resize ui/browser.c:206 #7 0x55c94047979b in do_annotate ui/browsers/hists.c:2458 #8 0x55c94047fb17 in evsel__hists_browse ui/browsers/hists.c:3412 #9 0x55c940480a0c in perf_evsel_menu__run ui/browsers/hists.c:3527 #10 0x55c940481108 in __evlist__tui_browse_hists ui/browsers/hists.c:3613 #11 0x55c9404813f7 in evlist__tui_browse_hists ui/browsers/hists.c:3661 #12 0x55c93ffa253f in report__browse_hists tools/perf/builtin-report.c:671 #13 0x55c93ffa58ca in __cmd_report tools/perf/builtin-report.c:1141 #14 0x55c93ffaf159 in cmd_report tools/perf/builtin-report.c:1805 #15 0x55c94000c05c in report_events tools/perf/builtin-mem.c:374 #16 0x55c94000d96d in cmd_mem tools/perf/builtin-mem.c:516 #17 0x55c9400e44ee in run_builtin tools/perf/perf.c:350 #18 0x55c9400e4a5a in handle_internal_command tools/perf/perf.c:403 #19 0x55c9400e4e22 in run_argv tools/perf/perf.c:447 #20 0x55c9400e53ad in main tools/perf/perf.c:561 #21 0x7f28170456c9 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 #22 0x7f2817045784 in __libc_start_main_impl ../csu/libc-start.c:360 #23 0x55c93ff544c0 in _start (/tmp/perf/perf+0x19a4c0) (BuildId: 84899b0e8c7d3a3eaa67b2eb35e3d8b2f8cd4c93) Address 0x7f2813331920 is located in stack of thread T0 at offset 32 in frame #0 0x55c94046e85e in hist_browser__run ui/browsers/hists.c:746 This frame has 1 object(s): [32, 192) 'title' (line 747) <== Memory access at offset 32 is inside this variable HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork ``` hist_browser__run isn't on the stack so the asan error looks legit. There's no clean init/exit on struct ui_browser so I may be trading a use-after-return for a memory leak, but that seems look a good trade anyway. Fixes: 05e8b08 ("perf ui browser: Stop using 'self'") Signed-off-by: Ian Rogers <[email protected]> Cc: Adrian Hunter <[email protected]> Cc: Alexander Shishkin <[email protected]> Cc: Andi Kleen <[email protected]> Cc: Athira Rajeev <[email protected]> Cc: Ben Gainey <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: James Clark <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Kajol Jain <[email protected]> Cc: Kan Liang <[email protected]> Cc: K Prateek Nayak <[email protected]> Cc: Li Dong <[email protected]> Cc: Mark Rutland <[email protected]> Cc: Namhyung Kim <[email protected]> Cc: Oliver Upton <[email protected]> Cc: Paran Lee <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Ravi Bangoria <[email protected]> Cc: Sun Haiyong <[email protected]> Cc: Tim Chen <[email protected]> Cc: Yanteng Si <[email protected]> Cc: Yicong Yang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
htejun
pushed a commit
that referenced
this pull request
Sep 11, 2024
With latest llvm19, the selftest iters/iter_arr_with_actual_elem_count
failed with -mcpu=v4.
The following are the details:
0: R1=ctx() R10=fp0
; int iter_arr_with_actual_elem_count(const void *ctx) @ iters.c:1420
0: (b4) w7 = 0 ; R7_w=0
; int i, n = loop_data.n, sum = 0; @ iters.c:1422
1: (18) r1 = 0xffffc90000191478 ; R1_w=map_value(map=iters.bss,ks=4,vs=1280,off=1144)
3: (61) r6 = *(u32 *)(r1 +128) ; R1_w=map_value(map=iters.bss,ks=4,vs=1280,off=1144) R6_w=scalar(smin=0,smax=umax=0xffffffff,var_off=(0x0; 0xffffffff))
; if (n > ARRAY_SIZE(loop_data.data)) @ iters.c:1424
4: (26) if w6 > 0x20 goto pc+27 ; R6_w=scalar(smin=smin32=0,smax=umax=smax32=umax32=32,var_off=(0x0; 0x3f))
5: (bf) r8 = r10 ; R8_w=fp0 R10=fp0
6: (07) r8 += -8 ; R8_w=fp-8
; bpf_for(i, 0, n) { @ iters.c:1427
7: (bf) r1 = r8 ; R1_w=fp-8 R8_w=fp-8
8: (b4) w2 = 0 ; R2_w=0
9: (bc) w3 = w6 ; R3_w=scalar(id=1,smin=smin32=0,smax=umax=smax32=umax32=32,var_off=(0x0; 0x3f)) R6_w=scalar(id=1,smin=smin32=0,smax=umax=smax32=umax32=32,var_off=(0x0; 0x3f))
10: (85) call bpf_iter_num_new#45179 ; R0=scalar() fp-8=iter_num(ref_id=2,state=active,depth=0) refs=2
11: (bf) r1 = r8 ; R1=fp-8 R8=fp-8 refs=2
12: (85) call bpf_iter_num_next#45181 13: R0=rdonly_mem(id=3,ref_obj_id=2,sz=4) R6=scalar(id=1,smin=smin32=0,smax=umax=smax32=umax32=32,var_off=(0x0; 0x3f)) R7=0 R8=fp-8 R10=fp0 fp-8=iter_num(ref_id=2,state=active,depth=1) refs=2
; bpf_for(i, 0, n) { @ iters.c:1427
13: (15) if r0 == 0x0 goto pc+2 ; R0=rdonly_mem(id=3,ref_obj_id=2,sz=4) refs=2
14: (81) r1 = *(s32 *)(r0 +0) ; R0=rdonly_mem(id=3,ref_obj_id=2,sz=4) R1_w=scalar(smin=0xffffffff80000000,smax=0x7fffffff) refs=2
15: (ae) if w1 < w6 goto pc+4 20: R0=rdonly_mem(id=3,ref_obj_id=2,sz=4) R1=scalar(smin=0xffffffff80000000,smax=smax32=umax32=31,umax=0xffffffff0000001f,smin32=0,var_off=(0x0; 0xffffffff0000001f)) R6=scalar(id=1,smin=umin=smin32=umin32=1,smax=umax=smax32=umax32=32,var_off=(0x0; 0x3f)) R7=0 R8=fp-8 R10=fp0 fp-8=iter_num(ref_id=2,state=active,depth=1) refs=2
; sum += loop_data.data[i]; @ iters.c:1429
20: (67) r1 <<= 2 ; R1_w=scalar(smax=0x7ffffffc0000007c,umax=0xfffffffc0000007c,smin32=0,smax32=umax32=124,var_off=(0x0; 0xfffffffc0000007c)) refs=2
21: (18) r2 = 0xffffc90000191478 ; R2_w=map_value(map=iters.bss,ks=4,vs=1280,off=1144) refs=2
23: (0f) r2 += r1
math between map_value pointer and register with unbounded min value is not allowed
The source code:
int iter_arr_with_actual_elem_count(const void *ctx)
{
int i, n = loop_data.n, sum = 0;
if (n > ARRAY_SIZE(loop_data.data))
return 0;
bpf_for(i, 0, n) {
/* no rechecking of i against ARRAY_SIZE(loop_data.n) */
sum += loop_data.data[i];
}
return sum;
}
The insn #14 is a sign-extenstion load which is related to 'int i'.
The insn #15 did a subreg comparision. Note that smin=0xffffffff80000000 and this caused later
insn #23 failed verification due to unbounded min value.
Actually insn #15 R1 smin range can be better. Before insn #15, we have
R1_w=scalar(smin=0xffffffff80000000,smax=0x7fffffff)
With the above range, we know for R1, upper 32bit can only be 0xffffffff or 0.
Otherwise, the value range for R1 could be beyond [smin=0xffffffff80000000,smax=0x7fffffff].
After insn #15, for the true patch, we know smin32=0 and smax32=32. With the upper 32bit 0xffffffff,
then the corresponding value is [0xffffffff00000000, 0xffffffff00000020]. The range is
obviously beyond the original range [smin=0xffffffff80000000,smax=0x7fffffff] and the
range is not possible. So the upper 32bit must be 0, which implies smin = smin32 and
smax = smax32.
This patch fixed the issue by adding additional register deduction after 32-bit compare
insn. If the signed 32-bit register range is non-negative then 64-bit smin is
in range of [S32_MIN, S32_MAX], then the actual 64-bit smin/smax should be the same
as 32-bit smin32/smax32.
With this patch, iters/iter_arr_with_actual_elem_count succeeded with better register range:
from 15 to 20: R0=rdonly_mem(id=7,ref_obj_id=2,sz=4) R1_w=scalar(smin=smin32=0,smax=umax=smax32=umax32=31,var_off=(0x0; 0x1f)) R6=scalar(id=1,smin=umin=smin32=umin32=1,smax=umax=smax32=umax32=32,var_off=(0x0; 0x3f)) R7=scalar(id=9,smin=0,smax=umax=0xffffffff,var_off=(0x0; 0xffffffff)) R8=scalar(id=9,smin=0,smax=umax=0xffffffff,var_off=(0x0; 0xffffffff)) R10=fp0 fp-8=iter_num(ref_id=2,state=active,depth=3) refs=2
Acked-by: Eduard Zingerman <[email protected]>
Acked-by: Shung-Hsi Yu <[email protected]>
Signed-off-by: Yonghong Song <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Alexei Starovoitov <[email protected]>
Signed-off-by: Andrii Nakryiko <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Includes all scx-specific patches. Does not include bpf-next merges.