- Linaro-mm-sig - lists.linaro.org

Re: [RFC PATCH v3 07/12] page-pool: device memory support

by Christian König

Am 09.11.23 um 04:20 schrieb Mina Almasry: > [SNIP] >> But we might be able to do something as folio is doing now, mm subsystem >> is still seeing 'struct folio/page', but other subsystem like slab is using >> 'struct slab', and there is still some common fields shared between >> 'struct folio' and 'struct slab'. >> > In my eyes this is almost exactly what I suggested in RFC v1 and got > immediately nacked with no room to negotiate. What we did for v1 is to > allocate struct pages for dma-buf to make dma-bufs look like struct > page to mm subsystem. Almost exactly what you're describing above. > It's a no-go. I don't think renaming struct page to netmem is going to > move the needle (it also re-introduces code-churn). What I feel like I > learnt is that dma-bufs are not struct pages and can't be made to look > like one, I think. Yeah, that pretty much hits the nail on the head. What was not mentioned yet and you could potentially try to do is to go the other way around. In other words instead of importing a DMA-buf file descriptor into the page-pool, you take some netdev page-pool pages and export them as DMA-buf handle. All you then need to do is to implement the necessary DMA-buf interface, e.g. wait for DMA-fences before accessing stuff, when you have an async operation install a DMA-fence so that other can wait for your operation to finish etc.. etc.. This still doesn't gives you peer 2 peer over for example the PCIe bus, but it would give you zero copy in the sense that a GPU or other acceleration device directly writes stuff into memory a network device can work with. We already have some similar functionality for at least Intel and AMD hw where an userptr mechanism is used to make malloced memory (backed by normal struct pages) available to the GPU. The problem with this approach is that most GPUs currently can't do good recoverable page faults which in turn makes the whole MMU notifier based approach just horrible inefficient. Just giving a few more pointers you might want to look into... Cheers, Christian.

1 year, 7 months

1
0
0 0

[syzbot] [dri?] kernel BUG in vmf_insert_pfn_prot (2)

by syzbot

Hello, syzbot found the following issue on: HEAD commit: 9e6c269de404 Merge tag 'i2c-for-6.5-rc7' of git://git.kern.. git tree: upstream console+strace: https://syzkaller.appspot.com/x/log.txt?x=110b32d3a80000 kernel config: https://syzkaller.appspot.com/x/.config?x=aa796b6080b04102 dashboard link: https://syzkaller.appspot.com/bug?extid=398e17b61dab22cc56bc 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=14284307a80000 Downloadable assets: disk image: https://storage.googleapis.com/syzbot-assets/481d8421bfb2/disk-9e6c269d.raw… vmlinux: https://storage.googleapis.com/syzbot-assets/5ec626f94634/vmlinux-9e6c269d.… kernel image: https://storage.googleapis.com/syzbot-assets/ab1e59619bd6/bzImage-9e6c269d.… IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+398e17b61dab22cc56bc(a)syzkaller.appspotmail.com ------------[ cut here ]------------ kernel BUG at mm/memory.c:2214! invalid opcode: 0000 [#1] PREEMPT SMP KASAN CPU: 0 PID: 5157 Comm: syz-executor.3 Not tainted 6.5.0-rc6-syzkaller-00253-g9e6c269de404 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/26/2023 RIP: 0010:vmf_insert_pfn_prot+0x247/0x430 mm/memory.c:2214 Code: 0f 0b e8 0c 4f c0 ff 49 89 ef bf 20 00 00 00 41 83 e7 28 4c 89 fe e8 88 4a c0 ff 49 83 ff 20 0f 85 aa fe ff ff e8 e9 4e c0 ff <0f> 0b 48 bd ff ff ff ff ff ff 0f 00 e8 d8 4e c0 ff 4c 89 f6 48 89 RSP: 0018:ffffc9000415f750 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffff8880275a0d00 RCX: 0000000000000000 RDX: ffff888018379dc0 RSI: ffffffff81c5b9b7 RDI: 0000000000000007 RBP: 000000000c140477 R08: 0000000000000007 R09: 0000000000000020 R10: 0000000000000020 R11: 000000000000001f R12: 0000000020ffc000 R13: 1ffff9200082beeb R14: 000000000007e79e R15: 0000000000000020 FS: 00007f235bd9a6c0(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020ffc000 CR3: 0000000022a32000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> drm_gem_shmem_fault+0x1ea/0x3a0 drivers/gpu/drm/drm_gem_shmem_helper.c:563 __do_fault+0x107/0x5f0 mm/memory.c:4198 do_read_fault mm/memory.c:4547 [inline] do_fault mm/memory.c:4670 [inline] do_pte_missing mm/memory.c:3664 [inline] handle_pte_fault mm/memory.c:4939 [inline] __handle_mm_fault+0x27e0/0x3b80 mm/memory.c:5079 handle_mm_fault+0x2ab/0x9d0 mm/memory.c:5233 do_user_addr_fault+0x446/0xfc0 arch/x86/mm/fault.c:1392 handle_page_fault arch/x86/mm/fault.c:1486 [inline] exc_page_fault+0x5c/0xd0 arch/x86/mm/fault.c:1542 asm_exc_page_fault+0x26/0x30 arch/x86/include/asm/idtentry.h:570 RIP: 0010:rep_movs_alternative+0x4a/0xb0 arch/x86/lib/copy_user_64.S:71 Code: 75 f1 c3 66 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 8b 06 48 89 07 48 83 c6 08 48 83 c7 08 83 e9 08 74 df 83 f9 08 73 e8 eb c9 <f3> a4 c3 0f 1f 00 4c 8b 06 4c 8b 4e 08 4c 8b 56 10 4c 8b 5e 18 4c RSP: 0018:ffffc9000415fb50 EFLAGS: 00050206 RAX: 0000000000000001 RBX: 0000000020ffc000 RCX: 0000000000001000 RDX: 0000000000000000 RSI: 0000000020ffc000 RDI: ffff88807b764000 RBP: 0000000000001000 R08: 0000000000000001 R09: ffffed100f6ec9ff R10: ffff88807b764fff R11: 0000000000000000 R12: 0000000020ffd000 R13: ffff88807b764000 R14: 0000000000000000 R15: 0000000020ffc000 copy_user_generic arch/x86/include/asm/uaccess_64.h:112 [inline] raw_copy_from_user arch/x86/include/asm/uaccess_64.h:127 [inline] _copy_from_user+0xc2/0xf0 lib/usercopy.c:23 copy_from_user include/linux/uaccess.h:183 [inline] snd_rawmidi_kernel_write1+0x360/0x860 sound/core/rawmidi.c:1618 snd_rawmidi_write+0x278/0xc10 sound/core/rawmidi.c:1687 vfs_write+0x2a4/0xe40 fs/read_write.c:582 ksys_write+0x1f0/0x250 fs/read_write.c:637 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:0x7f235b07cae9 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 20 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:00007f235bd9a0c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00007f235b19bf80 RCX: 00007f235b07cae9 RDX: 00000000fffffd2c RSI: 0000000020000000 RDI: 0000000000000005 RBP: 00007f235b0c847a R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 000000000000000b R14: 00007f235b19bf80 R15: 00007ffd9cdf0fe8 </TASK> Modules linked in: ---[ end trace 0000000000000000 ]--- RIP: 0010:vmf_insert_pfn_prot+0x247/0x430 mm/memory.c:2214 Code: 0f 0b e8 0c 4f c0 ff 49 89 ef bf 20 00 00 00 41 83 e7 28 4c 89 fe e8 88 4a c0 ff 49 83 ff 20 0f 85 aa fe ff ff e8 e9 4e c0 ff <0f> 0b 48 bd ff ff ff ff ff ff 0f 00 e8 d8 4e c0 ff 4c 89 f6 48 89 RSP: 0018:ffffc9000415f750 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffff8880275a0d00 RCX: 0000000000000000 RDX: ffff888018379dc0 RSI: ffffffff81c5b9b7 RDI: 0000000000000007 RBP: 000000000c140477 R08: 0000000000000007 R09: 0000000000000020 R10: 0000000000000020 R11: 000000000000001f R12: 0000000020ffc000 R13: 1ffff9200082beeb R14: 000000000007e79e R15: 0000000000000020 FS: 00007f235bd9a6c0(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f93c20ffac1 CR3: 0000000022a32000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 ---------------- Code disassembly (best guess): 0: 75 f1 jne 0xfffffff3 2: c3 ret 3: 66 66 2e 0f 1f 84 00 data16 cs nopw 0x0(%rax,%rax,1) a: 00 00 00 00 e: 66 90 xchg %ax,%ax 10: 48 8b 06 mov (%rsi),%rax 13: 48 89 07 mov %rax,(%rdi) 16: 48 83 c6 08 add $0x8,%rsi 1a: 48 83 c7 08 add $0x8,%rdi 1e: 83 e9 08 sub $0x8,%ecx 21: 74 df je 0x2 23: 83 f9 08 cmp $0x8,%ecx 26: 73 e8 jae 0x10 28: eb c9 jmp 0xfffffff3 * 2a: f3 a4 rep movsb %ds:(%rsi),%es:(%rdi) <-- trapping instruction 2c: c3 ret 2d: 0f 1f 00 nopl (%rax) 30: 4c 8b 06 mov (%rsi),%r8 33: 4c 8b 4e 08 mov 0x8(%rsi),%r9 37: 4c 8b 56 10 mov 0x10(%rsi),%r10 3b: 4c 8b 5e 18 mov 0x18(%rsi),%r11 3f: 4c rex.WR --- 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

1 year, 7 months

1
2
0 0

Re: [RFC PATCH v3 09/12] net: add support for skbs with unreadable frags

by David Laight

From: Mina Almasry > Sent: 06 November 2023 02:44 > > For device memory TCP, we expect the skb headers to be available in host > memory for access, and we expect the skb frags to be in device memory > and unaccessible to the host. We expect there to be no mixing and > matching of device memory frags (unaccessible) with host memory frags > (accessible) in the same skb. > > Add a skb->devmem flag which indicates whether the frags in this skb > are device memory frags or not. > ... > diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h > index 1fae276c1353..8fb468ff8115 100644 > --- a/include/linux/skbuff.h > +++ b/include/linux/skbuff.h > @@ -805,6 +805,8 @@ typedef unsigned char *sk_buff_data_t; > * @csum_level: indicates the number of consecutive checksums found in > * the packet minus one that have been verified as > * CHECKSUM_UNNECESSARY (max 3) > + * @devmem: indicates that all the fragments in this skb are backed by > + * device memory. > * @dst_pending_confirm: need to confirm neighbour > * @decrypted: Decrypted SKB > * @slow_gro: state present at GRO time, slower prepare step required > @@ -991,7 +993,7 @@ struct sk_buff { > #if IS_ENABLED(CONFIG_IP_SCTP) > __u8 csum_not_inet:1; > #endif > - > + __u8 devmem:1; > #if defined(CONFIG_NET_SCHED) || defined(CONFIG_NET_XGRESS) > __u16 tc_index; /* traffic control index */ > #endif > @@ -1766,6 +1768,12 @@ static inline void skb_zcopy_downgrade_managed(struct sk_buff *skb) > __skb_zcopy_downgrade_managed(skb); > } Doesn't that bloat struct sk_buff? I'm not sure there are any spare bits available. Although CONFIG_NET_SWITCHDEV and CONFIG_NET_SCHED seem to already add padding. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)

1 year, 7 months

1
0
0 0

Re: [RFC PATCH] drm/test: add a test suite for GEM objects backed by shmem

by Maxime Ripard

On Mon, Oct 30, 2023 at 11:58:20AM +0100, Marco Pagani wrote: > On 2023-10-25 10:43, Maxime Ripard wrote: > > On Tue, Oct 24, 2023 at 07:14:25PM +0200, Marco Pagani wrote: > >>>> +static void drm_gem_shmem_test_obj_create_private(struct kunit *test) > >>>> +{ > >>>> + struct fake_dev *fdev = test->priv; > >>>> + struct drm_gem_shmem_object *shmem; > >>>> + struct drm_gem_object *gem_obj; > >>>> + struct dma_buf buf_mock; > >>>> + struct dma_buf_attachment attach_mock; > >>>> + struct sg_table *sgt; > >>>> + char *buf; > >>>> + int ret; > >>>> + > >>>> + /* Create a mock scatter/gather table */ > >>>> + buf = kunit_kzalloc(test, TEST_SIZE, GFP_KERNEL); > >>>> + KUNIT_ASSERT_NOT_NULL(test, buf); > >>>> + > >>>> + sgt = kzalloc(sizeof(*sgt), GFP_KERNEL); > >>>> + KUNIT_ASSERT_NOT_NULL(test, sgt); > >>>> + > >>>> + ret = sg_alloc_table(sgt, 1, GFP_KERNEL); > >>>> + KUNIT_ASSERT_EQ(test, ret, 0); > >>>> + sg_init_one(sgt->sgl, buf, TEST_SIZE); > >>>> + > >>>> + /* Init a mock DMA-BUF */ > >>>> + buf_mock.size = TEST_SIZE; > >>>> + attach_mock.dmabuf = &buf_mock; > >>>> + > >>>> + gem_obj = drm_gem_shmem_prime_import_sg_table(&fdev->drm_dev, &attach_mock, sgt); > >>>> + KUNIT_ASSERT_NOT_ERR_OR_NULL(test, gem_obj); > >>>> + KUNIT_ASSERT_EQ(test, gem_obj->size, TEST_SIZE); > >>>> + KUNIT_ASSERT_NULL(test, gem_obj->filp); > >>>> + KUNIT_ASSERT_NOT_NULL(test, gem_obj->funcs); > >>>> + > >>>> + shmem = to_drm_gem_shmem_obj(gem_obj); > >>>> + KUNIT_ASSERT_PTR_EQ(test, shmem->sgt, sgt); > >>>> + > >>>> + /* The scatter/gather table is freed by drm_gem_shmem_free */ > >>>> + drm_gem_shmem_free(shmem); > >>>> +} > >>> > >>> KUNIT_ASSERT_* will stop the execution of the test on failure, you > >>> should probably use a bit more of KUNIT_EXPECT_* calls otherwise you'll > >>> leak resources. > >>> > >>> You also probably want to use a kunit_action to clean up and avoid that > >>> whole discussion > >>> > >> > >> You are right. I slightly prefer using KUnit expectations (unless actions > >> are strictly necessary) since I feel using actions makes test cases a bit > >> less straightforward to understand. Is this okay for you? > > > > I disagree. Actions make it easier to reason about, even when comparing > > assertion vs expectation > > > > Like, for the call to sg_alloc_table and > > drm_gem_shmem_prime_import_sg_table(), the reasonable use of assert vs > > expect would be something like: > > > > sgt = kzalloc(sizeof(*sgt), GFP_KERNEL); > > KUNIT_ASSERT_NOT_NULL(test, sgt); > > > > ret = sg_alloc_table(sgt, 1, GFP_KERNEL); > > KUNIT_ASSERT_EQ(test, ret, 0); > > > > /* > > * Here, it's already not super clear whether you want to expect vs > > * assert. expect will make you handle the failure case later, assert will > > * force you to call kfree on sgt. Both kind of suck in their own ways. > > */ > > > > sg_init_one(sgt->sgl, buf, TEST_SIZE); > > > > gem_obj = drm_gem_shmem_prime_import_sg_table(&fdev->drm_dev, &attach_mock, sgt); > > KUNIT_ASSERT_NOT_ERR_OR_NULL(test, gem_obj); > > > > /* > > * If the assert fails, we forgot to call sg_free_table(sgt) and kfree(sgt). > > */ > > > > KUNIT_EXPECT_EQ(test, gem_obj->size, TEST_SIZE); > > KUNIT_EXPECT_NULL(test, gem_obj->filp); > > KUNIT_EXPECT_NOT_NULL(test, gem_obj->funcs); > > > > /* > > * And here we have to handle the case where the expectation was wrong, > > * but the test still continued. > > */ > > > > But if you're not using an action, you still have to call kfree(sgt), > > which means that you might still > > > > shmem = to_drm_gem_shmem_obj(gem_obj); > > KUNIT_ASSERT_PTR_EQ(test, shmem->sgt, sgt); > > > > /* > > * If the assertion fails, we now have to call drm_gem_shmem_free(shmem) > > */ > > > > /* The scatter/gather table is freed by drm_gem_shmem_free */ > > drm_gem_shmem_free(shmem); > > > > /* everything's fine now */ > > > > The semantics around drm_gem_shmem_free make it a bit convoluted, but > > doing it using goto/labels, plus handling the assertions and error > > reporting would be difficult. > > > > Using actions, we have: > > > > sgt = kzalloc(sizeof(*sgt), GFP_KERNEL); > > KUNIT_ASSERT_NOT_NULL(test, sgt); > > > > ret = kunit_add_action_or_reset(test, kfree_wrapper, sgt); > > KUNIT_ASSERT_EQ(test, ret, 0); > > > > ret = sg_alloc_table(sgt, 1, GFP_KERNEL); > > KUNIT_ASSERT_EQ(test, ret, 0); > > > > ret = kunit_add_action_or_reset(test, sg_free_table_wrapper, sgt); > > KUNIT_ASSERT_EQ(test, ret, 0); > > > > sg_init_one(sgt->sgl, buf, TEST_SIZE); > > > > gem_obj = drm_gem_shmem_prime_import_sg_table(&fdev->drm_dev, &attach_mock, sgt); > > KUNIT_ASSERT_NOT_ERR_OR_NULL(test, gem_obj); > > KUNIT_EXPECT_EQ(test, gem_obj->size, TEST_SIZE); > > KUNIT_EXPECT_NULL(test, gem_obj->filp); > > KUNIT_EXPECT_NOT_NULL(test, gem_obj->funcs); > > > > /* drm_gem_shmem_free will free the struct sg_table itself */ > > kunit_remove_action(test, sg_free_table_wrapper, sgt); > > kunit_remove_action(test, kfree_wrapper, sgt); > > I agree that using actions makes error handling cleaner. However, I still > have some concerns about the additional complexity that actions introduce. > For instance, I feel these two lines make the testing harness more complex > without asserting any additional property of the component under test. If anything, the API makes it more difficult to deal with. It would actually be harder/messier to handle without an action. > In some sense, I wonder if it is worth worrying about memory leaks when > a test case fails. At that point, the system is already in an inconsistent > state due to a bug in the component under test, so it is unsafe to continue > anyway. I guess the larger issue is: once that code will be merged, we're going to have patches to convert to actions because they make it nicer and fix a couple of issues anyway. So, if it's still the state we're going to end up in, why not doing it right from the beginning? Maxime

1 year, 7 months

1
0
0 0

Re: [PATCH 8/9] dt-bindings: reserved-memory: MediaTek: Add reserved memory for SVP

by Yong Wu (吴勇)

On Wed, 2023-11-01 at 11:20 +0530, Jaskaran Singh wrote: > > External email : Please do not click links or open attachments until > you have verified the sender or the content. > On 10/20/2023 3:20 PM, Yong Wu (吴勇) wrote: > > On Thu, 2023-10-19 at 10:16 +0530, Vijayanand Jitta wrote: > >> > >> Instead of having a vendor specific binding for cma area, How > about > >> retrieving > >> > > > https://lore.kernel.org/lkml/1594948208-4739-1-git-send-email-hayashi.kunih… > >> ? > >> dma_heap_add_cma can just associate cma region and create a heap. > So, > >> we can reuse cma heap > >> code for allocation instead of replicating that code here. > >> > > > > Thanks for the reference. I guess we can't use it. There are two > > reasons: > > > > a) The secure heap driver is a pure software driver and we have no > > device for it, therefore we cannot call dma_heap_add_cma. > > > > Hi Yong, > > We're considering using struct cma as the function argument to > dma_heap_add_cma() rather than struct device. Would this help > resolve the problem of usage with dma_heap_add_cma()? Yes. If we use "struct cma", I guess it works. > > > b) The CMA area here is dynamic for SVP. Normally this CMA can be > used > > in the kernel. In the SVP case we use cma_alloc to get it and pass > the > > entire CMA physical start address and size into TEE to protect the > CMA > > region. The original CMA heap cannot help with the TEE part. > > > > Referring the conversation at > https://lore.kernel.org/lkml/7a2995de23c24ef22c071c6976c02b97e9b50126.camel… > ; > > since we're considering abstracting secure mem ops, would it make > sense > to use the default CMA heap ops (cma_heap_ops), allocate buffers from > it > and secure each allocated buffer? Then it looks you also need tee operation like tee_client_open_session and tee_client_invoke_func, right? It seems we also need change a bit for "cma_heap_allocate" to allow cma support operations from secure heap. I will send a v2 to move the discussion forward. The v2 is based on our case, It won't include the cma part. > > Thanks, > Jaskaran. > > > Thanks. > > > >> Thanks, > >> Vijay > >> > >> > >> >

1 year, 7 months

1
0
0 0

[PATCH 0/9] dma-buf: heaps: Add MediaTek secure heap

by Yong Wu

This patchset consists of two parts, the first is from John and TJ. It adds some heap interfaces, then our kernel users could allocate buffer from special heap. The second part is adding MTK secure heap for SVP (Secure Video Path). A total of two heaps are added, one is mtk_svp and the other is mtk_svp_cma. The mtk_svp buffer is reserved for the secure world after bootup and it is used for ES/working buffer, while the mtk_svp_cma buffer is dynamically reserved for the secure world and will be get ready when we start playing secure videos, this heap is used for the frame buffer. Once the security video playing is complete, the CMA will be released. For easier viewing, I've split the new heap file into several patches. The consumers of new heap and new interfaces are our codec and drm which will send upstream soon, probably this week. Base on v6.6-rc1. John Stultz (2): dma-heap: Add proper kref handling on dma-buf heaps dma-heap: Provide accessors so that in-kernel drivers can allocate dmabufs from specific heaps T.J. Mercier (1): dma-buf: heaps: Deduplicate docs and adopt common format Yong Wu (6): dma-buf: heaps: Initialise MediaTek secure heap dma-buf: heaps: mtk_sec_heap: Initialise tee session dma-buf: heaps: mtk_sec_heap: Add tee service call for buffer allocating/freeing dma-buf: heaps: mtk_sec_heap: Add dma_ops dt-bindings: reserved-memory: MediaTek: Add reserved memory for SVP dma_buf: heaps: mtk_sec_heap: Add a new CMA heap .../mediatek,secure_cma_chunkmem.yaml | 42 ++ drivers/dma-buf/dma-heap.c | 127 +++-- drivers/dma-buf/heaps/Kconfig | 8 + drivers/dma-buf/heaps/Makefile | 1 + drivers/dma-buf/heaps/mtk_secure_heap.c | 458 ++++++++++++++++++ include/linux/dma-heap.h | 42 +- 6 files changed, 630 insertions(+), 48 deletions(-) create mode 100644 Documentation/devicetree/bindings/reserved-memory/mediatek,secure_cma_chunkmem.yaml create mode 100644 drivers/dma-buf/heaps/mtk_secure_heap.c -- 2.18.0

1 year, 7 months

16
68
0 0

Re: [RFC PATCH] drm/test: add a test suite for GEM objects backed by shmem

by Maxime Ripard

Hi, On Tue, Oct 24, 2023 at 07:14:25PM +0200, Marco Pagani wrote: > >> +static void drm_gem_shmem_test_obj_create_private(struct kunit *test) > >> +{ > >> + struct fake_dev *fdev = test->priv; > >> + struct drm_gem_shmem_object *shmem; > >> + struct drm_gem_object *gem_obj; > >> + struct dma_buf buf_mock; > >> + struct dma_buf_attachment attach_mock; > >> + struct sg_table *sgt; > >> + char *buf; > >> + int ret; > >> + > >> + /* Create a mock scatter/gather table */ > >> + buf = kunit_kzalloc(test, TEST_SIZE, GFP_KERNEL); > >> + KUNIT_ASSERT_NOT_NULL(test, buf); > >> + > >> + sgt = kzalloc(sizeof(*sgt), GFP_KERNEL); > >> + KUNIT_ASSERT_NOT_NULL(test, sgt); > >> + > >> + ret = sg_alloc_table(sgt, 1, GFP_KERNEL); > >> + KUNIT_ASSERT_EQ(test, ret, 0); > >> + sg_init_one(sgt->sgl, buf, TEST_SIZE); > >> + > >> + /* Init a mock DMA-BUF */ > >> + buf_mock.size = TEST_SIZE; > >> + attach_mock.dmabuf = &buf_mock; > >> + > >> + gem_obj = drm_gem_shmem_prime_import_sg_table(&fdev->drm_dev, &attach_mock, sgt); > >> + KUNIT_ASSERT_NOT_ERR_OR_NULL(test, gem_obj); > >> + KUNIT_ASSERT_EQ(test, gem_obj->size, TEST_SIZE); > >> + KUNIT_ASSERT_NULL(test, gem_obj->filp); > >> + KUNIT_ASSERT_NOT_NULL(test, gem_obj->funcs); > >> + > >> + shmem = to_drm_gem_shmem_obj(gem_obj); > >> + KUNIT_ASSERT_PTR_EQ(test, shmem->sgt, sgt); > >> + > >> + /* The scatter/gather table is freed by drm_gem_shmem_free */ > >> + drm_gem_shmem_free(shmem); > >> +} > > > > KUNIT_ASSERT_* will stop the execution of the test on failure, you > > should probably use a bit more of KUNIT_EXPECT_* calls otherwise you'll > > leak resources. > > > > You also probably want to use a kunit_action to clean up and avoid that > > whole discussion > > > > You are right. I slightly prefer using KUnit expectations (unless actions > are strictly necessary) since I feel using actions makes test cases a bit > less straightforward to understand. Is this okay for you? I disagree. Actions make it easier to reason about, even when comparing assertion vs expectation Like, for the call to sg_alloc_table and drm_gem_shmem_prime_import_sg_table(), the reasonable use of assert vs expect would be something like: sgt = kzalloc(sizeof(*sgt), GFP_KERNEL); KUNIT_ASSERT_NOT_NULL(test, sgt); ret = sg_alloc_table(sgt, 1, GFP_KERNEL); KUNIT_ASSERT_EQ(test, ret, 0); /* * Here, it's already not super clear whether you want to expect vs * assert. expect will make you handle the failure case later, assert will * force you to call kfree on sgt. Both kind of suck in their own ways. */ sg_init_one(sgt->sgl, buf, TEST_SIZE); gem_obj = drm_gem_shmem_prime_import_sg_table(&fdev->drm_dev, &attach_mock, sgt); KUNIT_ASSERT_NOT_ERR_OR_NULL(test, gem_obj); /* * If the assert fails, we forgot to call sg_free_table(sgt) and kfree(sgt). */ KUNIT_EXPECT_EQ(test, gem_obj->size, TEST_SIZE); KUNIT_EXPECT_NULL(test, gem_obj->filp); KUNIT_EXPECT_NOT_NULL(test, gem_obj->funcs); /* * And here we have to handle the case where the expectation was wrong, * but the test still continued. */ But if you're not using an action, you still have to call kfree(sgt), which means that you might still shmem = to_drm_gem_shmem_obj(gem_obj); KUNIT_ASSERT_PTR_EQ(test, shmem->sgt, sgt); /* * If the assertion fails, we now have to call drm_gem_shmem_free(shmem) */ /* The scatter/gather table is freed by drm_gem_shmem_free */ drm_gem_shmem_free(shmem); /* everything's fine now */ The semantics around drm_gem_shmem_free make it a bit convoluted, but doing it using goto/labels, plus handling the assertions and error reporting would be difficult. Using actions, we have: sgt = kzalloc(sizeof(*sgt), GFP_KERNEL); KUNIT_ASSERT_NOT_NULL(test, sgt); ret = kunit_add_action_or_reset(test, kfree_wrapper, sgt); KUNIT_ASSERT_EQ(test, ret, 0); ret = sg_alloc_table(sgt, 1, GFP_KERNEL); KUNIT_ASSERT_EQ(test, ret, 0); ret = kunit_add_action_or_reset(test, sg_free_table_wrapper, sgt); KUNIT_ASSERT_EQ(test, ret, 0); sg_init_one(sgt->sgl, buf, TEST_SIZE); gem_obj = drm_gem_shmem_prime_import_sg_table(&fdev->drm_dev, &attach_mock, sgt); KUNIT_ASSERT_NOT_ERR_OR_NULL(test, gem_obj); KUNIT_EXPECT_EQ(test, gem_obj->size, TEST_SIZE); KUNIT_EXPECT_NULL(test, gem_obj->filp); KUNIT_EXPECT_NOT_NULL(test, gem_obj->funcs); /* drm_gem_shmem_free will free the struct sg_table itself */ kunit_remove_action(test, sg_free_table_wrapper, sgt); kunit_remove_action(test, kfree_wrapper, sgt); shmem = to_drm_gem_shmem_obj(gem_obj); KUNIT_ASSERT_PTR_EQ(test, shmem->sgt, sgt); ret = kunit_add_action_or_reset(test, drm_gem_shmem_free_wrapper, shmem); KUNIT_ASSERT_EQ(test, ret, 0); The last one is arguable, but for the previous ones it makes error handling much more convenient and easy to reason about. The wrappers are also a bit inconvenient to use, but it's mostly there to avoid a compiler warning at the moment. This patch will help hopefully: https://lore.kernel.org/linux-kselftest/20230915050125.3609689-1-davidgow@g… Maxime

1 year, 7 months

1
0
0 0

Re: [PATCH] drm: docs: Remove item from TODO list

by Maxime Ripard

Hi, On Mon, Oct 23, 2023 at 10:25:50AM -0700, Doug Anderson wrote: > On Mon, Oct 23, 2023 at 9:31 AM Yuran Pereira <yuran.pereira(a)hotmail.com> wrote: > > > > Since "Clean up checks for already prepared/enabled in panels" has > > already been done and merged [1], I think there is no longer a need > > for this item to be in the gpu TODO. > > > > [1] https://patchwork.freedesktop.org/patch/551421/ > > > > Signed-off-by: Yuran Pereira <yuran.pereira(a)hotmail.com> > > --- > > Documentation/gpu/todo.rst | 25 ------------------------- > > 1 file changed, 25 deletions(-) > > It's not actually all done. It's in a bit of a limbo state right now, > unfortunately. I landed all of the "simple" cases where panels were > needlessly tracking prepare/enable, but the less simple cases are > still outstanding. > > Specifically the issue is that many panels have code to properly power > cycle themselves off at shutdown time and in order to do that they > need to keep track of the prepare/enable state. After a big, long > discussion [1] it was decided that we could get rid of all the panel > code handling shutdown if only all relevant DRM KMS drivers would > properly call drm_atomic_helper_shutdown(). > > I made an attempt to get DRM KMS drivers to call > drm_atomic_helper_shutdown() [2] [3] [4]. I was able to land the > patches that went through drm-misc, but currently many of the > non-drm-misc ones are blocked waiting for attention. > > ...so things that could be done to help out: > > a) Could review patches that haven't landed in [4]. Maybe adding a > Reviewed-by tag would help wake up maintainers? > > b) Could see if you can identify panels that are exclusively used w/ > DRM drivers that have already been converted and then we could post > patches for just those panels. I have no idea how easy this task would > be. Is it enough to look at upstream dts files by "compatible" string? I think it is, yes. Maxime

1 year, 7 months

1
0
0 0

Re: [RFC PATCH] drm/test: add a test suite for GEM objects backed by shmem

by Maxime Ripard

Hi Marco, On Mon, Oct 23, 2023 at 06:45:40PM +0200, Marco Pagani wrote: > This patch introduces an initial KUnit test suite for GEM objects > backed by shmem buffers. > > Signed-off-by: Marco Pagani <marpagan(a)redhat.com> > --- > drivers/gpu/drm/Kconfig | 1 + > drivers/gpu/drm/tests/Makefile | 3 +- > drivers/gpu/drm/tests/drm_gem_shmem_test.c | 303 +++++++++++++++++++++ > 3 files changed, 306 insertions(+), 1 deletion(-) > create mode 100644 drivers/gpu/drm/tests/drm_gem_shmem_test.c > > diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig > index 3eee8636f847..f0a77e3e04d7 100644 > --- a/drivers/gpu/drm/Kconfig > +++ b/drivers/gpu/drm/Kconfig > @@ -84,6 +84,7 @@ config DRM_KUNIT_TEST > select DRM_EXPORT_FOR_TESTS if m > select DRM_KUNIT_TEST_HELPERS > select DRM_EXEC > + select DRM_GEM_SHMEM_HELPER I know that DRM_EXEC already stands out, but these should be ordered alphabetically, so it should be before DRM_KUNIT_TEST_HELPERS. > default KUNIT_ALL_TESTS > help > This builds unit tests for DRM. This option is not useful for > diff --git a/drivers/gpu/drm/tests/Makefile b/drivers/gpu/drm/tests/Makefile > index ba7baa622675..b8227aab369e 100644 > --- a/drivers/gpu/drm/tests/Makefile > +++ b/drivers/gpu/drm/tests/Makefile > @@ -18,6 +18,7 @@ obj-$(CONFIG_DRM_KUNIT_TEST) += \ > drm_plane_helper_test.o \ > drm_probe_helper_test.o \ > drm_rect_test.o \ > - drm_exec_test.o > + drm_exec_test.o \ > + drm_gem_shmem_test.o Ditto. > CFLAGS_drm_mm_test.o := $(DISABLE_STRUCTLEAK_PLUGIN) > diff --git a/drivers/gpu/drm/tests/drm_gem_shmem_test.c b/drivers/gpu/drm/tests/drm_gem_shmem_test.c > new file mode 100644 > index 000000000000..0bf6727f08d2 > --- /dev/null > +++ b/drivers/gpu/drm/tests/drm_gem_shmem_test.c > @@ -0,0 +1,303 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * KUnit test suite for GEM objects backed by shmem buffers > + * > + * Copyright (C) 2023 Red Hat, Inc. > + * > + * Author: Marco Pagani <marpagan(a)redhat.com> > + */ > + > +#include <linux/dma-buf.h> > +#include <linux/iosys-map.h> > +#include <linux/sizes.h> > + > +#include <kunit/test.h> > + > +#include <drm/drm_device.h> > +#include <drm/drm_drv.h> > +#include <drm/drm_gem.h> > +#include <drm/drm_gem_shmem_helper.h> > +#include <drm/drm_kunit_helpers.h> > + > +#define TEST_SIZE SZ_1M > +#define TEST_BYTE 0xae > + > +struct fake_dev { > + struct drm_device drm_dev; > + struct device *dev; > +}; > + > +/* Test creating a shmem GEM object */ > +static void drm_gem_shmem_test_obj_create(struct kunit *test) > +{ > + struct fake_dev *fdev = test->priv; > + struct drm_gem_shmem_object *shmem; > + > + shmem = drm_gem_shmem_create(&fdev->drm_dev, TEST_SIZE); > + KUNIT_ASSERT_NOT_ERR_OR_NULL(test, shmem); > + KUNIT_ASSERT_EQ(test, shmem->base.size, TEST_SIZE); > + KUNIT_ASSERT_NOT_NULL(test, shmem->base.filp); > + KUNIT_ASSERT_NOT_NULL(test, shmem->base.funcs); > + > + drm_gem_shmem_free(shmem); > +} > + > +/* Test creating a private shmem GEM object from a scatter/gather table */ Thanks for documenting those tests. I believe we should also document what we expect from the test: should the test succeed? fail? if it fails, what is the cause of failure? Based on the following test, I think something like the following would be good: Test that creating a private shmem GEM object from a previously allocated sg_table succeeds and is properly initialized Feel free to change it to something else if you find something missing. > +static void drm_gem_shmem_test_obj_create_private(struct kunit *test) > +{ > + struct fake_dev *fdev = test->priv; > + struct drm_gem_shmem_object *shmem; > + struct drm_gem_object *gem_obj; > + struct dma_buf buf_mock; > + struct dma_buf_attachment attach_mock; > + struct sg_table *sgt; > + char *buf; > + int ret; > + > + /* Create a mock scatter/gather table */ > + buf = kunit_kzalloc(test, TEST_SIZE, GFP_KERNEL); > + KUNIT_ASSERT_NOT_NULL(test, buf); > + > + sgt = kzalloc(sizeof(*sgt), GFP_KERNEL); > + KUNIT_ASSERT_NOT_NULL(test, sgt); > + > + ret = sg_alloc_table(sgt, 1, GFP_KERNEL); > + KUNIT_ASSERT_EQ(test, ret, 0); > + sg_init_one(sgt->sgl, buf, TEST_SIZE); > + > + /* Init a mock DMA-BUF */ > + buf_mock.size = TEST_SIZE; > + attach_mock.dmabuf = &buf_mock; > + > + gem_obj = drm_gem_shmem_prime_import_sg_table(&fdev->drm_dev, &attach_mock, sgt); > + KUNIT_ASSERT_NOT_ERR_OR_NULL(test, gem_obj); > + KUNIT_ASSERT_EQ(test, gem_obj->size, TEST_SIZE); > + KUNIT_ASSERT_NULL(test, gem_obj->filp); > + KUNIT_ASSERT_NOT_NULL(test, gem_obj->funcs); > + > + shmem = to_drm_gem_shmem_obj(gem_obj); > + KUNIT_ASSERT_PTR_EQ(test, shmem->sgt, sgt); > + > + /* The scatter/gather table is freed by drm_gem_shmem_free */ > + drm_gem_shmem_free(shmem); > +} KUNIT_ASSERT_* will stop the execution of the test on failure, you should probably use a bit more of KUNIT_EXPECT_* calls otherwise you'll leak resources. You also probably want to use a kunit_action to clean up and avoid that whole discussion > + > +/* Test pinning backing pages */ > +static void drm_gem_shmem_test_pin_pages(struct kunit *test) > +{ > + struct fake_dev *fdev = test->priv; > + struct drm_gem_shmem_object *shmem; > + int i, ret; > + > + shmem = drm_gem_shmem_create(&fdev->drm_dev, TEST_SIZE); > + KUNIT_ASSERT_NOT_ERR_OR_NULL(test, shmem); > + KUNIT_ASSERT_NULL(test, shmem->pages); > + KUNIT_ASSERT_EQ(test, shmem->pages_use_count, 0); > + > + ret = drm_gem_shmem_pin(shmem); > + KUNIT_ASSERT_EQ(test, ret, 0); > + KUNIT_ASSERT_NOT_NULL(test, shmem->pages); > + KUNIT_ASSERT_EQ(test, shmem->pages_use_count, 1); > + > + for (i = 0; i < (shmem->base.size >> PAGE_SHIFT); i++) > + KUNIT_ASSERT_NOT_NULL(test, shmem->pages[i]); > + > + drm_gem_shmem_unpin(shmem); > + KUNIT_ASSERT_NULL(test, shmem->pages); > + KUNIT_ASSERT_EQ(test, shmem->pages_use_count, 0); > + > + drm_gem_shmem_free(shmem); > +} > + > +/* Test creating a virtual mapping */ > +static void drm_gem_shmem_test_vmap(struct kunit *test) > +{ > + struct fake_dev *fdev = test->priv; > + struct drm_gem_shmem_object *shmem; > + struct iosys_map map; > + int ret, i; > + > + shmem = drm_gem_shmem_create(&fdev->drm_dev, TEST_SIZE); > + KUNIT_ASSERT_NOT_ERR_OR_NULL(test, shmem); > + KUNIT_ASSERT_NULL(test, shmem->vaddr); > + KUNIT_ASSERT_EQ(test, shmem->vmap_use_count, 0); > + > + ret = drm_gem_shmem_vmap(shmem, &map); > + KUNIT_ASSERT_EQ(test, ret, 0); > + KUNIT_ASSERT_NOT_NULL(test, shmem->vaddr); > + KUNIT_ASSERT_EQ(test, shmem->vmap_use_count, 1); > + KUNIT_ASSERT_FALSE(test, iosys_map_is_null(&map)); > + > + iosys_map_memset(&map, 0, TEST_BYTE, TEST_SIZE); > + for (i = 0; i < TEST_SIZE; i++) > + KUNIT_ASSERT_EQ(test, iosys_map_rd(&map, i, u8), TEST_BYTE); > + > + drm_gem_shmem_vunmap(shmem, &map); > + KUNIT_ASSERT_NULL(test, shmem->vaddr); > + KUNIT_ASSERT_EQ(test, shmem->vmap_use_count, 0); > + > + drm_gem_shmem_free(shmem); > +} > + > +/* Test exporting a scatter/gather table */ > +static void drm_gem_shmem_test_get_pages_sgt(struct kunit *test) > +{ > + struct fake_dev *fdev = test->priv; > + struct drm_gem_shmem_object *shmem; > + struct sg_table *sgt; > + struct scatterlist *sg; > + unsigned int si, len = 0; > + int ret; > + > + shmem = drm_gem_shmem_create(&fdev->drm_dev, TEST_SIZE); > + KUNIT_ASSERT_NOT_ERR_OR_NULL(test, shmem); > + > + ret = drm_gem_shmem_pin(shmem); > + KUNIT_ASSERT_EQ(test, ret, 0); > + > + sgt = drm_gem_shmem_get_sg_table(shmem); > + KUNIT_ASSERT_NOT_ERR_OR_NULL(test, sgt); > + KUNIT_ASSERT_NULL(test, shmem->sgt); > + > + for_each_sgtable_sg(sgt, sg, si) { > + KUNIT_ASSERT_NOT_NULL(test, sg); > + len += sg->length; > + } > + KUNIT_ASSERT_GE(test, len, TEST_SIZE); > + > + kfree(sgt); > + drm_gem_shmem_free(shmem); > +} > + > +/* Test exporting a scatter/gather pinned table for PRIME */ > +static void drm_gem_shmem_test_get_sg_table(struct kunit *test) > +{ > + struct fake_dev *fdev = test->priv; > + struct drm_gem_shmem_object *shmem; > + struct sg_table *sgt; > + struct scatterlist *sg; > + unsigned int si, len = 0; > + > + shmem = drm_gem_shmem_create(&fdev->drm_dev, TEST_SIZE); > + KUNIT_ASSERT_NOT_ERR_OR_NULL(test, shmem); > + > + sgt = drm_gem_shmem_get_pages_sgt(shmem); > + KUNIT_ASSERT_NOT_ERR_OR_NULL(test, sgt); > + KUNIT_ASSERT_PTR_EQ(test, sgt, shmem->sgt); > + > + for_each_sgtable_sg(sgt, sg, si) { > + KUNIT_ASSERT_NOT_NULL(test, sg); > + len += sg->length; > + } > + KUNIT_ASSERT_GE(test, len, TEST_SIZE); > + > + /* The scatter/gather table is freed by drm_gem_shmem_free */ > + drm_gem_shmem_free(shmem); > +} > + > +/* Test updating madvise status */ > +static void drm_gem_shmem_test_madvise(struct kunit *test) > +{ > + struct fake_dev *fdev = test->priv; > + struct drm_gem_shmem_object *shmem; > + int ret; > + > + shmem = drm_gem_shmem_create(&fdev->drm_dev, TEST_SIZE); > + KUNIT_ASSERT_NOT_ERR_OR_NULL(test, shmem); > + KUNIT_ASSERT_EQ(test, shmem->madv, 0); > + > + ret = drm_gem_shmem_madvise(shmem, 1); > + KUNIT_ASSERT_TRUE(test, ret); > + KUNIT_ASSERT_EQ(test, shmem->madv, 1); > + > + ret = drm_gem_shmem_madvise(shmem, -1); > + KUNIT_ASSERT_FALSE(test, ret); > + KUNIT_ASSERT_EQ(test, shmem->madv, -1); > + > + ret = drm_gem_shmem_madvise(shmem, 0); > + KUNIT_ASSERT_FALSE(test, ret); > + KUNIT_ASSERT_EQ(test, shmem->madv, -1); > + > + drm_gem_shmem_free(shmem); > +} > + > +/* Test purging */ > +static void drm_gem_shmem_test_purge(struct kunit *test) > +{ > + struct fake_dev *fdev = test->priv; > + struct drm_gem_shmem_object *shmem; > + struct sg_table *sgt; > + int ret; > + > + shmem = drm_gem_shmem_create(&fdev->drm_dev, TEST_SIZE); > + KUNIT_ASSERT_NOT_ERR_OR_NULL(test, shmem); > + > + ret = drm_gem_shmem_is_purgeable(shmem); > + KUNIT_ASSERT_FALSE(test, ret); > + > + ret = drm_gem_shmem_madvise(shmem, 1); > + KUNIT_ASSERT_TRUE(test, ret); > + > + sgt = drm_gem_shmem_get_pages_sgt(shmem); > + KUNIT_ASSERT_NOT_ERR_OR_NULL(test, sgt); > + > + ret = drm_gem_shmem_is_purgeable(shmem); > + KUNIT_ASSERT_TRUE(test, ret); > + > + drm_gem_shmem_purge(shmem); > + KUNIT_ASSERT_TRUE(test, ret); > + > + drm_gem_shmem_free(shmem); > +} > + > +static int drm_gem_shmem_test_init(struct kunit *test) > +{ > + struct fake_dev *fdev; > + struct device *dev; > + > + /* Allocate a parent device */ > + dev = drm_kunit_helper_alloc_device(test); > + KUNIT_ASSERT_NOT_ERR_OR_NULL(test, dev); > + > + /* > + * The DRM core will automatically initialize the GEM core and create > + * a DRM Memory Manager object which provides an address space pool > + * for GEM objects allocation. > + */ > + fdev = drm_kunit_helper_alloc_drm_device(test, dev, struct fake_dev, > + drm_dev, DRIVER_GEM); > + KUNIT_ASSERT_NOT_ERR_OR_NULL(test, fdev); > + > + fdev->dev = dev; > + test->priv = fdev; > + > + return 0; > +} > + > +static void drm_gem_shmem_test_exit(struct kunit *test) > +{ > + struct fake_dev *fdev = test->priv; > + > + drm_kunit_helper_free_device(test, fdev->dev); > +} You don't need to call drm_kunit_helper_free_device() anymore Maxime

1 year, 7 months

1
0
0 0

[PATCH v2 00/11] 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 3 series and 1 patch: [1] dma-buf: heaps: Add MediaTek secure heap - https://patchwork.kernel.org/project/linux-mediatek/list/?series=782776 [2] add driver to support secure video decoder - https://patchwork.kernel.org/project/linux-mediatek/list/?series=782922 [3] soc: mediatek: Add register definitions for GCE - https://patchwork.kernel.org/project/linux-mediatek/patch/20231017064717.21… [4] Add CMDQ secure driver for SVP - https://patchwork.kernel.org/project/linux-mediatek/list/?series=795502 --- Change in v2: 1. remove the DRIVER_RDNDER flag for mtk_drm_ioctl 2. move cmdq_insert_backup_cookie into client driver 3. move secure gce node define from mt8195-cherry.dtsi to mt8195.dtsi --- CK Hu (1): drm/mediatek: Add interface to allocate MediaTek GEM buffer. Jason-JH.Lin (10): 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 drm/mediatek: Add cmdq_insert_backup_cookie before secure pkt finalize arm64: dts: mt8195: Add secure mbox settings for vdosys arch/arm64/boot/dts/mediatek/mt8195.dtsi | 6 +- 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 | 274 +++++++++++++++++- 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 | 13 + 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, 570 insertions(+), 18 deletions(-) create mode 100644 include/uapi/drm/mediatek_drm.h -- 2.18.0

1 year, 7 months

2
17
0 0

Re: [PATCH] drm/amdgpu: Fix a null pointer access when the smc_rreg pointer is NULL

by Alex Deucher

Applied. Thanks! Alex On Mon, Oct 23, 2023 at 9:06 AM <qu.huang(a)linux.dev> wrote: > > In certain types of chips, such as VEGA20, reading the amdgpu_regs_smc file could result in an abnormal null pointer access when the smc_rreg pointer is NULL. Below are the steps to reproduce this issue and the corresponding exception log: > > 1. Navigate to the directory: /sys/kernel/debug/dri/0 > 2. Execute command: cat amdgpu_regs_smc > 3. Exception Log:: > [4005007.702554] BUG: kernel NULL pointer dereference, address: 0000000000000000 > [4005007.702562] #PF: supervisor instruction fetch in kernel mode > [4005007.702567] #PF: error_code(0x0010) - not-present page > [4005007.702570] PGD 0 P4D 0 > [4005007.702576] Oops: 0010 [#1] SMP NOPTI > [4005007.702581] CPU: 4 PID: 62563 Comm: cat Tainted: G OE 5.15.0-43-generic #46-Ubunt u > [4005007.702590] RIP: 0010:0x0 > [4005007.702598] Code: Unable to access opcode bytes at RIP 0xffffffffffffffd6. > [4005007.702600] RSP: 0018:ffffa82b46d27da0 EFLAGS: 00010206 > [4005007.702605] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffa82b46d27e68 > [4005007.702609] RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffff9940656e0000 > [4005007.702612] RBP: ffffa82b46d27dd8 R08: 0000000000000000 R09: ffff994060c07980 > [4005007.702615] R10: 0000000000020000 R11: 0000000000000000 R12: 00007f5e06753000 > [4005007.702618] R13: ffff9940656e0000 R14: ffffa82b46d27e68 R15: 00007f5e06753000 > [4005007.702622] FS: 00007f5e0755b740(0000) GS:ffff99479d300000(0000) knlGS:0000000000000000 > [4005007.702626] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > [4005007.702629] CR2: ffffffffffffffd6 CR3: 00000003253fc000 CR4: 00000000003506e0 > [4005007.702633] Call Trace: > [4005007.702636] <TASK> > [4005007.702640] amdgpu_debugfs_regs_smc_read+0xb0/0x120 [amdgpu] > [4005007.703002] full_proxy_read+0x5c/0x80 > [4005007.703011] vfs_read+0x9f/0x1a0 > [4005007.703019] ksys_read+0x67/0xe0 > [4005007.703023] __x64_sys_read+0x19/0x20 > [4005007.703028] do_syscall_64+0x5c/0xc0 > [4005007.703034] ? do_user_addr_fault+0x1e3/0x670 > [4005007.703040] ? exit_to_user_mode_prepare+0x37/0xb0 > [4005007.703047] ? irqentry_exit_to_user_mode+0x9/0x20 > [4005007.703052] ? irqentry_exit+0x19/0x30 > [4005007.703057] ? exc_page_fault+0x89/0x160 > [4005007.703062] ? asm_exc_page_fault+0x8/0x30 > [4005007.703068] entry_SYSCALL_64_after_hwframe+0x44/0xae > [4005007.703075] RIP: 0033:0x7f5e07672992 > [4005007.703079] Code: c0 e9 b2 fe ff ff 50 48 8d 3d fa b2 0c 00 e8 c5 1d 02 00 0f 1f 44 00 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 0f 05 <48> 3d 00 f0 ff ff 77 56 c3 0f 1f 44 00 00 48 83 e c 28 48 89 54 24 > [4005007.703083] RSP: 002b:00007ffe03097898 EFLAGS: 00000246 ORIG_RAX: 0000000000000000 > [4005007.703088] RAX: ffffffffffffffda RBX: 0000000000020000 RCX: 00007f5e07672992 > [4005007.703091] RDX: 0000000000020000 RSI: 00007f5e06753000 RDI: 0000000000000003 > [4005007.703094] RBP: 00007f5e06753000 R08: 00007f5e06752010 R09: 00007f5e06752010 > [4005007.703096] R10: 0000000000000022 R11: 0000000000000246 R12: 0000000000022000 > [4005007.703099] R13: 0000000000000003 R14: 0000000000020000 R15: 0000000000020000 > [4005007.703105] </TASK> > [4005007.703107] Modules linked in: nf_tables libcrc32c nfnetlink algif_hash af_alg binfmt_misc nls_ iso8859_1 ipmi_ssif ast intel_rapl_msr intel_rapl_common drm_vram_helper drm_ttm_helper amd64_edac t tm edac_mce_amd kvm_amd ccp mac_hid k10temp kvm acpi_ipmi ipmi_si rapl sch_fq_codel ipmi_devintf ipm i_msghandler msr parport_pc ppdev lp parport mtd pstore_blk efi_pstore ramoops pstore_zone reed_solo mon ip_tables x_tables autofs4 ib_uverbs ib_core amdgpu(OE) amddrm_ttm_helper(OE) amdttm(OE) iommu_v 2 amd_sched(OE) amdkcl(OE) drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops cec rc_core drm igb ahci xhci_pci libahci i2c_piix4 i2c_algo_bit xhci_pci_renesas dca > [4005007.703184] CR2: 0000000000000000 > [4005007.703188] ---[ end trace ac65a538d240da39 ]--- > [4005007.800865] RIP: 0010:0x0 > [4005007.800871] Code: Unable to access opcode bytes at RIP 0xffffffffffffffd6. > [4005007.800874] RSP: 0018:ffffa82b46d27da0 EFLAGS: 00010206 > [4005007.800878] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffa82b46d27e68 > [4005007.800881] RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffff9940656e0000 > [4005007.800883] RBP: ffffa82b46d27dd8 R08: 0000000000000000 R09: ffff994060c07980 > [4005007.800886] R10: 0000000000020000 R11: 0000000000000000 R12: 00007f5e06753000 > [4005007.800888] R13: ffff9940656e0000 R14: ffffa82b46d27e68 R15: 00007f5e06753000 > [4005007.800891] FS: 00007f5e0755b740(0000) GS:ffff99479d300000(0000) knlGS:0000000000000000 > [4005007.800895] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > [4005007.800898] CR2: ffffffffffffffd6 CR3: 00000003253fc000 CR4: 00000000003506e0 > > Signed-off-by: Qu Huang <qu.huang(a)linux.dev> > --- > drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 6 ++++++ > 1 file changed, 6 insertions(+) > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c > index a4faea4..05405da 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c > @@ -748,6 +748,9 @@ static ssize_t amdgpu_debugfs_regs_smc_read(struct file *f, char __user *buf, > ssize_t result = 0; > int r; > > + if (!adev->smc_rreg) > + return -EPERM; > + > if (size & 0x3 || *pos & 0x3) > return -EINVAL; > > @@ -804,6 +807,9 @@ static ssize_t amdgpu_debugfs_regs_smc_write(struct file *f, const char __user * > ssize_t result = 0; > int r; > > + if (!adev->smc_wreg) > + return -EPERM; > + > if (size & 0x3 || *pos & 0x3) > return -EINVAL; > > -- > 1.8.3.1

1 year, 7 months

1
0
0 0

[syzbot] [dri?] WARNING in drm_prime_fd_to_handle_ioctl

by syzbot

Hello, syzbot found the following issue on: HEAD commit: 1c8b86a3799f Merge tag 'xsa441-6.6-tag' of git://git.kerne.. git tree: upstream console+strace: https://syzkaller.appspot.com/x/log.txt?x=13005e31680000 kernel config: https://syzkaller.appspot.com/x/.config?x=32d0b9b42ceb8b10 dashboard link: https://syzkaller.appspot.com/bug?extid=0da81ccba2345eeb7f48 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=13c48345680000 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=101b3679680000 Downloadable assets: disk image: https://storage.googleapis.com/syzbot-assets/45e9377886e9/disk-1c8b86a3.raw… vmlinux: https://storage.googleapis.com/syzbot-assets/9511a41a6d1e/vmlinux-1c8b86a3.… kernel image: https://storage.googleapis.com/syzbot-assets/fac07e1c3c1a/bzImage-1c8b86a3.… The issue was bisected to: commit 85e26dd5100a182bf8448050427539c0a66ab793 Author: Christian König <christian.koenig(a)amd.com> Date: Thu Jan 26 09:24:26 2023 +0000 drm/client: fix circular reference counting issue bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=14cf17f1680000 final oops: https://syzkaller.appspot.com/x/report.txt?x=16cf17f1680000 console output: https://syzkaller.appspot.com/x/log.txt?x=12cf17f1680000 IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+0da81ccba2345eeb7f48(a)syzkaller.appspotmail.com Fixes: 85e26dd5100a ("drm/client: fix circular reference counting issue") ------------[ cut here ]------------ WARNING: CPU: 0 PID: 5040 at drivers/gpu/drm/drm_prime.c:326 drm_gem_prime_fd_to_handle drivers/gpu/drm/drm_prime.c:326 [inline] WARNING: CPU: 0 PID: 5040 at drivers/gpu/drm/drm_prime.c:326 drm_prime_fd_to_handle_ioctl+0x555/0x600 drivers/gpu/drm/drm_prime.c:374 Modules linked in: CPU: 0 PID: 5040 Comm: syz-executor405 Not tainted 6.6.0-rc5-syzkaller-00055-g1c8b86a3799f #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/06/2023 RIP: 0010:drm_gem_prime_fd_to_handle drivers/gpu/drm/drm_prime.c:326 [inline] RIP: 0010:drm_prime_fd_to_handle_ioctl+0x555/0x600 drivers/gpu/drm/drm_prime.c:374 Code: 89 df e8 0e 9b 26 fd f0 48 ff 03 e9 7e fd ff ff e8 b0 dc d0 fc 4c 89 f7 44 89 eb e8 75 73 8b 05 e9 da fe ff ff e8 9b dc d0 fc <0f> 0b e9 5d fd ff ff e8 3f 94 26 fd e9 3a fc ff ff 48 8b 7c 24 08 RSP: 0018:ffffc90003a5fc70 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffff888018f14c00 RCX: 0000000000000000 RDX: ffff88801d691dc0 RSI: ffffffff84b6ea15 RDI: ffff8881476f3928 RBP: ffff88801fac5400 R08: 0000000000000007 R09: fffffffffffff000 R10: ffff8881476f3800 R11: 0000000000000000 R12: ffffc90003a5fe10 R13: ffff8881476f3800 R14: ffff88801c590c10 R15: 0000000000000000 FS: 00005555555d6380(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000555db75f4058 CR3: 0000000072209000 CR4: 0000000000350ef0 Call Trace: <TASK> 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:0x7f0c8214be69 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 c1 17 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 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fff6f4156f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f0c8214be69 RDX: 0000000020000000 RSI: 00000000c00c642e RDI: 0000000000000003 RBP: 0000000000000000 R08: 00000000000000a0 R09: 00000000000000a0 R10: 00000000000000a0 R11: 0000000000000246 R12: 0000000000000000 R13: 00007f0c821c3820 R14: 00007fff6f415720 R15: 00007fff6f415710 </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. For information about bisection process see: https://goo.gl/tpsmEJ#bisection 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

1 year, 7 months

2
1
0 0

[PATCH][next] dma-buf: Fix NULL pointer dereference in dma_fence_enable_sw_signaling()

by Gustavo A. R. Silva

Currently, a NULL pointer dereference will happen in function `dma_fence_enable_sw_signaling()` (at line 615), in case `chain` is not allocated in `mock_chain()` and this function returns `NULL` (at line 86). See below: drivers/dma-buf/st-dma-fence-chain.c: 86 chain = mock_chain(NULL, f, 1); 87 if (!chain) 88 err = -ENOMEM; 89 90 dma_fence_enable_sw_signaling(chain); drivers/dma-buf/dma-fence.c: 611 void dma_fence_enable_sw_signaling(struct dma_fence *fence) 612 { 613 unsigned long flags; 614 615 spin_lock_irqsave(fence->lock, flags); ^^^^^^^^^^^ | NULL pointer reference if fence == NULL 616 __dma_fence_enable_signaling(fence); 617 spin_unlock_irqrestore(fence->lock, flags); 618 } Fix this by adding a NULL check before dereferencing `fence` in `dma_fence_enable_sw_signaling()`. This will prevent any other NULL pointer dereference when the `fence` passed as an argument is `NULL`. Addresses-Coverity: ("Dereference after null check") Fixes: d62c43a953ce ("dma-buf: Enable signaling on fence for selftests") Cc: stable(a)vger.kernel.org Signed-off-by: Gustavo A. R. Silva <gustavoars(a)kernel.org> --- drivers/dma-buf/dma-fence.c | 9 ++++++++- include/linux/dma-fence.h | 2 +- 2 files changed, 9 insertions(+), 2 deletions(-) diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c index 8aa8f8cb7071..4d2f13560d0f 100644 --- a/drivers/dma-buf/dma-fence.c +++ b/drivers/dma-buf/dma-fence.c @@ -607,14 +607,21 @@ static bool __dma_fence_enable_signaling(struct dma_fence *fence) * This will request for sw signaling to be enabled, to make the fence * complete as soon as possible. This calls &dma_fence_ops.enable_signaling * internally. + * + * Returns 0 on success and a negative error value when @fence is NULL. */ -void dma_fence_enable_sw_signaling(struct dma_fence *fence) +int dma_fence_enable_sw_signaling(struct dma_fence *fence) { unsigned long flags; + if (!fence) + return -EINVAL; + spin_lock_irqsave(fence->lock, flags); __dma_fence_enable_signaling(fence); spin_unlock_irqrestore(fence->lock, flags); + + return 0; } EXPORT_SYMBOL(dma_fence_enable_sw_signaling); diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h index ebe78bd3d121..1e4025e925e6 100644 --- a/include/linux/dma-fence.h +++ b/include/linux/dma-fence.h @@ -399,7 +399,7 @@ int dma_fence_add_callback(struct dma_fence *fence, dma_fence_func_t func); bool dma_fence_remove_callback(struct dma_fence *fence, struct dma_fence_cb *cb); -void dma_fence_enable_sw_signaling(struct dma_fence *fence); +int dma_fence_enable_sw_signaling(struct dma_fence *fence); /** * dma_fence_is_signaled_locked - Return an indication if the fence -- 2.34.1

1 year, 7 months

4
3
0 0

[PATCH] dma-buf: Fix NULL pointer dereference in sanitycheck()

by Pavel Sakharov

If mock_chain() returns NULL, NULL pointer is dereferenced in dma_fence_enable_sw_signaling(). Found by Linux Verification Center (linuxtesting.org) with SVACE. Signed-off-by: Pavel Sakharov <p.sakharov(a)ispras.ru> Fixes: d62c43a953ce ("dma-buf: Enable signaling on fence for selftests") --- drivers/dma-buf/st-dma-fence-chain.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/dma-buf/st-dma-fence-chain.c b/drivers/dma-buf/st-dma-fence-chain.c index c0979c8049b5..661de4add4c7 100644 --- a/drivers/dma-buf/st-dma-fence-chain.c +++ b/drivers/dma-buf/st-dma-fence-chain.c @@ -84,11 +84,11 @@ static int sanitycheck(void *arg) return -ENOMEM; chain = mock_chain(NULL, f, 1); - if (!chain) + if (chain) + dma_fence_enable_sw_signaling(chain); + else err = -ENOMEM; - dma_fence_enable_sw_signaling(chain); - dma_fence_signal(f); dma_fence_put(f); -- 2.42.0

1 year, 8 months

1
0
0 0

[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)

1 year, 8 months

4
14
0 0

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

1 year, 8 months

1
0
0 0

[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

1 year, 8 months

2
3
0 0

[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

1 year, 8 months

3
3
0 0

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 > >

1 year, 8 months

1
0
0 0

[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

1 year, 8 months

4
13
0 0

[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

1 year, 8 months

1
0
0 0

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

1 year, 8 months

1
0
0 0

[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

1 year, 8 months

1
0
0 0

[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

1 year, 8 months

3
2
0 0

Redukcja mocy na wezwanie

by Dawid Jarocki

Dzień dobry, czy jest możliwość, by na pewien czas Państwa zakład produkcyjny mógł zrezygnować z części lub całości zużywanej energii? W zamian za gotowość do redukcji i jej wykonanie mogą otrzymać Państwo stałe wynagrodzenie, które w przeliczeniu na 1 MW redukcji mocy wynosi od 500 do 720 tys. zł w zależności od czasu zdolności do redukcji. Uczestnictwo w programie DSR (Demand Side Response) to dla Państwa brak kosztów implementacji i wzrost bezpieczeństwa energetycznego. Jeśli interesuje Państwa generowanie wieloletnich przychodów z programu DSR, proszę o wiadomość. Pozdrawiam Dawid Jarocki

1 year, 8 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig