On 08/04/21 12:05, Daniel Vetter wrote:
On Mon, Mar 29, 2021 at 10:31:01AM -0300, Jason Gunthorpe wrote:
On Tue, Mar 16, 2021 at 04:33:03PM +0100, Daniel Vetter wrote:
Both kvm (in bd2fae8da794 ("KVM: do not assume PTE is writable after
follow_pfn")) and vfio (in 07956b6269d3 ("vfio/type1: Use
follow_pte()")) have lost their callsites of follow_pfn(). All the
other ones have been switched over to unsafe_follow_pfn because they
cannot be fixed without breaking userspace api.
Argueably the vfio code is still racy, but that's kinda a bigger
vfio and kvm
Hm I thought kvm is non-racy due to the mmu notifier catch races?
No, but the plan is indeed to have some struct for each page that uses
follow_pfn and update it from the MMU notifiers.
Paolo
picture. But since it does leak the pte beyond where it drops the pt
lock, without anything else like an mmu notifier guaranteeing
coherence, the problem is at least clearly visible in the vfio code.
So good enough with me.
I've decided to keep the explanation that after dropping the pt lock
you must have an mmu notifier if you keep using the pte somehow by
adjusting it and moving it into the kerneldoc for the new follow_pte()
function.
Cc: 3pvd@xxxxxxxxxx
Cc: Jann Horn <jannh@xxxxxxxxxx>
Cc: Paolo Bonzini <pbonzini@xxxxxxxxxx>
Cc: Jason Gunthorpe <jgg@xxxxxxxxxx>
Cc: Cornelia Huck <cohuck@xxxxxxxxxx>
Cc: Peter Xu <peterx@xxxxxxxxxx>
Cc: Alex Williamson <alex.williamson@xxxxxxxxxx>
Cc: linux-mm@xxxxxxxxx
Cc: linux-arm-kernel@xxxxxxxxxxxxxxxxxxx
Cc: linux-samsung-soc@xxxxxxxxxxxxxxx
Cc: linux-media@xxxxxxxxxxxxxxx
Cc: kvm@xxxxxxxxxxxxxxx
Signed-off-by: Daniel Vetter <daniel.vetter@xxxxxxxxx>
---
include/linux/mm.h | 2 --
mm/memory.c | 26 +++++---------------------
mm/nommu.c | 13 +------------
3 files changed, 6 insertions(+), 35 deletions(-)
Reviewed-by: Jason Gunthorpe <jgg@xxxxxxxxxx>
Thanks for your r-b tags, I'll add them.
-Daniel
Jason
