Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
In-Reply-To: <26247.1511533324@warthog.procyon.org.uk>
References: <26247.1511533324@warthog.procyon.org.uk>
From:   Linus Torvalds <torvalds@linux-foundation.org>
Date:   Sat, 25 Nov 2017 08:05:18 -1000
Message-ID: <CA+55aFz2Cs+TizSRZF1hYaGak++ehs4Kyb4u__n=aOJh+G_=1w@mail.gmail.com>
Subject: Re: [GIT PULL] afs: Fixes
To:     David Howells <dhowells@redhat.com>
Cc:     linux-afs@vger.kernel.org,
        linux-fsdevel <linux-fsdevel@vger.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Fri, Nov 24, 2017 at 4:22 AM, David Howells <dhowells@redhat.com> wrote:
>
>  (2) Don't write to a page that's being written out, but wait for it to
>      complete.

So I see in the commit message why afs needs to do this, but it's
worth pointing out that it's

 (a) impossible to avoid the "inconsistent data" case for writable mmap'ed pages

 (b) can cause some really nasty latency issues

So the "page->private" issue does mean that write-vs-writeback clearly
needs that serialization (and that's not an issue for the mapped page
being changed at the same time), but in general filesystem people
should be aware that data under writeback may still be further dirtied
while the writeback is active (and the page marked dirty again). It
can obviously screw with things like checksums etc, and make for
temporarily inconsistent state if the filesystem does those kinds of
things.

            Linus

From 1584957627109406089@xxx Fri Nov 24 14:23:01 +0000 2017
X-GM-THRID: 1584957627109406089
X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread