Re: [PATCH v2 1/1] iomap: fix readahead folio refcounting race

["Darrick J. Wong" <djwong@kernel.org>]

On Fri, Jan 16, 2026 at 02:02:20PM -0800, Joanne Koong wrote:
> On Fri, Jan 16, 2026 at 1:45 PM Matthew Wilcox <willy@infradead.org> wrote:
> >
> > On Fri, Jan 16, 2026 at 10:36:25AM -0800, Joanne Koong wrote:
> > > On Thu, Jan 15, 2026 at 6:52 PM Matthew Wilcox <willy@infradead.org> wrote:
> > > >
> > > > > +                     if (!ifs) {
> > > > > +                             ctx->cur_folio = NULL;
> > > > > +                             if (unlikely(plen != folio_len))
> > > > > +                                 return -EIO;
> > > >
> > > > This should be indented with a tab, not four spaces.  Can it even
> > > > happen?  If we didn't attach an ifs, can we do a short read?
> > >
> > > The short read can happen if the filesystem sets the iomap length to a
> > > size that's less than the folio size. plen is determined by
> > > iomap_length() (which returns the minimum of the iter->len and the
> > > iomap length value the filesystem set).
> >
> > Understood, but if plen is less than folio_size(), don't we allocate
> > an ifs?  So !ifs && plen < folio_size() shouldn't be possible?  Or have
> > I misunderstood this part?
> 
> Maybe I'm misunderstanding this, but I'm pretty sure the ifs is only
> allocated if the inode's block size is less than the folio size, and
> is not based on plen. The logic I'm looking at is the code inside
> ifs_alloc().

Hrmm.  If there's no ifs then blocksize == foliosize, so if
plen < foliosize then that means we're not fully reading in the folio
contents?  That doesn't sound good, especially if the folio can be
mmapped into someone's address space.

--D

> Thanks,
> Joanne
>