Hi,
I'm debugging an interesting problem: split_folio() will fail on dirty
folios on XFS, and I am not sure who will trigger the writeback in a
timely manner so code relying on the split to work at some point (in
sane setups where page pinning is not applicable) can make progress.
https://issues.redhat.com/browse/RHEL-58218
s390x PV ("Protected Virtualization" / "Secure virtualization") does not
support large folios. So when we want to convert an individual 4k page
to "secure" and we hit a large folio, we have to split it.
In gmap_make_secure(), we call split_folio() if we hit a large folio,
and essentially retry forever (after dropping the folio reference).
Starting a "protected VM" (similar to encrypted VMs) will not make
progress when trying to load the initial encrypted VM state into memory
("unpack").
I assume other split_folio() users might similarly be affected:
split_folio() will frequently just fail without any obvious way to "fix
that up" to make progress.
Looking into the details, it seems to be an IOMAP limitation:
split_folio() will keep failing in filemap_release_folio() because
iomap_release_folio() fails on dirty folios. I would have expected
background writeback to "fix that", but it's either not happening or
because it's just happening too slowly.
I can see that migration code manually triggers writeback, using
folio_clear_dirty_for_io() and mapping->a_ops->writepages) when it
stumbles over a dirty folio.
Should we do the same in split_folio() directly? Or offer callers
(gmap_make_secure()) a way to trigger this conditionally, similarly to
how we have ways for waiting for a folio that is under writeback to finish?
... or is there a feasible way forward to make iomap_release_folio() not
bail out on dirty folios?
The comment there says:
"If the folio is dirty, we refuse to release our metadata because it may
be partially dirty. Once we track per-block dirty state, we can release
the metadata if every block is dirty."
--
Cheers,
David / dhildenb
