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@xxxxxxxxxxxxxxxxxxxxxxxxx > > > Closes: https://syzkaller.appspot.com/bug?extid=5d4cb6b4409edfd18646 > > > Tested-by: Dmitry Antipov <dmantipov@xxxxxxxxx> > > 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@xxxxxxxxxx/ > > 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. 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 ... -Sima -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
