From: "Christian König" <christian.koenig@amd.com>
To: Dmitry Antipov <dmantipov@yandex.ru>,
Sumit Semwal <sumit.semwal@linaro.org>
Cc: linux-media@vger.kernel.org, dri-devel@lists.freedesktop.org,
lvc-project@linuxtesting.org,
syzbot+5d4cb6b4409edfd18646@syzkaller.appspotmail.com
Subject: Re: [PATCH] [RFC] dma-buf: fix race condition between poll and close
Date: Wed, 24 Apr 2024 13:28:05 +0200 [thread overview]
Message-ID: <72f5f1b8-ca5b-4207-9ac9-95b60c607f3a@amd.com> (raw)
In-Reply-To: <3a7d0f38-13b9-4e98-a5fa-9a0d775bcf81@yandex.ru>
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
>
next prev parent reply other threads:[~2024-04-24 11:28 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-23 19:13 [PATCH] [RFC] dma-buf: fix race condition between poll and close Dmitry Antipov
2024-04-24 7:09 ` Christian König
2024-04-24 10:19 ` Dmitry Antipov
2024-04-24 11:28 ` Christian König [this message]
2024-05-03 7:07 ` Dmitry Antipov
2024-05-03 8:18 ` Christian König
2024-05-03 11:08 ` Dmitry Antipov
2024-05-06 6:52 ` [lvc-project] " Fedor Pchelkin
2024-05-07 9:58 ` Christian König
2024-05-07 10:40 ` Daniel Vetter
2024-05-07 15:02 ` Christian König
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=72f5f1b8-ca5b-4207-9ac9-95b60c607f3a@amd.com \
--to=christian.koenig@amd.com \
--cc=dmantipov@yandex.ru \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-media@vger.kernel.org \
--cc=lvc-project@linuxtesting.org \
--cc=sumit.semwal@linaro.org \
--cc=syzbot+5d4cb6b4409edfd18646@syzkaller.appspotmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).