Message-ID: <4A48E9EB.9080803@kernel.org>
Date: Tue, 30 Jun 2009 01:20:59 +0900
From: Tejun Heo <tj@kernel.org>
User-Agent: Thunderbird 2.0.0.19 (X11/20081227)
MIME-Version: 1.0
To: Miklos Szeredi <miklos@szeredi.hu>
CC: linux-kernel@vger.kernel.org, fuse-devel@lists.sourceforge.net,
       akpm@linux-foundation.org, npiggin@suse.de
Subject: Re: [PATCH 2/4] FUSE: make request_wait_answer() wait for ->end()
 completion
References: <1245317073-24000-1-git-send-email-tj@kernel.org> <1245317073-24000-3-git-send-email-tj@kernel.org> <E1MJPJX-0001NB-SG@pomaz-ex.szeredi.hu>
In-Reply-To: <E1MJPJX-0001NB-SG@pomaz-ex.szeredi.hu>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1522
Lines: 45

Hello, Miklos.

Miklos Szeredi wrote:
> On Thu, 18 Jun 2009, Tejun Heo wrote:
>> Previously, a request was marked FINISHED before ->end() is executed
>> and thus request_wait_answer() can return before it's done.  This
>> patch makes request_wait_answer() wait for ->end() to finish before
>> returning.
> 
> Why is this change needed?

Direct mmap implementation manages fds in the server process using the
end() callback.  After each command which needs to manipulate server
fds in some way, the end callback is responsible for doing it and
communicating what happened to the client side which is executing
fuse_file_direct_mmap(), so it needs to wait for end to complete
before proceeding.

>>  	spin_unlock(&fc->lock);
>> -	wake_up(&req->waitq);
>> -	if (end)
>> +
>> +	if (end) {
>>  		end(fc, req);
>> +		smp_wmb();
> 
> Why is this barrier needed?

To separate the changes end() made from setting FUSE_REQ_FINISHED.
The corresponding wait is in wait_answer_interruptible() and the
corresponding barrier is rmb() implied by spin_lock(&fc->lock) in that
function.  ie. the barrier makes sure that when
wait_event_interruptible() exits the waiting state because state
equals FUSE_REQ_FINISHED, the caller is guaranteed to see the changes
made by end().

Thanks.

-- 
tejun
--
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/