From: "Christian König" <christian.koenig@amd.com> To: Jason Gunthorpe <jgg@nvidia.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 15:47:20 +0200 [thread overview] Message-ID: <77d47856-4b01-cfb6-bdd6-ccb3f68014d9@amd.com> (raw) In-Reply-To: <Yv+SfymnK9RF0qTA@nvidia.com> Am 19.08.22 um 15:39 schrieb Jason Gunthorpe: > 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. Mhm, Daniel or other do you have any opinion on that as well? Thanks, Christian. > > Jason
WARNING: multiple messages have this Message-ID (diff)
From: "Christian König" <christian.koenig@amd.com> To: Jason Gunthorpe <jgg@nvidia.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 15:47:20 +0200 [thread overview] Message-ID: <77d47856-4b01-cfb6-bdd6-ccb3f68014d9@amd.com> (raw) In-Reply-To: <Yv+SfymnK9RF0qTA@nvidia.com> Am 19.08.22 um 15:39 schrieb Jason Gunthorpe: > 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. Mhm, Daniel or other do you have any opinion on that as well? Thanks, Christian. > > Jason
next prev parent reply other threads:[~2022-08-19 13:47 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 2022-08-19 13:39 ` Jason Gunthorpe 2022-08-19 13:47 ` Christian König [this message] 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=77d47856-4b01-cfb6-bdd6-ccb3f68014d9@amd.com \ --to=christian.koenig@amd.com \ --cc=alex.williamson@redhat.com \ --cc=cohuck@redhat.com \ --cc=daniel.vetter@ffwll.ch \ --cc=dri-devel@lists.freedesktop.org \ --cc=jgg@nvidia.com \ --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: linkBe 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.