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