From mboxrd@z Thu Jan  1 00:00:00 1970
From: Steve French <smfltc@us.ibm.com>
Subject: Re: What trigge fsync of file on last close of the open inode?
Date: Tue, 03 Oct 2006 15:45:49 -0500
Message-ID: <4522CBFD.3010202@us.ibm.com>
References: <4522BFA8.9040000@us.ibm.com> <1159905941.18918.7.camel@kleikamp.austin.ibm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: linux-fsdevel@vger.kernel.org,
	Shirish S Pargaonkar <shirishp@us.ibm.com>
Return-path: <linux-fsdevel-owner@vger.kernel.org>
Received: from e5.ny.us.ibm.com ([32.97.182.145]:13703 "EHLO e5.ny.us.ibm.com")
	by vger.kernel.org with ESMTP id S1030379AbWJCUpB (ORCPT
	<rfc822;linux-fsdevel@vger.kernel.org>);
	Tue, 3 Oct 2006 16:45:01 -0400
Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234])
	by e5.ny.us.ibm.com (8.13.8/8.12.11) with ESMTP id k93Kj0Em032540
	for <linux-fsdevel@vger.kernel.org>; Tue, 3 Oct 2006 16:45:00 -0400
Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64])
	by d01relay02.pok.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id k93KiteJ250938
	for <linux-fsdevel@vger.kernel.org>; Tue, 3 Oct 2006 16:45:00 -0400
Received: from d01av04.pok.ibm.com (loopback [127.0.0.1])
	by d01av04.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id k93Kis1Y014268
	for <linux-fsdevel@vger.kernel.org>; Tue, 3 Oct 2006 16:44:55 -0400
To: Dave Kleikamp <shaggy@austin.ibm.com>
In-Reply-To: <1159905941.18918.7.camel@kleikamp.austin.ibm.com>
Sender: linux-fsdevel-owner@vger.kernel.org
List-Id: linux-fsdevel.vger.kernel.org

Dave Kleikamp wrote:
>> Someone had reported a problem with a writepages call coming in on with 
>> no open files (so presumably the file was closed, with dirty pages not 
>> written).
>>     
>
> This is normal behavior for most file systems.  I thought cifs protected
> this by flushing dirty data in cifs_close.  I don't think any data
> should be dirtied after cifs_close is called (on the last open file
> handle).
>   
I found it ...

cifs exports flush, filp_close calls flush (before calling close)

cifs_flush calls filemap_fdatawrite

May be a case in which filemap_fdatawrite returns before the write(s) is 
sent to the vfs and write races with close (although cifs will defer a 
file close if a write is pending on that handle)?