On Fri, May 03, 2024 at 02:24:45PM -0700, Linus Torvalds wrote:
Because even with perfectly normal "->poll()", and even with the ep_item_poll() happening *before* eventpoll_release_file(), you have this trivial race:
ep_item_poll() ->poll()
and *between* those two operations, another CPU does "close()", and that causes eventpoll_release_file() to be called, and now f_count goes down to zero while ->poll() is running.
So you do need to increment the file count around the ->poll() call, I feel.
Or, alternatively, you'd need to serialize with eventpoll_release_file(), but that would need to be some sleeping lock held over the ->poll() call.
As it is, dma_buf ->poll() is very suspicious regardless of that mess - it can grab reference to file for unspecified interval.
I think that's actually much preferable to what epoll does, which is to keep using files without having reference counts to them (and then relying on magically not racing with eventpoll_release_file().
eventpoll_release_file() calling __ep_remove() while ep_item_poll() is something we need to avoid anyway - having epi freed under ep_item_poll() would be a problem regardless of struct file lifetime issues.