From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Hellstrom Subject: RFC: get_dma_buf_unless_zero ? Date: Wed, 06 Nov 2013 20:59:03 +0100 Message-ID: <527A9F87.2070400@vmware.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: Received: from smtp-outbound-1.vmware.com (smtp-outbound-1.vmware.com [208.91.2.12]) by gabe.freedesktop.org (Postfix) with ESMTP id AF860EE2F6 for ; Wed, 6 Nov 2013 11:59:06 -0800 (PST) List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dri-devel-bounces@lists.freedesktop.org Errors-To: dri-devel-bounces@lists.freedesktop.org To: "dri-devel@lists.freedesktop.org" , "linaro-mm-sig@lists.linaro.org" , "linux-kernel@vger.kernel.org" List-Id: dri-devel@lists.freedesktop.org Anyone else but me that feels such a function could be useful? My main use-case is that it would resolve the mutual refcounting problem: 1) drm buffer object caches a dma_buf pointer which it refcounts 2) The dma-buf holds a refcount to the buffer. This is resolved today by having the user-space visible part of the drm-buffer holding the refcount to the dma_buf. When user-space closes the drm-buffer, the reference goes away, and eventually the buffer is freed, when all external dma-buf users are done with the dma-buf However, this also means that the dma-buf remains for the buffer lifetime even when there are no external users, which bugs me a bit. This can be resolved by viewing the drm buffer as a lookup structure that doesn't hold a refcount to the dma-buf, but that means that the lookup structure (buffer) would need to share locks with the dma-buf implementation, unless we have a get_dma_buf_unless_zero, which means we can use locks local to the lookup structure, the drm buffer. (See the last part of the kref documentation for a detailed discussion of this). Now I don't think keeping the dma_buf for the drm buffer lifetime is a HUGE problem, but I just wanted to get people's views of this. Thanks, Thomas