From: "Christian König" <christian.koenig@amd.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: Fedor Pchelkin <pchelkin@ispras.ru>,
Dmitry Antipov <dmantipov@yandex.ru>,
lvc-project@linuxtesting.org, dri-devel@lists.freedesktop.org,
"T.J. Mercier" <tjmercier@google.com>,
syzbot+5d4cb6b4409edfd18646@syzkaller.appspotmail.com,
linux-fsdevel@vger.kernel.org,
Zhiguo Jiang <justinjiang@vivo.com>,
Sumit Semwal <sumit.semwal@linaro.org>,
linux-media@vger.kernel.org
Subject: Re: [lvc-project] [PATCH] [RFC] dma-buf: fix race condition between poll and close
Date: Tue, 7 May 2024 17:02:04 +0200 [thread overview]
Message-ID: <fca9ea1e-8e42-43a1-b49d-4a5b929be30d@amd.com> (raw)
In-Reply-To: <ZjoFOwPt2vTP1X-x@phenom.ffwll.local>
Am 07.05.24 um 12:40 schrieb Daniel Vetter:
> On Tue, May 07, 2024 at 11:58:33AM +0200, Christian König wrote:
>> Am 06.05.24 um 08:52 schrieb Fedor Pchelkin:
>>> On Fri, 03. May 14:08, Dmitry Antipov wrote:
>>>> On 5/3/24 11:18 AM, Christian König wrote:
>>>>
>>>>> Attached is a compile only tested patch, please verify if it fixes your problem.
>>>> LGTM, and this is similar to get_file() in __pollwait() and fput() in
>>>> free_poll_entry() used in implementation of poll(). Please resubmit to
>>>> linux-fsdevel@ including the following:
>>>>
>>>> Reported-by: syzbot+5d4cb6b4409edfd18646@syzkaller.appspotmail.com
>>>> Closes: https://syzkaller.appspot.com/bug?extid=5d4cb6b4409edfd18646
>>>> Tested-by: Dmitry Antipov <dmantipov@yandex.ru>
>>> I guess the problem is addressed by commit 4efaa5acf0a1 ("epoll: be better
>>> about file lifetimes") which was pushed upstream just before v6.9-rc7.
>>>
>>> Link: https://lore.kernel.org/lkml/0000000000002d631f0615918f1e@google.com/
>> Yeah, Linus took care of that after convincing Al that this is really a bug.
>>
>> They key missing information was that we have a mutex which makes sure that
>> fput() blocks for epoll to stop the polling.
>>
>> It also means that you should probably re-consider using epoll together with
>> shared DMA-bufs. Background is that when both client and display server try
>> to use epoll the kernel will return an error because there can only be one
>> user of epoll.
> I think for dma-buf implicit sync the best is to use the new fence export
> ioctl, which has the added benefit that you get a snapshot and so no funny
> livelock issues if someone keeps submitting rendering to a shared buffer.
+1
>
> That aside, why can you not use the same file with multiple epoll files in
> different processes? Afaik from a quick look, all the tracking structures
> are per epoll file, so both client and compositor using it should work?
>
> I haven't tried, so I just might be extremely blind ...
I've misunderstood one of the comments in the discussion.
You can't add the same file with the same file descriptor number to the
same epoll file descriptor, but you can add it to different epoll file
descriptors.
So using epoll in both client and server should actually work.
Sorry for the noise,
Christian.
> -Sima
prev parent reply other threads:[~2024-05-07 15:02 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
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 [this message]
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=fca9ea1e-8e42-43a1-b49d-4a5b929be30d@amd.com \
--to=christian.koenig@amd.com \
--cc=daniel@ffwll.ch \
--cc=dmantipov@yandex.ru \
--cc=dri-devel@lists.freedesktop.org \
--cc=justinjiang@vivo.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=lvc-project@linuxtesting.org \
--cc=pchelkin@ispras.ru \
--cc=sumit.semwal@linaro.org \
--cc=syzbot+5d4cb6b4409edfd18646@syzkaller.appspotmail.com \
--cc=tjmercier@google.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).