linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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.


  reply	other threads:[~2009-12-10  2:12 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 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).