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

[Christian König]

Am 24.04.24 um 12:19 schrieb Dmitry Antipov:
> On 4/24/24 10:09, Christian König wrote:
>
>> To repeat what I already said on the other thread: Calling 
>> dma_buf_poll() while fput() is in progress is illegal in the first 
>> place.
>>
>> So there is nothing to fix in dma_buf_poll(), but rather to figure 
>> out who is incorrectly calling fput().
>
> Hm. OTOH it's legal if userspace app calls close([fd]) in one thread 
> when another
> thread sleeps in (e)poll({..., [fd], ...}) (IIUC this is close to what 
> the syzbot
> reproducer actually does). What behavior should be considered as valid 
> in this
> (yes, really weird) scenario?

That scenario is actually not weird at all, but just perfectly normal.

As far as I read up on it the EPOLL_FD implementation grabs a reference 
to the underlying file of added file descriptors.

So you can actually close the added file descriptor directly after the 
operation completes, that is perfectly valid behavior.

It's just that somehow the reference which is necessary to call 
dma_buf_poll() is dropped to early.

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.

Regards,
Christian.

>
> Dmitry
>