From: Leon Romanovsky <leonro@nvidia.com>
Till now VFIO has rejected pinned importers, largely to avoid being used
with the RDMA pinned importer that cannot handle a move_notify() to revoke
access.
Using dma_buf_attach_revocable() it can tell the difference between pinned
importers that support the flow described in dma_buf_invalidate_mappings()
and those that don't.
Thus permit compatible pinned importers.
This is one of two items IOMMUFD requires to remove its private interface
to VFIO's dma-buf.
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Reviewed-by: Alex Williamson <alex@shazbot.org>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
---
drivers/vfio/pci/vfio_pci_dmabuf.c | 15 +++------------
1 file changed, 3 insertions(+), 12 deletions(-)
diff --git a/drivers/vfio/pci/vfio_pci_dmabuf.c b/drivers/vfio/pci/vfio_pci_dmabuf.c
index 78d47e260f34..a5fb80e068ee 100644
--- a/drivers/vfio/pci/vfio_pci_dmabuf.c
+++ b/drivers/vfio/pci/vfio_pci_dmabuf.c
@@ -22,16 +22,6 @@ struct vfio_pci_dma_buf {
u8 revoked : 1;
};
-static int vfio_pci_dma_buf_pin(struct dma_buf_attachment *attachment)
-{
- return -EOPNOTSUPP;
-}
-
-static void vfio_pci_dma_buf_unpin(struct dma_buf_attachment *attachment)
-{
- /* Do nothing */
-}
-
static int vfio_pci_dma_buf_attach(struct dma_buf *dmabuf,
struct dma_buf_attachment *attachment)
{
@@ -43,6 +33,9 @@ static int vfio_pci_dma_buf_attach(struct dma_buf *dmabuf,
if (priv->revoked)
return -ENODEV;
+ if (!dma_buf_attach_revocable(attachment))
+ return -EOPNOTSUPP;
+
return 0;
}
@@ -107,8 +100,6 @@ static void vfio_pci_dma_buf_release(struct dma_buf *dmabuf)
}
static const struct dma_buf_ops vfio_pci_dmabuf_ops = {
- .pin = vfio_pci_dma_buf_pin,
- .unpin = vfio_pci_dma_buf_unpin,
.attach = vfio_pci_dma_buf_attach,
.map_dma_buf = vfio_pci_dma_buf_map,
.unmap_dma_buf = vfio_pci_dma_buf_unmap,
--
2.52.0
On 1/31/26 06:34, Leon Romanovsky wrote:
> From: Leon Romanovsky <leonro@nvidia.com>
>
> Till now VFIO has rejected pinned importers, largely to avoid being used
> with the RDMA pinned importer that cannot handle a move_notify() to revoke
> access.
>
> Using dma_buf_attach_revocable() it can tell the difference between pinned
> importers that support the flow described in dma_buf_invalidate_mappings()
> and those that don't.
>
> Thus permit compatible pinned importers.
>
> This is one of two items IOMMUFD requires to remove its private interface
> to VFIO's dma-buf.
>
> Reviewed-by: Kevin Tian <kevin.tian@intel.com>
> Reviewed-by: Alex Williamson <alex@shazbot.org>
> Reviewed-by: Christian König <christian.koenig@amd.com>
> Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
> ---
> drivers/vfio/pci/vfio_pci_dmabuf.c | 15 +++------------
> 1 file changed, 3 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/vfio/pci/vfio_pci_dmabuf.c b/drivers/vfio/pci/vfio_pci_dmabuf.c
> index 78d47e260f34..a5fb80e068ee 100644
> --- a/drivers/vfio/pci/vfio_pci_dmabuf.c
> +++ b/drivers/vfio/pci/vfio_pci_dmabuf.c
> @@ -22,16 +22,6 @@ struct vfio_pci_dma_buf {
> u8 revoked : 1;
> };
>
> -static int vfio_pci_dma_buf_pin(struct dma_buf_attachment *attachment)
> -{
> - return -EOPNOTSUPP;
> -}
> -
> -static void vfio_pci_dma_buf_unpin(struct dma_buf_attachment *attachment)
> -{
> - /* Do nothing */
> -}
> -
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.
Regards,
Christian.
> static int vfio_pci_dma_buf_attach(struct dma_buf *dmabuf,
> struct dma_buf_attachment *attachment)
> {
> @@ -43,6 +33,9 @@ static int vfio_pci_dma_buf_attach(struct dma_buf *dmabuf,
> if (priv->revoked)
> return -ENODEV;
>
> + if (!dma_buf_attach_revocable(attachment))
> + return -EOPNOTSUPP;
> +
> return 0;
> }
>
> @@ -107,8 +100,6 @@ static void vfio_pci_dma_buf_release(struct dma_buf *dmabuf)
> }
>
> static const struct dma_buf_ops vfio_pci_dmabuf_ops = {
> - .pin = vfio_pci_dma_buf_pin,
> - .unpin = vfio_pci_dma_buf_unpin,
> .attach = vfio_pci_dma_buf_attach,
> .map_dma_buf = vfio_pci_dma_buf_map,
> .unmap_dma_buf = vfio_pci_dma_buf_unmap,
>
On Wed, Feb 04, 2026 at 05:21:45PM +0100, Christian König wrote:
> On 1/31/26 06:34, Leon Romanovsky wrote:
> > From: Leon Romanovsky <leonro@nvidia.com>
> >
> > Till now VFIO has rejected pinned importers, largely to avoid being used
> > with the RDMA pinned importer that cannot handle a move_notify() to revoke
> > access.
> >
> > Using dma_buf_attach_revocable() it can tell the difference between pinned
> > importers that support the flow described in dma_buf_invalidate_mappings()
> > and those that don't.
> >
> > Thus permit compatible pinned importers.
> >
> > This is one of two items IOMMUFD requires to remove its private interface
> > to VFIO's dma-buf.
> >
> > Reviewed-by: Kevin Tian <kevin.tian@intel.com>
> > Reviewed-by: Alex Williamson <alex@shazbot.org>
> > Reviewed-by: Christian König <christian.koenig@amd.com>
> > Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
> > ---
> > drivers/vfio/pci/vfio_pci_dmabuf.c | 15 +++------------
> > 1 file changed, 3 insertions(+), 12 deletions(-)
> >
> > diff --git a/drivers/vfio/pci/vfio_pci_dmabuf.c b/drivers/vfio/pci/vfio_pci_dmabuf.c
> > index 78d47e260f34..a5fb80e068ee 100644
> > --- a/drivers/vfio/pci/vfio_pci_dmabuf.c
> > +++ b/drivers/vfio/pci/vfio_pci_dmabuf.c
> > @@ -22,16 +22,6 @@ struct vfio_pci_dma_buf {
> > u8 revoked : 1;
> > };
> >
> > -static int vfio_pci_dma_buf_pin(struct dma_buf_attachment *attachment)
> > -{
> > - return -EOPNOTSUPP;
> > -}
> > -
> > -static void vfio_pci_dma_buf_unpin(struct dma_buf_attachment *attachment)
> > -{
> > - /* Do nothing */
> > -}
> > -
>
> 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.
There is no need for a backmerge; it should go in through the shared
branch. Alex has created the tag vfio-v6.19-rc8, which is v6.19-rc6 plus
the VFIO pin patch.
You need to merge this tag into drm-misc-next. That will ensure that
Linus, DRM, and VFIO all see the same SHA-1, and that patches 5–6 can be
applied afterward.
Thanks
>
> I can request a backmerge from the drm-misc-next maintainers, but then we clearly don't get that upstream this week.
>
> Regards,
> Christian.
>
> > static int vfio_pci_dma_buf_attach(struct dma_buf *dmabuf,
> > struct dma_buf_attachment *attachment)
> > {
> > @@ -43,6 +33,9 @@ static int vfio_pci_dma_buf_attach(struct dma_buf *dmabuf,
> > if (priv->revoked)
> > return -ENODEV;
> >
> > + if (!dma_buf_attach_revocable(attachment))
> > + return -EOPNOTSUPP;
> > +
> > return 0;
> > }
> >
> > @@ -107,8 +100,6 @@ static void vfio_pci_dma_buf_release(struct dma_buf *dmabuf)
> > }
> >
> > static const struct dma_buf_ops vfio_pci_dmabuf_ops = {
> > - .pin = vfio_pci_dma_buf_pin,
> > - .unpin = vfio_pci_dma_buf_unpin,
> > .attach = vfio_pci_dma_buf_attach,
> > .map_dma_buf = vfio_pci_dma_buf_map,
> > .unmap_dma_buf = vfio_pci_dma_buf_unmap,
> >
>
>
On Wed, 4 Feb 2026 17:21:45 +0100
Christian König <christian.koenig@amd.com> wrote:
> On 1/31/26 06:34, Leon Romanovsky wrote:
> > From: Leon Romanovsky <leonro@nvidia.com>
> >
> > Till now VFIO has rejected pinned importers, largely to avoid being used
> > with the RDMA pinned importer that cannot handle a move_notify() to revoke
> > access.
> >
> > Using dma_buf_attach_revocable() it can tell the difference between pinned
> > importers that support the flow described in dma_buf_invalidate_mappings()
> > and those that don't.
> >
> > Thus permit compatible pinned importers.
> >
> > This is one of two items IOMMUFD requires to remove its private interface
> > to VFIO's dma-buf.
> >
> > Reviewed-by: Kevin Tian <kevin.tian@intel.com>
> > Reviewed-by: Alex Williamson <alex@shazbot.org>
> > Reviewed-by: Christian König <christian.koenig@amd.com>
> > Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
> > ---
> > drivers/vfio/pci/vfio_pci_dmabuf.c | 15 +++------------
> > 1 file changed, 3 insertions(+), 12 deletions(-)
> >
> > diff --git a/drivers/vfio/pci/vfio_pci_dmabuf.c b/drivers/vfio/pci/vfio_pci_dmabuf.c
> > index 78d47e260f34..a5fb80e068ee 100644
> > --- a/drivers/vfio/pci/vfio_pci_dmabuf.c
> > +++ b/drivers/vfio/pci/vfio_pci_dmabuf.c
> > @@ -22,16 +22,6 @@ struct vfio_pci_dma_buf {
> > u8 revoked : 1;
> > };
> >
> > -static int vfio_pci_dma_buf_pin(struct dma_buf_attachment *attachment)
> > -{
> > - return -EOPNOTSUPP;
> > -}
> > -
> > -static void vfio_pci_dma_buf_unpin(struct dma_buf_attachment *attachment)
> > -{
> > - /* Do nothing */
> > -}
> > -
>
> 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,
Alex
> > static int vfio_pci_dma_buf_attach(struct dma_buf *dmabuf,
> > struct dma_buf_attachment
> > *attachment) {
> > @@ -43,6 +33,9 @@ static int vfio_pci_dma_buf_attach(struct dma_buf
> > *dmabuf, if (priv->revoked)
> > return -ENODEV;
> >
> > + if (!dma_buf_attach_revocable(attachment))
> > + return -EOPNOTSUPP;
> > +
> > return 0;
> > }
> >
> > @@ -107,8 +100,6 @@ static void vfio_pci_dma_buf_release(struct
> > dma_buf *dmabuf) }
> >
> > static const struct dma_buf_ops vfio_pci_dmabuf_ops = {
> > - .pin = vfio_pci_dma_buf_pin,
> > - .unpin = vfio_pci_dma_buf_unpin,
> > .attach = vfio_pci_dma_buf_attach,
> > .map_dma_buf = vfio_pci_dma_buf_map,
> > .unmap_dma_buf = vfio_pci_dma_buf_unmap,
> >
>
>
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.html#merge-timeline
Thanks,
Christian.
>
> Alex
On Thu, Feb 05, 2026 at 10:43:08AM +0100, Christian König wrote:
> 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.
Christian,
You don't need any backmerge, SHA-1 version of vfio-v6.19-rc8 tag is the
same as in Linus's tree, so the flow is:
➜ kernel git:(wip/leon-for-next) git remote update drm-misc
Fetching drm-misc
remote: Enumerating objects: 32768, done.
remote: Counting objects: 100% (21620/21620), done.
remote: Compressing objects: 100% (4620/4620), done.
remote: Total 18154 (delta 14789), reused 16751 (delta 13519), pack-reused 0
Receiving objects: 100% (18154/18154), 4.33 MiB | 4.30 MiB/s, done.
Resolving deltas: 100% (14789/14789), completed with 1564 local objects.
From https://anongit.freedesktop.org/git/drm/drm-misc
* [new branch] drm-misc-fixes -> drm-misc/drm-misc-fixes
* [new branch] drm-misc-next -> drm-misc/drm-misc-next
...
➜ kernel git:(wip/leon-for-next) git checkout -b drm-misc-next drm-misc/drm-misc-next
Switched to a new branch 'drm-misc-next'
HEAD is now at 2bcbc706dfa0 dma-buf: add dma_fence_was_initialized function v2
➜ kernel git:(drm-misc-next) git merge vfio-v6.19-rc8
Auto-merging drivers/vfio/pci/vfio_pci_dmabuf.c
Merge made by the 'ort' strategy.
drivers/vfio/pci/vfio_pci_dmabuf.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
➜ kernel git:(drm-misc-next) git l -2
f6e4419050ce (HEAD -> drm-misc-next) Merge tag 'vfio-v6.19-rc8' into drm-misc-next
2bcbc706dfa0 (drm-misc/drm-misc-next, drm-misc/HEAD) dma-buf: add dma_fence_was_initialized function v2
And after that you can apply rest of dma-buf patches.
Thanks
>
> Leon the flow of patches through the DRM subsystem is documented here: https://drm.pages.freedesktop.org/maintainer-tools/repositories/drm-misc.html#merge-timeline
>
> Thanks,
> Christian.
>
> >
> > Alex
On Thu, Feb 05, 2026 at 02:19:45PM +0200, Leon Romanovsky wrote:
> You don't need any backmerge, SHA-1 version of vfio-v6.19-rc8 tag is the
> same as in Linus's tree, so the flow is:
I'm confused what is the problem here?
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@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.
Jason
On 2/5/26 15:21, Jason Gunthorpe wrote: > On Thu, Feb 05, 2026 at 02:19:45PM +0200, Leon Romanovsky wrote: >> You don't need any backmerge, SHA-1 version of vfio-v6.19-rc8 tag is the >> same as in Linus's tree, so the flow is: > > I'm confused what is the problem here? > > 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@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. Christian. > > Jason
On Thu, Feb 5, 2026, at 7:28 AM, Christian König wrote: > On 2/5/26 15:21, Jason Gunthorpe wrote: >> On Thu, Feb 05, 2026 at 02:19:45PM +0200, Leon Romanovsky wrote: >>> You don't need any backmerge, SHA-1 version of vfio-v6.19-rc8 tag is the >>> same as in Linus's tree, so the flow is: >> >> I'm confused what is the problem here? >> >> 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@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, Alex
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@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 Wed, Feb 04, 2026 at 05:21:45PM +0100, Christian König wrote:
> On 1/31/26 06:34, Leon Romanovsky wrote:
> > From: Leon Romanovsky <leonro@nvidia.com>
> >
> > Till now VFIO has rejected pinned importers, largely to avoid being used
> > with the RDMA pinned importer that cannot handle a move_notify() to revoke
> > access.
> >
> > Using dma_buf_attach_revocable() it can tell the difference between pinned
> > importers that support the flow described in dma_buf_invalidate_mappings()
> > and those that don't.
> >
> > Thus permit compatible pinned importers.
> >
> > This is one of two items IOMMUFD requires to remove its private interface
> > to VFIO's dma-buf.
> >
> > Reviewed-by: Kevin Tian <kevin.tian@intel.com>
> > Reviewed-by: Alex Williamson <alex@shazbot.org>
> > Reviewed-by: Christian König <christian.koenig@amd.com>
> > Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
> > ---
> > drivers/vfio/pci/vfio_pci_dmabuf.c | 15 +++------------
> > 1 file changed, 3 insertions(+), 12 deletions(-)
> >
> > diff --git a/drivers/vfio/pci/vfio_pci_dmabuf.c b/drivers/vfio/pci/vfio_pci_dmabuf.c
> > index 78d47e260f34..a5fb80e068ee 100644
> > --- a/drivers/vfio/pci/vfio_pci_dmabuf.c
> > +++ b/drivers/vfio/pci/vfio_pci_dmabuf.c
> > @@ -22,16 +22,6 @@ struct vfio_pci_dma_buf {
> > u8 revoked : 1;
> > };
> >
> > -static int vfio_pci_dma_buf_pin(struct dma_buf_attachment *attachment)
> > -{
> > - return -EOPNOTSUPP;
> > -}
> > -
> > -static void vfio_pci_dma_buf_unpin(struct dma_buf_attachment *attachment)
> > -{
> > - /* Do nothing */
> > -}
> > -
>
> 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.
Yes. It looks like Alex took it to his next tree:
commit 61ceaf236115f20f4fdd7cf60f883ada1063349a
Author: Leon Romanovsky <leon@kernel.org>
Date: Wed Jan 21 17:45:02 2026 +0200
vfio: Prevent from pinned DMABUF importers to attach to VFIO DMABUF
Some pinned importers, such as non-ODP RDMA ones, cannot invalidate their
mappings and therefore must be prevented from attaching to this exporter.
Fixes: 5d74781ebc86 ("vfio/pci: Add dma-buf export support for MMIO regions")
Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
Reviewed-by: Pranjal Shrivastava <praan@google.com>
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Link: https://lore.kernel.org/r/20260121-vfio-add-pin-v1-1-4e04916b17f1@nvidia.com
Signed-off-by: Alex Williamson <alex@shazbot.org>
The very best thing would be to pull
61ceaf236115f20f4fdd7cf60f883ada1063349a which is cleanly based on
v6.19-rc6 ?
> 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.
Or we get Alex to take a branch from you for the first 3 and push it?
Jason
© 2016 - 2026 Red Hat, Inc.