Re: Function to do end-writeback in bulk

On Mon, Aug 24, 2026 at 04:47:08PM +0100, David Howells wrote:
> Matthew Wilcox <[email protected]> wrote:
> 
> > I hate this API.  I much prefer the _iter() style:
> 
> I'm not that keen on the _iter() style, but whatever.

The implementation is more contorted (for the iter style), but it makes
the callers easier to write as they don't need the callback function and
to package all the data it needs up into a struct.

> However, does that make it harder to do the stats manipulation in bulk in
> future?
> 
> I was looking at __folio_end_writeback(), and I see:
> 
> 	....
> 			wb = inode_to_wb(inode);
> 			wb_stat_mod(wb, WB_WRITEBACK, -nr);
> 			__wb_writeout_add(wb, nr);
> 			if (!mapping_tagged(mapping, PAGECACHE_TAG_WRITEBACK)) {
> 				wb_inode_writeback_end(wb);
> 				if (mapping->host)
> 					sb_clear_inode_writeback(mapping->host);
> 			}
> 	...
> 		lruvec_stat_mod_folio(folio, NR_WRITEBACK, -nr);
> 		zone_stat_mod_folio(folio, NR_ZONE_WRITE_PENDING, -nr);
> 		node_stat_mod_folio(folio, NR_WRITTEN, nr);
> 	...
> 
> And I was thinking those could be done in bulk... but there seems to be an IRQ
> disablement requirement around them.  Does the folio_xor_flags_has_waiters()
> have to be done inside?  I presume this is to prevent a set/clear race on the
> master WRITEBACK tag.

I was envisaging embedding a folio_batch into the ctrl struct and when
that fills up, do the entire batch at once.  That gives us a 31x
reduction in overhead, which is usually enough.

Jan's more of an expert on the writeback path than I am, but once we've
cleared the PG_writeback flag on the folio, there's nothing preventing
us from removing the folio from the pagecache, right?  So the inode could
then be evicted, and then doing mapping->host would be a UAF.