On Tue, Jan 15, 2019 at 4:55 PM Kirill Tkhai <ktkhai@xxxxxxxxxxxxx> wrote: > > On 15.01.2019 18:37, Miklos Szeredi wrote: > > On Thu, Jan 10, 2019 at 12:03 PM Kirill Tkhai <ktkhai@xxxxxxxxxxxxx> wrote: > >> > >> On 10.01.2019 14:00, Miklos Szeredi wrote: > >>> On Thu, Jan 10, 2019 at 11:48 AM Kirill Tkhai <ktkhai@xxxxxxxxxxxxx> 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. Ah, so the race was introduced earlier, when fiq->waitq.lock was split out from fc->lock. Thanks, Miklos
