mm: fix error handling in __filemap_get_folio() with FGP_NOWAIT

JIRA: https://issues.redhat.com/browse/RHEL-84184

This patch is a backport of the following upstream commit:
commit 182db97
Author: Raphael S. Carvalho <[email protected]>
Date:   Mon Feb 24 11:37:00 2025 -0300

    mm: fix error handling in __filemap_get_folio() with FGP_NOWAIT

    original report:
    https://lore.kernel.org/all/CAKhLTr1UL3ePTpYjXOx2AJfNk8Ku2EdcEfu+CH1sf3Asr=B-Dw@mail.gmail.com/T/

    When doing buffered writes with FGP_NOWAIT, under memory pressure, the
    system returned ENOMEM despite there being plenty of available memory, to
    be reclaimed from page cache.  The user space used io_uring interface,
    which in turn submits I/O with FGP_NOWAIT (the fast path).

    retsnoop pointed to iomap_get_folio:

    00:34:16.180612 -> 00:34:16.180651 TID/PID 253786/253721
    (reactor-1/combined_tests):

                        entry_SYSCALL_64_after_hwframe+0x76
                        do_syscall_64+0x82
                        __do_sys_io_uring_enter+0x265
                        io_submit_sqes+0x209
                        io_issue_sqe+0x5b
                        io_write+0xdd
                        xfs_file_buffered_write+0x84
                        iomap_file_buffered_write+0x1a6
        32us [-ENOMEM]  iomap_write_begin+0x408
    iter=&{.inode=0xffff8c67aa031138,.len=4096,.flags=33,.iomap={.addr=0xffffffffffffffff,.length=4096,.type=1,.flags=3,.bdev=0x…
    pos=0 len=4096 foliop=0xffffb32c296b7b80
    !    4us [-ENOMEM]  iomap_get_folio
    iter=&{.inode=0xffff8c67aa031138,.len=4096,.flags=33,.iomap={.addr=0xffffffffffffffff,.length=4096,.type=1,.flags=3,.bdev=0x…
    pos=0 len=4096

    This is likely a regression caused by 66dabbb ("mm: return an ERR_PTR
    from __filemap_get_folio"), which moved error handling from
    io_map_get_folio() to __filemap_get_folio(), but broke FGP_NOWAIT
    handling, so ENOMEM is being escaped to user space.  Had it correctly
    returned -EAGAIN with NOWAIT, either io_uring or user space itself would
    be able to retry the request.

    It's not enough to patch io_uring since the iomap interface is the one
    responsible for it, and pwritev2(RWF_NOWAIT) and AIO interfaces must
    return the proper error too.

    The patch was tested with scylladb test suite (its original reproducer),
    and the tests all pass now when memory is pressured.

    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: 66dabbb ("mm: return an ERR_PTR from __filemap_get_folio")
    Signed-off-by: Raphael S. Carvalho <[email protected]>
    Reviewed-by: Christoph Hellwig <[email protected]>
    Reviewed-by: Dave Chinner <[email protected]>
    Cc: "Darrick J. Wong" <[email protected]>
    Cc: Matthew Wilcow (Oracle) <[email protected]>
    Cc: <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>

Signed-off-by: Rafael Aquini <[email protected]>

Author: Rafael Aquini

mm/filemap.c

@@ -1927,8 +1927,19 @@ struct folio *__filemap_get_folio(struct address_space *mapping, pgoff_t index,
 
 		if (err == -EEXIST)
 			goto repeat;
-		if (err)
+		if (err) {
+			/*
+			 * When NOWAIT I/O fails to allocate folios this could
+			 * be due to a nonblocking memory allocation and not
+			 * because the system actually is out of memory.
+			 * Return -EAGAIN so that there caller retries in a
+			 * blocking fashion instead of propagating -ENOMEM
+			 * to the application.
+			 */
+			if ((fgp_flags & FGP_NOWAIT) && err == -ENOMEM)
+				err = -EAGAIN;
 			return ERR_PTR(err);
+		}
 		/*
 		 * filemap_add_folio locks the page, and for mmap
 		 * we expect an unlocked page.