On 15.01.2019 18:37, Miklos Szeredi wrote: > On Thu, Jan 10, 2019 at 12:03 PM Kirill Tkhai <[email protected]> wrote: >> >> On 10.01.2019 14:00, Miklos Szeredi wrote: >>> On Thu, Jan 10, 2019 at 11:48 AM Kirill Tkhai <[email protected]> wrote: >>>> >>>> Hi, Miklos, >>>> >>>> any comments about this? >>> >>> Is there a reproducer? ISTR that fsx-linux with mmaps enabled was >>> good for stressing the writeback_cache code. >> >> There is no a reproducer, since I found that by eyes during preparation of >> another patchset. > > That's good. It would even better to have a reproducer, but it > doesn't look easy... > > Completely redid this and reordered the patchset so this change is > made before the locking changes actually introduce the bug.
Hm, I meant that I found this during preparation of the patchset, but not that fi->lock patchset introduces the bug. I don't think the patchset is involved: 1)before we had race, because different locks fc->lock and fiq->waitq.lock are taken in fuse_dev_read() and fuse_writepage_in_flight(); 2)after we have the same race, and the locks are fi->lock and fiq->waitq.lock. >See fuse.git#for-next. The renewed patch looks correct for me. Thanks, Kirill
