On Mon, Feb 24, 2025 at 11:37:00AM -0300, Raphael S. Carvalho wrote: > original report: > https://lore.kernel.org/all/CAKhLTr1UL3ePTpYjXOx2AJfNk8Ku2EdcEfu+CH1sf3Asr=B-Dw@xxxxxxxxxxxxxx/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). .... > > diff --git a/mm/filemap.c b/mm/filemap.c > index 804d7365680c..3e75dced0fd9 100644 > --- a/mm/filemap.c > +++ b/mm/filemap.c > @@ -1986,8 +1986,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. Looks good to me. Reviewed-by: Dave Chinner <dchinner@xxxxxxxxxx> -- Dave Chinner david@xxxxxxxxxxxxx
