At lsf-mm, the issue was brought up that there is a precedence with interfaces like mlock, such that new mappings in a pre-existing range do no inherit the mlock state.
This is mostly because mlock only modifies the existing vmas, and so any new mmaps create new vmas, which won't be mlocked. Since volatility is not stored in the vma (for good cause, specfically as we'd have to have manage file volatility differently from anonymous and we're likely to manage volatility on small chunks of memory, which would cause lots of vma splitting and churn), this patch clears volatilty on new mappings, to ensure that we don't inherit volatility if memory in an existing volatile range is unmapped and then re-mapped with something else. Thus, this patch forces any volatility to be cleared on mmap. XXX: We expect this patch to be not well loved by mm folks, and are open to alternative methods here. Its more of a place holder to address the issue from lsf-mm and hopefully will spur some further discussion. Cc: Andrew Morton <[email protected]> Cc: Android Kernel Team <[email protected]> Cc: Robert Love <[email protected]> Cc: Mel Gorman <[email protected]> Cc: Hugh Dickins <[email protected]> Cc: Dave Hansen <[email protected]> Cc: Rik van Riel <[email protected]> Cc: Dmitry Adamushko <[email protected]> Cc: Dave Chinner <[email protected]> Cc: Neil Brown <[email protected]> Cc: Andrea Righi <[email protected]> Cc: Andrea Arcangeli <[email protected]> Cc: Aneesh Kumar K.V <[email protected]> Cc: Mike Hommey <[email protected]> Cc: Taras Glek <[email protected]> Cc: Dhaval Giani <[email protected]> Cc: Jan Kara <[email protected]> Cc: KOSAKI Motohiro <[email protected]> Cc: Michel Lespinasse <[email protected]> Cc: Minchan Kim <[email protected]> Cc: [email protected] <[email protected]> Signed-off-by: John Stultz <[email protected]> --- include/linux/vrange.h | 2 ++ mm/mmap.c | 5 +++++ mm/vrange.c | 8 ++++++++ 3 files changed, 15 insertions(+) diff --git a/include/linux/vrange.h b/include/linux/vrange.h index 13f4887..a97ac25 100644 --- a/include/linux/vrange.h +++ b/include/linux/vrange.h @@ -32,6 +32,8 @@ static inline int vrange_type(struct vrange *vrange) } void vrange_init(void); +extern int vrange_clear(struct vrange_root *vroot, + unsigned long start, unsigned long end); extern void vrange_root_cleanup(struct vrange_root *vroot); extern int vrange_fork(struct mm_struct *new, struct mm_struct *old); diff --git a/mm/mmap.c b/mm/mmap.c index f681e18..80d3676 100644 --- a/mm/mmap.c +++ b/mm/mmap.c @@ -36,6 +36,7 @@ #include <linux/sched/sysctl.h> #include <linux/notifier.h> #include <linux/memory.h> +#include <linux/vrange.h> #include <asm/uaccess.h> #include <asm/cacheflush.h> @@ -1500,6 +1501,10 @@ unsigned long mmap_region(struct file *file, unsigned long addr, /* Clear old maps */ error = -ENOMEM; munmap_back: + + /* zap any volatile ranges */ + vrange_clear(&mm->vroot, addr, addr + len); + if (find_vma_links(mm, addr, addr + len, &prev, &rb_link, &rb_parent)) { if (do_munmap(mm, addr, len)) return -ENOMEM; diff --git a/mm/vrange.c b/mm/vrange.c index bbaa184..5ca8853 100644 --- a/mm/vrange.c +++ b/mm/vrange.c @@ -164,6 +164,14 @@ static int vrange_remove(struct vrange_root *vroot, return 0; } +int vrange_clear(struct vrange_root *vroot, + unsigned long start, unsigned long end) +{ + int purged; + + return vrange_remove(vroot, start, end-1, &purged); +} + void vrange_root_cleanup(struct vrange_root *vroot) { struct vrange *range; -- 1.8.1.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
