From: Will Huck <will.huckk@gmail.com>
To: Hugh Dickins <hughd@google.com>
Cc: Greg Thelen <gthelen@google.com>,
akpm@linux-foundation.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] tmpfs: fix mempolicy object leaks
Date: Mon, 04 Mar 2013 07:49:12 +0800 [thread overview]
Message-ID: <5133E178.90405@gmail.com> (raw)
In-Reply-To: <alpine.LNX.2.00.1302201221270.1152@eggly.anvils>
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 <hughd@google.com>
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 <gthelen@google.com>
>> ---
>> 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: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
--
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: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2013-03-03 23:49 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-20 7:11 [PATCH 1/2] tmpfs: fix use-after-free of mempolicy object Greg Thelen
2013-02-20 7:11 ` [PATCH 2/2] tmpfs: fix mempolicy object leaks Greg Thelen
2013-02-20 20:26 ` Hugh Dickins
2013-02-20 21:06 ` Andrew Morton
2013-03-03 23:49 ` Will Huck [this message]
2013-03-05 19:40 ` Hugh Dickins
2013-03-07 6:41 ` Will Huck
2013-02-20 20:21 ` [PATCH 1/2] tmpfs: fix use-after-free of mempolicy object Hugh Dickins
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5133E178.90405@gmail.com \
--to=will.huckk@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=gthelen@google.com \
--cc=hughd@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).