lkml.org 
[lkml]   [2017]   [Jul]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC v5 09/11] mm: Try spin lock in speculative path
On Fri, Jun 16, 2017 at 07:52:33PM +0200, Laurent Dufour wrote:
> @@ -2294,8 +2295,19 @@ static bool pte_map_lock(struct vm_fault *vmf)
> if (vma_has_changed(vmf->vma, vmf->sequence))
> goto out;
>
> - pte = pte_offset_map_lock(vmf->vma->vm_mm, vmf->pmd,
> - vmf->address, &ptl);
> + /* Same as pte_offset_map_lock() except that we call

comment style..

> + * spin_trylock() in place of spin_lock() to avoid race with
> + * unmap path which may have the lock and wait for this CPU
> + * to invalidate TLB but this CPU has irq disabled.
> + * Since we are in a speculative patch, accept it could fail
> + */
> + ptl = pte_lockptr(vmf->vma->vm_mm, vmf->pmd);
> + pte = pte_offset_map(vmf->pmd, vmf->address);
> + if (unlikely(!spin_trylock(ptl))) {
> + pte_unmap(pte);
> + goto out;
> + }
> +
> if (vma_has_changed(vmf->vma, vmf->sequence)) {
> pte_unmap_unlock(pte, ptl);
> goto out;

Right, so if you look at my earlier patches you'll see I did something
quite disgusting here.

Not sure that wants repeating, but I cannot remember why I thought this
deadlock didn't exist anymore.

\
 
 \ /
  Last update: 2017-07-05 20:51    [W:0.216 / U:0.032 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site