[PATCH] ext3: fix trim length underflow with small trim length.

[PATCH] ext3: fix trim length underflow with small trim length.

[Tao Ma]

From: Tao Ma <boyu.mt@taobao.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.

Cc: Jan Kara <jack@suse.cz>
Cc: Lukas Czerner <lczerner@redhat.com>
Signed-off-by: Tao Ma <boyu.mt@taobao.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;
-- 
1.6.3.GIT

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

[Lukas Czerner]

On Wed, 19 Jan 2011, Tao Ma wrote:

> From: Tao Ma <boyu.mt@taobao.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@suse.cz>
> Cc: Lukas Czerner <lczerner@redhat.com>
> Signed-off-by: Tao Ma <boyu.mt@taobao.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;
> 

-- 

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

[Jan Kara]

On Wed 19-01-11 11:42:50, Lukas Czerner wrote:
> On Wed, 19 Jan 2011, Tao Ma wrote:
> 
> > From: Tao Ma <boyu.mt@taobao.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.
  Well, since we speak about at most 1KB (s_first_data_block is non-zero
only when blocksize == 1024 and in that case it is 1), I don't think it
really matters and I don't mind whatever solution. What user expects is
a bit hard to guess (whether he views 'start' as a start of the filesystem
or a start of the device). Maybe the former makes a tad bit more sense
but as I said I don't really care so since you're the author of the code I
leave it up to you.

								Honza
-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR

[PATCH v2] ext3: Adjust trim start with first_data_block.

[Tao Ma]

From: Tao Ma <boyu.mt@taobao.com>

As we have make the consense in the e-mail[1], the trim start should
be added with first_data_block. So this patch fulfill it and remove
the check for start < first_data_block.

[1] http://www.spinics.net/lists/linux-ext4/msg22737.html

Cc: Jan Kara <jack@suse.cz>
Cc: Lukas Czerner <lczerner@redhat.com>
Signed-off-by: Tao Ma <boyu.mt@taobao.com>
---
 fs/ext3/balloc.c |    7 ++-----
 1 files changed, 2 insertions(+), 5 deletions(-)

diff --git a/fs/ext3/balloc.c b/fs/ext3/balloc.c
index 971e1bd..13bfebe 100644
--- a/fs/ext3/balloc.c
+++ b/fs/ext3/balloc.c
@@ -2091,7 +2091,8 @@ int ext3_trim_fs(struct super_block *sb, struct fstrim_range *range)
 	ext3_fsblk_t max_blks = le32_to_cpu(es->s_blocks_count);
 	int ret = 0;
 
-	start = range->start >> sb->s_blocksize_bits;
+	start = (range->start >> sb->s_blocksize_bits) +
+		le32_to_cpu(es->s_first_data_block);
 	len = range->len >> sb->s_blocksize_bits;
 	minlen = range->minlen >> sb->s_blocksize_bits;
 	trimmed = 0;
@@ -2100,10 +2101,6 @@ int ext3_trim_fs(struct super_block *sb, struct fstrim_range *range)
 		return -EINVAL;
 	if (start >= max_blks)
 		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 + len > max_blks)
 		len = max_blks - start;
 
-- 
1.6.3.GIT

Re: [PATCH v2] ext3: Adjust trim start with first_data_block.

[Lukas Czerner]

On Fri, 21 Jan 2011, Tao Ma wrote:

> From: Tao Ma <boyu.mt@taobao.com>
> 
> As we have make the consense in the e-mail[1], the trim start should
> be added with first_data_block. So this patch fulfill it and remove
> the check for start < first_data_block.
> 
> [1] http://www.spinics.net/lists/linux-ext4/msg22737.html
> 
> Cc: Jan Kara <jack@suse.cz>
> Cc: Lukas Czerner <lczerner@redhat.com>
> Signed-off-by: Tao Ma <boyu.mt@taobao.com>
> ---
>  fs/ext3/balloc.c |    7 ++-----
>  1 files changed, 2 insertions(+), 5 deletions(-)
> 
> diff --git a/fs/ext3/balloc.c b/fs/ext3/balloc.c
> index 971e1bd..13bfebe 100644
> --- a/fs/ext3/balloc.c
> +++ b/fs/ext3/balloc.c
> @@ -2091,7 +2091,8 @@ int ext3_trim_fs(struct super_block *sb, struct fstrim_range *range)
>  	ext3_fsblk_t max_blks = le32_to_cpu(es->s_blocks_count);
>  	int ret = 0;
>  
> -	start = range->start >> sb->s_blocksize_bits;
> +	start = (range->start >> sb->s_blocksize_bits) +
> +		le32_to_cpu(es->s_first_data_block);
>  	len = range->len >> sb->s_blocksize_bits;
>  	minlen = range->minlen >> sb->s_blocksize_bits;
>  	trimmed = 0;
> @@ -2100,10 +2101,6 @@ int ext3_trim_fs(struct super_block *sb, struct fstrim_range *range)
>  		return -EINVAL;
>  	if (start >= max_blks)
>  		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 + len > max_blks)
>  		len = max_blks - start;
>  
> 

Hi,

Thanks for this patch, I was going to do this, but I am quite busy right
now. Can you do it for ext4 as well ?

Thanks!
-Lukas

Re: [PATCH v2] ext3: Adjust trim start with first_data_block.

[Tao Ma]

On 01/21/2011 06:36 PM, Lukas Czerner wrote:
> On Fri, 21 Jan 2011, Tao Ma wrote:
>
>> From: Tao Ma<boyu.mt@taobao.com>
>>
>> As we have make the consense in the e-mail[1], the trim start should
>> be added with first_data_block. So this patch fulfill it and remove
>> the check for start<  first_data_block.
>>
>> [1] http://www.spinics.net/lists/linux-ext4/msg22737.html
>>
>> Cc: Jan Kara<jack@suse.cz>
>> Cc: Lukas Czerner<lczerner@redhat.com>
>> Signed-off-by: Tao Ma<boyu.mt@taobao.com>
>> ---
>>   fs/ext3/balloc.c |    7 ++-----
>>   1 files changed, 2 insertions(+), 5 deletions(-)
>>
>> diff --git a/fs/ext3/balloc.c b/fs/ext3/balloc.c
>> index 971e1bd..13bfebe 100644
>> --- a/fs/ext3/balloc.c
>> +++ b/fs/ext3/balloc.c
>> @@ -2091,7 +2091,8 @@ int ext3_trim_fs(struct super_block *sb, struct fstrim_range *range)
>>   	ext3_fsblk_t max_blks = le32_to_cpu(es->s_blocks_count);
>>   	int ret = 0;
>>
>> -	start = range->start>>  sb->s_blocksize_bits;
>> +	start = (range->start>>  sb->s_blocksize_bits) +
>> +		le32_to_cpu(es->s_first_data_block);
>>   	len = range->len>>  sb->s_blocksize_bits;
>>   	minlen = range->minlen>>  sb->s_blocksize_bits;
>>   	trimmed = 0;
>> @@ -2100,10 +2101,6 @@ int ext3_trim_fs(struct super_block *sb, struct fstrim_range *range)
>>   		return -EINVAL;
>>   	if (start>= max_blks)
>>   		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 + len>  max_blks)
>>   		len = max_blks - start;
>>
>>
> Hi,
>
> Thanks for this patch, I was going to do this, but I am quite busy right
> now. Can you do it for ext4 as well ?
yes, I will send another patch for ext4.

Regards,
Tao

Re: [PATCH v2] ext3: Adjust trim start with first_data_block.

[Jan Kara]

On Fri 21-01-11 10:52:56, Tao Ma wrote:
> From: Tao Ma <boyu.mt@taobao.com>
> 
> As we have make the consense in the e-mail[1], the trim start should
> be added with first_data_block. So this patch fulfill it and remove
> the check for start < first_data_block.
> 
> [1] http://www.spinics.net/lists/linux-ext4/msg22737.html
  Thanks. Merged.

								Honza
> 
> Cc: Jan Kara <jack@suse.cz>
> Cc: Lukas Czerner <lczerner@redhat.com>
> Signed-off-by: Tao Ma <boyu.mt@taobao.com>
> ---
>  fs/ext3/balloc.c |    7 ++-----
>  1 files changed, 2 insertions(+), 5 deletions(-)
> 
> diff --git a/fs/ext3/balloc.c b/fs/ext3/balloc.c
> index 971e1bd..13bfebe 100644
> --- a/fs/ext3/balloc.c
> +++ b/fs/ext3/balloc.c
> @@ -2091,7 +2091,8 @@ int ext3_trim_fs(struct super_block *sb, struct fstrim_range *range)
>  	ext3_fsblk_t max_blks = le32_to_cpu(es->s_blocks_count);
>  	int ret = 0;
>  
> -	start = range->start >> sb->s_blocksize_bits;
> +	start = (range->start >> sb->s_blocksize_bits) +
> +		le32_to_cpu(es->s_first_data_block);
>  	len = range->len >> sb->s_blocksize_bits;
>  	minlen = range->minlen >> sb->s_blocksize_bits;
>  	trimmed = 0;
> @@ -2100,10 +2101,6 @@ int ext3_trim_fs(struct super_block *sb, struct fstrim_range *range)
>  		return -EINVAL;
>  	if (start >= max_blks)
>  		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 + len > max_blks)
>  		len = max_blks - start;
>  
> -- 
> 1.6.3.GIT
> 
-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR

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

[Tao Ma]

On 01/19/2011 06:42 PM, Lukas Czerner wrote:
> On Wed, 19 Jan 2011, Tao Ma wrote:
>
>> From: Tao Ma<boyu.mt@taobao.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.
It is hard to tell, anyway, it is just 1kb(in case bs=1k and 
first_data_block != 0), so I guess either is ok. ;)
> 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.
I am fine with it. And it should make the code more clear and easy to 
read I guess.

Regards,
Tao