On Fri, Sep 12, 2025 at 3:35 PM James Houghton jthoughton@google.com 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?