linux-ext4 - Re: [PATCH] ext3: fix trim length underflow with small trim length.

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Wed, 19 Jan 2011 11:42:50 +0100 (CET)
From:	Lukas Czerner <lczerner@...hat.com>
To:	Tao Ma <tm@....ma>
cc:	linux-ext4@...r.kernel.org, Jan Kara <jack@...e.cz>,
	Lukas Czerner <lczerner@...hat.com>
Subject: Re: [PATCH] ext3: fix trim length underflow with small trim
 length.

On Wed, 19 Jan 2011, Tao Ma wrote:

> From: Tao Ma <boyu.mt@...bao.com>
> 
> We adjust 'len' with s_first_data_block - start in case of start is less
> than s_first_data_block, but it could underflow in case blocksize=1K, while
> fstrim_range.len=512 and fstrim_range.start = 0. In this case len happens
> to be underflow and in the end, although we are safe that last_group check
> will limit the trim to the whole volume, I am afraid that isn't what the user
> really want.
> 
> So this patch fix it. It also adds a new variable s_first_data_block so that
> the 4 le32_to_cpu can be replaced with 1.

Well, I just realized that what are we doing is not exactly what will
user expect. User does not really care where the first data block is.
What the user will expect is, to trim let's say first one gigabyte
of his filesystem, not gigabyte - first data block.

So what I suggest is to always add first_data_block to
fstrim_range.start and do all the necessary checks for overflow. If no
one has any objections I'll put it to the patch.

Thanks!
-Lukas

> 
> Cc: Jan Kara <jack@...e.cz>
> Cc: Lukas Czerner <lczerner@...hat.com>
> Signed-off-by: Tao Ma <boyu.mt@...bao.com>
> ---
>  fs/ext3/balloc.c |    9 +++++----
>  1 files changed, 5 insertions(+), 4 deletions(-)
> 
> diff --git a/fs/ext3/balloc.c b/fs/ext3/balloc.c
> index 045995c..ee7e0f3 100644
> --- a/fs/ext3/balloc.c
> +++ b/fs/ext3/balloc.c
> @@ -2088,6 +2088,7 @@ int ext3_trim_fs(struct super_block *sb, struct fstrim_range *range)
>  	struct ext3_super_block *es = EXT3_SB(sb)->s_es;
>  	uint64_t start, len, minlen, trimmed;
>  	ext3_fsblk_t max_blks = le32_to_cpu(es->s_blocks_count);
> +	ext3_fsblk_t first_data_block = le32_to_cpu(es->s_first_data_block);
>  	int ret = 0;
>  
>  	start = range->start >> sb->s_blocksize_bits;
> @@ -2097,11 +2098,11 @@ int ext3_trim_fs(struct super_block *sb, struct fstrim_range *range)
>  
>  	if (unlikely(minlen > EXT3_BLOCKS_PER_GROUP(sb)))
>  		return -EINVAL;
> -	if (start >= max_blks)
> +	if (start >= max_blks || start + len <= first_data_block)
>  		goto out;
> -	if (start < le32_to_cpu(es->s_first_data_block)) {
> -		len -= le32_to_cpu(es->s_first_data_block) - start;
> -		start = le32_to_cpu(es->s_first_data_block);
> +	if (start < first_data_block) {
> +		len -= first_data_block - start;
> +		start = first_data_block;
>  	}
>  	if (start + len > max_blks)
>  		len = max_blks - start;
> 

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