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: linux-fsdevel@vger.kernel.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	"Jorge Boncompte [DTI2]" <jorge@dti2.net>,
	Adrian Hunter <ext-adrian.hunter@nokia.com>,
	stable@kernel.org
Subject: Re: [patch] fs: avoid I_NEW inodes
Date: Wed, 11 Mar 2009 13:57:48 +0100	[thread overview]
Message-ID: <20090311125748.GA14144@wotan.suse.de> (raw)
In-Reply-To: <20090311122420.GB24590@duck.suse.cz>

On Wed, Mar 11, 2009 at 01:24:20PM +0100, Jan Kara wrote:
> On Wed 11-03-09 04:29:18, Nick Piggin wrote:
> > How about this?
>   Looks fine to me.

Thanks for the good review. Andrew, do you think you can apply this
on top of the previous patch? I'm undecided as to whether they should
go together or not. Probably the first one is a minimal fix that
doesn't alter behaviour as much, but things seem more robust after this
2nd patch. I think both would probably be suitable for 2.6.29, being a
nasty bug, but it isn't a recent regression AFAIKS.

> 
> > --
> > To be on the safe side, it should be less fragile to exclude I_NEW inodes
> > from inode list scans by default (unless there is an important reason to
> > have them).
> > 
> > Normally they will get excluded (eg. by zero refcount or writecount etc),
> > however it is a bit fragile for list walkers to know exactly what parts of
> > the inode state is set up and valid to test when in I_NEW. So along these
> > lines, move I_NEW checks upward as well (sometimes taking I_FREEING etc
> > checks with them too -- this shouldn't be a problem should it?)
> > 
> > Signed-off-by: Nick Piggin <npiggin@suse.de>
>   Acked-by: Jan Kara <jack@suse.cz>

  reply	other threads:[~2009-03-11 12:57 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-05  6:45 [patch] fs: new inode i_state corruption fix Nick Piggin
2009-03-05 10:00 ` Jan Kara
2009-03-05 10:16   ` Nick Piggin
2009-03-05 11:12     ` Jan Kara
2009-03-10 13:41       ` [patch] fs: avoid I_NEW inodes Nick Piggin
2009-03-10 16:03         ` Jan Kara
2009-03-11  2:34           ` Nick Piggin
2009-03-11 12:22             ` Jan Kara
2009-03-11  3:29           ` Nick Piggin
2009-03-11 12:24             ` Jan Kara
2009-03-11 12:57               ` Nick Piggin [this message]
2009-03-11 20:19                 ` Andrew Morton
2009-03-12  3:09                   ` Nick Piggin

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=20090311125748.GA14144@wotan.suse.de \
    --to=npiggin@suse.de \
    --cc=akpm@linux-foundation.org \
    --cc=ext-adrian.hunter@nokia.com \
    --cc=jack@suse.cz \
    --cc=jorge@dti2.net \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=stable@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).