[Revert] arm64: optimized copy_to_user and copy_from_user assembly code
Bug #1398596 reported by
Craig Magina
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
linux (Ubuntu) |
Fix Released
|
Medium
|
Unassigned | ||
Trusty |
Fix Released
|
Medium
|
Unassigned | ||
Utopic |
Fix Released
|
Medium
|
Unassigned |
Bug Description
[Impact]
Fixes an issue where the kernel hits unhandled pagefaults when copy_to_user is called.
http://
[Test Case]
Put the system under memory pressure.
[Regression Potential]
It will cause a performance regression on certain workloads on arm64 systems.
description: | updated |
summary: |
- Revert arm64: optimized copy_to_user and copy_from_user assembly code + [Revert] arm64: optimized copy_to_user and copy_from_user assembly code |
Changed in linux (Ubuntu Trusty): | |
importance: | Undecided → Medium |
Changed in linux (Ubuntu Utopic): | |
importance: | Undecided → Medium |
Changed in linux (Ubuntu): | |
importance: | Undecided → Medium |
tags: | added: kernel-da-key trusty utopic |
Changed in linux (Ubuntu Trusty): | |
status: | New → Triaged |
Changed in linux (Ubuntu Utopic): | |
status: | New → Triaged |
Changed in linux (Ubuntu): | |
status: | Confirmed → Triaged |
tags: | added: hs-arm64 |
tags: |
added: verification-done-trusty verification-done-utopic removed: verification-needed-trusty verification-needed-utopic |
To post a comment you must log in.
Excerpt from the report:
The exact same fixup code is being used for copy_to_user and
copy_from_user.
For the copy_from_user case we want to zero the rest of the kernel
destination buffer when we hit a pagefault reading from user space.
However, for the copy_to_user case we most definitely don't want to
write zeros in the destination buffer when we hit a pagefault writing
to user space! I get unhandled pagefaults here, when copy_to_user is
called:
0xffffffc000 73c638 <+8920>: strb wzr, [x6],#1 73c63c <+8924>: subs x2, x2, #0x1 73c640 <+8928>: b.ne 0xffffffc00073c638 <__hyp_ text_end+ 8920> 73c644 <+8932>: ret
0xffffffc000
0xffffffc000
0xffffffc000
I would suggest re-working the fixup path and testing both fixup paths
thoroughly by placing the system under memory pressure and confirming
that they are both "hit".