On 15.01.2019 19:03, Miklos Szeredi wrote: > 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. Yeah, and there was another performer, not me :)
