Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18;
MIME-Version: 1.0
References: <20211229040239.66075-1-zhangjiachen.jaycee@bytedance.com>
 <YhX1QlW87Hs/HS4h@miu.piliscsaba.redhat.com> <CAFQAk7gUCefe7WJhLD-oJdnjowqDVorpYv_u9_AqkceTvn9xNA@mail.gmail.com>
In-Reply-To: <CAFQAk7gUCefe7WJhLD-oJdnjowqDVorpYv_u9_AqkceTvn9xNA@mail.gmail.com>
From:   Miklos Szeredi <miklos@szeredi.hu>
Date:   Fri, 4 Mar 2022 16:30:35 +0100
Message-ID: <CAJfpegt=9D1wAdxbr82br-cCnikNTiEZ=9NfPo02LAbTPMNb2Q@mail.gmail.com>
Subject: Re: [External] Re: [PATCH v2] fuse: fix deadlock between atomic
 O_TRUNC open() and page invalidations
To:     Jiachen Zhang <zhangjiachen.jaycee@bytedance.com>
Cc:     linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
        Xie Yongji <xieyongji@bytedance.com>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Fri, 4 Mar 2022 at 07:23, Jiachen Zhang
<zhangjiachen.jaycee@bytedance.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.

Thanks,
Miklos