Public bug reported:
The check for the _SEGMENT_ENTRY_PROTECT bit in gup_huge_pmd() is the
wrong way around. It must not be set for write==1, and not be checked for
write==0. Fix this similar to how it was fixed for ptes long time ago in
commit 25591b0 ("[S390] fix get_user_pages_fast").
One impact of this bug would be unnecessarily using the gup slow path for
write==0 on r/w mappings. A potentially more severe impact would be that
gup_huge_pmd() will succeed for write==1 on r/o mappings.
Addl information
Problem: The check for the _SEGMENT_ENTRY_PROTECT bit in
gup_huge_pmd() is the wrong way around. It must not be set
for write==1, and not be checked for write==0. Allowing
write==1 with protection bit set, instead of breaking out
to the slow path, will result in a missing faultin_page()
to clear the protection bit (for valid writable mappings),
and the async I/O write operation will fail to write to
such a mapping.
Solution: Fix it by correctly checking the protection bit like it is
also done in gup_pte_range() and gup_huge_pud().
Reproduction: Async I/O workload on buffers that are mapped as transparent
hugepages.
Upstream-ID: ba385c0594e723d41790ecfb12c610e6f90c7785
** Affects: linux (Ubuntu)
Importance: Undecided
Assignee: Skipper Bug Screeners (skipper-screen-team)
Status: New
** Tags: architecture-s39064 bugnameltc-161009 severity-high
targetmilestone-inin1604
** Tags added: architecture-s39064 bugnameltc-161009 severity-high
targetmilestone-inin1604
** Changed in: ubuntu
Assignee: (unassigned) => Skipper Bug Screeners (skipper-screen-team)
** Package changed: ubuntu => linux (Ubuntu)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1730596
Title:
s390/mm: fix write access check in gup_huge_pmd()
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1730596/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
