[next] arm64: db410c: Internal error: Oops: 96000004 - pc : sysfs_kf_seq_show
Arnd Bergmann
arnd at arndb.de
Wed Jun 15 03:48:38 PDT 2022
On Tue, Jun 14, 2022 at 10:57 PM Naresh Kamboju
<naresh.kamboju at linaro.org> wrote:
>
> Following kernel crash reported while booting arm64 db410c board with
> Linux next-20220614 [1] kfence enabled on this kernel.
>
> CONFIG_KFENCE=y
>
>
> Reported-by: Linux Kernel Functional Testing <lkft at linaro.org>
Did it work on older linux-next kernels with KFENCE enabled, or did you
just start enabling it?
>
> Boot log:
> ---------
> [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd030]
> [ 0.000000] Linux version 5.19.0-rc2-next-20220614
> (tuxmake at tuxmake) (aarch64-linux-gnu-gcc (Debian 11.3.0-3) 11.3.0, GNU
> ld (GNU Binutils for Debian) 2.38) #1 SMP PREEMPT @1655189659
> [ 0.000000] Machine model: Qualcomm Technologies, Inc. APQ 8016 SBC
> [ 0.000000] efi: UEFI not found.
> [ 0.000000] [Firmware Bug]: Kernel image misaligned at boot, please
> fix your bootloader!
This is probably unrelated, but try updating your boot loader to get rid of
this warning.
> <trim>
> [ 0.000000] kfence: initialized - using 2097152 bytes for 255
> objects at 0x(____ptrval____)-0x(____ptrval____)
> <trim>
> [ 11.317288] Unable to handle kernel NULL pointer dereference at
> virtual address 0000000000000000
> [ 11.317361] Mem abort info:
> [ 11.317906] Unable to handle kernel paging request at virtual
> address 0000000029f63007
> [ 11.328825] Unable to handle kernel NULL pointer dereference at
> virtual address 0000000000000009
> [ 11.334704] ESR = 0x0000000096000004
> [ 11.343115] Unable to handle kernel NULL pointer dereference at
> virtual address 0000000000000000
> [ 11.357163] Mem abort info:
> [ 11.357217] ESR = 0x0000000096000004
> [ 11.359935] Mem abort info:
> [ 11.369085] Mem abort info:
> [ 11.369138] ESR = 0x0000000096000004
> [ 11.373564] EC = 0x25: DABT (current EL), IL = 32 bits
> [ 11.374530] SET = 0, FnV = 0
> [ 11.382591] EC = 0x25: DABT (current EL), IL = 32 bits
> [ 11.382864] SET = 0, FnV = 0
> [ 11.400484] ESR = 0x0000000096000004
> [ 11.411713] EC = 0x25: DABT (current EL), IL = 32 bits
> [ 11.411776] SET = 0, FnV = 0
> [ 11.422177] EA = 0, S1PTW = 0
> [ 11.422234] FSC = 0x04: level 0 translation fault
> [ 11.422724] EC = 0x25: DABT (current EL), IL = 32 bits
> [ 11.424129] Data abort info:
> [ 11.428397] EA = 0, S1PTW = 0
> [ 11.428416] FSC = 0x04: level 0 translation fault
> [ 11.428427] Data abort info:
> [ 11.428434] ISV = 0, ISS = 0x00000004
> [ 11.428442] CM = 0, WnR = 0
> [ 11.428451] user pgtable: 4k pages, 48-bit VAs, pgdp=00000000854b8000
> [ 11.428464] [0000000029f63007] pgd=0000000000000000, p4d=0000000000000000
> [ 11.428494] Internal error: Oops: 96000004 [#1] PREEMPT SMP
> [ 11.428503] Modules linked in: venus_enc venus_dec
> videobuf2_dma_contig crct10dif_ce adv7511(+) cec qcom_wcnss_pil
> snd_soc_msm8916_analog qcom_pon qcom_spmi_temp_alarm rtc_pm8xxx
> qcom_spmi_vadc snd_soc_lpass_apq8016 qcom_vadc_common
> snd_soc_msm8916_digital snd_soc_lpass_cpu snd_soc_apq8016_sbc
> snd_soc_lpass_platform qcom_q6v5_mss snd_soc_qcom_common qcom_pil_info
> msm qcom_camss qcom_q6v5 gpu_sched qcom_sysmon drm_dp_aux_bus
> venus_core qcom_common videobuf2_dma_sg v4l2_mem2mem v4l2_fwnode
> qcom_glink_smem v4l2_async videobuf2_memops qmi_helpers videobuf2_v4l2
> mdt_loader qnoc_msm8916 drm_display_helper videobuf2_common
> i2c_qcom_cci qcom_rng qcom_stats icc_smd_rpm rfkill display_connector
> drm_kms_helper drm socinfo rmtfs_mem qrtr fuse
> [ 11.428683] CPU: 3 PID: 312 Comm: systemd-udevd Tainted: G W
> 5.19.0-rc2-next-20220614 #1
> [ 11.428694] Hardware name: Qualcomm Technologies, Inc. APQ 8016 SBC (DT)
> [ 11.428699] pstate: 00000005 (nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> [ 11.428709] pc : sysfs_kf_seq_show+0x3c/0x130
> [ 11.428724] lr : kernfs_seq_show+0x38/0x44
> [ 11.428735] sp : ffff80000b7ebbf0
> [ 11.428739] x29: ffff80000b7ebbf0 x28: 0000000000000001 x27: 0000000000400cc0
> [ 11.428753] x26: 000000007ffff000 x25: ffff000005581290 x24: ffff000005581280
> [ 11.428767] x23: 0000000000000000 x22: ffff0000056dd520 x21: ffff000004413d00
> [ 11.428780] x20: 0000000029f62fff x19: ffff000005581258 x18: 0000000000000000
> [ 11.428793] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
> [ 11.428806] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000
> [ 11.428819] x11: 0000000000000000 x10: 0000000000000000 x9 : ffff8000084b0ca8
> [ 11.428832] x8 : 0000000000000000 x7 : 0000000000000200 x6 : 0000000000000000
> [ 11.428845] x5 : 0000000000000000 x4 : 0000000000000001 x3 : ffff000004413d00
> [ 11.428857] x2 : ffff8000084b2e64 x1 : 0000000000000001 x0 : ffff000002368a00
It appears that kobj->ktype is x20 here, which is a user space address
(0x29f62fff),
reading ->sysfs_ops at offset 8 from that causes a trap.
static const struct sysfs_ops *sysfs_file_ops(struct kernfs_node *kn)
{
struct kobject *kobj = kn->parent->priv;
if (kn->flags & KERNFS_LOCKDEP)
lockdep_assert_held(kn);
return kobj->ktype ? kobj->ktype->sysfs_ops : NULL;
}
static int sysfs_kf_seq_show(struct seq_file *sf, void *v)
{
struct kernfs_open_file *of = sf->private;
struct kobject *kobj = of->kn->parent->priv;
const struct sysfs_ops *ops = sysfs_file_ops(of->kn);
...
ffff800008432e64 <sysfs_kf_seq_show>:
ffff800008432e64: d503245f bti c
ffff800008432e68: d503201f nop
ffff800008432e6c: d503201f nop
ffff800008432e70: d503233f paciasp
ffff800008432e74: a9bd7bfd stp x29, x30, [sp, #-48]!
ffff800008432e78: 910003fd mov x29, sp
ffff800008432e7c: a90153f3 stp x19, x20, [sp, #16]
ffff800008432e80: aa0003f3 mov x19, x0
ffff800008432e84: a9025bf5 stp x21, x22, [sp, #32]
ffff800008432e88: f9403815 ldr x21, [x0, #112] # of
= sf->private
ffff800008432e8c: f94002a0 ldr x0, [x21] # of->kn
ffff800008432e90: f9400400 ldr x0, [x0, #8] # kn->parent
ffff800008432e94: f9403016 ldr x22, [x0, #96] # kobj
= parent->priv
ffff800008432e98: f94016d4 ldr x20, [x22, #40] # kobj-> ktype
ffff800008432e9c: b4000054 cbz x20, ffff800008432ea4
<sysfs_kf_seq_show+0x40>
ffff800008432ea0: f9400694 ldr x20, [x20, #8] #
ktype->sysfs_ops, traps
...
Arnd
More information about the linux-arm-kernel
mailing list