[PATCH] [RFC] dma-buf: fix race condition between poll and close

Dmitry Antipov dmantipov at yandex.ru
Fri May 3 07:07:11 UTC 2024


On 4/24/24 2:28 PM, Christian König wrote:

> I don't fully understand how that happens either, it could be that there is some bug in the EPOLL_FD code. Maybe it's a race when the EPOLL file descriptor is closed or something like that.

IIUC the race condition looks like the following:

Thread 0                        Thread 1
-> do_epoll_ctl()
    f_count++, now 2
    ...
    ...                          -> vfs_poll(), f_count == 2
    ...                          ...
<- do_epoll_ctl()               ...
    f_count--, now 1             ...
-> filp_close(), f_count == 1   ...
    ...                            -> dma_buf_poll(), f_count == 1
    -> fput()                      ... [*** race window ***]
       f_count--, now 0              -> maybe get_file(), now ???
       -> __fput() (delayed)

E.g. dma_buf_poll() may be entered in thread 1 with f->count == 1
and call to get_file() shortly later (and may even skip this if
there is nothing to EPOLLIN or EPOLLOUT). During this time window,
thread 0 may call fput() (on behalf of close() in this example)
and (since it sees f->count == 1) file is scheduled to delayed_fput().

Dmitry


More information about the dri-devel mailing list