All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@redhat.com>
To: Xi Wang <xi.wang@gmail.com>
Cc: Haogang Chen <haogangchen@gmail.com>,
	Theodore Tso <tytso@mit.edu>,
	Andreas Dilger <adilger.kernel@dilger.ca>,
	linux-ext4@vger.kernel.org, linux-kernel@vger.kernel.org,
	Yongqiang Yang <xiaoqiangnk@gmail.com>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH] FS: ext4: fix integer overflow in alloc_flex_gd()
Date: Tue, 21 Feb 2012 10:36:53 -0600	[thread overview]
Message-ID: <4F43C825.1040501@redhat.com> (raw)
In-Reply-To: <0E72E3B2-DAA7-45F4-845D-AF4E76174A33@gmail.com>

On 02/21/2012 07:55 AM, Xi Wang wrote:
> On Feb 20, 2012, at 6:47 PM, Eric Sandeen wrote:
>> Hm this raises a few questions I think.
>>
>> On the one hand, making sure the kmalloc arg doesn't overflow here is
>> certainly a good thing and probably the right thing to do in the short term.
>>
>> So I guess:
>>
>> Reviewed-by: Eric Sandeen <sandeen@redhat.com>
>>
>> for that, to close the hole.
> 
> Another possibility is to wait for knalloc/kmalloc_array in the -mm
> tree, which is basically the non-zeroing version of kcalloc that
> performs overflow checking.
> 
>> Doesn't this also mean that a valid s_log_groups_per_flex (i.e. 31)
>> will fail in this resize code?  That would be an unexpected outcome.
>> 2^31 groups per flex is a little crazy, but still technically valid
>> according to the limits in the code.
> 
> Or we could limit s_log_groups_per_flex/groups_per_flex to a
> reasonable upper bound in ext4_fill_flex_info(), right?

Depends on the "flex_bg" design intent, I guess.

I don't know if the 2^31 was an intended design limit, or just a
mathematical limit that based on container sizes etc...

I'd have to look at the resize code more carefully but I can't imagine
that it's imperative to allocate this stuff all at once.

-Eric

> - xi
> 

  reply	other threads:[~2012-02-21 16:36 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-20 22:41 [PATCH] FS: ext4: fix integer overflow in alloc_flex_gd() Haogang Chen
2012-02-20 23:47 ` Eric Sandeen
2012-02-21 13:55   ` Xi Wang
2012-02-21 16:36     ` Eric Sandeen [this message]
2012-02-21 17:19       ` Andreas Dilger
2012-05-28 18:24 ` 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=4F43C825.1040501@redhat.com \
    --to=sandeen@redhat.com \
    --cc=adilger.kernel@dilger.ca \
    --cc=akpm@linux-foundation.org \
    --cc=haogangchen@gmail.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tytso@mit.edu \
    --cc=xi.wang@gmail.com \
    --cc=xiaoqiangnk@gmail.com \
    /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.