All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tao Ma <tm@tao.ma>
To: Lukas Czerner <lczerner@redhat.com>
Cc: linux-ext4@vger.kernel.org, Theodore Ts'o <tytso@mit.edu>
Subject: Re: [PATCH] ext4: Fix a BUG in mb_mark_used during trim.
Date: Thu, 03 Mar 2011 18:13:06 +0800	[thread overview]
Message-ID: <4D6F69B2.3060408@tao.ma> (raw)
In-Reply-To: <alpine.LFD.2.00.1103031053380.8737@dhcp-27-109.brq.redhat.com>

On 03/03/2011 06:01 PM, Lukas Czerner wrote:
> On Thu, 3 Mar 2011, Tao Ma wrote:
>
>    
>> From: Tao Ma<boyu.mt@taobao.com>
>>
>> In a bs=4096 volume, if we call FITRIM with the following parameter as
>> fstrim_range(start = 102400, len = 134144000, minlen = 10240),
>> we will trigger a BUG_ON.
>> BUG_ON(start + len>  (e4b->bd_sb->s_blocksize<<  3));
>>
>> Mar  4 00:55:52 boyu-tm kernel: ------------[ cut here ]------------
>> Mar  4 00:55:52 boyu-tm kernel: kernel BUG at fs/ext4/mballoc.c:1506!
>> Mar  4 01:21:09 boyu-tm kernel: Code: d4 00 00 00 00 49 89 fe 8b 56 0c 44 8b 7e 04 89 55 c4 48 8b 4f 28 89 d6 44 01 fe 48 63 d6 48 8b 41 18 48 c1 e0 03 48 39 c2 76 04<0f>  0b eb fe 48 8b 55 b0 8b 47 34 3b 42 08 74 04 0f 0b eb fe 48
>> Mar  4 01:21:09 boyu-tm kernel: RIP  [<ffffffffa053eb42>] mb_mark_used+0x47/0x26c [ext4]
>> Mar  4 01:21:09 boyu-tm kernel:  RSP<ffff880121e45c38>
>> Mar  4 01:21:09 boyu-tm kernel: ---[ end trace 9f461696f6a9dcf2 ]---
>>
>> The reason is that in ext4_trim_fs, the last_block is checked wrongly.
>> if (len>= EXT4_BLOCKS_PER_GROUP(sb))
>> 	len -= (EXT4_BLOCKS_PER_GROUP(sb) - first_block);
>> else
>> 	last_block = first_block + len;
>>
>> So if len<  EXT4_BLOCKS_PER_GROUP while first_block + len>  EXT4_BLOCKS_PER_GROUP,
>> last_block will be set to a overflow value which exceeds EXT4_BLOCKS_PER_GROUP.
>>
>> This patch fixes it and adjusts len accordingly.
>>      
> Oh, thanks for spotting this. One comment though.
>
>    
>> Cc: "Theodore Ts'o"<tytso@mit.edu>
>> Signed-off-by: Tao Ma<boyu.mt@taobao.com>
>> ---
>>   fs/ext4/mballoc.c |    5 +++--
>>   1 files changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c
>> index 29d7d17..ed63c3e 100644
>> --- a/fs/ext4/mballoc.c
>> +++ b/fs/ext4/mballoc.c
>> @@ -4889,10 +4889,11 @@ int ext4_trim_fs(struct super_block *sb, struct fstrim_range *range)
>>   			break;
>>   		}
>>
>> -		if (len>= EXT4_BLOCKS_PER_GROUP(sb))
>> -			len -= (EXT4_BLOCKS_PER_GROUP(sb) - first_block);
>> +		if (first_block + len>= EXT4_BLOCKS_PER_GROUP(sb))
>> +			last_block = EXT4_BLOCKS_PER_GROUP(sb);
>>   		else
>>   			last_block = first_block + len;
>>      
> Since last_block would not change until the last group, can we simplify
> the condition ?
>
> 		if (first_block + len<  EXT4_BLOCKS_PER_GROUP(sb))
> 			last_block = first_block + len;
>    
yes, it should work. But it is a bit tricky. And I guess we need a 
comment here
to describe the situation. Otherwise, the people who read the code would 
consider
why last_block won't be reset in case first _block + len >= 
EXT4_BLOCKS_PER_GROUP
every time. Agree?
>    
>> +		len -= last_block - first_block;
>>
>>   		if (e4b.bd_info->bb_free>= minlen) {
>>   			cnt = ext4_trim_all_free(sb,&e4b, first_block,
>>
>>      
> Thanks!
> -Lukas
>    
Regards,
Tao

  reply	other threads:[~2011-03-03 10:13 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-03  9:33 [PATCH] ext4: Fix a BUG in mb_mark_used during trim Tao Ma
2011-03-03 10:01 ` Lukas Czerner
2011-03-03 10:13   ` Tao Ma [this message]
2011-03-03 10:17     ` Lukas Czerner
2011-03-03 13:59       ` [PATCH v2] " Tao Ma
2011-03-03 14:20         ` Lukas Czerner
     [not found]         ` <20110303141109.GB16191@infradead.org>
2011-03-03 15:33           ` Tao Ma
2011-03-03 15:38             ` Christoph Hellwig
2011-03-16 15:20         ` [PATCH v2] ext4: Fix a kernel panic " Tao Ma
2011-03-23 19:47         ` [PATCH v2] ext4: Fix a BUG " Ted Ts'o

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=4D6F69B2.3060408@tao.ma \
    --to=tm@tao.ma \
    --cc=lczerner@redhat.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=tytso@mit.edu \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.