Hi all,
__filemap_get_folio and its wrappers can return NULL for three different
conditions, which in some cases requires the caller to reverse engineer
the decision making. This is fixed by returning an ERR_PTR instead of
NULL and thus transporting the reason for the failure. But to make
that work we first need to ensure that no xa_value special case is
returned and thus return the FGP_ENTRY flag. It turns out that flag
is barely used and can usually be deal with in a better way.
Note that the shmem patches in here are non-trivial and need some
careful review and testing.
Changes since v1:
- drop the patches to check for errors in btrfs and gfs2
- document the new calling conventions for the wrappers around
__filemap_get_folio
- rebased against the iomap changes in latest linux-next
Diffstat
fs/afs/dir.c | 10 +++----
fs/afs/dir_edit.c | 2 -
fs/afs/write.c | 4 +-
fs/btrfs/disk-io.c | 2 -
fs/ext4/inode.c | 2 -
fs/ext4/move_extent.c | 8 ++---
fs/hugetlbfs/inode.c | 2 -
fs/iomap/buffered-io.c | 15 +----------
fs/netfs/buffered_read.c | 4 +-
fs/nilfs2/page.c | 6 ++--
include/linux/pagemap.h | 15 +++++------
include/linux/shmem_fs.h | 1
mm/filemap.c | 27 ++++++++-----------
mm/folio-compat.c | 4 +-
mm/huge_memory.c | 5 +--
mm/memcontrol.c | 2 -
mm/mincore.c | 2 -
mm/shmem.c | 64 +++++++++++++++++++----------------------------
mm/swap_state.c | 17 ++++++------
mm/swapfile.c | 4 +-
mm/truncate.c | 15 +++++------
21 files changed, 94 insertions(+), 117 deletions(-)
On Sat, 21 Jan 2023 07:57:48 +0100 Christoph Hellwig <[email protected]> wrote:
> Hi all,
>
> __filemap_get_folio and its wrappers can return NULL for three different
> conditions, which in some cases requires the caller to reverse engineer
> the decision making. This is fixed by returning an ERR_PTR instead of
> NULL and thus transporting the reason for the failure. But to make
> that work we first need to ensure that no xa_value special case is
> returned and thus return the FGP_ENTRY flag. It turns out that flag
> is barely used and can usually be deal with in a better way.
>
> Note that the shmem patches in here are non-trivial and need some
> careful review and testing.
I'll hide for a while, awaiting that review. Plus...
> Changes since v1:
> - drop the patches to check for errors in btrfs and gfs2
> - document the new calling conventions for the wrappers around
> __filemap_get_folio
> - rebased against the iomap changes in latest linux-next
This patchset doesn't apply to fs/btrfs/ because linux-next contains
this 6+ month-old commit:
commit 964688b32d9ada55a7fce2e650d85ef24188f73f
Author: Matthew Wilcox (Oracle) <[email protected]>
AuthorDate: Tue May 17 18:03:27 2022 -0400
Commit: Matthew Wilcox (Oracle) <[email protected]>
CommitDate: Wed Jun 29 08:51:07 2022 -0400
btrfs: Use a folio in wait_dev_supers()
Matthew, what's the story here?
On Sat, Jan 21, 2023 at 05:06:41PM -0800, Andrew Morton wrote:
> This patchset doesn't apply to fs/btrfs/ because linux-next contains
> this 6+ month-old commit:
Hmm. It was literally written against linux-next as of last morning,
which does not have that commit.
On Sun, 22 Jan 2023 08:20:06 +0100 Christoph Hellwig <[email protected]> wrote:
> On Sat, Jan 21, 2023 at 05:06:41PM -0800, Andrew Morton wrote:
> > This patchset doesn't apply to fs/btrfs/ because linux-next contains
> > this 6+ month-old commit:
>
> Hmm. It was literally written against linux-next as of last morning,
> which does not have that commit.
Confused. According to
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/fs/btrfs/disk-io.c#n4023
it's there today. wait_dev_supers() has been foliofied.
On Mon, Jan 23, 2023 at 10:59:45AM -0800, Andrew Morton wrote:
> On Sun, 22 Jan 2023 08:20:06 +0100 Christoph Hellwig <[email protected]> wrote:
>
> > On Sat, Jan 21, 2023 at 05:06:41PM -0800, Andrew Morton wrote:
> > > This patchset doesn't apply to fs/btrfs/ because linux-next contains
> > > this 6+ month-old commit:
> >
> > Hmm. It was literally written against linux-next as of last morning,
> > which does not have that commit.
>
> Confused. According to
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/fs/btrfs/disk-io.c#n4023
>
> it's there today. wait_dev_supers() has been foliofied.
Yes, it's there now. But I'm pretty sure it wasn't there when
I did the last rebase. Weird.
On Sat, 21 Jan 2023 07:57:48 +0100 Christoph Hellwig <[email protected]> wrote:
> __filemap_get_folio and its wrappers can return NULL for three different
> conditions, which in some cases requires the caller to reverse engineer
> the decision making. This is fixed by returning an ERR_PTR instead of
> NULL and thus transporting the reason for the failure. But to make
> that work we first need to ensure that no xa_value special case is
> returned and thus return the FGP_ENTRY flag. It turns out that flag
> is barely used and can usually be deal with in a better way.
>
> Note that the shmem patches in here are non-trivial and need some
> careful review and testing.
How are we going with the review and testing. I assume that
we're now OK on the runtime testing front, but do you feel that
review has been adequate?
Thanks.
On Tue, Mar 28, 2023 at 04:04:33PM -0700, Andrew Morton wrote:
> > Note that the shmem patches in here are non-trivial and need some
> > careful review and testing.
>
> How are we going with the review and testing. I assume that
> we're now OK on the runtime testing front, but do you feel that
> review has been adequate?
Yes, I think we're fine, mostly due to Hugh. I'm a little sad about
the simplification / descoping from him, but at least we get the main
objective done. Maybe at some point we can do another pass at
cleaning up the shmem page finding/reading mess.