[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wh4SKRxKQf5LawRMSijtjRVQevaFioBK+tOZAVPt7ek0Q@mail.gmail.com>
Date: Wed, 30 Oct 2019 11:54:35 +0100
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Steven Whitehouse <swhiteho@...hat.com>
Cc: Konstantin Khlebnikov <khlebnikov@...dex-team.ru>,
"Kirill A. Shutemov" <kirill@...temov.name>,
Linux-MM <linux-mm@...ck.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
linux-fsdevel <linux-fsdevel@...r.kernel.org>,
Alexander Viro <viro@...iv.linux.org.uk>,
Johannes Weiner <hannes@...xchg.org>,
"cluster-devel@...hat.com" <cluster-devel@...hat.com>
Subject: Re: [PATCH] mm/filemap: do not allocate cache pages beyond end of
file at read
On Wed, Oct 30, 2019 at 11:35 AM Steven Whitehouse <swhiteho@...hat.com> wrote:
>
> NFS may be ok here, but it will break GFS2. There may be others too...
> OCFS2 is likely one. Not sure about CIFS either. Does it really matter
> that we might occasionally allocate a page and then free it again?
Why are gfs2 and cifs doing things wrong?
"readpage()" is not for synchrionizing metadata. Never has been. You
shouldn't treat it that way, and you shouldn't then make excuses for
filesystems that treat it that way.
Look at mmap, for example. It will do the SIGBUS handling before
calling readpage(). Same goes for the copyfile code. A filesystem that
thinks "I will update size at readpage" is already fundamentally
buggy.
We do _recheck_ the inode size under the page lock, but that's to
handle the races with truncate etc.
Linus
Powered by blists - more mailing lists