Chris Wilson wrote:
> On Thu, Jun 19, 2014 at 03:57:46PM +0300, Kirill A. Shutemov wrote:
> > One possible option is to create a variant of remap_pfn_range() which will
> > return how many PTEs it was able to setup, before hitting the !pte_none().
> > Caller will decide what to do with partially fi
On Thu, Jun 19, 2014 at 03:57:46PM +0300, Kirill A. Shutemov wrote:
> Chris Wilson wrote:
> > 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)
>
Chris Wilson wrote:
> 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 co
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 ran
Chris Wilson wrote:
> When using remap_pfn_range() from a fault handler, we are exposed to
> races between concurrent faults. Rather than hitting a BUG, report the
> error back to the caller, like vm_insert_pfn().
>
> v2: Fix the pte address for unmapping along the error path.
> v3: Report the err
When using remap_pfn_range() from a fault handler, we are exposed to
races between concurrent faults. Rather than hitting a BUG, report the
error back to the caller, like vm_insert_pfn().
v2: Fix the pte address for unmapping along the error path.
v3: Report the error back and cleanup partial rema
