[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAFQAk7j-Osw7jR6YxOL3OgcAiwmVq_bfV-ceqrD4JzyLEnBe7Q@mail.gmail.com>
Date: Mon, 7 Mar 2022 15:55:46 +0800
From: Jiachen Zhang <zhangjiachen.jaycee@...edance.com>
To: Miklos Szeredi <miklos@...redi.hu>
Cc: linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
Xie Yongji <xieyongji@...edance.com>
Subject: Re: [External] Re: [PATCH v2] fuse: fix deadlock between atomic
O_TRUNC open() and page invalidations
On Fri, Mar 4, 2022 at 11:30 PM Miklos Szeredi <miklos@...redi.hu> wrote:
>
> On Fri, 4 Mar 2022 at 07:23, Jiachen Zhang
> <zhangjiachen.jaycee@...edance.com> wrote:
>
> > I tested this fix, and it did pass the xfstests generic/464 in our
>
> Thanks for testing!
>
> > environment. However, if I understand correctly, one of the usages of
> > the nowrite is to protect file truncation, as said in the commit
> > message of e4648309b85a78f8c787457832269a8712a8673e. So, does that
> > mean this fix may introduce some other problems?
>
> That's an excellent question. I don't think this will cause an issue,
> since the nowrite protection is for truncation of the file on the
> server (userspace) side. The inode lock still protects concurrent
> writes against page cache truncation in the writeback cache case. In
> the non-writeback cache case the nowrite protection does not do
> anything.
Got it. So the nowrite is protecting O_TRUNC FUSE_OPEN (or truncating
FUSE_SETATTR) against FUSE_WRITE in writeback_cache mode? Then this
patch looks good to me.
Thanks,
Jiachen
>
> Thanks,
> Miklos
Powered by blists - more mailing lists