On Thu, Jul 30, 2020 at 2:17 PM Thomas Hellström (Intel) thomas_os@shipmail.org wrote:
On 7/28/20 3:58 PM, Daniel Vetter wrote:
GPU drivers need this in their shrinkers, to be able to throw out mmap'ed buffers. Note that we also need dma_resv_lock in shrinkers, but that loop is resolved by trylocking in shrinkers.
So full hierarchy is now (ignore some of the other branches we already have primed):
mmap_read_lock -> dma_resv -> shrinkers -> i_mmap_lock_write
I hope that's not inconsistent with anything mm or fs does, adding relevant people.
Looks OK to me. The mapping_dirty_helpers run under the i_mmap_lock, but don't allocate any memory AFAICT.
Since huge page-table-entry splitting may happen under the i_mmap_lock from unmap_mapping_range() it might be worth figuring out how new page directory pages are allocated, though.
ofc I'm not an mm expert at all, but I did try to scroll through all i_mmap_lock_write/read callers. Found the following:
- kernel/events/uprobes.c in build_map_info:
/* * Needs GFP_NOWAIT to avoid i_mmap_rwsem recursion through * reclaim. This is optimistic, no harm done if it fails. */
- I got lost in the hugetlb.c code and couldn't convince myself it's not allocating page directories at various levels with something else than GFP_KERNEL.
So looks like the recursion is clearly there and known, but the hugepage code is too complex and flying over my head. -Daniel
/Thomas