David,
On 08/04/2015 01:48 PM, David Daney wrote:
I think the best way to think about it is to ignore vmap, and consider
the semantics of set_pte().
...
You can go around in circles all you want trying to indirectly avoid
using the buddy-PTE from another thread, but I think it is best to
make set_pte() have easily understood semantics (and semantics that
match those of other architectures) and not clobber things in
unexpected ways.
My primary interest here is not a semantics of set_pte() but the
followup of your finding, I tried test it: if guard page logic doesn't
work anymore (as I can judge basing on your observations) then it calls
back my old optimization in flush_cache_vmap(start, end) and similar.
Right now it flushes the whole cache because if it tries to flush a
guard page (and it THERE IS such attempt in some mm/*.c) it does TLB
exception and I have a hard lock in do_page_fault().
Issue is significant for some GPU/display drivers which calls flushing
VMALLOC area pretty often.
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html