Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

15 participants
3337 discussions

[REGRESSION] BUG: KFENCE: memory corruption in drm_gem_put_pages+0x186/0x250

by Oleksandr Natalenko

Hello. I've got a VM from a cloud provider, and since v6.5 I observe the following kfence splat in dmesg during boot: ``` BUG: KFENCE: memory corruption in drm_gem_put_pages+0x186/0x250 Corrupted memory at 0x00000000e173a294 [ ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ] (in kfence-#108): drm_gem_put_pages+0x186/0x250 drm_gem_shmem_put_pages_locked+0x43/0xc0 drm_gem_shmem_object_vunmap+0x83/0xe0 drm_gem_vunmap_unlocked+0x46/0xb0 drm_fbdev_generic_helper_fb_dirty+0x1dc/0x310 drm_fb_helper_damage_work+0x96/0x170 process_one_work+0x254/0x470 worker_thread+0x55/0x4f0 kthread+0xe8/0x120 ret_from_fork+0x34/0x50 ret_from_fork_asm+0x1b/0x30 kfence-#108: 0x00000000cda343af-0x00000000aec2c095, size=3072, cache=kmalloc-4k allocated by task 51 on cpu 0 at 14.668667s: drm_gem_get_pages+0x94/0x2b0 drm_gem_shmem_get_pages+0x5d/0x110 drm_gem_shmem_object_vmap+0xc4/0x1e0 drm_gem_vmap_unlocked+0x3c/0x70 drm_client_buffer_vmap+0x23/0x50 drm_fbdev_generic_helper_fb_dirty+0xae/0x310 drm_fb_helper_damage_work+0x96/0x170 process_one_work+0x254/0x470 worker_thread+0x55/0x4f0 kthread+0xe8/0x120 ret_from_fork+0x34/0x50 ret_from_fork_asm+0x1b/0x30 freed by task 51 on cpu 0 at 14.668697s: drm_gem_put_pages+0x186/0x250 drm_gem_shmem_put_pages_locked+0x43/0xc0 drm_gem_shmem_object_vunmap+0x83/0xe0 drm_gem_vunmap_unlocked+0x46/0xb0 drm_fbdev_generic_helper_fb_dirty+0x1dc/0x310 drm_fb_helper_damage_work+0x96/0x170 process_one_work+0x254/0x470 worker_thread+0x55/0x4f0 kthread+0xe8/0x120 ret_from_fork+0x34/0x50 ret_from_fork_asm+0x1b/0x30 CPU: 0 PID: 51 Comm: kworker/0:2 Not tainted 6.5.0-pf4 #1 8b557a4173114d86eef7240f7a080080cfc4617e Hardware name: Red Hat KVM, BIOS 1.11.0-2.el7 04/01/2014 Workqueue: events drm_fb_helper_damage_work ``` This repeats a couple of times and then stops. Currently, I'm running v6.5.5. So far, there's no impact on how VM functions for me. The VGA adapter is as follows: 00:02.0 VGA compatible controller: Cirrus Logic GD 5446 Please check. Thanks. -- Oleksandr Natalenko (post-factum)

2 years, 4 months

Re: [PATCH 01/10] drm/mediatek: Add interface to allocate MediaTek GEM buffer.

by Jeffrey Kardatzke

You can remove the DRIVER_RENDER flag from this patchset. That should not be upstreamed. The IOCTLs are still needed though because of the flag for allocating a secure surface that is in the next patch. If that flag wasn't needed, then dumb buffer allocations could be used instead. Thanks, Jeff Kardatzke

2 years, 4 months

[PATCH] dma-buf: heaps: Fix off by one in cma_heap_vm_fault()

by Dan Carpenter

The buffer->pages[] has "buffer->pagecount" elements so this > comparison has to be changed to >= to avoid reading beyond the end of the array. The buffer->pages[] array is allocated in cma_heap_allocate(). Fixes: a5d2d29e24be ("dma-buf: heaps: Move heap-helper logic into the cma_heap implementation") Signed-off-by: Dan Carpenter <dan.carpenter(a)linaro.org> --- drivers/dma-buf/heaps/cma_heap.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/dma-buf/heaps/cma_heap.c b/drivers/dma-buf/heaps/cma_heap.c index ee899f8e6721..bea7e574f916 100644 --- a/drivers/dma-buf/heaps/cma_heap.c +++ b/drivers/dma-buf/heaps/cma_heap.c @@ -165,7 +165,7 @@ static vm_fault_t cma_heap_vm_fault(struct vm_fault *vmf) struct vm_area_struct *vma = vmf->vma; struct cma_heap_buffer *buffer = vma->vm_private_data; - if (vmf->pgoff > buffer->pagecount) + if (vmf->pgoff >= buffer->pagecount) return VM_FAULT_SIGBUS; vmf->page = buffer->pages[vmf->pgoff]; -- 2.39.2

2 years, 4 months

[PATCH] udmabuf: Fix a potential (and unlikely) access to unallocated memory

by Christophe JAILLET

If 'list_limit' is set to a very high value, 'lsize' computation could overflow if 'head.count' is big enough. In such a case, udmabuf_create() will access to memory beyond 'list'. Use size_mul() to saturate the value, and have memdup_user() fail. Fixes: fbb0de795078 ("Add udmabuf misc device") Signed-off-by: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> --- drivers/dma-buf/udmabuf.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c index c40645999648..fb4c4b5b3332 100644 --- a/drivers/dma-buf/udmabuf.c +++ b/drivers/dma-buf/udmabuf.c @@ -314,13 +314,13 @@ static long udmabuf_ioctl_create_list(struct file *filp, unsigned long arg) struct udmabuf_create_list head; struct udmabuf_create_item *list; int ret = -EINVAL; - u32 lsize; + size_t lsize; if (copy_from_user(&head, (void __user *)arg, sizeof(head))) return -EFAULT; if (head.count > list_limit) return -EINVAL; - lsize = sizeof(struct udmabuf_create_item) * head.count; + lsize = size_mul(sizeof(struct udmabuf_create_item), head.count); list = memdup_user((void __user *)(arg + sizeof(head)), lsize); if (IS_ERR(list)) return PTR_ERR(list); -- 2.34.1

2 years, 4 months

Re: [PATCH 00/10] Add mediate-drm secure flow for SVP

by Jeffrey Kardatzke

On Tue, Sep 19, 2023 at 10:26 PM CK Hu (胡俊光) <ck.hu(a)mediatek.com> wrote: > > Hi, Jason: > > On Tue, 2023-09-19 at 11:03 +0800, Jason-JH.Lin wrote: > > The patch series provides drm driver support for enabling secure > > video > > path (SVP) playback on MediaiTek hardware in the Linux kernel. > > > > Memory Definitions: > > secure memory - Memory allocated in the TEE (Trusted Execution > > Environment) which is inaccessible in the REE (Rich Execution > > Environment, i.e. linux kernel/userspace). > > secure handle - Integer value which acts as reference to 'secure > > memory'. Used in communication between TEE and REE to reference > > 'secure memory'. > > secure buffer - 'secure memory' that is used to store decrypted, > > compressed video or for other general purposes in the TEE. > > secure surface - 'secure memory' that is used to store graphic > > buffers. > > > > Memory Usage in SVP: > > The overall flow of SVP starts with encrypted video coming in from an > > outside source into the REE. The REE will then allocate a 'secure > > buffer' and send the corresponding 'secure handle' along with the > > encrypted, compressed video data to the TEE. The TEE will then > > decrypt > > the video and store the result in the 'secure buffer'. The REE will > > then allocate a 'secure surface'. The REE will pass the 'secure > > handles' for both the 'secure buffer' and 'secure surface' into the > > TEE for video decoding. The video decoder HW will then decode the > > contents of the 'secure buffer' and place the result in the 'secure > > surface'. The REE will then attach the 'secure surface' to the > > overlay > > plane for rendering of the video. > > > > Everything relating to ensuring security of the actual contents of > > the > > 'secure buffer' and 'secure surface' is out of scope for the REE and > > is the responsibility of the TEE. > > > > DRM driver handles allocation of gem objects that are backed by a > > 'secure > > surface' and for displaying a 'secure surface' on the overlay plane. > > This introduces a new flag for object creation called > > DRM_MTK_GEM_CREATE_ENCRYPTED which indicates it should be a 'secure > > surface'. All changes here are in MediaTek specific code. > > How do you define SVP? Is there standard requirement we could refer to? > If the secure video buffer is read by display hardware and output to > HDMI without any protection and user could capture HDMI signal, is this > secure? SVP (Secure Video Path) is essentially the video being completed isolated from the kernel/userspace. The specific requirements for it vary between implementations. Regarding HDMI/HDCP output; it's the responsibility of the TEE to enforce that. Nothing on the kernel/userspace side needs to be concerned about enforcing HDCP. The only thing userspace is involved in there is actually turning on HDCP via the kernel drivers; and then the TEE ensures that it is active if the policy for the encrypted content requires it. > > Regards, > CK > > > > > --- > > Based on 2 series: > > [1] Add CMDQ secure driver for SVP > > - > > https://urldefense.com/v3/__https://patchwork.kernel.org/project/linux-medi… > > > > > > [2] dma-buf: heaps: Add MediaTek secure heap > > - > > https://urldefense.com/v3/__https://patchwork.kernel.org/project/linux-medi… > > > > --- > > > > CK Hu (1): > > drm/mediatek: Add interface to allocate MediaTek GEM buffer. > > > > Jason-JH.Lin (9): > > drm/mediatek/uapi: Add DRM_MTK_GEM_CREATED_ENCRYPTTED flag > > drm/mediatek: Add secure buffer control flow to mtk_drm_gem > > drm/mediatek: Add secure identify flag and funcution to > > mtk_drm_plane > > drm/mediatek: Add mtk_ddp_sec_write to config secure buffer info > > drm/mediatek: Add get_sec_port interface to mtk_ddp_comp > > drm/mediatek: Add secure layer config support for ovl > > drm/mediatek: Add secure layer config support for ovl_adaptor > > drm/mediatek: Add secure flow support to mediatek-drm > > arm64: dts: mt8195-cherry: Add secure mbox settings for vdosys > > > > .../boot/dts/mediatek/mt8195-cherry.dtsi | 10 + > > drivers/gpu/drm/mediatek/mtk_disp_drv.h | 3 + > > drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 31 +- > > .../gpu/drm/mediatek/mtk_disp_ovl_adaptor.c | 15 + > > drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 271 > > +++++++++++++++++- > > drivers/gpu/drm/mediatek/mtk_drm_crtc.h | 1 + > > drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 14 + > > drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 13 + > > drivers/gpu/drm/mediatek/mtk_drm_drv.c | 16 +- > > drivers/gpu/drm/mediatek/mtk_drm_gem.c | 121 ++++++++ > > drivers/gpu/drm/mediatek/mtk_drm_gem.h | 16 ++ > > drivers/gpu/drm/mediatek/mtk_drm_plane.c | 7 + > > drivers/gpu/drm/mediatek/mtk_drm_plane.h | 2 + > > drivers/gpu/drm/mediatek/mtk_mdp_rdma.c | 11 +- > > drivers/gpu/drm/mediatek/mtk_mdp_rdma.h | 2 + > > include/uapi/drm/mediatek_drm.h | 59 ++++ > > 16 files changed, 575 insertions(+), 17 deletions(-) > > create mode 100644 include/uapi/drm/mediatek_drm.h > >

2 years, 4 months

[PATCH 00/10] Add mediate-drm secure flow for SVP

by Jason-JH.Lin

The patch series provides drm driver support for enabling secure video path (SVP) playback on MediaiTek hardware in the Linux kernel. Memory Definitions: secure memory - Memory allocated in the TEE (Trusted Execution Environment) which is inaccessible in the REE (Rich Execution Environment, i.e. linux kernel/userspace). secure handle - Integer value which acts as reference to 'secure memory'. Used in communication between TEE and REE to reference 'secure memory'. secure buffer - 'secure memory' that is used to store decrypted, compressed video or for other general purposes in the TEE. secure surface - 'secure memory' that is used to store graphic buffers. Memory Usage in SVP: The overall flow of SVP starts with encrypted video coming in from an outside source into the REE. The REE will then allocate a 'secure buffer' and send the corresponding 'secure handle' along with the encrypted, compressed video data to the TEE. The TEE will then decrypt the video and store the result in the 'secure buffer'. The REE will then allocate a 'secure surface'. The REE will pass the 'secure handles' for both the 'secure buffer' and 'secure surface' into the TEE for video decoding. The video decoder HW will then decode the contents of the 'secure buffer' and place the result in the 'secure surface'. The REE will then attach the 'secure surface' to the overlay plane for rendering of the video. Everything relating to ensuring security of the actual contents of the 'secure buffer' and 'secure surface' is out of scope for the REE and is the responsibility of the TEE. DRM driver handles allocation of gem objects that are backed by a 'secure surface' and for displaying a 'secure surface' on the overlay plane. This introduces a new flag for object creation called DRM_MTK_GEM_CREATE_ENCRYPTED which indicates it should be a 'secure surface'. All changes here are in MediaTek specific code. --- Based on 2 series: [1] Add CMDQ secure driver for SVP - https://patchwork.kernel.org/project/linux-mediatek/list/?series=785332 [2] dma-buf: heaps: Add MediaTek secure heap - https://patchwork.kernel.org/project/linux-mediatek/list/?series=782776 --- CK Hu (1): drm/mediatek: Add interface to allocate MediaTek GEM buffer. Jason-JH.Lin (9): drm/mediatek/uapi: Add DRM_MTK_GEM_CREATED_ENCRYPTTED flag drm/mediatek: Add secure buffer control flow to mtk_drm_gem drm/mediatek: Add secure identify flag and funcution to mtk_drm_plane drm/mediatek: Add mtk_ddp_sec_write to config secure buffer info drm/mediatek: Add get_sec_port interface to mtk_ddp_comp drm/mediatek: Add secure layer config support for ovl drm/mediatek: Add secure layer config support for ovl_adaptor drm/mediatek: Add secure flow support to mediatek-drm arm64: dts: mt8195-cherry: Add secure mbox settings for vdosys .../boot/dts/mediatek/mt8195-cherry.dtsi | 10 + drivers/gpu/drm/mediatek/mtk_disp_drv.h | 3 + drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 31 +- .../gpu/drm/mediatek/mtk_disp_ovl_adaptor.c | 15 + drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 271 +++++++++++++++++- drivers/gpu/drm/mediatek/mtk_drm_crtc.h | 1 + drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 14 + drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 13 + drivers/gpu/drm/mediatek/mtk_drm_drv.c | 16 +- drivers/gpu/drm/mediatek/mtk_drm_gem.c | 121 ++++++++ drivers/gpu/drm/mediatek/mtk_drm_gem.h | 16 ++ drivers/gpu/drm/mediatek/mtk_drm_plane.c | 7 + drivers/gpu/drm/mediatek/mtk_drm_plane.h | 2 + drivers/gpu/drm/mediatek/mtk_mdp_rdma.c | 11 +- drivers/gpu/drm/mediatek/mtk_mdp_rdma.h | 2 + include/uapi/drm/mediatek_drm.h | 59 ++++ 16 files changed, 575 insertions(+), 17 deletions(-) create mode 100644 include/uapi/drm/mediatek_drm.h -- 2.18.0

2 years, 4 months

[syzbot] [dri?] WARNING in drm_gem_object_handle_put_unlocked

by syzbot

Hello, syzbot found the following issue on: HEAD commit: 0bb80ecc33a8 Linux 6.6-rc1 git tree: upstream console+strace: https://syzkaller.appspot.com/x/log.txt?x=1002530c680000 kernel config: https://syzkaller.appspot.com/x/.config?x=f4894cf58531f dashboard link: https://syzkaller.appspot.com/bug?extid=ef3256a360c02207a4cb compiler: gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=14a79ca0680000 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=16900402680000 Downloadable assets: disk image: https://storage.googleapis.com/syzbot-assets/eeb0cac260c7/disk-0bb80ecc.raw… vmlinux: https://storage.googleapis.com/syzbot-assets/a3c360110254/vmlinux-0bb80ecc.… kernel image: https://storage.googleapis.com/syzbot-assets/22b81065ba5f/bzImage-0bb80ecc.… IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+ef3256a360c02207a4cb(a)syzkaller.appspotmail.com R10: 0000000000000000 R11: 0000000000000246 R12: 00007fda971e917c R13: 00007fda97153210 R14: 0023647261632f69 R15: 6972642f7665642f </TASK> ------------[ cut here ]------------ WARNING: CPU: 1 PID: 5043 at drivers/gpu/drm/drm_gem.c:225 drm_gem_object_handle_put_unlocked+0x299/0x390 drivers/gpu/drm/drm_gem.c:225 Modules linked in: CPU: 1 PID: 5043 Comm: syz-executor141 Not tainted 6.6.0-rc1-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/04/2023 RIP: 0010:drm_gem_object_handle_put_unlocked+0x299/0x390 drivers/gpu/drm/drm_gem.c:225 Code: ea 03 0f b6 04 02 84 c0 74 0c 3c 03 7f 08 4c 89 f7 e8 2b 06 2a fd c7 83 20 01 00 00 00 00 00 00 e9 98 fe ff ff e8 57 44 d4 fc <0f> 0b 5b 5d 41 5c 41 5d 41 5e e9 48 44 d4 fc e8 43 44 d4 fc 48 8d RSP: 0018:ffffc90003d5fbb8 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffff888027b61000 RCX: 0000000000000000 RDX: ffff888014fcbb80 RSI: ffffffff84b38a29 RDI: 0000000000000005 RBP: ffff888027b61004 R08: 0000000000000005 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000001 R12: ffff88801d140000 R13: ffff888027b61008 R14: 0000000000000000 R15: ffff888027b61018 FS: 00007fda971536c0(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fda971fe794 CR3: 0000000072975000 CR4: 00000000003506e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> drm_gem_handle_create_tail+0x32f/0x540 drivers/gpu/drm/drm_gem.c:407 drm_gem_shmem_create_with_handle drivers/gpu/drm/drm_gem_shmem_helper.c:417 [inline] drm_gem_shmem_dumb_create+0x21a/0x310 drivers/gpu/drm/drm_gem_shmem_helper.c:505 drm_mode_create_dumb drivers/gpu/drm/drm_dumb_buffers.c:96 [inline] drm_mode_create_dumb_ioctl+0x268/0x2f0 drivers/gpu/drm/drm_dumb_buffers.c:102 drm_ioctl_kernel+0x280/0x4c0 drivers/gpu/drm/drm_ioctl.c:789 drm_ioctl+0x5cb/0xbf0 drivers/gpu/drm/drm_ioctl.c:892 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:871 [inline] __se_sys_ioctl fs/ioctl.c:857 [inline] __x64_sys_ioctl+0x18f/0x210 fs/ioctl.c:857 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x38/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7fda971954e9 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 51 18 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fda971531f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007fda9721c3e8 RCX: 00007fda971954e9 RDX: 0000000020000080 RSI: 00000000c02064b2 RDI: 0000000000000003 RBP: 00007fda9721c3e0 R08: 00007fda97152f96 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007fda971e917c R13: 00007fda97153210 R14: 0023647261632f69 R15: 6972642f7665642f </TASK> --- This report is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkaller(a)googlegroups.com. syzbot will keep track of this issue. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot. If the bug is already fixed, let syzbot know by replying with: #syz fix: exact-commit-title If you want syzbot to run the reproducer, reply with: #syz test: git://repo/address.git branch-or-commit-hash If you attach or paste a git patch, syzbot will apply it before testing. If you want to overwrite bug's subsystems, reply with: #syz set subsystems: new-subsystem (See the list of subsystem names on the web dashboard) If the bug is a duplicate of another bug, reply with: #syz dup: exact-subject-of-another-report If you want to undo deduplication, reply with: #syz undup

2 years, 4 months

Re: [syzbot] [mm?] kernel BUG in filemap_unaccount_folio

by syzbot

syzbot has bisected this issue to: commit 5c074eeabbd332b11559f7fc1e89d456f94801fb Author: Gerd Hoffmann <kraxel(a)redhat.com> Date: Wed Nov 14 12:20:29 2018 +0000 udmabuf: set read/write flag when exporting bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=12b21bbfa80000 start commit: db906f0ca6bb Merge tag 'phy-for-6.6' of git://git.kernel.o.. git tree: upstream final oops: https://syzkaller.appspot.com/x/report.txt?x=11b21bbfa80000 console output: https://syzkaller.appspot.com/x/log.txt?x=16b21bbfa80000 kernel config: https://syzkaller.appspot.com/x/.config?x=3bd57a1ac08277b0 dashboard link: https://syzkaller.appspot.com/bug?extid=17a207d226b8a5fb0fd9 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=11609f38680000 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=14c1fc00680000 Reported-by: syzbot+17a207d226b8a5fb0fd9(a)syzkaller.appspotmail.com Fixes: 5c074eeabbd3 ("udmabuf: set read/write flag when exporting") For information about bisection process see: https://goo.gl/tpsmEJ#bisection

2 years, 4 months

[linus:master] [dma] d62c43a953: WARNING:at_mm/slab_common.c:#kmem_cache_destroy

by kernel test robot

hi, Arvind Yadav, we know this commit is quite old, but it shows persistent low rate issue and parent keeps clean even when we run both this commit and parent up to ~300 times. the config to build both kernel is a randconfig as in https://download.01.org/0day-ci/archive/20230913/202309132239.70437559-oliv… c85d00d4fd8b98ea d62c43a953ce02d54521ec06217 ---------------- --------------------------- fail:runs %reproduction fail:runs | | | :300 6% 17:312 dmesg.BUG_mock_fence(Tainted:G_T):Objects_remaining_in_mock_fence_on__kmem_cache_shutdown() :300 11% 33:312 dmesg.EIP:kmem_cache_destroy :300 11% 33:312 dmesg.WARNING:at_mm/slab_common.c:#kmem_cache_destroy at the same time, as in below formal report mentioned, we still observed similar issue on latest linus/master and linux-next/master, so we just send out this report FYI. Hello, kernel test robot noticed "WARNING:at_mm/slab_common.c:#kmem_cache_destroy" on: commit: d62c43a953ce02d54521ec06217d0c2ed6d489af ("dma-buf: Enable signaling on fence for selftests") https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master [test failed on linus/master 0bb80ecc33a8fb5a682236443c1e740d5c917d1d] [test failed on linux-next/master 3c13c772fc233a10342c8e1605ff0855dfdf0c89] in testcase: boot compiler: gcc-12 test machine: qemu-system-i386 -enable-kvm -cpu SandyBridge -smp 2 -m 4G (please refer to attached dmesg/kmsg for entire log/backtrace) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <oliver.sang(a)intel.com> | Closes: https://lore.kernel.org/oe-lkp/202309132239.70437559-oliver.sang@intel.com [ 21.601153][ T1] ------------[ cut here ]------------ [ 21.693224][ T1] kmem_cache_destroy mock_fence: Slab cache still has objects when called from dma_fence_chain (drivers/dma-buf/st-dma-fence-chain.c:709) [ 21.693275][ T1] WARNING: CPU: 0 PID: 1 at mm/slab_common.c:478 kmem_cache_destroy (mm/slab_common.c:478) [ 21.697039][ T1] Modules linked in: [ 21.697859][ T1] CPU: 0 PID: 1 Comm: swapper Tainted: G T 6.0.0-rc2-00744-gd62c43a953ce #1 26be6099e9dfaf1dc1fa091a1f5a61f95afa9121 [ 21.700290][ T1] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 [ 21.702175][ T1] EIP: kmem_cache_destroy (mm/slab_common.c:478) [ 21.707576][ T1] Code: 00 ff 4b 2c 0f 85 b2 00 00 00 89 d8 e8 ea 4a 02 00 85 c0 74 1f ff 75 04 ff 73 40 68 6c ff 96 d7 68 7d 44 09 d8 e8 40 c8 da 00 <0f> 0b 83 c4 10 e9 88 00 00 00 8d 73 44 89 f0 e8 8a 8e 2e 00 84 c0 All code ======== 0: 00 ff add %bh,%bh 2: 4b 2c 0f rex.WXB sub $0xf,%al 5: 85 b2 00 00 00 89 test %esi,-0x77000000(%rdx) b: d8 e8 fsubr %st(0),%st d: ea (bad) e: 4a 02 00 rex.WX add (%rax),%al 11: 85 c0 test %eax,%eax 13: 74 1f je 0x34 15: ff 75 04 push 0x4(%rbp) 18: ff 73 40 push 0x40(%rbx) 1b: 68 6c ff 96 d7 push $0xffffffffd796ff6c 20: 68 7d 44 09 d8 push $0xffffffffd809447d 25: e8 40 c8 da 00 call 0xdac86a 2a:* 0f 0b ud2 <-- trapping instruction 2c: 83 c4 10 add $0x10,%esp 2f: e9 88 00 00 00 jmp 0xbc 34: 8d 73 44 lea 0x44(%rbx),%esi 37: 89 f0 mov %esi,%eax 39: e8 8a 8e 2e 00 call 0x2e8ec8 3e: 84 c0 test %al,%al Code starting with the faulting instruction =========================================== 0: 0f 0b ud2 2: 83 c4 10 add $0x10,%esp 5: e9 88 00 00 00 jmp 0x92 a: 8d 73 44 lea 0x44(%rbx),%esi d: 89 f0 mov %esi,%eax f: e8 8a 8e 2e 00 call 0x2e8e9e 14: 84 c0 test %al,%al [ 21.711048][ T1] EAX: 00000066 EBX: ee62b680 ECX: 00000001 EDX: 80000001 [ 21.712412][ T1] ESI: d87beb98 EDI: ffffffff EBP: c128dee8 ESP: c128decc [ 21.713723][ T1] DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068 EFLAGS: 00010292 [ 21.715192][ T1] CR0: 80050033 CR2: b7d07070 CR3: 189fe000 CR4: 00040690 [ 21.716533][ T1] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000 [ 21.717859][ T1] DR6: fffe0ff0 DR7: 00000400 [ 21.718792][ T1] Call Trace: [ 21.719488][ T1] ? dma_fence_chain (drivers/dma-buf/st-dma-fence-chain.c:709) [ 21.720419][ T1] dma_fence_chain (drivers/dma-buf/st-dma-fence-chain.c:709) [ 21.721327][ T1] st_init (drivers/dma-buf/selftest.c:141 drivers/dma-buf/selftest.c:155) [ 21.722117][ T1] ? udmabuf_dev_init (drivers/dma-buf/selftest.c:154) [ 21.723147][ T1] do_one_initcall (init/main.c:1296) [ 21.724108][ T1] do_initcalls (init/main.c:1368 init/main.c:1385) [ 21.725029][ T1] kernel_init_freeable (init/main.c:1615) [ 21.726030][ T1] ? rest_init (init/main.c:1492) [ 21.726907][ T1] kernel_init (init/main.c:1502) [ 21.727732][ T1] ret_from_fork (arch/x86/entry/entry_32.S:770) [ 21.728608][ T1] irq event stamp: 1964001 [ 21.729500][ T1] hardirqs last enabled at (1964011): __up_console_sem (arch/x86/include/asm/irqflags.h:29 (discriminator 1) arch/x86/include/asm/irqflags.h:70 (discriminator 1) arch/x86/include/asm/irqflags.h:130 (discriminator 1) kernel/printk/printk.c:264 (discriminator 1)) [ 21.731230][ T1] hardirqs last disabled at (1964020): __up_console_sem (kernel/printk/printk.c:262 (discriminator 1)) [ 21.735324][ T1] softirqs last enabled at (1963746): __do_softirq (arch/x86/include/asm/preempt.h:27 kernel/softirq.c:415 kernel/softirq.c:600) [ 21.736992][ T1] softirqs last disabled at (1963735): do_softirq_own_stack (arch/x86/kernel/irq_32.c:60 arch/x86/kernel/irq_32.c:150) [ 21.738743][ T1] ---[ end trace 0000000000000000 ]--- [ 21.739776][ T1] dma-buf: Running dma_fence_unwrap The kernel config and materials to reproduce are available at: https://download.01.org/0day-ci/archive/20230913/202309132239.70437559-oliv… -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

2 years, 5 months

[PATCH] spi: tegra: Fix missing IRQ check in tegra_slink_probe()

by Zhang Shurong

This func misses checking for platform_get_irq()'s call and may passes the negative error codes to request_irq(), which takes unsigned IRQ #, causing it to fail with -EINVAL, overriding an original error code. Fix this by stop calling request_irq() with invalid IRQ #s. Fixes: dc4dc3605639 ("spi: tegra: add spi driver for SLINK controller") Signed-off-by: Zhang Shurong <zhang_shurong(a)foxmail.com> --- drivers/spi/spi-tegra20-slink.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/spi/spi-tegra20-slink.c b/drivers/spi/spi-tegra20-slink.c index 4d6db6182c5e..f5cd365c913a 100644 --- a/drivers/spi/spi-tegra20-slink.c +++ b/drivers/spi/spi-tegra20-slink.c @@ -1086,6 +1086,8 @@ static int tegra_slink_probe(struct platform_device *pdev) reset_control_deassert(tspi->rst); spi_irq = platform_get_irq(pdev, 0); + if (spi_irq < 0) + return spi_irq; tspi->irq = spi_irq; ret = request_threaded_irq(tspi->irq, tegra_slink_isr, tegra_slink_isr_thread, IRQF_ONESHOT, -- 2.30.2

2 years, 5 months

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig