- Linux-stable-mirror - lists.linaro.org

BUG: perf hardware breakpoint pc value mismatch

by liaochen (A)

Hi all, We found the following issue with Linux v6.12-rc7 on KunPeng920 platform. A very low frequency problem of pc value mismatch occurs when using perf hardware breakpoints to trigger a signal handler and comparing pc from u_context with its desired value. Attached please find the reproducer for this issue. It applies perf events to set a hardware breakpoint to an address while binding a signal to the perf event fd. When stepping into the breakpoint address, the signal handler compares pc value copied from signal ucontext with the real breakpoint address and see if there is a mismatch. While looking into the flow of execution: // normal flow of exe: a.out-19844 [038] d... 8763.348609: hw_breakpoint_control: perf user addr: 400c6c, bp addr: 400c6c, ops: 0 // breakpoint exception: a.out-19844 [038] d... 8763.348611: do_debug_exception: ec: 0, pc: 400c6c, pstate: 20001000 a.out-19844 [038] d... 8763.348611: breakpoint_handler: perf bp read: 400c6c // send signal: a.out-19844 [038] d.h. 8763.348613: send_sigio_to_task <-send_sigio a.out-19844 [038] d.h. 8763.348614: <stack trace> => send_sigio_to_task => send_sigio => kill_fasync_rcu => kill_fasync => perf_event_wakeup => perf_pending_event => irq_work_single => irq_work_run_list => irq_work_run => do_handle_IPI => ipi_handler => handle_percpu_devid_fasteoi_ipi => __handle_domain_irq => gic_handle_irq => el0_irq_naked a.out-19844 [038] d.h. 8763.348614: send_sigio_to_task: step in with signum 38 a.out-19844 [038] d.h. 8763.348615: send_sigio_to_task: will do_send_sig_info 38 // kernel signal handling: a.out-19844 [038] .... 8763.348616: do_notify_resume: thread_flags 2097665, _TIF_SIGPENDING 1, _TIF_NOTIFY_SIGNAL40 a.out-19844 [038] .... 8763.348617: setup_sigframe: restore sig: 400c6c // single step exception: a.out-19844 [038] d... 8763.348619: do_debug_exception: ec: 1, pc: 400988, pstate: 20001000 a.out-19844 [038] d... 8763.348621: hw_breakpoint_control: perf user addr: 400c6c, bp addr: 400c6c, ops: 1 // abnormal flow of exe: a.out-19844 [084] d... 8763.782103: hw_breakpoint_control: perf user addr: 400c6c, bp addr: 400c6c, ops: 0 // breakpoint exception: a.out-19844 [084] d... 8763.782104: do_debug_exception: ec: 0, pc: 400c6c, pstate: 20001000 // single step exception: a.out-19844 [084] d... 8763.782105: breakpoint_handler: perf bp read: 400c6c a.out-19844 [084] d... 8763.782107: do_debug_exception: ec: 1, pc: 400c70, pstate: 20001000 // send signal: a.out-19844 [084] d.h. 8763.782108: send_sigio_to_task <-send_sigio a.out-19844 [084] d.h. 8763.782109: <stack trace> => send_sigio_to_task => send_sigio => kill_fasync_rcu => kill_fasync => perf_event_wakeup => perf_pending_event => irq_work_single => irq_work_run_list => irq_work_run => do_handle_IPI => ipi_handler => handle_percpu_devid_fasteoi_ipi => __handle_domain_irq => gic_handle_irq => el0_irq_naked a.out-19844 [084] d.h. 8763.782110: send_sigio_to_task: step in with signum 38 a.out-19844 [084] d.h. 8763.782110: send_sigio_to_task: will do_send_sig_info 38 // kernel signal handling: a.out-19844 [084] .... 8763.782111: do_notify_resume: thread_flags 513, _TIF_SIGPENDING 1, _TIF_NOTIFY_SIGNAL40 a.out-19844 [084] .... 8763.782113: setup_sigframe: restore sig: 400c70 a.out-19844 [084] d... 8763.782115: hw_breakpoint_control: perf user addr: 400c6c, bp addr: 400c6c, ops: 1 Kernel sends this signal to task through pushing a perf_pending_event (which sends the signal) in irq_work_queue then triggering an IPI to let kernel handle this pended task. seems that when mismatch occurs, the IPI does not preempt the breakpoint exception it should preempt, causing no pending signals to be handled. In this way, there is no pending signals in do_notify_resume and kernel will not set up signal frame with correct pc value. Thanks, Chen

5 hours, 12 minutes

1
0
0 0

[PATCH v2 4/7] arm64: dts: ti: k3-j721e-sk: Add requiried voltage supplies for IMX219

by Yemike Abhilash Chandra

The device tree overlay for the IMX219 sensor requires three voltage supplies to be defined: VANA (analog), VDIG (digital core), and VDDL (digital I/O). Add the corresponding voltage supply definitions to avoid dtbs_check warnings. Fixes: f767eb918096 ("arm64: dts: ti: k3-j721e-sk: Add overlay for IMX219") Cc: stable(a)vger.kernel.org Signed-off-by: Yemike Abhilash Chandra <y-abhilashchandra(a)ti.com> --- .../dts/ti/k3-j721e-sk-csi2-dual-imx219.dtso | 33 +++++++++++++++++++ 1 file changed, 33 insertions(+) diff --git a/arch/arm64/boot/dts/ti/k3-j721e-sk-csi2-dual-imx219.dtso b/arch/arm64/boot/dts/ti/k3-j721e-sk-csi2-dual-imx219.dtso index 4a395d1209c8..4eb3cffab032 100644 --- a/arch/arm64/boot/dts/ti/k3-j721e-sk-csi2-dual-imx219.dtso +++ b/arch/arm64/boot/dts/ti/k3-j721e-sk-csi2-dual-imx219.dtso @@ -19,6 +19,33 @@ clk_imx219_fixed: imx219-xclk { #clock-cells = <0>; clock-frequency = <24000000>; }; + + reg_2p8v: regulator-2p8v { + compatible = "regulator-fixed"; + regulator-name = "2P8V"; + regulator-min-microvolt = <2800000>; + regulator-max-microvolt = <2800000>; + vin-supply = <&vdd_sd_dv>; + regulator-always-on; + }; + + reg_1p8v: regulator-1p8v { + compatible = "regulator-fixed"; + regulator-name = "1P8V"; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <1800000>; + vin-supply = <&vdd_sd_dv>; + regulator-always-on; + }; + + reg_1p2v: regulator-1p2v { + compatible = "regulator-fixed"; + regulator-name = "1P2V"; + regulator-min-microvolt = <1200000>; + regulator-max-microvolt = <1200000>; + vin-supply = <&vdd_sd_dv>; + regulator-always-on; + }; }; &csi_mux { @@ -34,6 +61,9 @@ imx219_0: imx219-0@10 { reg = <0x10>; clocks = <&clk_imx219_fixed>; + VANA-supply = <&reg_2p8v>; + VDIG-supply = <&reg_1p8v>; + VDDL-supply = <&reg_1p2v>; port { csi2_cam0: endpoint { @@ -55,6 +85,9 @@ imx219_1: imx219-1@10 { reg = <0x10>; clocks = <&clk_imx219_fixed>; + VANA-supply = <&reg_2p8v>; + VDIG-supply = <&reg_1p8v>; + VDDL-supply = <&reg_1p2v>; port { csi2_cam1: endpoint { -- 2.34.1

5 hours, 16 minutes

2
2
0 0

[PATCH] rust: kasan/kbuild: fix missing flags on first build

by Miguel Ojeda

If KASAN is enabled, and one runs in a clean repository e.g.: make LLVM=1 prepare make LLVM=1 prepare Then the Rust code gets rebuilt, which should not happen. The reason is some of the LLVM KASAN `rustc` flags are added in the second run: -Cllvm-args=-asan-instrumentation-with-call-threshold=10000 -Cllvm-args=-asan-stack=0 -Cllvm-args=-asan-globals=1 -Cllvm-args=-asan-kernel-mem-intrinsic-prefix=1 Further runs do not rebuild Rust because the flags do not change anymore. Rebuilding like that in the second run is bad, even if this just happens with KASAN enabled, but missing flags in the first one is even worse. The root issue is that we pass, for some architectures and for the moment, a generated `target.json` file. That file is not ready by the time `rustc` gets called for the flag test, and thus the flag test fails just because the file is not available, e.g.: $ ... --target=./scripts/target.json ... -Cllvm-args=... error: target file "./scripts/target.json" does not exist There are a few approaches we could take here to solve this. For instance, we could ensure that every time that the config is rebuilt, we regenerate the file and recompute the flags. Or we could use the LLVM version to check for these flags, instead of testing the flag (which may have other advantages, such as allowing us to detect renames on the LLVM side). However, it may be easier than that: `rustc` is aware of the `-Cllvm-args` regardless of the `--target` (e.g. I checked that the list printed is the same, plus that I can check for these flags even if I pass a completely unrelated target), and thus we can just eliminate the dependency completely. Thus filter out the target. This does mean that `rustc-option` cannot be used to test a flag that requires the right target, but we don't have other users yet, it is a minimal change and we want to get rid of custom targets in the future. We could only filter in the case `target.json` is used, to make it work in more cases, but then it would be harder to notice that it may not work in a couple architectures. Cc: Matthew Maurer <mmaurer(a)google.com> Cc: Sami Tolvanen <samitolvanen(a)google.com> Cc: stable(a)vger.kernel.org Fixes: e3117404b411 ("kbuild: rust: Enable KASAN support") Signed-off-by: Miguel Ojeda <ojeda(a)kernel.org> --- By the way, I noticed that we are not getting `asan-instrument-allocas` enabled in neither C nor Rust -- upstream LLVM renamed it in commit 8176ee9b5dda ("[asan] Rename asan-instrument-allocas -> asan-instrument-dynamic-allocas")). But it happened a very long time ago (9 years ago), and the addition in the kernel is fairly old too, in 342061ee4ef3 ("kasan: support alloca() poisoning"). I assume it should either be renamed or removed? Happy to send a patch if so. scripts/Makefile.compiler | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/Makefile.compiler b/scripts/Makefile.compiler index 8956587b8547..7ed7f92a7daa 100644 --- a/scripts/Makefile.compiler +++ b/scripts/Makefile.compiler @@ -80,7 +80,7 @@ ld-option = $(call try-run, $(LD) $(KBUILD_LDFLAGS) $(1) -v,$(1),$(2),$(3)) # TODO: remove RUSTC_BOOTSTRAP=1 when we raise the minimum GNU Make version to 4.4 __rustc-option = $(call try-run,\ echo '#![allow(missing_docs)]#![feature(no_core)]#![no_core]' | RUSTC_BOOTSTRAP=1\ - $(1) --sysroot=/dev/null $(filter-out --sysroot=/dev/null,$(2)) $(3)\ + $(1) --sysroot=/dev/null $(filter-out --sysroot=/dev/null --target=%,$(2)) $(3)\ --crate-type=rlib --out-dir=$(TMPOUT) --emit=obj=- - >/dev/null,$(3),$(4)) # rustc-option base-commit: 0af2f6be1b4281385b618cb86ad946eded089ac8 -- 2.49.0

5 hours, 35 minutes

4
4
0 0

[PATCH RESEND] sparc: fix error handling in scan_one_device()

by Ma Ke

Once of_device_register() failed, we should call put_device() to decrement reference count for cleanup. Or it could cause memory leak. So fix this by calling put_device(), then the name can be freed in kobject_cleanup(). As comment of device_add() says, 'if device_add() succeeds, you should call device_del() when you want to get rid of it. If device_add() has not succeeded, use only put_device() to drop the reference count'. Found by code review. Cc: stable(a)vger.kernel.org Fixes: cf44bbc26cf1 ("[SPARC]: Beginnings of generic of_device framework.") Signed-off-by: Ma Ke <make24(a)iscas.ac.cn> --- arch/sparc/kernel/of_device_64.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/sparc/kernel/of_device_64.c b/arch/sparc/kernel/of_device_64.c index f98c2901f335..4272746d7166 100644 --- a/arch/sparc/kernel/of_device_64.c +++ b/arch/sparc/kernel/of_device_64.c @@ -677,7 +677,7 @@ static struct platform_device * __init scan_one_device(struct device_node *dp, if (of_device_register(op)) { printk("%pOF: Could not register of device.\n", dp); - kfree(op); + put_device(&op->dev); op = NULL; } -- 2.25.1

5 hours, 38 minutes

1
0
0 0

[PATCH v1 1/2] platform/x86: int3472: add hpd pin support

by Dongcheng Yan

Typically HDMI to MIPI CSI-2 bridges have a pin to signal image data is being received. On the host side this is wired to a GPIO for polling or interrupts. This includes the Lontium HDMI to MIPI CSI-2 bridges lt6911uxe and lt6911uxc. The GPIO "hpd" is used already by other HDMI to CSI-2 bridges, use it here as well. Signed-off-by: Dongcheng Yan <dongcheng.yan(a)intel.com> --- drivers/platform/x86/intel/int3472/common.h | 1 + drivers/platform/x86/intel/int3472/discrete.c | 6 ++++++ 2 files changed, 7 insertions(+) diff --git a/drivers/platform/x86/intel/int3472/common.h b/drivers/platform/x86/intel/int3472/common.h index 145dec66df64..db4cd3720e24 100644 --- a/drivers/platform/x86/intel/int3472/common.h +++ b/drivers/platform/x86/intel/int3472/common.h @@ -22,6 +22,7 @@ #define INT3472_GPIO_TYPE_POWER_ENABLE 0x0b #define INT3472_GPIO_TYPE_CLK_ENABLE 0x0c #define INT3472_GPIO_TYPE_PRIVACY_LED 0x0d +#define INT3472_GPIO_TYPE_HOTPLUG_DETECT 0x13 #define INT3472_PDEV_MAX_NAME_LEN 23 #define INT3472_MAX_SENSOR_GPIOS 3 diff --git a/drivers/platform/x86/intel/int3472/discrete.c b/drivers/platform/x86/intel/int3472/discrete.c index 30ff8f3ea1f5..28d41b1b3809 100644 --- a/drivers/platform/x86/intel/int3472/discrete.c +++ b/drivers/platform/x86/intel/int3472/discrete.c @@ -186,6 +186,10 @@ static void int3472_get_con_id_and_polarity(struct acpi_device *adev, u8 *type, *con_id = "privacy-led"; *gpio_flags = GPIO_ACTIVE_HIGH; break; + case INT3472_GPIO_TYPE_HOTPLUG_DETECT: + *con_id = "hpd"; + *gpio_flags = GPIO_LOOKUP_FLAGS_DEFAULT; + break; case INT3472_GPIO_TYPE_POWER_ENABLE: *con_id = "power-enable"; *gpio_flags = GPIO_ACTIVE_HIGH; @@ -212,6 +216,7 @@ static void int3472_get_con_id_and_polarity(struct acpi_device *adev, u8 *type, * 0x0b Power enable * 0x0c Clock enable * 0x0d Privacy LED + * 0x13 Hotplug detect * * There are some known platform specific quirks where that does not quite * hold up; for example where a pin with type 0x01 (Power down) is mapped to @@ -281,6 +286,7 @@ static int skl_int3472_handle_gpio_resources(struct acpi_resource *ares, switch (type) { case INT3472_GPIO_TYPE_RESET: case INT3472_GPIO_TYPE_POWERDOWN: + case INT3472_GPIO_TYPE_HOTPLUG_DETECT: ret = skl_int3472_map_gpio_to_sensor(int3472, agpio, con_id, gpio_flags); if (ret) err_msg = "Failed to map GPIO pin to sensor\n"; base-commit: 01c6df60d5d4ae00cd5c1648818744838bba7763 -- 2.34.1

5 hours, 47 minutes

6
12
0 0

[PATCH V2 6.14.y 0/7] arm64/boot: Enable EL2 requirements for FEAT_PMUv3p9

by Anshuman Khandual

This series adds fine grained trap control in EL2 required for FEAT_PMUv3p9 registers like PMICNTR_EL0, PMICFILTR_EL0, and PMUACR_EL1 which are already being used in the kernel. This is required to prevent their EL1 access trap into EL2. The following commits that enabled access into FEAT_PMUv3p9 registers have already been merged upstream from 6.12 onwards. d8226d8cfbaf ("perf: arm_pmuv3: Add support for Armv9.4 PMU instruction counter") 0bbff9ed8165 ("perf/arm_pmuv3: Add PMUv3.9 per counter EL0 access control") The sysreg patches in this series are required for the final patch which fixes the actual problem. Changes in V2: - Replaced [] with () for upstream commit reference across patches in response to the following warning from Sasha https://lore.kernel.org/stable/f1153021-846b-4fb1-8c4d-9fa813f982d3@arm.com/ Anshuman Khandual (7): arm64/sysreg: Update register fields for ID_AA64MMFR0_EL1 arm64/sysreg: Add register fields for HDFGRTR2_EL2 arm64/sysreg: Add register fields for HDFGWTR2_EL2 arm64/sysreg: Add register fields for HFGITR2_EL2 arm64/sysreg: Add register fields for HFGRTR2_EL2 arm64/sysreg: Add register fields for HFGWTR2_EL2 arm64/boot: Enable EL2 requirements for FEAT_PMUv3p9 Documentation/arch/arm64/booting.rst | 22 ++++++ arch/arm64/include/asm/el2_setup.h | 25 +++++++ arch/arm64/tools/sysreg | 103 +++++++++++++++++++++++++++ 3 files changed, 150 insertions(+) -- 2.30.2

5 hours, 48 minutes

2
14
0 0

[PATCH 5.10.y] vfio/pci: fix memory leak during D3hot to D0 transition

by Feng Liu

From: Abhishek Sahu <abhsahu(a)nvidia.com> [ Upstream commit eadf88ecf6ac7d6a9f47a76c6055d9a1987a8991 ] If 'vfio_pci_core_device::needs_pm_restore' is set (PCI device does not have No_Soft_Reset bit set in its PMCSR config register), then the current PCI state will be saved locally in 'vfio_pci_core_device::pm_save' during D0->D3hot transition and same will be restored back during D3hot->D0 transition. For saving the PCI state locally, pci_store_saved_state() is being used and the pci_load_and_free_saved_state() will free the allocated memory. But for reset related IOCTLs, vfio driver calls PCI reset-related API's which will internally change the PCI power state back to D0. So, when the guest resumes, then it will get the current state as D0 and it will skip the call to vfio_pci_set_power_state() for changing the power state to D0 explicitly. In this case, the memory pointed by 'pm_save' will never be freed. In a malicious sequence, the state changing to D3hot followed by VFIO_DEVICE_RESET/VFIO_DEVICE_PCI_HOT_RESET can be run in a loop and it can cause an OOM situation. This patch frees the earlier allocated memory first before overwriting 'pm_save' to prevent the mentioned memory leak. Fixes: 51ef3a004b1e ("vfio/pci: Restore device state on PM transition") Signed-off-by: Abhishek Sahu <abhsahu(a)nvidia.com> Link: https://lore.kernel.org/r/20220217122107.22434-2-abhsahu@nvidia.com Signed-off-by: Alex Williamson <alex.williamson(a)redhat.com> [Minor context change fixed] Signed-off-by: Feng Liu <Feng.Liu3(a)windriver.com> Signed-off-by: He Zhe <Zhe.He(a)windriver.com> --- Verified the build test. --- drivers/vfio/pci/vfio_pci.c | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c index 57ae8b46b836..7835712f730d 100644 --- a/drivers/vfio/pci/vfio_pci.c +++ b/drivers/vfio/pci/vfio_pci.c @@ -299,6 +299,19 @@ int vfio_pci_set_power_state(struct vfio_pci_device *vdev, pci_power_t state) if (!ret) { /* D3 might be unsupported via quirk, skip unless in D3 */ if (needs_save && pdev->current_state >= PCI_D3hot) { + /* + * The current PCI state will be saved locally in + * 'pm_save' during the D3hot transition. When the + * device state is changed to D0 again with the current + * function, then pci_store_saved_state() will restore + * the state and will free the memory pointed by + * 'pm_save'. There are few cases where the PCI power + * state can be changed to D0 without the involvement + * of the driver. For these cases, free the earlier + * allocated memory first before overwriting 'pm_save' + * to prevent the memory leak. + */ + kfree(vdev->pm_save); vdev->pm_save = pci_store_saved_state(pdev); } else if (needs_restore) { pci_load_and_free_saved_state(pdev, &vdev->pm_save); -- 2.34.1

5 hours, 48 minutes

2
1
0 0

[PATCH v2 0/3] Restrict devmem for confidential VMs

by Dan Williams

Changes since v1 [1]: * Fix the fact that devmem_is_allowed() == 2 does not prevent mmap access (Kees) * Rather than teach devmem_is_allowed() == 2 to map zero pages in the mmap case, just fail (Nikolay) [1]: http://lore.kernel.org/67f5b75c37143_71fe2949b@dwillia2-xfh.jf.intel.com.no… --- The story starts with Nikolay reporting an SEPT violation due to mismatched encrypted/non-encrypted mappings of the BIOS data space [2]. An initial suggestion to just make sure that the BIOS data space is mapped consistently [3] ran into another issue that TDX and SEV-SNP disagree about when that space can be mapped as encrypted. Then, in response to a partial patch to allow SEV-SNP to block BIOS data space for other reasons [4], Dave asked why not just give up on /dev/mem access entirely in the confidential VM case [5]. Enter this series to: 1/ Close a subtle hole whereby /dev/mem that is supposed return zeros in lieu of access only enforces that for read()/write() 2/ Use that new closed hole to reliably disable all /dev/mem access for confidential x86 VMs [2]: http://lore.kernel.org/20250318113604.297726-1-nik.borisov@suse.com [3]: http://lore.kernel.org/174346288005.2166708.14425674491111625620.stgit@dwil… [4]: http://lore.kernel.org/20250403120228.2344377-1-naveen@kernel.org [5]: http://lore.kernel.org/fd683daa-d953-48ca-8c5d-6f4688ad442c@intel.com --- Dan Williams (3): x86/devmem: Remove duplicate range_is_allowed() definition devmem: Block mmap access when read/write access is restricted x86/devmem: Restrict /dev/mem access for potentially unaccepted memory by default arch/x86/Kconfig | 2 ++ arch/x86/include/asm/x86_init.h | 2 ++ arch/x86/kernel/x86_init.c | 6 ++++++ arch/x86/mm/init.c | 23 +++++++++++++++++------ arch/x86/mm/pat/memtype.c | 31 ++++--------------------------- drivers/char/mem.c | 18 ------------------ include/linux/io.h | 26 ++++++++++++++++++++++++++ 7 files changed, 57 insertions(+), 51 deletions(-) base-commit: 0af2f6be1b4281385b618cb86ad946eded089ac8

6 hours, 1 minute

2
2
0 0

[PATCH] f2fs: fix to do sanity check on sit_bitmap_size

by Chao Yu

w/ below testcase, resize will generate a corrupted image which contains inconsistent metadata, so when mounting such image, it will trigger kernel panic: touch img truncate -s $((512*1024*1024*1024)) img mkfs.f2fs -f img $((256*1024*1024)) resize.f2fs -s -i img -t $((1024*1024*1024)) mount img /mnt/f2fs ------------[ cut here ]------------ kernel BUG at fs/f2fs/segment.h:863! Oops: invalid opcode: 0000 [#1] SMP PTI CPU: 11 UID: 0 PID: 3922 Comm: mount Not tainted 6.15.0-rc1+ #191 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:f2fs_ra_meta_pages+0x47c/0x490 Call Trace: f2fs_build_segment_manager+0x11c3/0x2600 f2fs_fill_super+0xe97/0x2840 mount_bdev+0xf4/0x140 legacy_get_tree+0x2b/0x50 vfs_get_tree+0x29/0xd0 path_mount+0x487/0xaf0 __x64_sys_mount+0x116/0x150 do_syscall_64+0x82/0x190 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7fdbfde1bcfe The reaseon is: sit_i->bitmap_size is 192, so size of sit bitmap is 192*8=1536, at maximum there are 1536 sit blocks, however MAIN_SEGS is 261893, so that sit_blk_cnt is 4762, build_sit_entries() -> current_sit_addr() tries to access out-of-boundary in sit_bitmap at offset from [1536, 4762), once sit_bitmap and sit_bitmap_mirror is not the same, it will trigger f2fs_bug_on(). Let's add sanity check in f2fs_sanity_check_ckpt() to avoid panic. Cc: stable(a)vger.kernel.org Signed-off-by: Chao Yu <chao(a)kernel.org> --- fs/f2fs/super.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c index eb1275616d8c..8abfbee13204 100644 --- a/fs/f2fs/super.c +++ b/fs/f2fs/super.c @@ -3716,6 +3716,7 @@ int f2fs_sanity_check_ckpt(struct f2fs_sb_info *sbi) block_t user_block_count, valid_user_blocks; block_t avail_node_count, valid_node_count; unsigned int nat_blocks, nat_bits_bytes, nat_bits_blocks; + unsigned int sit_blk_cnt; int i, j; total = le32_to_cpu(raw_super->segment_count); @@ -3827,6 +3828,13 @@ int f2fs_sanity_check_ckpt(struct f2fs_sb_info *sbi) return 1; } + sit_blk_cnt = DIV_ROUND_UP(main_segs, SIT_ENTRY_PER_BLOCK); + if (sit_bitmap_size * 8 < sit_blk_cnt) { + f2fs_err(sbi, "Wrong bitmap size: sit: %u, sit_blk_cnt:%u", + sit_bitmap_size, sit_blk_cnt); + return 1; + } + cp_pack_start_sum = __start_sum_addr(sbi); cp_payload = __cp_payload(sbi); if (cp_pack_start_sum < cp_payload + 1 || -- 2.49.0

6 hours, 2 minutes

1
0
0 0

[PATCH 00/20] Add support for HEVC and VP9 codecs in decoder

by Dikshita Agarwal

Hi All, This patch series adds initial support for the HEVC(H.265) and VP9 codecs in iris decoder. The objective of this work is to extend the decoder's capabilities to handle HEVC and VP9 codec streams, including necessary format handling and buffer management. In addition, the series also includes a set of fixes to address issues identified during testing of these additional codecs. These patches also address the comments and feedback received from the RFC patches previously sent. I have made the necessary improvements based on the community's suggestions. Changes sinces RFC: - Added additional fixes to address issues identified during further testing. - Moved typo fix to a seperate patch [Neil] - Reordered the patches for better logical flow and clarity [Neil, Dmitry] - Added fixes tag wherever applicable [Neil, Dmitry] - Removed the default case in the switch statement for codecs [Bryan] - Replaced if-else statements with switch-case [Bryan] - Added comments for mbpf [Bryan] - RFC: https://lore.kernel.org/linux-media/20250305104335.3629945-1-quic_dikshita@… These patches are tested on SM8250 and SM8550 with v4l2-ctl and Gstreamer for HEVC and VP9 decoders, at the same time ensured that the existing H264 decoder functionality remains uneffected. Note: 1 of the fluster compliance test is fixed with firmware [1] [1]: https://lore.kernel.org/linux-firmware/1a511921-446d-cdc4-0203-084c88a5dc1e… The result of fluster test on SM8550: 131/147 testcases passed while testing JCT-VC-HEVC_V1 with GStreamer-H.265-V4L2-Gst1.0. The failing test case: - 10 testcases failed due to unsupported 10 bit format. - DBLK_A_MAIN10_VIXS_4 - INITQP_B_Main10_Sony_1 - TSUNEQBD_A_MAIN10_Technicolor_2 - WP_A_MAIN10_Toshiba_3 - WP_MAIN10_B_Toshiba_3 - WPP_A_ericsson_MAIN10_2 - WPP_B_ericsson_MAIN10_2 - WPP_C_ericsson_MAIN10_2 - WPP_E_ericsson_MAIN10_2 - WPP_F_ericsson_MAIN10_2 - 4 testcase failed due to unsupported resolution - PICSIZE_A_Bossen_1 - PICSIZE_B_Bossen_1 - WPP_D_ericsson_MAIN10_2 - WPP_D_ericsson_MAIN_2 - 1 testcase failed as bitstream is invalid (this fails with reference as well) - RAP_B_Bossen_2 - 1 testcase failed due to CRC mismatch - RAP_A_docomo_6 Analysis - First few frames in this discarded by firmware and are sent to driver with 0 filled length. Driver send such buffers to client with timestamp 0 and payload set to 0 and make buf state to VB2_BUF_STATE_ERROR. Such buffers should be dropped by GST. But instead, the first frame displayed as green frame and when a valid buffer is sent to client later with same 0 timestamp, its dropped, leading to CRC mismatch for first frame. 235/305 testcases passed while testing VP9-TEST-VECTORS with GStreamer-VP9-V4L2-Gst1.0. The failing test case: - 64 testcases failed due to unsupported resolution - vp90-2-02-size-08x08.webm - vp90-2-02-size-08x10.webm - vp90-2-02-size-08x16.webm - vp90-2-02-size-08x18.webm - vp90-2-02-size-08x32.webm - vp90-2-02-size-08x34.webm - vp90-2-02-size-08x64.webm - vp90-2-02-size-08x66.webm - vp90-2-02-size-10x08.webm - vp90-2-02-size-10x10.webm - vp90-2-02-size-10x16.webm - vp90-2-02-size-10x18.webm - vp90-2-02-size-10x32.webm - vp90-2-02-size-10x34.webm - vp90-2-02-size-10x64.webm - vp90-2-02-size-10x66.webm - vp90-2-02-size-16x08.webm - vp90-2-02-size-16x10.webm - vp90-2-02-size-16x16.webm - vp90-2-02-size-16x18.webm - vp90-2-02-size-16x32.webm - vp90-2-02-size-16x34.webm - vp90-2-02-size-16x64.webm - vp90-2-02-size-16x66.webm - vp90-2-02-size-18x08.webm - vp90-2-02-size-18x10.webm - vp90-2-02-size-18x16.webm - vp90-2-02-size-18x18.webm - vp90-2-02-size-18x32.webm - vp90-2-02-size-18x34.webm - vp90-2-02-size-18x64.webm - vp90-2-02-size-18x66.webm - vp90-2-02-size-32x08.webm - vp90-2-02-size-32x10.webm - vp90-2-02-size-32x16.webm - vp90-2-02-size-32x18.webm - vp90-2-02-size-32x32.webm - vp90-2-02-size-32x34.webm - vp90-2-02-size-32x64.webm - vp90-2-02-size-32x66.webm - vp90-2-02-size-34x08.webm - vp90-2-02-size-34x10.webm - vp90-2-02-size-34x16.webm - vp90-2-02-size-34x18.webm - vp90-2-02-size-34x32.webm - vp90-2-02-size-34x34.webm - vp90-2-02-size-34x64.webm - vp90-2-02-size-34x66.webm - vp90-2-02-size-64x08.webm - vp90-2-02-size-64x10.webm - vp90-2-02-size-64x16.webm - vp90-2-02-size-64x18.webm - vp90-2-02-size-64x32.webm - vp90-2-02-size-64x34.webm - vp90-2-02-size-64x64.webm - vp90-2-02-size-64x66.webm - vp90-2-02-size-66x08.webm - vp90-2-02-size-66x10.webm - vp90-2-02-size-66x16.webm - vp90-2-02-size-66x18.webm - vp90-2-02-size-66x32.webm - vp90-2-02-size-66x34.webm - vp90-2-02-size-66x64.webm - vp90-2-02-size-66x66.webm - 2 testcases failed due to unsupported format - vp91-2-04-yuv422.webm - vp91-2-04-yuv444.webm - 1 testcase failed with CRC mismatch (fails with ref decoder as well) - vp90-2-22-svc_1280x720_3.ivf - 2 testcase failed due to unsupported resolution after sequence change - vp90-2-21-resize_inter_320x180_5_1-2.webm - vp90-2-21-resize_inter_320x180_7_1-2.webm - 1 testcase failed due to unsupported stream - vp90-2-16-intra-only.webm Note: There is a timing issue with the clips having multiple resolution change. Where firmware returned all the buffers with previous sequence and has no buffer left to attach the LAST flag to. At the same time, client is not queueing any further buffers, so there is deadlock where client is waiting for LAST flag, while firmware doesn't have any capture buffer to attach LAST flag to. Ideally client should keep queueing the buffers on capture queue untill the LAST flag is received. The result of fluster test on SM8250: 132/147 testcases passed while testing JCT-VC-HEVC_V1 with GStreamer-H.265-V4L2-Gst1.0. The failing test case: - 10 testcases failed due to unsupported 10 bit format. - DBLK_A_MAIN10_VIXS_4 - INITQP_B_Main10_Sony_1 - TSUNEQBD_A_MAIN10_Technicolor_2 - WP_A_MAIN10_Toshiba_3 - WP_MAIN10_B_Toshiba_3 - WPP_A_ericsson_MAIN10_2 - WPP_B_ericsson_MAIN10_2 - WPP_C_ericsson_MAIN10_2 - WPP_E_ericsson_MAIN10_2 - WPP_F_ericsson_MAIN10_2 - 4 testcase failed due to unsupported resolution - PICSIZE_A_Bossen_1 - PICSIZE_B_Bossen_1 - WPP_D_ericsson_MAIN10_2 - WPP_D_ericsson_MAIN_2 - 1 testcase failed as bitstream is invalid (this fails with reference as well) - RAP_B_Bossen_2 232/305 testcases passed while testing VP9-TEST-VECTORS with GStreamer-VP9-V4L2-Gst1.0. The failing test case: - 64 testcases failed due to unsupported resolution - vp90-2-02-size-08x08.webm - vp90-2-02-size-08x10.webm - vp90-2-02-size-08x16.webm - vp90-2-02-size-08x18.webm - vp90-2-02-size-08x32.webm - vp90-2-02-size-08x34.webm - vp90-2-02-size-08x64.webm - vp90-2-02-size-08x66.webm - vp90-2-02-size-10x08.webm - vp90-2-02-size-10x10.webm - vp90-2-02-size-10x16.webm - vp90-2-02-size-10x18.webm - vp90-2-02-size-10x32.webm - vp90-2-02-size-10x34.webm - vp90-2-02-size-10x64.webm - vp90-2-02-size-10x66.webm - vp90-2-02-size-16x08.webm - vp90-2-02-size-16x10.webm - vp90-2-02-size-16x16.webm - vp90-2-02-size-16x18.webm - vp90-2-02-size-16x32.webm - vp90-2-02-size-16x34.webm - vp90-2-02-size-16x64.webm - vp90-2-02-size-16x66.webm - vp90-2-02-size-18x08.webm - vp90-2-02-size-18x10.webm - vp90-2-02-size-18x16.webm - vp90-2-02-size-18x18.webm - vp90-2-02-size-18x32.webm - vp90-2-02-size-18x34.webm - vp90-2-02-size-18x64.webm - vp90-2-02-size-18x66.webm - vp90-2-02-size-32x08.webm - vp90-2-02-size-32x10.webm - vp90-2-02-size-32x16.webm - vp90-2-02-size-32x18.webm - vp90-2-02-size-32x32.webm - vp90-2-02-size-32x34.webm - vp90-2-02-size-32x64.webm - vp90-2-02-size-32x66.webm - vp90-2-02-size-34x08.webm - vp90-2-02-size-34x10.webm - vp90-2-02-size-34x16.webm - vp90-2-02-size-34x18.webm - vp90-2-02-size-34x32.webm - vp90-2-02-size-34x34.webm - vp90-2-02-size-34x64.webm - vp90-2-02-size-34x66.webm - vp90-2-02-size-64x08.webm - vp90-2-02-size-64x10.webm - vp90-2-02-size-64x16.webm - vp90-2-02-size-64x18.webm - vp90-2-02-size-64x32.webm - vp90-2-02-size-64x34.webm - vp90-2-02-size-64x64.webm - vp90-2-02-size-64x66.webm - vp90-2-02-size-66x08.webm - vp90-2-02-size-66x10.webm - vp90-2-02-size-66x16.webm - vp90-2-02-size-66x18.webm - vp90-2-02-size-66x32.webm - vp90-2-02-size-66x34.webm - vp90-2-02-size-66x64.webm - vp90-2-02-size-66x66.webm - 2 testcases failed due to unsupported format - vp91-2-04-yuv422.webm - vp91-2-04-yuv444.webm - 1 testcase failed with CRC mismatch (fails with ref decoder as well) - vp90-2-22-svc_1280x720_3.ivf - 5 testcase failed due to unsupported resolution after sequence change - vp90-2-21-resize_inter_320x180_5_1-2.webm - vp90-2-21-resize_inter_320x180_7_1-2.webm - vp90-2-21-resize_inter_320x240_5_1-2.webm - vp90-2-21-resize_inter_320x240_7_1-2.webm - vp90-2-18-resize.ivf - 1 testcase failed with CRC mismatch - vp90-2-16-intra-only.webm Analysis: First few frames are marked by firmware as NO_SHOW frame. Driver make buf state to VB2_BUF_STATE_ERROR for such frames. Such buffers should be dropped by GST. But instead, the first frame is being displayed and when a valid buffer is sent to client later with same timestamp, its dropped, leading to CRC mismatch for first frame. Note: Same timing issue as observed on SM8550 is seen on SM8250 as well. Signed-off-by: Dikshita Agarwal <quic_dikshita(a)quicinc.com> --- Dikshita Agarwal (20): media: iris: Skip destroying internal buffer if not dequeued media: iris: Update CAPTURE format info based on OUTPUT format media: iris: Add handling for corrupt and drop frames media: iris: Avoid updating frame size to firmware during reconfig media: iris: Send V4L2_BUF_FLAG_ERROR for buffers with 0 filled length media: iris: Add handling for no show frames media: iris: Improve last flag handling media: iris: Skip flush on first sequence change media: iris: Prevent HFI queue writes when core is in deinit state media: iris: Remove redundant buffer count check in stream off media: iris: Remove deprecated property setting to firmware media: iris: Fix missing function pointer initialization media: iris: Fix NULL pointer dereference media: iris: Fix typo in depth variable media: iris: Add a comment to explain usage of MBPS media: iris: Add HEVC and VP9 formats for decoder media: iris: Add platform capabilities for HEVC and VP9 decoders media: iris: Set mandatory properties for HEVC and VP9 decoders. media: iris: Add internal buffer calculation for HEVC and VP9 decoders media: iris: Add codec specific check for VP9 decoder drain handling drivers/media/platform/qcom/iris/iris_buffer.c | 22 +- drivers/media/platform/qcom/iris/iris_ctrls.c | 35 +- drivers/media/platform/qcom/iris/iris_hfi_common.h | 1 + .../platform/qcom/iris/iris_hfi_gen1_command.c | 44 ++- .../platform/qcom/iris/iris_hfi_gen1_defines.h | 5 +- .../platform/qcom/iris/iris_hfi_gen1_response.c | 22 +- .../platform/qcom/iris/iris_hfi_gen2_command.c | 143 +++++++- .../platform/qcom/iris/iris_hfi_gen2_defines.h | 5 + .../platform/qcom/iris/iris_hfi_gen2_response.c | 57 ++- drivers/media/platform/qcom/iris/iris_hfi_queue.c | 2 +- drivers/media/platform/qcom/iris/iris_instance.h | 6 + .../platform/qcom/iris/iris_platform_common.h | 28 +- .../platform/qcom/iris/iris_platform_sm8250.c | 15 +- .../platform/qcom/iris/iris_platform_sm8550.c | 143 +++++++- drivers/media/platform/qcom/iris/iris_vb2.c | 3 +- drivers/media/platform/qcom/iris/iris_vdec.c | 113 +++--- drivers/media/platform/qcom/iris/iris_vdec.h | 11 + drivers/media/platform/qcom/iris/iris_vidc.c | 3 - drivers/media/platform/qcom/iris/iris_vpu_buffer.c | 397 ++++++++++++++++++++- drivers/media/platform/qcom/iris/iris_vpu_buffer.h | 46 ++- 20 files changed, 948 insertions(+), 153 deletions(-) --- base-commit: 7824b91d23e9f255f0e9d2acaa74265c9cac2e9c change-id: 20250402-iris-dec-hevc-vp9-2654a1fc4d0d Best regards, -- Dikshita Agarwal <quic_dikshita(a)quicinc.com>

6 hours, 31 minutes

6
18
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror