© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
1b1ed1a
(Get the code!)
-- Problem Description --
GPFS mmfsd daemon is mapping shared tracing buffer(allocated from kernel driver using vmalloc) and then writing trace records from user space threads in parallel. While the SIGBUS happened, the access virtual memory address is in the mapped range, no overflow on access.
Worked with Benjamin Herrenschmidt on GPFS tracing kernel driver code and he made a suggestion as workaround on the driver code to bypass the problem, and it works....
the workaround code change as below:
- rc = remap_pfn_
+ rc = remap_pfn_
As Benjamin mentioned, this is a Linux kernel bug and this is just a workaround. He will give the details about the kernel bug and why this workaround works....
The root cause is that for PTEs created by a driver at mmap time (ie, that aren't created dynamically at fault time), it's not legit for ptep_set_
Thankfully such PTEs shouldn't normally be the subject of a RO->RW privilege escalation.
What happens is that the GPFS driver creates the PTEs using remap_pfn_
PAGE_SHARED has _PAGE_ACCESSED (R) but not _PAGE_DIRTY (C) set.
Thus on the first write, we try set C and while doing so, hit the above workaround, which causes the problem described earlier.
The proposed patch will ensure we only do the Nest MMU hack when changing _PAGE_RW and not for normal R/C updates.
The workaround tested by the GPFS team consists of adding _PAGE_DIRTY to the mapping created by remap_pfn_range() to avoid the RC update fault completely.
This is fixed by these:
https:/
https:/
Since DD1 support is still in (ie, 2bf1071a8d50928