All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Mason <mason@suse.com>
To: Andrew Morton <akpm@osdl.org>
Cc: Andrea Arcangeli <andrea@suse.de>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] fix nr_unused accounting, and avoid recursing in iput with I_WILL_FREE set
Date: Tue, 18 Oct 2005 20:40:18 -0400	[thread overview]
Message-ID: <20051019004018.GZ1027@watt.suse.com> (raw)
In-Reply-To: <20051018171335.3b308b3e.akpm@osdl.org>

On Tue, Oct 18, 2005 at 05:13:35PM -0700, Andrew Morton wrote:
> Andrea Arcangeli <andrea@suse.de> wrote:
> >
> > Hello,
> > 
> > @@ -183,6 +183,7 @@ __sync_single_inode(struct inode *inode,
> >  			list_move(&inode->i_list, &inode_in_use);
> >  		} else {
> >  			list_move(&inode->i_list, &inode_unused);
> > +			inodes_stat.nr_unused++;
> >  		}
> >  	}
> >  	wake_up_inode(inode);
> > 
> > Are you sure the above diff is correct? It was added somewhere between
> > 2.6.5 and 2.6.8. I think it's wrong.
> > 
> > The only way I can imagine the i_count to be zero in the above path, is
> > that I_WILL_FREE is set. And if I_WILL_FREE is set, then we must not
> > increase nr_unused. So I believe the above change is buggy and it will
> > definitely overstate the number of unused inodes and it should be backed
> > out.
> 
> Well according to my assertion (below), the inode in __sync_single_inode()
> cannot have a zero refcount, so the whole if() statement is never executed.

generic_forget_inode->write_inode_now->__writeback_single_inode->
__sync_single_inode

We do have I_WILL_FREE, but i_count will be zero.

> 
> The thinking behind that increment is that __sync_single_inode() has just
> taken a dirty, zero-refcount inode and has cleaned it.  A dirty inode
> cannot have previously been on inode_unused, hence we now are newly moving
> it to inode_unused.

nr_unused doesn't seem to count the number of inodes on the unused list.
It is actually counting the number of inodes whose i_count is 0.  See
generic_forget_inode and invalidate_list to see what I mean.

generic_forget_inode took care of incrementing the unused count when
i_count went to zero. So, I don't think we need to worry about the
unused count in __writeback_single_inode.

-chris


  reply	other threads:[~2005-10-19  0:40 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-10-18  8:26 [PATCH] fix nr_unused accounting, and avoid recursing in iput with I_WILL_FREE set Andrea Arcangeli
2005-10-19  0:13 ` Andrew Morton
2005-10-19  0:40   ` Chris Mason [this message]
2005-10-19  1:15     ` Andrew Morton
2005-10-19  1:58       ` Chris Mason
2005-10-19  2:26         ` Andrew Morton
2005-10-19  2:58           ` Chris Mason
2005-10-25  2:21           ` Chris Mason
2005-10-25 14:14             ` Andrea Arcangeli
2005-10-19  7:47   ` Andrea Arcangeli

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=20051019004018.GZ1027@watt.suse.com \
    --to=mason@suse.com \
    --cc=akpm@osdl.org \
    --cc=andrea@suse.de \
    --cc=linux-kernel@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 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.