/**
- * make_folio_secure() - make a folio secure
+ * __make_folio_secure() - make a folio secure
* @folio: the folio to make secure
* @uvcb: the uvcb that describes the UVC to be used
*
@@ -243,14 +276,13 @@ static int expected_folio_refs(struct folio *folio)
* -EINVAL if the UVC failed for other reasons.
*
* Context: The caller must hold exactly one extra reference on the folio
- * (it's the same logic as split_folio())
+ * (it's the same logic as split_folio()), and the folio must be
+ * locked.
*/
-int make_folio_secure(struct folio *folio, struct uv_cb_header *uvcb)
+static int __make_folio_secure(struct folio *folio, struct uv_cb_header *uvcb)
One more nit: -EBUSY can no longer be returned from his function, so you
might just remove it from the doc above.
While chasing a very weird folio split bug that seems to result in late
validation issues (:/), I was wondering if __gmap_destroy_page could
similarly be problematic.
We're now no longer holding the PTL while performing the operation.
(not that that would explain the issue I am chasing, because
gmap_destroy_page() is never called in my setup)
--
Cheers,
David / dhildenb
