Date: Fri, 19 May 2006 11:46:09 -0700
From: Andrew Morton <akpm@osdl.org>
To: cel@citi.umich.edu
Cc: cel@netapp.com, linux-kernel@vger.kernel.org, trond.myklebust@fys.uio.no
Subject: Re: [PATCH 1/6] nfs: "open code" the NFS direct write rescheduler
Message-Id: <20060519114609.7b6d059d.akpm@osdl.org>
In-Reply-To: <446E104F.3060900@citi.umich.edu>
References: <20060519175652.3244.7079.stgit@brahms.dsl.sfldmi.ameritech.net>
	<20060519180020.3244.75979.stgit@brahms.dsl.sfldmi.ameritech.net>
	<20060519111054.1842ccfb.akpm@osdl.org>
	<446E104F.3060900@citi.umich.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1161
Lines: 37

Chuck Lever <cel@citi.umich.edu> wrote:
>
> Andrew Morton wrote:
> > Chuck Lever <cel@netapp.com> wrote:
> >> +	 * Prevent I/O completion while we're still rescheduling
> >> +	 */
> >> +	dreq->outstanding++;
> >> +
> > 
> > No locking.
> > 
> >>  	dreq->count = 0;
> >> +	list_for_each(pos, &dreq->rewrite_list) {
> >> +		struct nfs_write_data *data =
> >> +			list_entry(dreq->rewrite_list.next, struct nfs_write_data, pages);
> >> +
> >> +		spin_lock(&dreq->lock);
> >> +		dreq->outstanding++;
> >> +		spin_unlock(&dreq->lock);
> > 
> > Locking.
> > 
> > Deliberate?
> 
> Yes.  At the top of the loop, there is no outstanding I/O, so no locking 
> is needed while updating "outstanding."  Inside the loop, we've 
> dispatched some I/O against "dreq" so locking is needed to ensure 
> outstanding is updated properly.
> 

OK.  Well if I asked, then others will wonder about it.  A comment would
cure that problem ;)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/