From: Eric Sandeen <sandeen@redhat.com>
To: Theodore Tso <tytso@mit.edu>
Cc: ext4 development <linux-ext4@vger.kernel.org>
Subject: Re: [PATCH] resize2fs: fix ENOSPC corruption case
Date: Wed, 20 May 2009 10:57:05 -0500 [thread overview]
Message-ID: <4A142851.6000807@redhat.com> (raw)
In-Reply-To: <20090520113748.GC24836@mit.edu>
Theodore Tso wrote:
> On Mon, May 18, 2009 at 04:30:29PM -0500, Eric Sandeen wrote:
>> Index: e2fsprogs/lib/ext2fs/extent.c
>> ===================================================================
>> --- e2fsprogs.orig/lib/ext2fs/extent.c
>> +++ e2fsprogs/lib/ext2fs/extent.c
>> @@ -1068,16 +1068,17 @@ errcode_t ext2fs_extent_insert(ext2_exte
>>
>> retval = ext2fs_extent_replace(handle, 0, extent);
>> if (retval)
>> - goto errout;
>> + goto errout_delete;
>>
>> retval = update_path(handle);
>> if (retval)
>> - goto errout;
>> + goto errout_delete;
>>
>> return 0;
>>
>> -errout:
>> +errout_delete:
>> ext2fs_extent_delete(handle, 0);
>> +errout:
>> return retval;
>> }
>
>
> Instead adding an errout_delete and changing what errout means, why
> not just change:
>
> retval = extent_node_split(handle);
> if (retval)
> - goto errout;
> + return retval;
> path = handle->path + handle->level;
I guess there are other earlier direct returns, so sure, that'd be fine.
> I also took a quick scan of extent_node_split(), and I'm not 100%
> convinced it handles all of its error cases sanely. But that should
> be the focus of a different patch....
yeah, it probably needs more careful inspection. Who wrote that thing
anyway ... ;)
>
>> @@ -1239,16 +1240,17 @@ again:
>> #ifdef DEBUG
>> printf("(re/un)mapping last block in extent\n");
>> #endif
>> - extent.e_len--;
>> - retval = ext2fs_extent_replace(handle, 0, &extent);
>> - if (retval)
>> - goto done;
>> + /* Make sure insert works before replacing old extent */
>> if (physical) {
>> retval = ext2fs_extent_insert(handle,
>> EXT2_EXTENT_INSERT_AFTER, &newextent);
>> if (retval)
>> goto done;
>> }
>> + extent.e_len--;
>> + retval = ext2fs_extent_replace(handle, 0, &extent);
>> + if (retval)
>> + goto done;
>> } else if (logical == extent.e_lblk) {
>
> Have you tested this by hand, using the tst_extents test progam?
No, but I should.
> Code
> inspection says that ext2fs_extent_insert leaves extent handle
> pointing at the same place, but I admit the semantics need to be
> better documented and tested to make sure they are correct in all
> situations. The extent code is new enough and tricky enough that I'm
> always cautious about changes to it.
yep, this likely needs more work to document the semantics, make sure
they're consistent, and check all those error cases.
For F11 I will likely put in the later 2 patches, to fix up the minimum
size reporting and then enforce that as the minimum size, so we
shouldn't(tm) get into these error paths. Seems like the safer
last-minute change.
-Eric
> Looks good, though.
>
> - Ted
next prev parent reply other threads:[~2009-05-20 15:57 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-18 21:30 [PATCH] resize2fs: fix ENOSPC corruption case Eric Sandeen
2009-05-18 21:35 ` Eric Sandeen
2009-05-20 11:37 ` Theodore Tso
2009-05-20 15:57 ` Eric Sandeen [this message]
2009-05-20 20:58 ` Theodore Tso
2009-05-20 21:36 ` [PATCH V2] " Eric Sandeen
2009-05-26 2:38 ` Theodore Tso
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=4A142851.6000807@redhat.com \
--to=sandeen@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.