linux-kernel - Re: [PATCH 2/2] tmpfs: fix mempolicy object leaks

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 04 Mar 2013 07:49:12 +0800
From:	Will Huck <will.huckk@...il.com>
To:	Hugh Dickins <hughd@...gle.com>
CC:	Greg Thelen <gthelen@...gle.com>, akpm@...ux-foundation.org,
	linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] tmpfs: fix mempolicy object leaks


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@...gle.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@...gle.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@...ck.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@...ck.org"> email@...ck.org </a>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/