Re: [PATCH v7 17/17] mm: add mmu_notifier argument to follow_pfn

2020-11-30 Thread Nick Desaulniers
On Mon, Nov 30, 2020 at 6:28 AM Daniel Vetter wrote: > > So I guess kvm platforms that don't set KVM_ARCH_WANT_MMU_NOTIFIER exist, > and at least on powerpc they're consistent with KVM_CAP_SYNC_MMU > signalling that the guest pagetables stays in sync automatically with any > updates. So for that c

Re: [PATCH v7 17/17] mm: add mmu_notifier argument to follow_pfn

2020-11-30 Thread Daniel Vetter
So I guess kvm platforms that don't set KVM_ARCH_WANT_MMU_NOTIFIER exist, and at least on powerpc they're consistent with KVM_CAP_SYNC_MMU signalling that the guest pagetables stays in sync automatically with any updates. So for that case I guess we could use unsafe_follow_pfn. But on s390 this se

Re: [PATCH v7 17/17] mm: add mmu_notifier argument to follow_pfn

2020-11-27 Thread kernel test robot
Hi Daniel, I love your patch! Yet something to improve: [auto build test ERROR on linuxtv-media/master] [also build test ERROR on char-misc/char-misc-testing v5.10-rc5] [cannot apply to hnaz-linux-mm/master next-20201127] [If your patch is applied to the wrong git tree, kindly drop us a note. And

[PATCH v7 17/17] mm: add mmu_notifier argument to follow_pfn

2020-11-27 Thread Daniel Vetter
The only safe way for non core/arch code to use follow_pfn() is together with an mmu_notifier subscription. follow_pfn() is already marked as _GPL and the kerneldoc explains this restriction. This patch here enforces all this by adding a mmu_notifier argument and verifying that it is registered fo