Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754077Ab3JCAwT (ORCPT ); Wed, 2 Oct 2013 20:52:19 -0400 Received: from mail-pa0-f49.google.com ([209.85.220.49]:59664 "EHLO mail-pa0-f49.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753944Ab3JCAwG (ORCPT ); Wed, 2 Oct 2013 20:52:06 -0400 From: John Stultz To: LKML Cc: John Stultz , Andrew Morton , Android Kernel Team , Robert Love , Mel Gorman , Hugh Dickins , Dave Hansen , Rik van Riel , Dmitry Adamushko , Dave Chinner , Neil Brown , Andrea Righi , Andrea Arcangeli , "Aneesh Kumar K.V" , Mike Hommey , Taras Glek , Dhaval Giani , Jan Kara , KOSAKI Motohiro , Michel Lespinasse , Rob Clark , Minchan Kim , "linux-mm@kvack.org" Subject: [PATCH 03/14] vrange: Clear volatility on new mmaps Date: Wed, 2 Oct 2013 17:51:32 -0700 Message-Id: <1380761503-14509-4-git-send-email-john.stultz@linaro.org> X-Mailer: git-send-email 1.8.1.2 In-Reply-To: <1380761503-14509-1-git-send-email-john.stultz@linaro.org> References: <1380761503-14509-1-git-send-email-john.stultz@linaro.org> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4051 Lines: 116 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, specifically 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 volitility 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. Minchan does have an alternative solution, but I'm not a big fan of it yet, so this simpler approach is a placeholder for now. Cc: Andrew Morton Cc: Android Kernel Team Cc: Robert Love Cc: Mel Gorman Cc: Hugh Dickins Cc: Dave Hansen Cc: Rik van Riel Cc: Dmitry Adamushko Cc: Dave Chinner Cc: Neil Brown Cc: Andrea Righi Cc: Andrea Arcangeli Cc: Aneesh Kumar K.V Cc: Mike Hommey Cc: Taras Glek Cc: Dhaval Giani Cc: Jan Kara Cc: KOSAKI Motohiro Cc: Michel Lespinasse Cc: Rob Clark Cc: Minchan Kim Cc: linux-mm@kvack.org Signed-off-by: John Stultz --- 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 2b96ee1..ef153c8 100644 --- a/include/linux/vrange.h +++ b/include/linux/vrange.h @@ -36,6 +36,8 @@ static inline int vrange_type(struct vrange *vrange) return vrange->owner->type; } +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 f9c97d1..ed7056f 100644 --- a/mm/mmap.c +++ b/mm/mmap.c @@ -36,6 +36,7 @@ #include #include #include +#include #include #include @@ -1502,6 +1503,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 4ddcc3e9..f2d1588 100644 --- a/mm/vrange.c +++ b/mm/vrange.c @@ -166,6 +166,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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/