From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
To: Jan Kara <jack@suse.cz>
Cc: linux-ext4@vger.kernel.org, Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH] ext3: Avoid false EIO errors
Date: Fri, 27 Mar 2009 23:38:06 +0530 [thread overview]
Message-ID: <20090327180806.GB2810@skywalker> (raw)
In-Reply-To: <1238091711-23464-1-git-send-email-jack@suse.cz>
On Thu, Mar 26, 2009 at 07:21:51PM +0100, Jan Kara wrote:
> Sometimes block_write_begin() can map buffers in a page but later we fail to
> copy data into those buffers (because the source page has been paged out in the
> mean time). We then end up with !uptodate mapped buffers. To add a bit more to
> the confusion, block_write_end() does not commit any data (and thus does not
> any mark buffers as uptodate) if we didn't succeed with copying all the data.
>
> Commit f4fc66a894546bdc88a775d0e83ad20a65210bcb (ext3: convert to new aops)
> missed these cases and thus we were inserting non-uptodate buffers to
> transaction's list which confuses JBD code and it reports IO errors, aborts
> a transaction and generally makes users afraid about their data ;-P.
>
> This patch fixes the problem by reorganizing ext3_..._write_end() code to
> first call block_write_end() to mark buffers with valid data uptodate and
> after that we file only uptodate buffers to transaction's lists. Also
> fix a problem where we could leave blocks allocated beyond i_size (i_disksize
> in fact).
>
> Signed-off-by: Jan Kara <jack@suse.cz>
> ---
> fs/ext3/inode.c | 99 +++++++++++++++++++++++-------------------------------
> 1 files changed, 42 insertions(+), 57 deletions(-)
>
> As a side note, ext4 / JBD2 only needs the "proper i_disksize update"
> part of the fix (we got rid of special handling of ordered mode buffers
> there). But I have to first figure out how to properly do it...
> Andrew, would you please merge the patch? Thanks.
>
> Honza
>
> diff --git a/fs/ext3/inode.c b/fs/ext3/inode.c
> index 5fa453b..e230f7a 100644
> --- a/fs/ext3/inode.c
> +++ b/fs/ext3/inode.c
> @@ -1211,6 +1211,18 @@ int ext3_journal_dirty_data(handle_t *handle, struct buffer_head *bh)
> return err;
> }
>
> +/* For ordered writepage and write_end functions */
> +static int journal_dirty_data_fn(handle_t *handle, struct buffer_head *bh)
> +{
> + /*
> + * Write could have mapped the buffer but it didn't copy the data in
> + * yet. So avoid filing such buffer into a transaction.
> + */
> + if (buffer_mapped(bh) && buffer_uptodate(bh))
> + return ext3_journal_dirty_data(handle, bh);
> + return 0;
> +}
> +
> /* For write_end() in data=journal mode */
> static int write_end_fn(handle_t *handle, struct buffer_head *bh)
> {
> @@ -1221,26 +1233,29 @@ static int write_end_fn(handle_t *handle, struct buffer_head *bh)
> }
>
> /*
> - * Generic write_end handler for ordered and writeback ext3 journal modes.
> - * We can't use generic_write_end, because that unlocks the page and we need to
> - * unlock the page after ext3_journal_stop, but ext3_journal_stop must run
> - * after block_write_end.
> + * This is nasty and subtle: ext3_write_begin() could have allocated blocks
> + * for the whole page but later we failed to copy the data in. So the disk
> + * size we really have allocated is pos + len (block_write_end() has zeroed
> + * the freshly allocated buffers so we aren't going to write garbage). But we
> + * want to keep i_size at the place where data copying finished so that we
> + * don't confuse readers. The worst what can happen is that we expose a page
> + * of zeros at the end of file after a crash...
> */
> -static int ext3_generic_write_end(struct file *file,
> - struct address_space *mapping,
> - loff_t pos, unsigned len, unsigned copied,
> - struct page *page, void *fsdata)
> +static void update_file_sizes(struct inode *inode, loff_t pos, unsigned len,
> + unsigned copied)
> {
> - struct inode *inode = file->f_mapping->host;
> -
> - copied = block_write_end(file, mapping, pos, len, copied, page, fsdata);
> + int mark_dirty = 0;
>
> - if (pos+copied > inode->i_size) {
> - i_size_write(inode, pos+copied);
> - mark_inode_dirty(inode);
> + if (pos + len > EXT3_I(inode)->i_disksize) {
> + mark_dirty = 1;
> + EXT3_I(inode)->i_disksize = pos + len;
> }
Won't this result in file having wrong contents if we failed to copy
the contents from user space? Now if we successfully allocated
blocks and we failed to copy the contents from user space, the above
would result in update of i_disksize and a mark_inode_dirty. Doesn't
that imply we have wrong contents in those block for which we failed to
copy the contents from user space ?
> -
> - return copied;
> + if (pos + copied > inode->i_size) {
> + i_size_write(inode, pos + copied);
> + mark_dirty = 1;
> + }
> + if (mark_dirty)
> + mark_inode_dirty(inode);
> }
>
-aneesh
next prev parent reply other threads:[~2009-03-27 18:08 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-26 18:21 [PATCH] ext3: Avoid false EIO errors Jan Kara
2009-03-27 18:08 ` Aneesh Kumar K.V [this message]
2009-03-27 20:24 ` Jan Kara
2009-03-30 8:25 ` Aneesh Kumar K.V
2009-03-30 10:32 ` Jan Kara
2009-03-30 10:58 ` Aneesh Kumar K.V
2009-03-30 16:05 ` Jan Kara
2009-03-31 4:45 ` Aneesh Kumar K.V
2009-03-31 9:29 ` [PATCH 1/2] [PATCH] ext4: Add inode to the orphan list during block allocation failure Aneesh Kumar K.V
2009-03-31 9:29 ` [PATCH 2/2] [PATCH] ext4: truncate the file properly if we fail to copy data from userspace Aneesh Kumar K.V
2009-03-31 9:38 ` Jan Kara
2009-04-05 3:22 ` Theodore Tso
2009-04-06 10:07 ` Jan Kara
2009-03-31 9:34 ` [PATCH 1/2] [PATCH] ext4: Add inode to the orphan list during block allocation failure Jan Kara
2009-04-05 3:11 ` Theodore Tso
2009-04-06 10:05 ` Jan Kara
2009-06-05 4:31 ` Theodore Tso
2009-06-05 6:22 ` Theodore Tso
2009-06-05 7:24 ` Theodore Tso
2009-06-05 23:42 ` Jan Kara
2009-06-05 23:44 ` Jan Kara
2009-06-08 4:35 ` [PATCH -V2 1/2] " Aneesh Kumar K.V
2009-06-08 4:35 ` [PATCH -V2 2/2] ext4: truncate the file properly if we fail to copy data from userspace Aneesh Kumar K.V
2009-06-08 16:29 ` Theodore Tso
2009-06-08 16:43 ` Aneesh Kumar K.V
2009-06-08 19:14 ` Theodore Tso
2009-06-08 19:23 ` Jan Kara
2009-06-08 20:20 ` Aneesh Kumar K.V
2009-06-09 10:12 ` Jan Kara
2009-06-08 16:29 ` [PATCH -V2 1/2] ext4: Add inode to the orphan list during block allocation failure Theodore Tso
2009-03-31 9:46 ` [PATCH] ext3: Avoid false EIO errors (version 4) Jan Kara
2009-04-01 0:06 ` Andrew Morton
2009-04-01 9:49 ` Jan Kara
2009-03-30 13:53 ` [PATCH] ext3: Avoid false EIO errors Eric Sandeen
2009-03-30 14:45 ` Aneesh Kumar K.V
2009-03-30 15:12 ` 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=20090327180806.GB2810@skywalker \
--to=aneesh.kumar@linux.vnet.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=jack@suse.cz \
--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).