From: Jason Gunthorpe <jgg@nvidia.com>
To: "Christian König" <christian.koenig@amd.com>
Cc: Alex Williamson <alex.williamson@redhat.com>,
Cornelia Huck <cohuck@redhat.com>,
dri-devel@lists.freedesktop.org, kvm@vger.kernel.org,
linaro-mm-sig@lists.linaro.org, linux-media@vger.kernel.org,
Sumit Semwal <sumit.semwal@linaro.org>,
Daniel Vetter <daniel.vetter@ffwll.ch>,
Leon Romanovsky <leon@kernel.org>,
linux-rdma@vger.kernel.org, Maor Gottlieb <maorg@nvidia.com>,
Oded Gabbay <ogabbay@kernel.org>
Subject: Re: [PATCH 0/4] Allow MMIO regions to be exported through dma-buf
Date: Fri, 19 Aug 2022 10:39:11 -0300 [thread overview]
Message-ID: <Yv+SfymnK9RF0qTA@nvidia.com> (raw)
In-Reply-To: <a29de43e-2dec-fd27-2e24-31af1d3ce470@amd.com>
On Fri, Aug 19, 2022 at 03:33:04PM +0200, Christian König wrote:
> > > > So we could delete the try_buf and just rely on move being safe on
> > > > partially destroyed dma_buf's as part of the API design.
> > > I think that might be the more defensive approach. A comment on the
> > > dma_buf_move_notify() function should probably be a good idea.
> > IMHO, it is an anti-pattern. The caller should hold a strong reference
> > on an object before invoking any API surface. Upgrading a weak
> > reference to a strong reference requires the standard "try get" API.
> >
> > But if you feel strongly I don't mind dropping the try_get around move.
>
> Well I see it as well that both approaches are not ideal, but my gut feeling
> tells me that just documenting that dma_buf_move_notify() can still be
> called as long as the release callback wasn't called yet is probably the
> better approach.
The comment would say something like:
"dma_resv_lock(), dma_buf_move_notify(), dma_resv_unlock() may be
called with a 0 refcount so long as ops->release() hasn't returned"
Which is a really abnormal API design, IMHO.
Jason
WARNING: multiple messages have this Message-ID (diff)
From: Jason Gunthorpe <jgg@nvidia.com>
To: "Christian König" <christian.koenig@amd.com>
Cc: Leon Romanovsky <leon@kernel.org>,
kvm@vger.kernel.org, linux-rdma@vger.kernel.org,
Daniel Vetter <daniel.vetter@ffwll.ch>,
Oded Gabbay <ogabbay@kernel.org>,
Cornelia Huck <cohuck@redhat.com>,
dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org,
Alex Williamson <alex.williamson@redhat.com>,
Maor Gottlieb <maorg@nvidia.com>,
Sumit Semwal <sumit.semwal@linaro.org>,
linux-media@vger.kernel.org
Subject: Re: [PATCH 0/4] Allow MMIO regions to be exported through dma-buf
Date: Fri, 19 Aug 2022 10:39:11 -0300 [thread overview]
Message-ID: <Yv+SfymnK9RF0qTA@nvidia.com> (raw)
In-Reply-To: <a29de43e-2dec-fd27-2e24-31af1d3ce470@amd.com>
On Fri, Aug 19, 2022 at 03:33:04PM +0200, Christian König wrote:
> > > > So we could delete the try_buf and just rely on move being safe on
> > > > partially destroyed dma_buf's as part of the API design.
> > > I think that might be the more defensive approach. A comment on the
> > > dma_buf_move_notify() function should probably be a good idea.
> > IMHO, it is an anti-pattern. The caller should hold a strong reference
> > on an object before invoking any API surface. Upgrading a weak
> > reference to a strong reference requires the standard "try get" API.
> >
> > But if you feel strongly I don't mind dropping the try_get around move.
>
> Well I see it as well that both approaches are not ideal, but my gut feeling
> tells me that just documenting that dma_buf_move_notify() can still be
> called as long as the release callback wasn't called yet is probably the
> better approach.
The comment would say something like:
"dma_resv_lock(), dma_buf_move_notify(), dma_resv_unlock() may be
called with a 0 refcount so long as ops->release() hasn't returned"
Which is a really abnormal API design, IMHO.
Jason
next prev parent reply other threads:[~2022-08-19 13:39 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-17 16:11 [PATCH 0/4] Allow MMIO regions to be exported through dma-buf Jason Gunthorpe
2022-08-17 16:11 ` Jason Gunthorpe
2022-08-17 16:11 ` [PATCH 1/4] dma-buf: Add dma_buf_try_get() Jason Gunthorpe
2022-08-17 16:11 ` Jason Gunthorpe
2022-08-17 16:11 ` [PATCH 2/4] vfio: Add vfio_device_get() Jason Gunthorpe
2022-08-17 16:11 ` Jason Gunthorpe
2022-08-17 16:11 ` [PATCH 3/4] vfio_pci: Do not open code pci_try_reset_function() Jason Gunthorpe
2022-08-17 16:11 ` Jason Gunthorpe
2022-08-17 16:11 ` [PATCH 4/4] vfio/pci: Allow MMIO regions to be exported through dma-buf Jason Gunthorpe
2022-08-17 16:11 ` Jason Gunthorpe
2022-08-21 13:51 ` Fwd: " Oded Gabbay
2022-08-21 13:51 ` Oded Gabbay
2022-08-26 18:10 ` Jason Gunthorpe
2022-08-26 18:10 ` Jason Gunthorpe
2022-08-29 5:04 ` Yan Zhao
2022-08-29 5:04 ` Yan Zhao
2022-08-29 12:26 ` Jason Gunthorpe
2022-08-29 12:26 ` Jason Gunthorpe
2022-08-18 11:07 ` [PATCH 0/4] " Christian König
2022-08-18 11:07 ` Christian König
2022-08-18 12:03 ` Jason Gunthorpe
2022-08-18 12:03 ` Jason Gunthorpe
2022-08-18 12:58 ` Christian König
2022-08-18 12:58 ` Christian König
2022-08-18 13:16 ` Jason Gunthorpe
2022-08-18 13:16 ` Jason Gunthorpe
2022-08-18 13:37 ` Christian König
2022-08-18 13:37 ` Christian König
2022-08-19 13:11 ` Jason Gunthorpe
2022-08-19 13:11 ` Jason Gunthorpe
2022-08-19 13:33 ` Christian König
2022-08-19 13:33 ` Christian König
2022-08-19 13:39 ` Jason Gunthorpe [this message]
2022-08-19 13:39 ` Jason Gunthorpe
2022-08-19 13:47 ` Christian König
2022-08-19 13:47 ` Christian König
2022-08-18 12:05 ` Jason Gunthorpe
2022-08-18 12:05 ` Jason Gunthorpe
2022-08-22 21:58 ` Alex Williamson
2022-08-22 21:58 ` Alex Williamson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Yv+SfymnK9RF0qTA@nvidia.com \
--to=jgg@nvidia.com \
--cc=alex.williamson@redhat.com \
--cc=christian.koenig@amd.com \
--cc=cohuck@redhat.com \
--cc=daniel.vetter@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=kvm@vger.kernel.org \
--cc=leon@kernel.org \
--cc=linaro-mm-sig@lists.linaro.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=maorg@nvidia.com \
--cc=ogabbay@kernel.org \
--cc=sumit.semwal@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.