From: Tao Ma <tm@tao.ma>
To: linux-ext4@vger.kernel.org
Cc: Jan Kara <jack@suse.cz>, Lukas Czerner <lczerner@redhat.com>
Subject: [PATCH] ext3: fix trim length underflow with small trim length.
Date: Wed, 19 Jan 2011 17:49:10 +0800 [thread overview]
Message-ID: <1295430550-8978-1-git-send-email-tm@tao.ma> (raw)
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
next reply other threads:[~2011-01-19 9:49 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-19 9:49 Tao Ma [this message]
2011-01-19 10:42 ` [PATCH] ext3: fix trim length underflow with small trim length Lukas Czerner
2011-01-19 11:39 ` Jan Kara
2011-01-21 2:52 ` [PATCH v2] ext3: Adjust trim start with first_data_block Tao Ma
2011-01-21 10:36 ` Lukas Czerner
2011-01-21 13:59 ` Tao Ma
2011-01-21 15:00 ` Jan Kara
2011-01-19 13:50 ` [PATCH] ext3: fix trim length underflow with small trim length Tao Ma
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=1295430550-8978-1-git-send-email-tm@tao.ma \
--to=tm@tao.ma \
--cc=jack@suse.cz \
--cc=lczerner@redhat.com \
--cc=linux-ext4@vger.kernel.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).