The patch titled
Subject: mm/vmalloc.c: make vmalloc_32_user() align base kernel virtual address to SHMLBA
has been added to the -mm tree. Its filename is
mm-vmalloc-make-vmalloc_32_user-align-base-kernel-virtual-address-to-shmlba.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/mm-vmalloc-make-vmalloc_32_user-align-base-kernel-virtual-address-to-shmlba.patch
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/mm-vmalloc-make-vmalloc_32_user-align-base-kernel-virtual-address-to-shmlba.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Roman Penyaev <rpenyaev@xxxxxxx>
Subject: mm/vmalloc.c: make vmalloc_32_user() align base kernel virtual address to SHMLBA
This patch repeats the original one from David S. Miller:
2dca6999eed5 ("mm, perf_event: Make vmalloc_user() align base kernel virtual address to SHMLBA")
but for missed vmalloc_32_user() case, which also requires correct
alignment of virtual address on kernel side to avoid D-caches aliases. A
bit of copy-paste from original patch to recover in memory of what is all
about:
When a vmalloc'd area is mmap'd into userspace, some kind of
co-ordination is necessary for this to work on platforms with cpu
D-caches which can have aliases.
Otherwise kernel side writes won't be seen properly in userspace
and vice versa.
If the kernel side mapping and the user side one have the same
alignment, modulo SHMLBA, this can work as long as VM_SHARED is
shared of VMA and for all current users this is true. VM_SHARED
will force SHMLBA alignment of the user side mmap on platforms with
D-cache aliasing matters.
David S. Miller
Link: http://lkml.kernel.org/r/20190108110944.23591-1-rpenyaev@xxxxxxx
Signed-off-by: Roman Penyaev <rpenyaev@xxxxxxx>
Cc: Stephen Rothwell <sfr@xxxxxxxxxxxxxxxx>
Cc: Michal Hocko <mhocko@xxxxxxxx>
Cc: David S. Miller <davem@xxxxxxxxxxxxx>
Cc: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
---
mm/vmalloc.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
--- a/mm/vmalloc.c~mm-vmalloc-make-vmalloc_32_user-align-base-kernel-virtual-address-to-shmlba
+++ a/mm/vmalloc.c
@@ -1967,8 +1967,9 @@ void *vmalloc_32_user(unsigned long size
struct vm_struct *area;
void *ret;
- ret = __vmalloc_node(size, 1, GFP_VMALLOC32 | __GFP_ZERO, PAGE_KERNEL,
- NUMA_NO_NODE, __builtin_return_address(0));
+ ret = __vmalloc_node(size, SHMLBA, GFP_VMALLOC32 | __GFP_ZERO,
+ PAGE_KERNEL, NUMA_NO_NODE,
+ __builtin_return_address(0));
if (ret) {
area = find_vm_area(ret);
area->flags |= VM_USERMAP;
_
Patches currently in -mm which might be from rpenyaev@xxxxxxx are
mm-vmalloc-make-vmalloc_32_user-align-base-kernel-virtual-address-to-shmlba.patch
mm-vmalloc-fix-size-check-for-remap_vmalloc_range_partial.patch
mm-vmalloc-do-not-call-kmemleak_free-on-not-yet-accounted-memory.patch
mm-vmalloc-pass-vm_usermap-flags-directly-to-__vmalloc_node_range.patch
epoll-make-sure-all-elements-in-ready-list-are-in-fifo-order.patch
epoll-loosen-irq-safety-in-ep_poll_callback.patch
epoll-unify-awaking-of-wakeup-source-on-ep_poll_callback-path.patch
epoll-use-rwlock-in-order-to-reduce-ep_poll_callback-contention.patch
