On Sat, May 04, 2024 at 12:03:18AM +0100, Al Viro wrote: > On Fri, May 03, 2024 at 03:46:25PM -0700, Kees Cook wrote: > > On Fri, May 03, 2024 at 02:52:38PM -0700, Linus Torvalds wrote: > > > That means that the file will be released - and it means that you have > > > violated all the refcounting rules for poll(). > > > > I feel like I've been looking at this too long. I think I see another > > problem here, but with dmabuf even when epoll is fixed: > > > > dma_buf_poll() > > get_file(dmabuf->file) /* f_count + 1 */ > > dma_buf_poll_add_cb() > > dma_resv_for_each_fence ... > > dma_fence_add_callback(fence, ..., dma_buf_poll_cb) > > > > dma_buf_poll_cb() > > ... > > fput(dmabuf->file); /* f_count - 1 ... for each fence */ > > > > Isn't it possible to call dma_buf_poll_cb() (and therefore fput()) > > multiple times if there is more than 1 fence? Perhaps I've missed a > > place where a single struct dma_resv will only ever signal 1 fence? But > > looking through dma_fence_signal_timestamp_locked(), I don't see > > anything about resv nor somehow looking into other fence cb_list > > contents... > > At a guess, > r = dma_fence_add_callback(fence, &dcb->cb, dma_buf_poll_cb); > if (!r) > return true; > > prevents that - it returns 0 on success and -E... on error; > insertion into the list happens only when it's returning 0, > so... Yes; thank you. I *have* been looking at it all too long. :) The last related thing is the drivers/gpu/drm/vmwgfx/ttm_object.c case: /** * get_dma_buf_unless_doomed - get a dma_buf reference if possible. * * @dmabuf: Non-refcounted pointer to a struct dma-buf. * * Obtain a file reference from a lookup structure that doesn't refcount * the file, but synchronizes with its release method to make sure it * has * not been freed yet. See for example kref_get_unless_zero * documentation. * Returns true if refcounting succeeds, false otherwise. * * Nobody really wants this as a public API yet, so let it mature here * for some time... */ static bool __must_check get_dma_buf_unless_doomed(struct dma_buf *dmabuf) { return atomic_long_inc_not_zero(&dmabuf->file->f_count) != 0L; } If we end up adding epi_fget(), we'll have 2 cases of using "atomic_long_inc_not_zero" for f_count. Do we need some kind of blessed helper to live in file.h or something, with appropriate comments? -- Kees Cook