]> git.ipfire.org Git - thirdparty/kernel/stable.git/commit - mm/memory.c
mm: delete historical BUG from zap_pmd_range()
authorHugh Dickins <hughd@google.com>
Wed, 1 Aug 2018 18:31:52 +0000 (11:31 -0700)
committerLinus Torvalds <torvalds@linux-foundation.org>
Wed, 1 Aug 2018 19:23:45 +0000 (12:23 -0700)
commit53406ed1bcfdabe4b5bc35e6d17946c6f9f563e2
treeb806be5503e22a43c7b784414af679f3089d195c
parent9a97ebf7a6bbfc1e420d53f5281f5f44df1e510d
mm: delete historical BUG from zap_pmd_range()

Delete the old VM_BUG_ON_VMA() from zap_pmd_range(), which asserted
that mmap_sem must be held when splitting an "anonymous" vma there.
Whether that's still strictly true nowadays is not entirely clear,
but the danger of sometimes crashing on the BUG is now fairly clear.

Even with the new stricter rules for anonymous vma marking, the
condition it checks for can possible trigger. Commit 44960f2a7b63
("staging: ashmem: Fix SIGBUS crash when traversing mmaped ashmem
pages") is good, and originally I thought it was safe from that
VM_BUG_ON_VMA(), because the /dev/ashmem fd exposed to the user is
disconnected from the vm_file in the vma, and madvise(,,MADV_REMOVE)
insists on VM_SHARED.

But after I read John's earlier mail, drawing attention to the
vfs_fallocate() in there: I may be wrong, and I don't know if Android
has THP in the config anyway, but it looks to me like an
unmap_mapping_range() from ashmem's vfs_fallocate() could hit precisely
the VM_BUG_ON_VMA(), once it's vma_is_anonymous().

Signed-off-by: Hugh Dickins <hughd@google.com>
Cc: John Stultz <john.stultz@linaro.org>
Cc: Kirill Shutemov <kirill.shutemov@linux.intel.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
mm/memory.c