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.
