On Fri, Sep 12, 2025 at 3:35 PM James Houghton <[email protected]> wrote: > > > >> + > > >> + if (folio_test_uptodate(folio)) { > > >> + folio_unlock(folio); > > >> + folio_put(folio); > > >> + return -ENOSPC; > > > > > > Does it actually matter for the folio not to be uptodate? It seems > > > unnecessarily restrictive not to be able to overwrite data if we're > > > saying that this is only usable for unencrypted memory anyway. > > > > In the context of direct map removal [1] it does actually because when > > we mark a folio as prepared, we remove it from the direct map making it > > inaccessible to the way write() performs the copy. It does not matter > > if direct map removal isn't enabled though. Do you think it should be > > conditional? > > Oh, good point. It's simpler (both to implement and to describe) to > disallow a second write() call in all cases (no matter if the direct > map for the page has been removed or if the contents have been > encrypted), so I'm all for leaving it unconditional like you have now. > Thanks!
Are we deviating from the way read/write semantics work for the other filesystems? I don't think other filesystems carry this restriction of one-time-write only. Do we strictly need the differing semantics? Maybe it would be simpler to not overload uptodate flag and just not allow read/write if folio is not mapped in the direct map for non-conf VMs (assuming there could be other ways to deduce that information). Can there be users who want to populate the file ranges multiple times as it seems more performant? > > > > > [1]: https://lore.kernel.org/kvm/[email protected] > > > > >
