On Wed, Oct 23, 2019 at 12:55:13PM -0700, Ralph Campbell wrote: > hmm_range_fault() calls find_vma() and walk_page_range() in a loop. > This is unnecessary duplication since walk_page_range() calls find_vma() > in a loop already. > Simplify hmm_range_fault() by defining a walk_test() callback function > to filter unhandled vmas. > This also fixes a bug where hmm_range_fault() was not checking > start >= vma->vm_start before checking vma->vm_flags so hmm_range_fault() > could return an error based on the wrong vma for the requested range. > It also fixes a bug when the vma has no read access and the caller did > not request a fault, there shouldn't be any error return code. > > Signed-off-by: Ralph Campbell <rcampbell@xxxxxxxxxx> > Cc: "Jérôme Glisse" <jglisse@xxxxxxxxxx> > Cc: Jason Gunthorpe <jgg@xxxxxxxxxxxx> > Cc: Christoph Hellwig <hch@xxxxxx> > mm/hmm.c | 126 +++++++++++++++++++++++++++---------------------------- > 1 file changed, 63 insertions(+), 63 deletions(-) This is looking OK, can we get an ack from Jerome? Christoph? I recall my first worry was that walk->vma could now be null, as ops->pte_hole is set. But it looks like that is all handled now? Thanks, Jason
