[Kernel-packages] [Bug 1792195] Comment bridged from LTC Bugzilla
--- Comment From mranw...@us.ibm.com 2018-10-15 17:55 EDT---
This kernel also looks good - I did a couple 10+ minutes runs against it
without any problems, which shows the problem being fixed.
I think that leaving out DD1 is ok - but at some point if it's still
there it may make some other backport much harder - but we can also just
deal with that when needed.
The backport removing DD1 also included the fix for powerpc/64s:
dt_cpu_ftrs fix POWER9 DD2.2 and above (9e9626e) - but maybe I should
open a bug to get that into the next SRU?
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1792195
Title:
Signal 7 error when running GPFS tracing in cluster
Status in The Ubuntu-power-systems project:
In Progress
Status in linux package in Ubuntu:
In Progress
Status in linux source package in Bionic:
In Progress
Status in linux source package in Cosmic:
In Progress
Bug description:
== SRU Justification ==
IBM is requesting these commits in bionic and cosmic. These commits
also rely on commit 7acf50e4efa6, which was SRU'd in bug 1792102. The
first patch, commit 2bf1071a8d50, was backported by IBM themself.
Description of bug:
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.
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_access_flags()
to make them invalid even temporarily. A concurrent access while they are
invalid will be unable to service the page fault and will cause as SIGBUS.
== Fixes ==
2bf1071a8d50 ("powerpc/64s: Remove POWER9 DD1 support")
bd0dbb73e013 ("powerpc/mm/books3s: Add new pte bit to mark pte temporarily
invalid.")
f08d08f3db55 ("powerpc/mm/radix: Only need the Nest MMU workaround for R ->
RW transition")
== Regression Potential ==
Low. Limited to powerpc.
== Test Case ==
A test kernel was built with these patches and tested by IBM.
IBM states the test kernel resolved the bug.
-- 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_range(vma, start, pfn, PAGE_SIZE, PAGE_SHARED);
+ rc = remap_pfn_range(vma, start, pfn, PAGE_SIZE,
__pgprot(pgprot_val(PAGE_SHARED)|_PAGE_DIRTY);
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_access_flags() to make them invalid even temporarily. A
concurrent access while they are invalid will be unable to service the
page fault and will cause as SIGBUS.
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_range(...,PAGE_SHARED).
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://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bd0dbb73e01306a1060e56f81e5fe287be936477
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f08d08f3db55452d31ba4a37c702da6245876b96
Since DD1 support is still in (ie,
2bf1071a8d50928a4ae366bb3108833166c2b70c is not applied) the second
doesn't apply cleanly. Did you want that attached?
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-power-systems/+bug/1792195/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1792195] Comment bridged from LTC Bugzilla
--- Comment From mranw...@us.ibm.com 2018-10-15 02:32 EDT---
A belated update - the ppa kernel looks good, too, I did try that out and
verified that both issues are fixed with it. Thank you!
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1792195
Title:
Signal 7 error when running GPFS tracing in cluster
Status in The Ubuntu-power-systems project:
In Progress
Status in linux package in Ubuntu:
In Progress
Status in linux source package in Bionic:
In Progress
Status in linux source package in Cosmic:
In Progress
Bug description:
== SRU Justification ==
IBM is requesting these commits in bionic and cosmic. These commits
also rely on commit 7acf50e4efa6, which was SRU'd in bug 1792102. The
first patch, commit 2bf1071a8d50, was backported by IBM themself.
Description of bug:
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.
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_access_flags()
to make them invalid even temporarily. A concurrent access while they are
invalid will be unable to service the page fault and will cause as SIGBUS.
== Fixes ==
2bf1071a8d50 ("powerpc/64s: Remove POWER9 DD1 support")
bd0dbb73e013 ("powerpc/mm/books3s: Add new pte bit to mark pte temporarily
invalid.")
f08d08f3db55 ("powerpc/mm/radix: Only need the Nest MMU workaround for R ->
RW transition")
== Regression Potential ==
Low. Limited to powerpc.
== Test Case ==
A test kernel was built with these patches and tested by IBM.
IBM states the test kernel resolved the bug.
-- 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_range(vma, start, pfn, PAGE_SIZE, PAGE_SHARED);
+ rc = remap_pfn_range(vma, start, pfn, PAGE_SIZE,
__pgprot(pgprot_val(PAGE_SHARED)|_PAGE_DIRTY);
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_access_flags() to make them invalid even temporarily. A
concurrent access while they are invalid will be unable to service the
page fault and will cause as SIGBUS.
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_range(...,PAGE_SHARED).
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://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bd0dbb73e01306a1060e56f81e5fe287be936477
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f08d08f3db55452d31ba4a37c702da6245876b96
Since DD1 support is still in (ie,
2bf1071a8d50928a4ae366bb3108833166c2b70c is not applied) the second
doesn't apply cleanly. Did you want that attached?
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-power-systems/+bug/1792195/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1792195] Comment bridged from LTC Bugzilla
--- Comment From mranw...@us.ibm.com 2018-10-11 12:27 EDT---
Just to clarify the previous comment - the bug is fixed with the v2 kernel. I
did multiple runs without hitting the problem.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1792195
Title:
Signal 7 error when running GPFS tracing in cluster
Status in The Ubuntu-power-systems project:
In Progress
Status in linux package in Ubuntu:
In Progress
Status in linux source package in Bionic:
In Progress
Status in linux source package in Cosmic:
In Progress
Bug description:
== SRU Justification ==
IBM is requesting these commits in bionic and cosmic. These commits
also rely on commit 7acf50e4efa6, which was SRU'd in bug 1792102. The
first patch, commit 2bf1071a8d50, was backported by IBM themself.
Description of bug:
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.
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_access_flags()
to make them invalid even temporarily. A concurrent access while they are
invalid will be unable to service the page fault and will cause as SIGBUS.
== Fixes ==
2bf1071a8d50 ("powerpc/64s: Remove POWER9 DD1 support")
bd0dbb73e013 ("powerpc/mm/books3s: Add new pte bit to mark pte temporarily
invalid.")
f08d08f3db55 ("powerpc/mm/radix: Only need the Nest MMU workaround for R ->
RW transition")
== Regression Potential ==
Low. Limited to powerpc.
== Test Case ==
A test kernel was built with these patches and tested by IBM.
IBM states the test kernel resolved the bug.
-- 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_range(vma, start, pfn, PAGE_SIZE, PAGE_SHARED);
+ rc = remap_pfn_range(vma, start, pfn, PAGE_SIZE,
__pgprot(pgprot_val(PAGE_SHARED)|_PAGE_DIRTY);
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_access_flags() to make them invalid even temporarily. A
concurrent access while they are invalid will be unable to service the
page fault and will cause as SIGBUS.
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_range(...,PAGE_SHARED).
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://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bd0dbb73e01306a1060e56f81e5fe287be936477
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f08d08f3db55452d31ba4a37c702da6245876b96
Since DD1 support is still in (ie,
2bf1071a8d50928a4ae366bb3108833166c2b70c is not applied) the second
doesn't apply cleanly. Did you want that attached?
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-power-systems/+bug/1792195/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1792195] Comment bridged from LTC Bugzilla
--- Comment From mranw...@us.ibm.com 2018-10-10 21:28 EDT--- Thanks, looks good! Over an hour of runtime, the failure recreates in a minute or so. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1792195 Title: Signal 7 error when running GPFS tracing in cluster Status in The Ubuntu-power-systems project: In Progress Status in linux package in Ubuntu: In Progress Status in linux source package in Bionic: In Progress Bug description: -- 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_range(vma, start, pfn, PAGE_SIZE, PAGE_SHARED); + rc = remap_pfn_range(vma, start, pfn, PAGE_SIZE, __pgprot(pgprot_val(PAGE_SHARED)|_PAGE_DIRTY); 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_access_flags() to make them invalid even temporarily. A concurrent access while they are invalid will be unable to service the page fault and will cause as SIGBUS. 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_range(...,PAGE_SHARED). 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://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bd0dbb73e01306a1060e56f81e5fe287be936477 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f08d08f3db55452d31ba4a37c702da6245876b96 Since DD1 support is still in (ie, 2bf1071a8d50928a4ae366bb3108833166c2b70c is not applied) the second doesn't apply cleanly. Did you want that attached? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/1792195/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1792195] Comment bridged from LTC Bugzilla
--- Comment From mranw...@us.ibm.com 2018-10-10 17:49 EDT--- Commit list good, the port for 2bf1071a8d50 also included 749a027 powerpc/64s: Fix DT CPU features Power9 DD2.1 logic as a pre-req/additional fix. The download directory there is empty, though, so I can't get to the test kernel. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1792195 Title: Signal 7 error when running GPFS tracing in cluster Status in The Ubuntu-power-systems project: In Progress Status in linux package in Ubuntu: In Progress Status in linux source package in Bionic: In Progress Bug description: -- 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_range(vma, start, pfn, PAGE_SIZE, PAGE_SHARED); + rc = remap_pfn_range(vma, start, pfn, PAGE_SIZE, __pgprot(pgprot_val(PAGE_SHARED)|_PAGE_DIRTY); 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_access_flags() to make them invalid even temporarily. A concurrent access while they are invalid will be unable to service the page fault and will cause as SIGBUS. 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_range(...,PAGE_SHARED). 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://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bd0dbb73e01306a1060e56f81e5fe287be936477 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f08d08f3db55452d31ba4a37c702da6245876b96 Since DD1 support is still in (ie, 2bf1071a8d50928a4ae366bb3108833166c2b70c is not applied) the second doesn't apply cleanly. Did you want that attached? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/1792195/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1792195] Comment bridged from LTC Bugzilla
--- Comment From mranw...@us.ibm.com 2018-10-10 16:00 EDT--- Thanks! I'm building that too, to see if that was the issue. But that patch applies with some (-2, -25) fuzz for me - I tried on master-next, too, and see the same. I'm at fd01374000c8 (-36.39) and I just have the patches from this bug and from LP 1792102 -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1792195 Title: Signal 7 error when running GPFS tracing in cluster Status in The Ubuntu-power-systems project: In Progress Status in linux package in Ubuntu: In Progress Status in linux source package in Bionic: In Progress Bug description: -- 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_range(vma, start, pfn, PAGE_SIZE, PAGE_SHARED); + rc = remap_pfn_range(vma, start, pfn, PAGE_SIZE, __pgprot(pgprot_val(PAGE_SHARED)|_PAGE_DIRTY); 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_access_flags() to make them invalid even temporarily. A concurrent access while they are invalid will be unable to service the page fault and will cause as SIGBUS. 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_range(...,PAGE_SHARED). 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://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bd0dbb73e01306a1060e56f81e5fe287be936477 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f08d08f3db55452d31ba4a37c702da6245876b96 Since DD1 support is still in (ie, 2bf1071a8d50928a4ae366bb3108833166c2b70c is not applied) the second doesn't apply cleanly. Did you want that attached? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/1792195/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1792195] Comment bridged from LTC Bugzilla
--- Comment From mranw...@us.ibm.com 2018-10-10 13:30 EDT--- I gave that a try and still saw the problem: Linux version 4.15.0-36-generic (jsalisbury@kathleen) (gcc version 7.3.0 (Ubuntu 7.3.0-16ubuntu3)) #40~lp1792195 SMP Wed Oct 10 13:19:58 UTC 2018 Does that also include bd0dbb73e01306a1060e56f81e5fe287be936477? -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1792195 Title: Signal 7 error when running GPFS tracing in cluster Status in The Ubuntu-power-systems project: In Progress Status in linux package in Ubuntu: In Progress Status in linux source package in Bionic: In Progress Bug description: -- 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_range(vma, start, pfn, PAGE_SIZE, PAGE_SHARED); + rc = remap_pfn_range(vma, start, pfn, PAGE_SIZE, __pgprot(pgprot_val(PAGE_SHARED)|_PAGE_DIRTY); 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_access_flags() to make them invalid even temporarily. A concurrent access while they are invalid will be unable to service the page fault and will cause as SIGBUS. 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_range(...,PAGE_SHARED). 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://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bd0dbb73e01306a1060e56f81e5fe287be936477 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f08d08f3db55452d31ba4a37c702da6245876b96 Since DD1 support is still in (ie, 2bf1071a8d50928a4ae366bb3108833166c2b70c is not applied) the second doesn't apply cleanly. Did you want that attached? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/1792195/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1792195] Comment bridged from LTC Bugzilla
--- Comment From mranw...@us.ibm.com 2018-10-09 13:31 EDT--- We can recreate this without GPFS using a modified version of the tests here: https://github.com/NVIDIA/gdrcopy Working on the DD1 removal backport. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1792195 Title: Signal 7 error when running GPFS tracing in cluster Status in The Ubuntu-power-systems project: Incomplete Status in linux package in Ubuntu: In Progress Status in linux source package in Bionic: In Progress Bug description: -- 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_range(vma, start, pfn, PAGE_SIZE, PAGE_SHARED); + rc = remap_pfn_range(vma, start, pfn, PAGE_SIZE, __pgprot(pgprot_val(PAGE_SHARED)|_PAGE_DIRTY); 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_access_flags() to make them invalid even temporarily. A concurrent access while they are invalid will be unable to service the page fault and will cause as SIGBUS. 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_range(...,PAGE_SHARED). 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://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bd0dbb73e01306a1060e56f81e5fe287be936477 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f08d08f3db55452d31ba4a37c702da6245876b96 Since DD1 support is still in (ie, 2bf1071a8d50928a4ae366bb3108833166c2b70c is not applied) the second doesn't apply cleanly. Did you want that attached? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/1792195/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
