From mboxrd@z Thu Jan  1 00:00:00 1970
From: Christoph Hellwig <hch@infradead.org>
Subject: Re: [PATCH 04/17] fs: icache lock i_state
Date: Fri, 1 Oct 2010 01:54:33 -0400
Message-ID: <20101001055433.GC32349@infradead.org>
References: <1285762729-17928-1-git-send-email-david@fromorbit.com>
 <1285762729-17928-5-git-send-email-david@fromorbit.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
To: Dave Chinner <david@fromorbit.com>
Return-path: <linux-fsdevel-owner@vger.kernel.org>
Received: from bombadil.infradead.org ([18.85.46.34]:46646 "EHLO
	bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1750864Ab0JAFye (ORCPT
	<rfc822;linux-fsdevel@vger.kernel.org>);
	Fri, 1 Oct 2010 01:54:34 -0400
Content-Disposition: inline
In-Reply-To: <1285762729-17928-5-git-send-email-david@fromorbit.com>
Sender: linux-fsdevel-owner@vger.kernel.org
List-ID: <linux-fsdevel.vger.kernel.org>

> +		spin_lock(&inode->i_lock);
> +		if (inode->i_state & (I_FREEING|I_WILL_FREE|I_NEW)
> +				|| inode->i_mapping->nrpages == 0) {


This is some pretty strange formatting.

		if ((inode->i_state & (I_FREEING|I_WILL_FREE|I_NEW)) ||
		    inode->i_mapping->nrpages == 0) {

would be more standard.

>  	list_for_each_entry(inode, &sb->s_inodes, i_sb_list) {
>  		struct address_space *mapping;
>  
> -		if (inode->i_state & (I_FREEING|I_WILL_FREE|I_NEW))
> -			continue;
>  		mapping = inode->i_mapping;
>  		if (mapping->nrpages == 0)
>  			continue;
> +		spin_lock(&inode->i_lock);
> +		if (inode->i_state & (I_FREEING|I_WILL_FREE|I_NEW)) {
> +			spin_unlock(&inode->i_lock);
> +			continue;
> +		}

Can we access the mapping safely when the inode isn't actually fully
setup?  Even if we can I'd rather not introduce this change hidden
inside an unrelated patch.