All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: viro@ZenIV.linux.org.uk, akpm@linux-foundation.org
Cc: linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH, RFC] prune back iprune_sem
Date: Tue, 15 Feb 2011 11:29:16 +0100	[thread overview]
Message-ID: <20110215102916.GA959@lst.de> (raw)
In-Reply-To: <20101102184536.GA22941@lst.de>

ping?

On Tue, Nov 02, 2010 at 07:45:36PM +0100, Christoph Hellwig wrote:
> iprune_sem is continously giving us lockdep warnings because we do take it in
> read mode in the reclaim path, but we're also doing non-NOFS allocations under
> it taken in write mode.
> 
> Taking a bit deeper look at it I think it's fixable quite trivially:
> 
>  - for invalidate_inodes we do not need iprune_sem at all.  We have an active
>    reference on the superblock, so the filesystem is not going away until it
>    has finished.
>  - for evict_inodes we do need it, to make sure prune_icache has done it's
>    work before we tear down the superblock.  But there is no reason to
>    hold it over the actual reclaim operation - it's enough to cycle through
>    it after the actual reclaim to make sure we wait for any pending
>    prune_icache to complete.
> 
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> 
> diff --git a/fs/inode.c b/fs/inode.c
> index ae2727a..cfa7722 100644
> --- a/fs/inode.c
> +++ b/fs/inode.c
> @@ -492,8 +492,6 @@ void evict_inodes(struct super_block *sb)
>  	struct inode *inode, *next;
>  	LIST_HEAD(dispose);
>  
> -	down_write(&iprune_sem);
> -
>  	spin_lock(&inode_lock);
>  	list_for_each_entry_safe(inode, next, &sb->s_inodes, i_sb_list) {
>  		if (atomic_read(&inode->i_count))
> @@ -518,6 +516,13 @@ void evict_inodes(struct super_block *sb)
>  	spin_unlock(&inode_lock);
>  
>  	dispose_list(&dispose);
> +
> +	/*
> +	 * Cycle through iprune_sem to make sure any inode that prune_icache
> +	 * moved off the list before we took the lock has been fully torn
> +	 * down.
> +	 */
> +	down_write(&iprune_sem);
>  	up_write(&iprune_sem);
>  }
>  
> @@ -534,8 +539,6 @@ int invalidate_inodes(struct super_block *sb)
>  	struct inode *inode, *next;
>  	LIST_HEAD(dispose);
>  
> -	down_write(&iprune_sem);
> -
>  	spin_lock(&inode_lock);
>  	list_for_each_entry_safe(inode, next, &sb->s_inodes, i_sb_list) {
>  		if (inode->i_state & (I_NEW | I_FREEING | I_WILL_FREE))
> @@ -559,7 +562,6 @@ int invalidate_inodes(struct super_block *sb)
>  	spin_unlock(&inode_lock);
>  
>  	dispose_list(&dispose);
> -	up_write(&iprune_sem);
>  
>  	return busy;
>  }
---end quoted text---

  parent reply	other threads:[~2011-02-15 10:29 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-02 18:45 [PATCH, RFC] prune back iprune_sem Christoph Hellwig
2010-11-04 23:32 ` Jan Kara
2011-02-15 10:29 ` Christoph Hellwig [this message]
2011-02-15 14:49   ` Jan Kara
2011-02-15 14:53     ` Christoph Hellwig

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=20110215102916.GA959@lst.de \
    --to=hch@lst.de \
    --cc=akpm@linux-foundation.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.