From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
To: Valerie Clement <valerie.clement@bull.net>
Cc: Mingming Cao <cmm@us.ibm.com>, linux-ext4 <linux-ext4@vger.kernel.org>
Subject: Re: [PATCH] Fix oops in mballoc caused by a variable overflow
Date: Thu, 17 Jan 2008 21:59:28 +0530 [thread overview]
Message-ID: <20080117162928.GC6667@skywalker> (raw)
In-Reply-To: <478F5395.9040203@bull.net>
[-- Attachment #1: Type: text/plain, Size: 1063 bytes --]
On Thu, Jan 17, 2008 at 02:09:41PM +0100, Valerie Clement wrote:
> Aneesh Kumar K.V wrote:
>> On Thu, Jan 17, 2008 at 10:43:40AM +0100, Valerie Clement wrote:
>>> Aneesh Kumar K.V wrote:
>>>> What about this ? I guess we will overflow start = start << bsbits;
>>>>
>>> Hi Aneesh,
>>> your patch below doesn't fix the issue, because as start_off is also
>>> loff_t, start_off = ac->ac_o_ex.fe_logical << bsbits also overflows.
>>>
>>
>> loff_t is 64 bits.
>>
>> typedef __kernel_loff_t loff_t;
>> typedef long long __kernel_loff_t;
>> typedef __u32 ext4_lblk_t;
>> typedef unsigned long long ext4_fsblk_t
>>
>> start_off = ac->ac_o_ex.fe_logical << bsbits;
>>
>> In the above line what we are storing in start_off is the offset in bytes.So it makes
>> sense to use the type loff_t. It is neither logical block nor physical block.
>
> Oh yes, sorry, you're right. I read too quickly.
>
> In fact, it's missing a cast :
> start_off = (loff_t) ac->ac_o_ex.fe_logical << bsbits;
>
> With that change, the test is ok.
Updated patch below.
-aneesh
[-- Attachment #2: overflow-fix.patch --]
[-- Type: text/x-diff, Size: 2739 bytes --]
ext4: Fix overflow in ext4_mb_normalize_request
From: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
kernel BUG at fs/ext4/mballoc.c:3148!
The BUG_ON is:
BUG_ON(size <= 0 || size >= EXT4_BLOCKS_PER_GROUP(ac->ac_sb));
where the value of "size" is 4293920768.
This is due to the overflow of the variable "start" in the
ext4_mb_normalize_request() function.
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
---
fs/ext4/mballoc.c | 24 +++++++++++-------------
1 files changed, 11 insertions(+), 13 deletions(-)
diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c
index d8cd81e..d16083c 100644
--- a/fs/ext4/mballoc.c
+++ b/fs/ext4/mballoc.c
@@ -2998,7 +2998,7 @@ static void ext4_mb_normalize_request(struct ext4_allocation_context *ac,
int bsbits, max;
ext4_lblk_t end;
struct list_head *cur;
- loff_t size, orig_size;
+ loff_t size, orig_size, start_off;
ext4_lblk_t start, orig_start;
struct ext4_inode_info *ei = EXT4_I(ac->ac_inode);
@@ -3039,7 +3039,7 @@ static void ext4_mb_normalize_request(struct ext4_allocation_context *ac,
/* first, try to predict filesize */
/* XXX: should this table be tunable? */
- start = 0;
+ start_off = 0;
if (size <= 16 * 1024) {
size = 16 * 1024;
} else if (size <= 32 * 1024) {
@@ -3055,26 +3055,24 @@ static void ext4_mb_normalize_request(struct ext4_allocation_context *ac,
} else if (size <= 1024 * 1024) {
size = 1024 * 1024;
} else if (NRL_CHECK_SIZE(size, 4 * 1024 * 1024, max, bsbits)) {
- start = ac->ac_o_ex.fe_logical << bsbits;
- start = (start / (1024 * 1024)) * (1024 * 1024);
+ start_off = ((loff_t)ac->ac_o_ex.fe_logical >>
+ (20 - bsbits)) << 20;
size = 1024 * 1024;
} else if (NRL_CHECK_SIZE(size, 8 * 1024 * 1024, max, bsbits)) {
- start = ac->ac_o_ex.fe_logical << bsbits;
- start = (start / (4 * (1024 * 1024))) * 4 * (1024 * 1024);
+ start_off = ((loff_t)ac->ac_o_ex.fe_logical >>
+ (22 - bsbits)) << 22;
size = 4 * 1024 * 1024;
} else if (NRL_CHECK_SIZE(ac->ac_o_ex.fe_len,
(8<<20)>>bsbits, max, bsbits)) {
- start = ac->ac_o_ex.fe_logical;
- start = start << bsbits;
- start = (start / (8 * (1024 * 1024))) * 8 * (1024 * 1024);
+ start_off = ((loff_t)ac->ac_o_ex.fe_logical >>
+ (23 - bsbits)) << 23;
size = 8 * 1024 * 1024;
} else {
- start = ac->ac_o_ex.fe_logical;
- start = start << bsbits;
- size = ac->ac_o_ex.fe_len << bsbits;
+ start_off = (loff_t)ac->ac_o_ex.fe_logical << bsbits;
+ size = ac->ac_o_ex.fe_len << bsbits;
}
orig_size = size = size >> bsbits;
- orig_start = start = start >> bsbits;
+ orig_start = start = start_off >> bsbits;
/* don't cover already allocated blocks in selected range */
if (ar->pleft && start <= ar->lleft) {
next prev parent reply other threads:[~2008-01-17 16:29 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-16 19:11 [PATCH] Fix oops in mballoc caused by a variable overflow Valerie Clement
2008-01-16 18:48 ` Mingming Cao
2008-01-17 6:47 ` Aneesh Kumar K.V
2008-01-17 9:43 ` Valerie Clement
2008-01-17 12:02 ` Aneesh Kumar K.V
2008-01-17 12:07 ` Aneesh Kumar K.V
2008-01-17 13:09 ` Valerie Clement
2008-01-17 16:29 ` Aneesh Kumar K.V [this message]
2008-01-17 20:07 ` Mingming Cao
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=20080117162928.GC6667@skywalker \
--to=aneesh.kumar@linux.vnet.ibm.com \
--cc=cmm@us.ibm.com \
--cc=linux-ext4@vger.kernel.org \
--cc=valerie.clement@bull.net \
/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