Laurent Dufour [off-list ref] writes:
From: Peter Zijlstra <peterz@infradead.org>
One of the side effects of speculating on faults (without holding
mmap_sem) is that we can race with free_pgtables() and therefore we
cannot assume the page-tables will stick around.
Remove the reliance on the pte pointer.
This needs a lot more explanation. So why is this code not needed with
SPF only?
-Andi
On 17/01/2018 04:04, Andi Kleen wrote:
Laurent Dufour [off-list ref] writes:
quoted
From: Peter Zijlstra <peterz@infradead.org>
One of the side effects of speculating on faults (without holding
mmap_sem) is that we can race with free_pgtables() and therefore we
cannot assume the page-tables will stick around.
Remove the reliance on the pte pointer.
This needs a lot more explanation. So why is this code not needed with
SPF only?
Hi Andi,
This is a good question, and I should detail that more in the commit's log.
Here is my response to Balbir when he asked for:
On 10/07/2017 19:48, Laurent Dufour wrote:
On 07/07/2017 09:07, Balbir Singh wrote:
quoted
On Fri, 2017-06-16 at 19:52 +0200, Laurent Dufour wrote:
quoted
From: Peter Zijlstra <peterz@infradead.org>
One of the side effects of speculating on faults (without holding
mmap_sem) is that we can race with free_pgtables() and therefore we
cannot assume the page-tables will stick around.
Remove the relyance on the pte pointer.
^^ reliance
Looking at the changelog and the code the impact is not clear.
It looks like after this patch we always assume the pte is not
the same. What is the impact of this patch?
Hi Balbir,
In most of the case pte_unmap_same() was returning 1, which meaning that
do_swap_page() should do its processing.
So in most of the case there will be no impact.
Now regarding the case where pte_unmap_safe() was returning 0, and thus
do_swap_page return 0 too, this happens when the page has already been
swapped back. This may happen before do_swap_page() get called or while in
the call to do_swap_page(). In that later case, the check done when
swapin_readahead() returns will detect that case.
The worst case would be that a page fault is occuring on 2 threads at the
same time on the same swapped out page. In that case one thread will take
much time looping in __read_swap_cache_async(). But in the regular page
fault path, this is even worse since the thread would wait for semaphore to
be released before starting anything.
Cheers,
Laurent.
I'll add that to the commit's log.
Thanks,
Laurent.