When __change_page_attr() finds it necessary to call
__cpa_process_fault(), it passes its return value directly up to its
own caller, even if this indicates success. Success to the callers,
however, means that whatever ->numpages currently holds is the count
of successfully processed pages. The cases when __change_page_attr()
calls __cpa_process_fault(), otoh, don't generally mean the entire
range got processed (as can be seen from one of the two success return
paths in __cpa_process_fault() adjusting ->numpages).
When a top level caller, like in the case of change_page_attr_set_clr()
only meaning to alter _PAGE_NX, wants to suppress alias processing, the
boolean value to indicate so results in __cpa_process_fault() taking
its other successful exit path. Since ->numpages so far didn't get
adjusted there, hitting either of the conditions that cause
__cpa_process_fault() to get called meant early termination of the
processing without having processed the entire range, yet still
reporting success.
Signed-off-by: Jan Beulich <jbeul...@suse.com>
---
v2: Completely re-written description.
---
arch/x86/mm/pageattr.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- 4.5-rc1/arch/x86/mm/pageattr.c
+++ 4.5-rc1-x86-cpa-non-primary/arch/x86/mm/pageattr.c
@@ -1122,8 +1122,10 @@ static int __cpa_process_fault(struct cp
/*
* Ignore all non primary paths.
*/
- if (!primary)
+ if (!primary) {
+ cpa->numpages = 1;
return 0;
+ }
/*
* Ignore the NULL PTE for kernel identity mapping, as it is expected
