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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux