On 2018/06/07 12:29, Ming Lei wrote: >> The vfs_fsync() isn't necessary in loop_update_dio() since both >> generic_file_write_iter() and generic_file_read_iter() can handle >> buffered io vs dio well. >> >> I will send one patch to remove the vfs_sync() later. > > Hi Tetsuo, > > The issue might be fixed by removing this vfs_sync(), but I'd like to > understand the idea behind since vfs_sync() shouldn't have caused > any IO to this loop queue. > > I also tried to do the test via the following c syzbot, but can't reproduce > it yet after running it for several hours. > > https://syzkaller.appspot.com/x/repro.c?id=4727023951937536 > > Could you share us how you reproduce it? I just reported that syzbot started hitting vfs_sync() case. I haven't succeeded reproducing vfs_sync() case in my environment. But in general, I modify "any reproducer provided by syzbot that loops forever" to call exit() if open() etc. failed, for continuing the loop unlikely helps after hitting "Too many open files" error. res = syscall(__NR_memfd_create, 0x200002c0, 0); if (res != -1) r[1] = res; + else + exit(1); Thus, I restart the reproducer in a loop from shell rather than keep running for hours. while :; do echo -n .; ./a.out; done
