All of lore.kernel.org
 help / color / mirror / Atom feed
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Dave Chinner <david@fromorbit.com>
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/8] fs: protect inode->i_state with inode->i_lock
Date: Fri, 29 Oct 2010 05:29:19 +0100	[thread overview]
Message-ID: <20101029042919.GM19804@ZenIV.linux.org.uk> (raw)
In-Reply-To: <1288322620-8566-2-git-send-email-david@fromorbit.com>

On Fri, Oct 29, 2010 at 02:23:33PM +1100, Dave Chinner wrote:
> @@ -293,9 +293,11 @@ static void inode_wait_for_writeback(struct inode *inode)
>  
>  	wqh = bit_waitqueue(&inode->i_state, __I_SYNC);
>  	 while (inode->i_state & I_SYNC) {
> +		spin_unlock(&inode->i_lock);

Minor annoyance, but...  Let's replace spaces with tab in that while.

> +		spin_unlock(&inode->i_lock);
> +
>  		pages_skipped = wbc->pages_skipped;
>  		writeback_single_inode(inode, wbc);

	Might make sense to lift locking i_lock into callers of
writeback_single_inode() (it has to grab the damn thing as soon as it's
called) and collapse it with spin_unlock() here.  Separate patch.

> +		spin_unlock(&inode->i_lock);
>  		/*
>  		 * If the inode was already on b_dirty/b_io/b_more_io, don't
>  		 * reposition it (that would break b_dirty time-ordering).

I'm not sure there's any point in dropping it here, actually.

> +	spin_lock(&inode->i_lock);
>  	inode->i_state = I_FREEING | I_CLEAR;
> +	spin_unlock(&inode->i_lock);

_Probably_ not needed here; we already had I_FREEING set by the time
we'd called that and no other thread will modify ->i_state of that
inode at that point.  Check for I_CLEAR will be later in the same
thread, so no barriers are needed.  Separate patch.

> @@ -552,8 +568,6 @@ int invalidate_inodes(struct super_block *sb)
>  		 */
>  		list_move(&inode->i_lru, &dispose);
>  		list_del_init(&inode->i_wb_list);
> -		if (!(inode->i_state & (I_DIRTY | I_SYNC)))
> -			percpu_counter_dec(&nr_inodes_unused);
>  	}
>  	spin_unlock(&inode_lock);

Ho-hum...

I'm not sure we need that list_del_init() here, actually, seeing that
I_FREEING is already set...  For later patch, anyway.

> @@ -917,10 +946,12 @@ static struct inode *get_new_inode_fast(struct super_block *sb,
>  		/* We released the lock, so.. */
>  		old = find_inode_fast(sb, head, ino);
>  		if (!old) {
> +			spin_lock(&inode->i_lock);
>  			inode->i_ino = ino;
> +			inode->i_state = I_NEW;
> +			spin_unlock(&inode->i_lock);

Almost certainly not needed; nobody can find this inode at that point.

> + * wake_up_bit(&inode->i_state, __I_NEW) after removing from the hash list
> + * will DTRT.

Add that i_lock is not regained.

  reply	other threads:[~2010-10-29  4:29 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-29  3:23 fs: break out inode operations from inode_lock V3 Dave Chinner
2010-10-29  3:23 ` [PATCH 1/8] fs: protect inode->i_state with inode->i_lock Dave Chinner
2010-10-29  4:29   ` Al Viro [this message]
2010-10-29  3:23 ` [PATCH 2/8] fs: factor inode disposal Dave Chinner
2010-10-29  4:45   ` Al Viro
2010-10-29  3:23 ` [PATCH 3/8] fs: Lock the inode LRU list separately Dave Chinner
2010-10-29  3:23 ` [PATCH 4/8] fs: remove inode_lock from iput_final and prune_icache Dave Chinner
2010-10-29  5:14   ` Al Viro
2010-10-29  3:23 ` [PATCH 5/8] fs: move i_sb_list out from under inode_lock Dave Chinner
2010-10-29  3:23 ` [PATCH 6/8] fs: move i_wb_list " Dave Chinner
2010-10-29  3:23 ` [PATCH 7/8] fs: rename inode_lock to inode_hash_lock Dave Chinner
2010-10-29  3:23 ` [PATCH 8/8] fs: Clean up documentation references to inode_lock Dave Chinner
2010-10-29  5:17   ` Al Viro
2010-10-29  7:46   ` Christoph Hellwig
  -- strict thread matches above, loose matches on Subject: below --
2010-10-29  8:59 fs: break out inode operations from inode_lock V4 Dave Chinner
2010-10-29  8:59 ` [PATCH 1/8] fs: protect inode->i_state with inode->i_lock Dave Chinner
2011-03-22 11:23 vfs: inode lock breakup Dave Chinner
2011-03-22 11:23 ` [PATCH 1/8] fs: protect inode->i_state with inode->i_lock Dave Chinner

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=20101029042919.GM19804@ZenIV.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=david@fromorbit.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --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.