From: Nick Piggin <npiggin@suse.de>
To: Jan Kara <jack@suse.cz>
Cc: Al Viro <viro@ZenIV.linux.org.uk>,
Christoph Hellwig <hch@infradead.org>,
linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org
Subject: Re: [patch 4/5] ext2: convert to use the new truncate convention
Date: Thu, 10 Dec 2009 12:11:03 +1100 [thread overview]
Message-ID: <20091210011103.GB9601@nick> (raw)
In-Reply-To: <20091209145713.GD7044@quack.suse.cz>
On Wed, Dec 09, 2009 at 03:57:13PM +0100, Jan Kara wrote:
> On Tue 08-12-09 09:42:09, Nick Piggin wrote:
> > I also have commented a possible bug in existing ext2 code, marked with XXX.
> >
> > Cc: linux-ext4@vger.kernel.org
> > Cc: Christoph Hellwig <hch@lst.de>
> > Signed-off-by: Nick Piggin <npiggin@suse.de>
> ...
> > @@ -752,8 +764,8 @@ int __ext2_write_begin(struct file *file
> > loff_t pos, unsigned len, unsigned flags,
> > struct page **pagep, void **fsdata)
> > {
> > - return block_write_begin(file, mapping, pos, len, flags, pagep, fsdata,
> > - ext2_get_block);
> > + return block_write_begin_newtrunc(file, mapping, pos, len, flags,
> > + pagep, fsdata, ext2_get_block);
> > }
> OK, but you should update the code in dir.c using __ext2_write_begin,
> shouldn't you?
To trim off blocks past i_size on failure? Yes I guess it should.
In fact, the ext2_write_failed call could just go into here I think.
I'll take a look.
> > +static int ext2_write_end(struct file *file, struct address_space *mapping,
> > + loff_t pos, unsigned len, unsigned copied,
> > + struct page *page, void *fsdata)
> > +{
> > + int ret;
> > +
> > + ret = generic_write_end(file, mapping, pos, len, copied, page, fsdata);
> > + if (ret < len)
> > + ext2_write_failed(mapping, pos + len);
> > + return ret;
> > }
> OK, when doing this, please also update ext2_commit_chunk in dir.c...
I think commit_chunk is OK. Because block_write_end does not fail
and the only reason for checking failure here is in case of a short
copy (which won't happen in dir.c code).
> > +static void ext2_truncate_blocks(struct inode *inode, loff_t offset)
> > +{
> > + /*
> > + * XXX: it seems like a bug here that we don't allow
> > + * IS_APPEND inode to have blocks-past-i_size trimmed off.
> > + * review and fix this.
> > + *
> > + * Also would be nice to be able to handle IO errors and such,
> > + * but that's probably too much to ask.
> > + */
> > + if (!(S_ISREG(inode->i_mode) || S_ISDIR(inode->i_mode) ||
> > + S_ISLNK(inode->i_mode)))
> > + return;
> > + if (ext2_inode_is_fast_symlink(inode))
> > + return;
> > + if (IS_APPEND(inode) || IS_IMMUTABLE(inode))
> > + return;
> Yes, I'd remove IS_APPEND check from here.
Didn't want to change that in this patch, but I'm happy for someone to
fix it (and in ext3/4 etc).
The checks probably should be done at a different level anyway: by the
time that this code gets called, the pagecache is truncated and i_size
modified anyway so it seems buggy if this made any difference.
next prev parent reply other threads:[~2009-12-10 1:11 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-08 8:38 [patch 1/5] fs: truncate introduce new sequence Nick Piggin
2009-12-08 8:39 ` [patch 2/5] fs: convert simple fs to new truncate Nick Piggin
2009-12-09 14:39 ` Jan Kara
2009-12-10 5:15 ` Nick Piggin
2009-12-10 8:44 ` Boaz Harrosh
2009-12-10 7:57 ` Nick Piggin
2009-12-08 8:41 ` [patch 3/5] tmpfs: convert to use the new truncate convention Nick Piggin
2009-12-09 14:45 ` Jan Kara
2009-12-10 0:48 ` Nick Piggin
2009-12-08 8:42 ` [patch 4/5] ext2: " Nick Piggin
2009-12-09 14:57 ` Jan Kara
2009-12-10 1:11 ` Nick Piggin [this message]
2009-12-10 10:20 ` Jan Kara
2009-12-08 8:43 ` [patch 5/5] fat: " Nick Piggin
2009-12-09 15:08 ` Jan Kara
2009-12-09 14:38 ` [patch 1/5] fs: truncate introduce new sequence Jan Kara
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=20091210011103.GB9601@nick \
--to=npiggin@suse.de \
--cc=hch@infradead.org \
--cc=jack@suse.cz \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=viro@ZenIV.linux.org.uk \
/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.