Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

30 participants
3372 discussions

Re: [PATCH 5/5] dma-buf: heaps: system: add an option to allocate explicitly decrypted memory

by kernel test robot

Hi Jiri, kernel test robot noticed the following build errors: [auto build test ERROR on drm-misc/drm-misc-next] [also build test ERROR on drm-tip/drm-tip trace/for-next linus/master v6.19] [cannot apply to next-20260209] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch#_base_tree_information] url: https://github.com/intel-lab-lkp/linux/commits/Jiri-Pirko/dma-mapping-avoid… base: https://gitlab.freedesktop.org/drm/misc/kernel.git drm-misc-next patch link: https://lore.kernel.org/r/20260209153809.250835-6-jiri%40resnulli.us patch subject: [PATCH 5/5] dma-buf: heaps: system: add an option to allocate explicitly decrypted memory config: s390-allmodconfig (https://download.01.org/0day-ci/archive/20260210/202602101926.lsquJdb1-lkp@…) compiler: clang version 18.1.8 (https://github.com/llvm/llvm-project 3b5b5c1ec4a3095ab096dd780e84d7ab81f3d7ff) reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260210/202602101926.lsquJdb1-lkp@…) 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 <lkp(a)intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202602101926.lsquJdb1-lkp@intel.com/ All errors (new ones prefixed by >>): >> drivers/dma-buf/heaps/system_heap.c:66:8: error: call to undeclared function 'set_memory_decrypted'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] 66 | ret = set_memory_decrypted(addr, nr_pages); | ^ >> drivers/dma-buf/heaps/system_heap.c:80:8: error: call to undeclared function 'set_memory_encrypted'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] 80 | ret = set_memory_encrypted(addr, nr_pages); | ^ 2 errors generated. vim +/set_memory_decrypted +66 drivers/dma-buf/heaps/system_heap.c 59 60 static int system_heap_set_page_decrypted(struct page *page) 61 { 62 unsigned long addr = (unsigned long)page_address(page); 63 unsigned int nr_pages = 1 << compound_order(page); 64 int ret; 65 > 66 ret = set_memory_decrypted(addr, nr_pages); 67 if (ret) 68 pr_warn_ratelimited("dma-buf system heap: failed to decrypt page at %p\n", 69 page_address(page)); 70 71 return ret; 72 } 73 74 static int system_heap_set_page_encrypted(struct page *page) 75 { 76 unsigned long addr = (unsigned long)page_address(page); 77 unsigned int nr_pages = 1 << compound_order(page); 78 int ret; 79 > 80 ret = set_memory_encrypted(addr, nr_pages); 81 if (ret) 82 pr_warn_ratelimited("dma-buf system heap: failed to re-encrypt page at %p, leaking memory\n", 83 page_address(page)); 84 85 return ret; 86 } 87 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 week

Independence for dma_fences! v7

by Christian König

Hi everyone, dma_fences have ever lived under the tyranny dictated by the module lifetime of their issuer, leading to crashes should anybody still holding a reference to a dma_fence when the module of the issuer was unloaded. The basic problem is that when buffer are shared between drivers dma_fence objects can leak into external drivers and stay there even after they are signaled. The dma_resv object for example only lazy releases dma_fences. So what happens is that when the module who originally created the dma_fence unloads the dma_fence_ops function table becomes unavailable as well and so any attempt to release the fence crashes the system. Previously various approaches have been discussed, including changing the locking semantics of the dma_fence callbacks (by me) as well as using the drm scheduler as intermediate layer (by Sima) to disconnect dma_fences from their actual users, but none of them are actually solving all problems. Tvrtko did some really nice prerequisite work by protecting the returned strings of the dma_fence_ops by RCU. This way dma_fence creators where able to just wait for an RCU grace period after fence signaling before they could be save to free those data structures. Now this patch set here goes a step further and protects the whole dma_fence_ops structure by RCU, so that after the fence signals the pointer to the dma_fence_ops is set to NULL when there is no wait nor release callback given. All functionality which use the dma_fence_ops reference are put inside an RCU critical section, except for the deprecated issuer specific wait and of course the optional release callback. Additional to the RCU changes the lock protecting the dma_fence state previously had to be allocated external. This set here now changes the functionality to make that external lock optional and allows dma_fences to use an inline lock and be self contained. v4: Rebases the whole set on upstream changes, especially the cleanup from Philip in patch "drm/amdgpu: independence for the amdkfd_fence!". Adding two patches which brings the DMA-fence self tests up to date. The first selftest changes removes the mock_wait and so actually starts testing the default behavior instead of some hacky implementation in the test. This one got upstreamed independent of this set. The second drops the mock_fence as well and tests the new RCU and inline spinlock functionality. v5: Rebase on top of drm-misc-next instead of drm-tip, leave out all driver changes for now since those should go through the driver specific paths anyway. Address a few more review comments, especially some rebase mess and typos. And finally fix one more bug found by AMDs CI system. v6: Minor style changes, re-ordered patch #1, dropped the scheduler fence change for now v7: The patch adding the dma_fence_was_initialized() function was pushed upstream individually since that is really an independent cleanup. Fixed some missing i915 bits in patch "dma-buf: abstract fence locking". Please review and comment, Christian.

1 week

Re: [PATCH 4/5] dma-buf: heaps: allow heap to specify valid heap flags

by John Stultz

On Mon, Feb 9, 2026 at 7:38 AM Jiri Pirko <jiri(a)resnulli.us> wrote: > > From: Jiri Pirko <jiri(a)nvidia.com> > > Currently the flags, which are unused, are validated for all heaps. > Since the follow-up patch introduces a flag valid for only one of the > heaps, allow to specify the valid flags per-heap. I'm not really in this space anymore, so take my feedback with a grain of salt. While the heap allocate flags argument is unused, it was intended to be used for generic allocation flags that would apply to all or at least a wide majority of heaps. It was definitely not added to allow for per-heap or heap specific flags (as this patch tries to utilize it). That was the mess we had with ION driver that we were trying to avoid. The intent of dma-buf heaps is to try to abstract all the different device memory constraints so there only needs to be a [usage] -> [heap] mapping, and otherwise userland can be generalized so that it doesn't need to be re-written to work with different devices/memory types. Adding heap-specific allocation flags prevents that generalization. So instead of adding heap specific flags, the general advice has been to add a separate heap name for the flag property. Now, there has been many discussions around "protected buffers" (which doesn't seem to map exactly to this confidental computing primitive, but sounds like it might be related) , which have bounced between being a allocation flag or a device specific heap without much resolution. I appreciate in this patch seires you've pushed your concept down into a DMA_ATTR_, as I do feel the kernel should have a deeper sense of protected buffers (or any general propery like this) as a concept if it is going to be a generic allocation flag, instead of it being a somewhat thin creation of the outer heap-driver layer. But, it seems like the use case here is still far too narrow for a top level allocation flag. So I'd advocate against introducing heap-specific flags like this. thanks -john

1 week, 1 day

Re: [PATCH] dma-fence: Fix sparse warnings due __rcu annotations

by Christian König

On 6/16/25 17:59, Tvrtko Ursulin wrote: > __rcu annotations on the return types from dma_fence_driver_name() and > dma_fence_timeline_name() cause sparse to complain because both the > constant signaled strings, and the strings return by the dma_fence_ops are > not __rcu annotated. > > For a simple fix it is easiest to cast them with __rcu added and undo the > smarts from the tracpoints side of things. There is no functional change > since the rest is left in place. Later we can consider changing the > dma_fence_ops return types too, and handle all the individual drivers > which define them. > > Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin(a)igalia.com> > Fixes: 506aa8b02a8d ("dma-fence: Add safe access helpers and document the rules") > Reported-by: kernel test robot <lkp(a)intel.com> > Closes: https://lore.kernel.org/oe-kbuild-all/202506162214.1eA69hLe-lkp@intel.com/ > Cc: Christian König <christian.koenig(a)amd.com> Sorry for the delayed reply, completed missed this one. Patch is reviewed and pushed to drm-misc-next. It eventually will be backported to stable kernels because of the fixes tag, but since this is not a functional bug I didn't added a CC:stable tag. Thanks, Christian. > --- > drivers/dma-buf/dma-fence.c | 8 ++++---- > include/trace/events/dma_fence.h | 35 +++++--------------------------- > 2 files changed, 9 insertions(+), 34 deletions(-) > > diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c > index 3f78c56b58dc..da60d4e68b89 100644 > --- a/drivers/dma-buf/dma-fence.c > +++ b/drivers/dma-buf/dma-fence.c > @@ -1109,9 +1109,9 @@ const char __rcu *dma_fence_driver_name(struct dma_fence *fence) > "RCU protection is required for safe access to returned string"); > > if (!test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags)) > - return fence->ops->get_driver_name(fence); > + return (const char __rcu *)fence->ops->get_driver_name(fence); > else > - return "detached-driver"; > + return (const char __rcu *)"detached-driver"; > } > EXPORT_SYMBOL(dma_fence_driver_name); > > @@ -1141,8 +1141,8 @@ const char __rcu *dma_fence_timeline_name(struct dma_fence *fence) > "RCU protection is required for safe access to returned string"); > > if (!test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags)) > - return fence->ops->get_driver_name(fence); > + return (const char __rcu *)fence->ops->get_driver_name(fence); > else > - return "signaled-timeline"; > + return (const char __rcu *)"signaled-timeline"; > } > EXPORT_SYMBOL(dma_fence_timeline_name); > diff --git a/include/trace/events/dma_fence.h b/include/trace/events/dma_fence.h > index 4814a65b68dc..3abba45c0601 100644 > --- a/include/trace/events/dma_fence.h > +++ b/include/trace/events/dma_fence.h > @@ -9,37 +9,12 @@ > > struct dma_fence; > > -DECLARE_EVENT_CLASS(dma_fence, > - > - TP_PROTO(struct dma_fence *fence), > - > - TP_ARGS(fence), > - > - TP_STRUCT__entry( > - __string(driver, dma_fence_driver_name(fence)) > - __string(timeline, dma_fence_timeline_name(fence)) > - __field(unsigned int, context) > - __field(unsigned int, seqno) > - ), > - > - TP_fast_assign( > - __assign_str(driver); > - __assign_str(timeline); > - __entry->context = fence->context; > - __entry->seqno = fence->seqno; > - ), > - > - TP_printk("driver=%s timeline=%s context=%u seqno=%u", > - __get_str(driver), __get_str(timeline), __entry->context, > - __entry->seqno) > -); > - > /* > * Safe only for call sites which are guaranteed to not race with fence > * signaling,holding the fence->lock and having checked for not signaled, or the > * signaling path itself. > */ > -DECLARE_EVENT_CLASS(dma_fence_unsignaled, > +DECLARE_EVENT_CLASS(dma_fence, > > TP_PROTO(struct dma_fence *fence), > > @@ -64,14 +39,14 @@ DECLARE_EVENT_CLASS(dma_fence_unsignaled, > __entry->seqno) > ); > > -DEFINE_EVENT(dma_fence_unsignaled, dma_fence_emit, > +DEFINE_EVENT(dma_fence, dma_fence_emit, > > TP_PROTO(struct dma_fence *fence), > > TP_ARGS(fence) > ); > > -DEFINE_EVENT(dma_fence_unsignaled, dma_fence_init, > +DEFINE_EVENT(dma_fence, dma_fence_init, > > TP_PROTO(struct dma_fence *fence), > > @@ -85,14 +60,14 @@ DEFINE_EVENT(dma_fence, dma_fence_destroy, > TP_ARGS(fence) > ); > > -DEFINE_EVENT(dma_fence_unsignaled, dma_fence_enable_signal, > +DEFINE_EVENT(dma_fence, dma_fence_enable_signal, > > TP_PROTO(struct dma_fence *fence), > > TP_ARGS(fence) > ); > > -DEFINE_EVENT(dma_fence_unsignaled, dma_fence_signaled, > +DEFINE_EVENT(dma_fence, dma_fence_signaled, > > TP_PROTO(struct dma_fence *fence), >

1 week, 1 day

Re: [PATCH v7 7/8] vfio: Permit VFIO to work with pinned importers

by Jason Gunthorpe

On Thu, Feb 05, 2026 at 07:41:11AM -0700, Alex Williamson wrote: > >> From https://anongit.freedesktop.org/git/drm/drm-misc > >> * branch drm-misc-next -> FETCH_HEAD > >> > >> $ git show FETCH_HEAD > >> commit 779ec12c85c9e4547519e3903a371a3b26a289de > >> Author: Alexander Konyukhov <Alexander.Konyukhov(a)kaspersky.com> > >> Date: Tue Feb 3 16:48:46 2026 +0300 > >> > >> drm/komeda: fix integer overflow in AFBC framebuffer size check > >> > >> $ git merge-base FETCH_HEAD 61ceaf236115f20f4fdd7cf60f883ada1063349a > >> 24d479d26b25bce5faea3ddd9fa8f3a6c3129ea7 > >> $ git describe --contains 24d479d26b25bce5faea3ddd9fa8f3a6c3129ea7 > >> v6.19-rc6^0 > >> > >> $ git log --oneline 61ceaf236115f20f4fdd7cf60f883ada1063349a ^FETCH_HEAD > >> 61ceaf236115f2 vfio: Prevent from pinned DMABUF importers to attach to VFIO DMABUF > >> > >> Just pull Alex's tree, the drm-misc-next tree already has v6.19-rc6, > >> so all they will see is one extra patch from Alex in your PR. > >> > >> No need to backmerge, this is normal git stuff and there won't be > >> conflicts when they merge a later Linus tag. > > > > Correct, but that would merge the same patch through two different > > trees. That is usually a pretty big no-go. > > Applying the patch through two different trees is a no-go, but > merging the same commit from a shared branch or tag is very common > and acceptable. It's the same commit after all, there is no > conflict, no duplicate commit. When the trees are merged, the > commit will exist once in the log. Thanks, +1 This is how shared branches work. There is no issue here. Jason

1 week, 5 days

Re: [PATCH v7 7/8] vfio: Permit VFIO to work with pinned importers

by Christian König

On 2/4/26 17:56, Alex Williamson wrote: ... >> >> This chunk here doesn't want to apply to drm-misc-next, my educated >> guess is that the patch adding those lines is missing in that tree. >> >> How should we handle that? Patches 1-3 have already been pushed to >> drm-misc-next and I would rather like to push patches 4-6 through >> that branch as well. >> >> I can request a backmerge from the drm-misc-next maintainers, but >> then we clearly don't get that upstream this week. > > Hmm, drm-next already has a backmerge up to v6.19-rc7, the patch here is > based on a commit merged in rc8. The tag for that change was based on > rc6. It can be found here: > > https://github.com/awilliam/linux-vfio.git tags/vfio-v6.19-rc8 > > As the same tag Linus merged in: > > 1f97d9dcf536 ("Merge tag 'vfio-v6.19-rc8' of https://github.com/awilliam/linux-vfio") > > drm-misc-next only seems to be based on v6.19-rc1 though, so I don't > know that any of that helps. Thanks, Thanks Alex, that was indeed helpful. Simona, Jani and Lucas can we do a backmerge of 6.19-rc8 into drm-misc-next or does that completely breaks the flow? If it's not possible immediately then I will do the merge next week or so when the final 6.19 is out and everything merged back into the drm-misc trees. Leon the flow of patches through the DRM subsystem is documented here: https://drm.pages.freedesktop.org/maintainer-tools/repositories/drm-misc.ht… Thanks, Christian. > > Alex

1 week, 5 days

Re: [PATCH rdma-next v3 0/3] RDMA: Add support for exporting dma-buf file descriptors

by Leon Romanovsky

On Sun, 01 Feb 2026 16:34:03 +0200, Edward Srouji wrote: > This patch series introduces dma-buf export support for RDMA/InfiniBand > devices, enabling userspace applications to export RDMA PCI-backed > memory regions (such as device memory or mlx5 UAR pages) as dma-buf file > descriptors. > > This allows PCI device memory to be shared with other kernel subsystems > (e.g., graphics or media) or between userspace processes, via the > standard dma-buf interface, avoiding unnecessary copies and enabling > efficient peer-to-peer (P2P) DMA transfers. See [1] for background on > dma-buf. > > [...] Applied, thanks! [1/3] RDMA/uverbs: Support external FD uobjects https://git.kernel.org/rdma/rdma/c/6b848074a32078 [2/3] RDMA/uverbs: Add DMABUF object type and operations https://git.kernel.org/rdma/rdma/c/e6738fe6cad448 [3/3] RDMA/mlx5: Implement DMABUF export ops https://git.kernel.org/rdma/rdma/c/992a14bb2150a1 Best regards, -- Leon Romanovsky <leon(a)kernel.org>

1 week, 5 days

How to Recover Lost or Scammed Cryptocurrency, visit OPTIMISTIC HACKER GAIUS

by benjaminlucas0a＠gmail.com

OPTIMISTIC HACKER GAIUS is a professional crypto recovery service specializing in lost Bitcoin recovery, scammed USDT recovery, and digital asset tracing. The company uses advanced blockchain analysis and investigative techniques to track and recover stolen or inaccessible cryptocurrency. Known for clear communication and ethical practices, OPTIMISTIC HACKER GAIUS provides realistic assessments and reliable support for individuals and businesses affected by crypto-related losses. Mail-Box: support @ optimistichackargaius. c om WhatsApp: +44 737 674 0569 Website: optimistichackargaius. co m

1 week, 5 days

How to Recover Lost or Scammed Cryptocurrency, visit OPTIMISTIC HACKER GAIUS

by benjaminlucas0a＠gmail.com

1 week, 5 days

How to Recover Lost or Scammed Cryptocurrency, visit OPTIMISTIC HACKER GAIUS

by benjaminlucas0a＠gmail.com

1 week, 5 days

← Newer
1
2
3
4
5
6
7
8
9
...
338
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig