Skip to content

Conversation

@ranj063
Copy link
Collaborator

@ranj063 ranj063 commented Dec 4, 2018

debugfs entries can be used to expose two different types of
memories:

  1. DSP memory and registers
  2. kernel buffers

We should use type struct snd_sof_dfsentry_io for the first one
and type struct snd_sof_dfsentry_buf for the second type.

So split the snd_sof_debugfs_create_item() into two flavours
based on the memory pointed to. snd_sof_debugfs_io_create_item()
should be used for io memory and
snd_sof_debugfs_buf_create_item() should beused for
kernel buffers, for example, the fw_version member
of snd_sof_dev.

Signed-off-by: Ranjani Sridharan ranjani.sridharan@linux.intel.com

@ranj063 ranj063 force-pushed the fix/debugfs_create_item branch from 5144da3 to ea2d735 Compare December 4, 2018 20:47
Copy link
Member

@plbossart plbossart left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just need to be rebased and use the same code w/ devm_

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you use the latest code, this was moved to:
dfse = devm_kzalloc(sdev->dev, sizeof(*dfse), GFP_KERNEL);

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@plbossart done

@ranj063 ranj063 force-pushed the fix/debugfs_create_item branch from ea2d735 to 797395b Compare December 5, 2018 03:17
Copy link
Member

@plbossart plbossart left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the perils of copy/paste (and not running tests with sparse?)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Gotcha.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lol really sorry about it. :)

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@plbossart fixed. I'm going to take all the changes that went in today and test everything today. I will keep you posted if I see a red flag.

debugfs entries can be used to expose two different types of
memories:
1. DSP memory and registers
2. kernel buffers

We should use type struct snd_sof_dfsentry_io for the first one
and type struct snd_sof_dfsentry_buf for the second type.

So split the snd_sof_debugfs_create_item() into two flavours
based on the memory pointed to. snd_sof_debugfs_io_create_item()
should be used for io memory and
snd_sof_debugfs_buf_create_item() should beused for
kernel buffers, for example, the fw_version member
of snd_sof_dev.

Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
@ranj063 ranj063 force-pushed the fix/debugfs_create_item branch from 797395b to 28502ca Compare December 5, 2018 03:29
@xiulipan
Copy link

xiulipan commented Dec 5, 2018

@ranj063
LGTM.
I think this can be used later for more debugfs.

Copy link
Member

@plbossart plbossart left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

let's merge and test further

@plbossart plbossart merged commit d0fbf1c into thesofproject:topic/sof-dev Dec 5, 2018
bardliao pushed a commit to bardliao/linux that referenced this pull request Nov 11, 2025
The following splat was reported:

    Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010
    Mem abort info:
      ESR = 0x0000000096000004
      EC = 0x25: DABT (current EL), IL = 32 bits
      SET = 0, FnV = 0
      EA = 0, S1PTW = 0
      FSC = 0x04: level 0 translation fault
    Data abort info:
      ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
      CM = 0, WnR = 0, TnD = 0, TagAccess = 0
      GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
    user pgtable: 4k pages, 48-bit VAs, pgdp=00000008d0fd8000
    [0000000000000010] pgd=0000000000000000, p4d=0000000000000000
    Internal error: Oops: 0000000096000004 [#1]  SMP
    CPU: 5 UID: 1000 PID: 149076 Comm: Xwayland Tainted: G S                  6.16.0-rc2-00809-g0b6974bb4134-dirty thesofproject#367 PREEMPT
    Tainted: [S]=CPU_OUT_OF_SPEC
    Hardware name: Qualcomm Technologies, Inc. SM8650 HDK (DT)
    pstate: 83400005 (Nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--)
    pc : build_detached_freelist+0x28/0x224
    lr : kmem_cache_free_bulk.part.0+0x38/0x244
    sp : ffff000a508c7a20
    x29: ffff000a508c7a20 x28: ffff000a508c7d50 x27: ffffc4e49d16f350
    x26: 0000000000000058 x25: 00000000fffffffc x24: 0000000000000000
    x23: ffff00098c4e1450 x22: 00000000fffffffc x21: 0000000000000000
    x20: ffff000a508c7af8 x19: 0000000000000002 x18: 00000000000003e8
    x17: ffff000809523850 x16: ffff000809523820 x15: 0000000000401640
    x14: ffff000809371140 x13: 0000000000000130 x12: ffff0008b5711e30
    x11: 00000000001058fa x10: 0000000000000a80 x9 : ffff000a508c7940
    x8 : ffff000809371ba0 x7 : 781fffe033087fff x6 : 0000000000000000
    x5 : ffff0008003cd000 x4 : 781fffe033083fff x3 : ffff000a508c7af8
    x2 : fffffdffc0000000 x1 : 0001000000000000 x0 : ffff0008001a6a00
    Call trace:
     build_detached_freelist+0x28/0x224 (P)
     kmem_cache_free_bulk.part.0+0x38/0x244
     kmem_cache_free_bulk+0x10/0x1c
     msm_iommu_pagetable_prealloc_cleanup+0x3c/0xd0
     msm_vma_job_free+0x30/0x240
     msm_ioctl_vm_bind+0x1d0/0x9a0
     drm_ioctl_kernel+0x84/0x104
     drm_ioctl+0x358/0x4d4
     __arm64_sys_ioctl+0x8c/0xe0
     invoke_syscall+0x44/0x100
     el0_svc_common.constprop.0+0x3c/0xe0
     do_el0_svc+0x18/0x20
     el0_svc+0x30/0x100
     el0t_64_sync_handler+0x104/0x130
     el0t_64_sync+0x170/0x174
    Code: aa0203f5 b26287e2 f2dfbfe2 aa0303f4 (f8737ab6)
    ---[ end trace 0000000000000000 ]---

Since msm_vma_job_free() is called directly from the ioctl, this looks
like an error path cleanup issue.  Which I think results from
prealloc_cleanup() called without a preceding successful
prealloc_allocate() call.  So handle that case better.

Reported-by: Connor Abbott <cwabbott0@gmail.com>
Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/678677/
Message-ID: <20251006153542.419998-1-robin.clark@oss.qualcomm.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants