mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Nathan Scott <nathans@sgi.com>
To: Masayuki Saito <m-saito@tnes.nec.co.jp>
Cc: David Chinner <dgc@sgi.com>,
	xfs@oss.sgi.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] xfs: i_state of inode is changed after the inode is freed
Date: Mon, 10 Jul 2006 10:37:40 +1000	[thread overview]
Message-ID: <20060710103740.B1674239@wobbly.melbourne.sgi.com> (raw)
In-Reply-To: <20060707214131m-saito@mail.aom.tnes.nec.co.jp>; from m-saito@tnes.nec.co.jp on Fri, Jul 07, 2006 at 09:41:31PM +0900

On Fri, Jul 07, 2006 at 09:41:31PM +0900, Masayuki Saito wrote:
> Thank you for comments.
> 
> >You'd be talking about xfs_iunpin(), wouldn't you ;)
> Yes, of course.
> 
> >http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=714250879ea61cdb1a39bb96fe9d934ee0c669a2
> >
> >This fixed the reproducable test case I had for the problem.
> >Can you see if it fixes your problem as well?
> We applied the above TAKE to linux-2.6.17.1 and tested it.
> However, we confirm the case that i_state of the inode was changed
> when the inode was freed in xfs filesystem.
> 
> We think that the TAKE reduces the occurrence only.
> And we think that our patch fixes the problem.
> 
> Could you review our patch again?

I'll leave it to Dave to comment more later (he's travelling at the
moment), since he's had his head deep in this area of the code most
recently - but my first thoughts on your patch are that its solving
the problem incorrectly.  We should not be in the destroy_inode code
if the inode reference counting is correct everywhere - I would have
expected the fix to be a get/put style change, rather than adding an
inode lock and new lock/unlock semantics around an individual field;
... and if that cannot be done to fix this (eh?), then some comments
as to why refcounting didn't solve the problem here.

cheers.

-- 
Nathan

  reply	other threads:[~2006-07-10  0:38 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-07-04 12:52 Masayuki Saito
2006-07-04 20:41 ` David Chinner
2006-07-07 12:41   ` Masayuki Saito
2006-07-10  0:37     ` Nathan Scott [this message]
2006-07-14 10:25       ` Masayuki Saito
2006-07-17 11:05         ` Nathan Scott
2006-07-17 14:07           ` David Chinner
2006-07-24  8:01             ` Masayuki Saito
2006-08-14  2:59               ` David Chinner
2006-08-22  7:48                 ` Masayuki Saito

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=20060710103740.B1674239@wobbly.melbourne.sgi.com \
    --to=nathans@sgi.com \
    --cc=dgc@sgi.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=m-saito@tnes.nec.co.jp \
    --cc=xfs@oss.sgi.com \
    /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

all inboxes | Powered by JetHome®