Excerpts from Paolo Bonzini's message of June 24, 2021 8:21 pm:
On 24/06/21 12:17, Nicholas Piggin wrote:
If all callers were updated that is one thing, but from the changelog it sounds like that would not happen and there would be some gfn_to_pfn users left over.
But yes in the end you would either need to make gfn_to_pfn never return a page found via follow_pte, or change all callers to the new way. If the plan is for the latter then I guess that's fine.
Actually in that case anyway I don't see the need -- the existence of gfn_to_pfn is enough to know it might be buggy. It can just as easily be grepped for as kvm_pfn_page_unwrap.
Sure, but that would leave us with longer function names (gfn_to_pfn_page* instead of gfn_to_pfn*). So the "safe" use is the one that looks worse and the unsafe use is the one that looks safe.
The churn isn't justified because of function name length. Choose g2pp() if you want a non-descriptive but short name.
The existing name isn't good anyway because it not only looks up a pfn but also a page, and more importantly it gets a ref on the page. The name should be changed if you introduce a new API.
And are gfn_to_page cases also vulernable to the same issue?
No, they're just broken for the VM_IO|VM_PFNMAP case.
No they aren't vulnerable, or they are vunlerable but also broken in other cases?
Thanks, Nick