From: Theodore Ts'o <tytso@mit.edu>
To: Eric Sandeen <sandeen@redhat.com>
Cc: Ext4 Developers List <linux-ext4@vger.kernel.org>
Subject: Re: [PATCH 1/4] resize2fs: fix 32-bit overflow issue which can corrupt 64-bit file systems
Date: Thu, 3 Jan 2013 12:16:35 -0500 [thread overview]
Message-ID: <20130103171635.GA3089@thunk.org> (raw)
In-Reply-To: <50E5AA43.2080200@redhat.com>
On Thu, Jan 03, 2013 at 09:56:51AM -0600, Eric Sandeen wrote:
>
> Yikes - seems like there are quite a few places where we need to
> audit this kind of thing
Fortunately a bunch of these only apply for 32-bit resizing (i..e,
involving the resize_inode or the 32-bit resize iocl). The goal_blk
calculations just mean that we will be using a non-optimal block
number, which we should fix, but it's not catastrophic.
The check_block_uninit() function in lib/ext2fs/alloc.c could
defintely cause a problem if someone were to use the library to write
into a 64-bit file system via FUSE, e2tools, or debugfs, but it's
unlikely to cause a problem for mke2fs or e2fsck. (It could
potentially cause a problem if e2fsck needed to freshly allocate some
new blocks for e.g., a missing lost+found directory, or during pass1b
processing and it allocates for the first time into an block group
with BLOCK_UNINIT, but it's not a high probability bug.)
Regardless of how likely they are, I agree absolutely that we should
audit and fix all of these problems.
- Ted
next prev parent reply other threads:[~2013-01-03 17:16 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-03 14:13 [PATCH 1/4] resize2fs: fix 32-bit overflow issue which can corrupt 64-bit file systems Theodore Ts'o
2013-01-03 14:13 ` [PATCH 2/4] resize2fs: fix 32-bit overflow when calculating the number of free blocks Theodore Ts'o
2013-01-03 14:13 ` [PATCH 3/4] resize2fs: add resource tracking as a debug option Theodore Ts'o
2013-01-03 14:13 ` [PATCH 4/4] resize2fs: use [un]mark_block_range bitmap functions to reduce CPU usage Theodore Ts'o
2013-01-03 15:56 ` [PATCH 1/4] resize2fs: fix 32-bit overflow issue which can corrupt 64-bit file systems Eric Sandeen
2013-01-03 17:16 ` Theodore Ts'o [this message]
2013-01-03 18:57 ` [PATCH] Fix 32-bit overflow problems: dgrp_t * s_blocks_per_group Theodore Ts'o
2013-01-04 17:21 ` Eric Sandeen
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=20130103171635.GA3089@thunk.org \
--to=tytso@mit.edu \
--cc=linux-ext4@vger.kernel.org \
--cc=sandeen@redhat.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.