Re: [PATCH 09/10] huge pagecache: mmap_sem is unlocked when truncation splits pmd

From: Kirill A. Shutemov
Date: Mon Apr 11 2016 - 06:35:18 EST


On Tue, Apr 05, 2016 at 01:55:23PM -0700, Hugh Dickins wrote:
> zap_pmd_range()'s CONFIG_DEBUG_VM !rwsem_is_locked(&mmap_sem) BUG()
> will be invalid with huge pagecache, in whatever way it is implemented:
> truncation of a hugely-mapped file to an unhugely-aligned size would
> easily hit it.
>
> (Although anon THP could in principle apply khugepaged to private file
> mappings, which are not excluded by the MADV_HUGEPAGE restrictions, in
> practice there's a vm_ops check which excludes them, so it never hits
> this BUG() - there's no interface to "truncate" an anonymous mapping.)
>
> We could complicate the test, to check i_mmap_rwsem also when there's a
> vm_file; but my inclination was to make zap_pmd_range() more readable by
> simply deleting this check. A search has shown no report of the issue in
> the years since commit e0897d75f0b2 ("mm, thp: print useful information
> when mmap_sem is unlocked in zap_pmd_range") expanded it from VM_BUG_ON()
> - though I cannot point to what commit I would say then fixed the issue.
>
> But there are a couple of other patches now floating around, neither
> yet in the tree: let's agree to retain the check as a VM_BUG_ON_VMA(),
> as Matthew Wilcox has done; but subject to a vma_is_anonymous() check,
> as Kirill Shutemov has done. And let's get this in, without waiting
> for any particular huge pagecache implementation to reach the tree.
>
> Signed-off-by: Hugh Dickins <hughd@xxxxxxxxxx>

Acked-by: Kirill A. Shutemov <kirill.shutemov@xxxxxxxxxxxxxxx>

--
Kirill A. Shutemov