On Sun, Feb 08, 2026 at 12:35:43PM +0200, Mike Rapoport wrote:
> > > +static void shmem_mfill_filemap_remove(struct folio *folio,
> > > + struct vm_area_struct *vma)
> > > +{
> > > + struct inode *inode = file_inode(vma->vm_file);
> > > +
> > > + filemap_remove_folio(folio);
> > > + shmem_recalc_inode(inode, 0, 0);
> > > folio_unlock(folio);
> > > - folio_put(folio);
> > > -out_unacct_blocks:
> > > - shmem_inode_unacct_blocks(inode, 1);
> >
> > This looks wrong, or maybe I miss somewhere we did the unacct_blocks()?
>
> This is handled by shmem_recalc_inode(inode, 0, 0).
IIUC shmem_recalc_inode() only does the fixup of shmem_inode_info over
possiblly changing inode->i_mapping->nrpages. It's not for reverting the
accounting in the failure paths here.
OTOH, we still need to maintain accounting for the rest things with
correctly invoke shmem_inode_unacct_blocks(). One thing we can try is
testing this series against either shmem quota support (since 2023, IIUC
it's relevant to "quota" mount option), or max_blocks accountings (IIUC,
"size" mount option), etc. Any of those should reflect a difference if my
understanding is correct.
So IIUC we still need the unacct_blocks(), please kindly help double check.
Thanks,
--
Peter Xu
