Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754832Ab3CCXtT (ORCPT ); Sun, 3 Mar 2013 18:49:19 -0500 Received: from mail-pa0-f52.google.com ([209.85.220.52]:37982 "EHLO mail-pa0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754655Ab3CCXtS (ORCPT ); Sun, 3 Mar 2013 18:49:18 -0500 Message-ID: <5133E178.90405@gmail.com> Date: Mon, 04 Mar 2013 07:49:12 +0800 From: Will Huck User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 MIME-Version: 1.0 To: Hugh Dickins CC: Greg Thelen , akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/2] tmpfs: fix mempolicy object leaks References: <1361344302-26565-1-git-send-email-gthelen@google.com> <1361344302-26565-2-git-send-email-gthelen@google.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3745 Lines: 115 Hi Hugh, On 02/21/2013 04:26 AM, Hugh Dickins wrote: > On Tue, 19 Feb 2013, Greg Thelen wrote: > >> This patch fixes several mempolicy leaks in the tmpfs mount logic. >> These leaks are slow - on the order of one object leaked per mount >> attempt. >> >> Leak 1 (umount doesn't free mpol allocated in mount): >> while true; do >> mount -t tmpfs -o mpol=interleave,size=100M nodev /mnt >> umount /mnt >> done >> >> Leak 2 (errors parsing remount options will leak mpol): >> mount -t tmpfs -o size=100M nodev /mnt >> while true; do >> mount -o remount,mpol=interleave,size=x /mnt 2> /dev/null >> done >> umount /mnt >> >> Leak 3 (multiple mpol per mount leak mpol): >> while true; do >> mount -t tmpfs -o mpol=interleave,mpol=interleave,size=100M nodev /mnt >> umount /mnt >> done >> >> This patch fixes all of the above. I could have broken the patch into >> three pieces but is seemed easier to review as one. > Yes, I agree, and nicely fixed - but one doubt below. If you resolve > that, please add my Acked-by: Hugh Dickins Could you explain me why shmem has more relationship with mempolicy? It seems that there are many codes in shmem handle mempolicy, but other components in mm subsystem just have little. > >> Signed-off-by: Greg Thelen >> --- >> mm/shmem.c | 12 +++++++++--- >> 1 file changed, 9 insertions(+), 3 deletions(-) >> >> diff --git a/mm/shmem.c b/mm/shmem.c >> index efd0b3a..ed2cb26 100644 >> --- a/mm/shmem.c >> +++ b/mm/shmem.c >> @@ -2386,6 +2386,7 @@ static int shmem_parse_options(char *options, struct shmem_sb_info *sbinfo, >> bool remount) >> { >> char *this_char, *value, *rest; >> + struct mempolicy *mpol = NULL; >> uid_t uid; >> gid_t gid; >> >> @@ -2414,7 +2415,7 @@ static int shmem_parse_options(char *options, struct shmem_sb_info *sbinfo, >> printk(KERN_ERR >> "tmpfs: No value for mount option '%s'\n", >> this_char); >> - return 1; >> + goto error; >> } >> >> if (!strcmp(this_char,"size")) { >> @@ -2463,19 +2464,23 @@ static int shmem_parse_options(char *options, struct shmem_sb_info *sbinfo, >> if (!gid_valid(sbinfo->gid)) >> goto bad_val; >> } else if (!strcmp(this_char,"mpol")) { >> - if (mpol_parse_str(value, &sbinfo->mpol)) >> + mpol_put(mpol); > I haven't tested to check, but don't we need > mpol = NULL; > here, in case the new option turns out to be bad? > >> + if (mpol_parse_str(value, &mpol)) >> goto bad_val; >> } else { >> printk(KERN_ERR "tmpfs: Bad mount option %s\n", >> this_char); >> - return 1; >> + goto error; >> } >> } >> + sbinfo->mpol = mpol; >> return 0; >> >> bad_val: >> printk(KERN_ERR "tmpfs: Bad value '%s' for mount option '%s'\n", >> value, this_char); >> +error: >> + mpol_put(mpol); >> return 1; >> >> } >> @@ -2551,6 +2556,7 @@ static void shmem_put_super(struct super_block *sb) >> struct shmem_sb_info *sbinfo = SHMEM_SB(sb); >> >> percpu_counter_destroy(&sbinfo->used_blocks); >> + mpol_put(sbinfo->mpol); >> kfree(sbinfo); >> sb->s_fs_info = NULL; >> } >> -- >> 1.8.1.3 > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majordomo@kvack.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: email@kvack.org -- 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/