All of lore.kernel.org
 help / color / mirror / Atom feed
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Thomas Hellstrom <thellstrom@vmware.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH RFC RESEND] dma-buf/fs Add get_[file|dma_buf]_unless_doomed
Date: Mon, 11 Nov 2013 15:17:04 +0000	[thread overview]
Message-ID: <20131111151704.GX13318@ZenIV.linux.org.uk> (raw)
In-Reply-To: <1384160267-3389-1-git-send-email-thellstrom@vmware.com>

On Mon, Nov 11, 2013 at 12:57:47AM -0800, Thomas Hellstrom wrote:
> Resending since it appears this RFC never got to the dri-devel lkml lists.
> 
> In this context, a "doomed" object is an object whose refcount has reached
> zero, but that has not yet been freed.
> 
> To avoid mutual refcounting vmwgfx need to have a non-refcounted pointer to
> a dma-buf in a lookup structure. The pointer is removed in the dma-buf
> destructor. To allow lookup-structure private locks we need
> get_dma_buf_unless_doomed(). This common refcounting scenario is described
> with examples in detail in the kref documentaion.
> The solution with local locks is under kref_get_unless_zero().
> See also kobject_get_unless_zero() and its commit message.
> Since dma-bufs are using the attached file for refcounting,
> get_dma_buf_unless_doomed maps directly to a get_file_unless_doomed.

NAK for struct file.  This kind of stuff is for implementing primitives,
not as a public API.  BTW, as for dmabuf...  dma_buf_fd() calling conventions
are seriously misguided - we are trying to transfer the reference we hold
into something (in this case - descriptor table), so the failure exit
should be dropping the reference, not leaving that to caller.

  reply	other threads:[~2013-11-11 15:17 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-11  8:57 [PATCH RFC RESEND] dma-buf/fs Add get_[file|dma_buf]_unless_doomed Thomas Hellstrom
2013-11-11 15:17 ` Al Viro [this message]
2013-11-11 16:15   ` Thomas Hellstrom
  -- strict thread matches above, loose matches on Subject: below --
2013-11-11  8:46 Thomas Hellstrom

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=20131111151704.GX13318@ZenIV.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=thellstrom@vmware.com \
    /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.