[Intel-gfx] [PATCH] mm: Report attempts to overwrite PTE from remap_pfn_range()

Chris Wilson chris at chris-wilson.co.uk
Thu Jun 19 14:00:04 CEST 2014


On Thu, Jun 19, 2014 at 02:50:18PM +0300, Kirill A. Shutemov wrote:
> > +	if (err) {
> >  		untrack_pfn(vma, pfn, PAGE_ALIGN(size));
> > +		if (err != -EBUSY)
> > +			zap_page_range_single(vma, addr, size, NULL);
> 
> Hm. If I read it correctly, you zap whole range, not only what you've
> set up. Looks wrong.

Yes. I didn't fancy threading the last touched pte back, but that should
be easier if moving to a struct.
 
> And for after zap, you probably whant to return -EBUSY to caller of
> remap_pfn_range(), not -EINVAL.

No, it has to be EINVAL for my purpose. If we return EBUSY, the caller
will just report VM_NOPAGE back to the fault handler, and the fault will
be retriggered - but the overlapping object will still be present. So the
EINVAL is there to report that the range conflicts with another and that
the caller should abort. It's a nasty semantic that works only when the
concurrent pagefaults are serialised around the call to remap_pfn_range().

The alternative would be to always report EINVAL and clean up, and
export pte_exists() so that the caller can detect when the PTEs have
already been populated by the concurrent fault.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre



More information about the Intel-gfx mailing list