Re: [PATCH v4 13/14] filemap: Add support for authoritative mappings

[Matthew Wilcox <willy@infradead.org>]

On Fri, Jul 24, 2026 at 05:15:03PM +0100, Matthew Wilcox wrote:
> Sashiko review identifies only a problem identified in the previous patch.
Er, this should have been the reply to patch 12, not 13.

Sashiko review:
> --- Patch [13]: [PATCH v4 13/14] filemap: Add support for authoritative mappings ---
> commit f97ea9a8250c2693263cf2f409975e439e79ddd4
> Author: Matthew Wilcox (Oracle) <willy@infradead.org>
> 
> filemap: Add support for authoritative mappings
> 
> An authoritative mapping knows about all the folios in the mapping.
> If read() finds a missing folio, we know it's a zero region of the file
> and can call iov_iter_zero() instead of allocating and trying to read one.
> 
> > diff --git a/mm/filemap.c b/mm/filemap.c
> > index 26a5f18121f90..5a8cc20e624e4 100644
> > --- a/mm/filemap.c
> > +++ b/mm/filemap.c
> > @@ -2697,6 +2697,8 @@ static int filemap_get_pages(struct kiocb *iocb, size_t count,
> >  	if (!folio_batch_count(fbatch)) {
> >  		DEFINE_READAHEAD(ractl, filp, &filp->f_ra, mapping, index);
> >
> > +		if (mapping_is_authoritative(mapping))
> > +			return 0;
> >  		if (iocb->ki_flags & IOCB_NOIO)
> >  			return -EAGAIN;
> 
> Does this early return cause an infinite loop in filemap_splice_read()
> when reading a hole?
> 
> When an AS_AUTHORITATIVE mapping has a hole, filemap_get_pages() now
> returns 0 and leaves fbatch empty. filemap_read() was updated in this patch
> to handle an empty batch, but filemap_splice_read() appears to assume that
> a return value of 0 means progress was made.
> 
> If filemap_splice_read() receives an empty fbatch:
> 
> mm/filemap.c:filemap_splice_read() {
>         ...
>         error = filemap_get_pages(&iocb, len, &fbatch, true);
>         if (error < 0)
>                 break;
> 
>         ...
>         for (i = 0; i < folio_batch_count(&fbatch); i++) {
>                 struct folio *folio = fbatch.folios[i];
>                 // updates to *ppos and len
>         }
> 
>         folio_batch_release(&fbatch);
>     } while (len);
> 
> Since the for loop is skipped, len and *ppos remain unchanged, which
> could cause the outer do-while loop to spin indefinitely.

This is a latent footgun, I guess.  When we come to it, we can move the
code from shmem_file_splice_read() here.