On Tue, Sep 30, 2014 at 9:03 AM, Rik van Riel <r...@redhat.com> wrote:
>
> On the other hand, do_wp_page does not seem to do a tlb flush when
> the old page is reused, so CPUs do get rid of inappropriate TLB
> entries. We would have noticed do_wp_page not working right :)
Hmm? do_wp_page() uses the same ptep_set_access_flags(). So it too
used to do the TLB flush before that got removed there..
I do agree that clearly the CPU must *usually* do a TLB flush, or we'd
have noticed the lack immediately. I just worry that there are some
very specific circumstances when it might be missed.
That said, I don't actually believe it's that commit. I would just
like to remove it from the list of suspects.
I'm wondering what else could cause us to take effectively the same
page fault over and over again on what is a very simple instruction:
movb $0x0,(%rdx)
where handle_mm_fault() doesn't see anything wrong with the page
tables, but the CPU does.
Hmm. We also have that
if (unlikely((fault & VM_FAULT_RETRY) && fatal_signal_pending(current)))
return;
thing. It assumes that the fatal signal will kill the process, but
that's only true if returning to user space. So that looks like a
potential mis-feature (although it should sort itself out *eventually*
when the IO has completed), but the trace Dave had didn't go through
the retry paths.
Anybody see anyting else?
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
