[lvc-project] [PATCH] [RFC] dma-buf: fix race condition between poll and close
Christian König
christian.koenig at amd.com
Wed Apr 24 14:28:05 MSK 2024
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
>
More information about the lvc-project
mailing list