Message-ID: <CA+G9fYvEGBAAEetvvtXWsGb3EQ2sTOM=szkxZ4m-Gt2bTszBdQ@mail.gmail.com>
Date: Thu, 7 Aug 2025 14:51:29 +0530
From: Naresh Kamboju <naresh.kamboju@...aro.org>
To: Dan Carpenter <dan.carpenter@...aro.org>
Cc: Renjiang Han <quic_renjiang@...cinc.com>, 
	"open list:KERNEL SELFTEST FRAMEWORK" <linux-kselftest@...r.kernel.org>, Cgroups <cgroups@...r.kernel.org>, 
	open list <linux-kernel@...r.kernel.org>, lkft-triage@...ts.linaro.org, 
	Linux Regressions <regressions@...ts.linux.dev>, linux-fsdevel@...r.kernel.org, 
	Song Liu <song@...nel.org>, yukuai3@...wei.com, Arnd Bergmann <arnd@...db.de>, 
	Anders Roxell <anders.roxell@...aro.org>, Ben Copeland <benjamin.copeland@...aro.org>
Subject: Re: next-20250804 Unable to handle kernel execute from non-executable
 memory at virtual address idem_hash

Hi Dan,

On Wed, 6 Aug 2025 at 20:24, Dan Carpenter <dan.carpenter@...aro.org> wrote:
>
> On Tue, Aug 05, 2025 at 12:50:28AM +0530, Naresh Kamboju wrote:
> > While booting and testing selftest cgroups and filesystem testing on arm64
> > dragonboard-410c the following kernel warnings / errors noticed and system
> > halted and did not recover with selftests Kconfig enabled running the kernel
> > Linux next tag next-20250804.
> >
> > Regression Analysis:
> > - New regression? Yes
> > - Reproducibility? Re-validation is in progress
> >
> > First seen on the next-20250804
> > Good: next-20250801
> > Bad: next-20250804
> >
> > Test regression: next-20250804 Unable to handle kernel execute from
> > non-executable memory at virtual address idem_hash
> > Test regression: next-20250804 refcount_t: addition on 0;
> > use-after-free refcount_warn_saturate
> >
> > Reported-by: Linux Kernel Functional Testing <lkft@...aro.org>
> >
> > ## Test crash log
> > [    9.811341] Unable to handle kernel NULL pointer dereference at
> > virtual address 000000000000002e
> > [    9.811444] Mem abort info:
> > [    9.821150]   ESR = 0x0000000096000004
> > [    9.833499]   SET = 0, FnV = 0
> > [    9.833566]   EA = 0, S1PTW = 0
> > [    9.835511]   FSC = 0x04: level 0 translation fault
> > [    9.838901] Data abort info:
> > [    9.843788]   ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
> > [    9.846565]   CM = 0, WnR = 0, TnD = 0, TagAccess = 0
> > [    9.851938]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
> > [    9.853510] rtc-pm8xxx 200f000.spmi:pmic@0:rtc@...0: registered as rtc0
> > [    9.856992] user pgtable: 4k pages, 48-bit VAs, pgdp=00000000856f8000
> > [    9.862446] rtc-pm8xxx 200f000.spmi:pmic@0:rtc@...0: setting system
> > clock to 1970-01-01T00:00:31 UTC (31)
> > [    9.868789] [000000000000002e] pgd=0000000000000000, p4d=0000000000000000
> > [    9.875459] Internal error: Oops: 0000000096000004 [#1]  SMP
> > [    9.889547] input: pm8941_pwrkey as
> > /devices/platform/soc@...00f000.spmi/spmi-0/0-00/200f000.spmi:pmic@0:pon@.../200f000.spmi:pmic@0:pon@800:pwrkey/input/input1
> > [    9.891545] Modules linked in: qcom_spmi_temp_alarm rtc_pm8xxx
> > qcom_pon(+) qcom_pil_info videobuf2_dma_sg ubwc_config qcom_q6v5
> > venus_core(+) qcom_sysmon qcom_spmi_vadc v4l2_fwnode llcc_qcom
> > v4l2_async qcom_vadc_common qcom_common ocmem v4l2_mem2mem drm_gpuvm
> > videobuf2_memops qcom_glink_smem videobuf2_v4l2 drm_exec mdt_loader
> > qmi_helpers gpu_sched drm_dp_aux_bus qnoc_msm8916 videodev
> > drm_display_helper qcom_stats videobuf2_common cec qcom_rng
> > drm_client_lib mc phy_qcom_usb_hs socinfo rpmsg_ctrl display_connector
> > rpmsg_char ramoops rmtfs_mem reed_solomon drm_kms_helper fuse drm
> > backlight
> > [    9.912286] input: pm8941_resin as
> > /devices/platform/soc@...00f000.spmi/spmi-0/0-00/200f000.spmi:pmic@0:pon@.../200f000.spmi:pmic@0:pon@800:resin/input/input2
> > [    9.941186] CPU: 2 UID: 0 PID: 221 Comm: (udev-worker) Not tainted
> > 6.16.0-next-20250804 #1 PREEMPT
> > [    9.941200] Hardware name: Qualcomm Technologies, Inc. APQ 8016 SBC (DT)
> > [    9.941206] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> > [    9.941215] pc : dev_pm_opp_put (/builds/linux/drivers/opp/core.c:1685)
> > [    9.941233] lr : core_clks_enable+0x54/0x148 venus_core
> > [   10.004266] sp : ffff8000842b35f0
> > [   10.004273] x29: ffff8000842b35f0 x28: ffff8000842b3ba0 x27: ffff0000047be938
> > [   10.004289] x26: 0000000000000000 x25: 0000000000000000 x24: ffff80007b350ba0
> > [   10.004303] x23: ffff00000ba380c8 x22: ffff00000ba38080 x21: 0000000000000000
> > [   10.004316] x20: 0000000000000000 x19: ffffffffffffffee x18: 00000000ffffffff
> > [   10.004330] x17: 0000000000000000 x16: 1fffe000017541a1 x15: ffff8000842b3560
> > [   10.004344] x14: 0000000000000000 x13: 007473696c5f7974 x12: 696e696666615f65
> > [   10.004358] x11: 00000000000000c0 x10: 0000000000000020 x9 : ffff80007b33f2bc
> > [   10.004371] x8 : ffffffffffffffde x7 : ffff0000044a4800 x6 : 0000000000000000
> > [   10.004384] x5 : 0000000000000002 x4 : 00000000c0000000 x3 : 0000000000000001
> > [   10.004397] x2 : 0000000000000002 x1 : ffffffffffffffde x0 : ffffffffffffffee
> > [   10.004412] Call trace:
> > [   10.004417] dev_pm_opp_put (/builds/linux/drivers/opp/core.c:1685) (P)
> > [   10.004435] core_clks_enable+0x54/0x148 venus_core
> > [   10.004504] core_power_v1+0x78/0x90 venus_core
> > [   10.004560] venus_runtime_resume+0x6c/0x98 venus_core
> > [   10.004616] pm_generic_runtime_resume
>
> Could you try adding some error checking to core_clks_enable()?
> Does the patch below help?

Your patch works.
The attached patch from Sasha fixes this reported problem on today's
Linux next tag.

$ git log --oneline next-20250805..next-20250807 --
drivers/media/platform/qcom/venus/pm_helpers.c
7881cd6886a89 media: venus: Fix OPP table error handling

- Naresh

View attachment "media-venus-fix-opp-table-error-handling.patch" of type "text/x-patch" (2334 bytes)

Powered by blists - more mailing lists