Re: [PATCH v14 05/21] fsverity: improve flushing performance of fsverity_fill_zerohash

[Matthew Wilcox <willy@infradead.org>]

On Tue, Aug 04, 2026 at 11:56:03AM -0700, Darrick J. Wong wrote:
> On Tue, Aug 04, 2026 at 07:46:03PM +0100, Matthew Wilcox wrote:
> > On Mon, Aug 03, 2026 at 10:07:55PM +0200, Andrey Albershteyn wrote:
> > > The current version calls flush_dcache_folio(), in memcpy_to_folio(), to
> > > flush whole folio on every digest (which is 128 for 4k) on the HIGHMEM
> > > systems. Open code folio mapping and flushing to copy all digests at
> > > once.
> > 
> > Have you looked at the implementations of flush_dcache_folio()?  On
> > any architecture we actually care about, all it does is set one bit
> > in folio->flags noting that the folio will need to be flushed if
> > it's going to be accessed by userspace.
> > 
> > But, um, do we support mapping folios containing fsverity data into
> > userspace?  Can't we just delete the calls to flush_dcache_folio()?
> 
> I don't think programs are allowed to mmap the fsverity data, right?
> I know there's an ioctl that effectively allows read()ing it.

read() is fine, there's no user/kernel d-cache aliasing problem with
read().  It's just mmaps that are problematic.

See Documentation/core-api/cachetlb.rst where it talks about
flush_dcache_folio().