Thomas Hellström wrote:But what mappings are there, immediately after alloc_page(), that set_memory_np won't catch? Certainly kmap_atomic() used to leave some stale mappings floating around, but that has been fixed as far as I can tell, and I guess we must be able to assume that a driver keeps track of its own kernel mappings and kill them before calling set_memory_np.Arjan van de Ven wrote:Thomas Hellström wrote:Hmm, I'm not sure I follow you here. Are you saying that it's illegal to have an NP mapping of a page (which, If I understand it correctly, means no mapping at all) at the same time as you have a, say user-space WC mapping pointing to the same physical page?Given this problem, the previously mentioned use-case, and the fact that we mostly really use user-space mappings,
Is there a possibility we could add the following functions to Dave's patch (provided they would work as intended, of course, namely invalidate / bring back the kernel mapping).
sadly there are multiple mappings, both in theory and practice.
Especially the _np / _p functions specifically work on only the mapping you specify.
For this to work we would need to somehow make a "mark all mappings NP, but please only do the kernel ones" kind of thing.
The semantics of that are... lets say messy at best.
no.
What I'm saying is that even if you make one mapping NP, it's hard to know you got all of them,
even just the kernel one.
I was under the impression that calling CPA on the kernel mapping of that page would do the rest?
this is not a correct assumption in general, especially not for things like
"present".
If a page is mapped 3 times in the kernel, and you set one to "np", the others
WILL stay mapped.
(and CPA itself no longer exists period ;)