The patch titled
Subject: mm: vmalloc: avoid racy handling of debugobjects in vunmap
has been added to the -mm tree. Its filename is
mm-vmalloc-avoid-racy-handling-of-debugobjects-in-vunmap.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/mm-vmalloc-avoid-racy-handling-of-debugobjects-in-vunmap.patch
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/mm-vmalloc-avoid-racy-handling-of-debugobjects-in-vunmap.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: Chintan Pandya <cpandya@xxxxxxxxxxxxxx>
Subject: mm: vmalloc: avoid racy handling of debugobjects in vunmap
Currently, __vunmap flow is,
1) Release the VM area
2) Free the debug objects corresponding to that vm area.
This leave some race window open.
1) Release the VM area
1.5) Some other client gets the same vm area
1.6) This client allocates new debug objects on the same
vm area
2) Free the debug objects corresponding to this vm area.
Here, we actually free 'other' client's debug objects.
Fix this by freeing the debug objects first and then releasing the VM
area.
Link: http://lkml.kernel.org/r/1523961828-9485-2-git-send-email-cpandya@xxxxxxxxxxxxxx
Signed-off-by: Chintan Pandya <cpandya@xxxxxxxxxxxxxx>
Reviewed-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
Cc: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
Cc: Byungchul Park <byungchul.park@xxxxxxx>
Cc: Catalin Marinas <catalin.marinas@xxxxxxx>
Cc: Florian Fainelli <f.fainelli@xxxxxxxxx>
Cc: Johannes Weiner <hannes@xxxxxxxxxxx>
Cc: Laura Abbott <labbott@xxxxxxxxxx>
Cc: Vlastimil Babka <vbabka@xxxxxxx>
Cc: Wei Yang <richard.weiyang@xxxxxxxxx>
Cc: Yisheng Xie <xieyisheng1@xxxxxxxxxx>
Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
---
mm/vmalloc.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff -puN mm/vmalloc.c~mm-vmalloc-avoid-racy-handling-of-debugobjects-in-vunmap mm/vmalloc.c
--- a/mm/vmalloc.c~mm-vmalloc-avoid-racy-handling-of-debugobjects-in-vunmap
+++ a/mm/vmalloc.c
@@ -1500,7 +1500,7 @@ static void __vunmap(const void *addr, i
addr))
return;
- area = remove_vm_area(addr);
+ area = find_vmap_area((unsigned long)addr)->vm;
if (unlikely(!area)) {
WARN(1, KERN_ERR "Trying to vfree() nonexistent vm area (%p)\n",
addr);
@@ -1510,6 +1510,7 @@ static void __vunmap(const void *addr, i
debug_check_no_locks_freed(addr, get_vm_area_size(area));
debug_check_no_obj_freed(addr, get_vm_area_size(area));
+ remove_vm_area(addr);
if (deallocate_pages) {
int i;
_
Patches currently in -mm which might be from cpandya@xxxxxxxxxxxxxx are
mm-vmalloc-clean-up-vunmap-to-avoid-pgtable-ops-twice.patch
mm-vmalloc-avoid-racy-handling-of-debugobjects-in-vunmap.patch
mm-vmalloc-pass-proper-vm_start-into-debugobjects.patch
--
To unsubscribe from this list: send the line "unsubscribe mm-commits" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
