From: Jan Harkes <jaharkes@cs.cmu.edu>
To: Al Viro <viro@ftp.linux.org.uk>
Cc: Christoph Hellwig <hch@lst.de>,
akpm@osdl.org, linux-fsdevel@vger.kernel.org
Subject: [PATCH] coda: file count cannot be used to discover last close
Date: Fri, 20 Jul 2007 00:10:00 -0400 [thread overview]
Message-ID: <20070720040959.GK8857@delft.aura.cs.cmu.edu> (raw)
In-Reply-To: <20070720031631.GC21668@ftp.linux.org.uk>
On Fri, Jul 20, 2007 at 04:16:31AM +0100, Al Viro wrote:
> On Fri, Jul 20, 2007 at 12:36:01PM +1000, David Chinner wrote:
> > To the context that dropped the last reference. It can't be
> > reported to anything else....
>
> Oh, for fsck sake...
Here is a patch which removes the file_count test from coda_flush. This
avoids the race condition described by Al Viro where we may never see
the file_count drop to 0 in ->flush, in which case userspace is never
notified that a writeback should occur.
Signed-off-by: Jan Harkes <jaharkes@cs.cmu.edu>
---
Going from here I can fix the problem in several ways in userspace. The
current implementation would end up making useless snapshots as a result
of every close, and still leave us with lost updates in the the
write-after-close case, but that isn't any worse than what it is now.
Seeing every fops->flush does allow us to perform preliminary checks so
we can return errors for common issues and we can flag the file so that
the final release upcall (where we can no longer return errors) will
start the writeback.
Really the problem for me is that Coda's semantics (write on last close)
are not compatible with UNIX semantics, where writes may occur even
after the application has closed all fd's. This is quite similar to
having an open fd to a removed file, UNIX obviously doesn't return an
error or block the unlink if there is an active reference it just
detaches the inode from the namespace.
I will try to find a clean way to block the close syscall until fput
drops the last reference. However I realize that such an implementation
would not be acceptable for other file systems, and there are some
interesting unresolved details such as 'which close is going to be the
last close'.
diff --git a/fs/coda/file.c b/fs/coda/file.c
index 7594962..0a300dd 100644
--- a/fs/coda/file.c
+++ b/fs/coda/file.c
@@ -169,15 +169,10 @@ int coda_flush(struct file *coda_file, fl_owner_t id)
unsigned short coda_flags = coda_flags_to_cflags(flags);
struct coda_file_info *cfi;
struct inode *coda_inode;
- int err = 0, fcnt;
+ int err = 0;
lock_kernel();
- /* last close semantics */
- fcnt = file_count(coda_file);
- if (fcnt > 1)
- goto out;
-
/* No need to make an upcall when we have not made any modifications
* to the file */
if ((coda_file->f_flags & O_ACCMODE) == O_RDONLY)
@@ -246,7 +241,7 @@ int coda_release(struct inode *coda_inode, struct file *coda_file)
coda_file->private_data = NULL;
unlock_kernel();
- return err;
+ return 0; /* no point in returning err, VFS ignores returned value */
}
int coda_fsync(struct file *coda_file, struct dentry *coda_dentry, int datasync)
next prev parent reply other threads:[~2007-07-20 4:10 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-19 21:45 [PATCH] coda: kill file_count abuse Christoph Hellwig
2007-07-19 22:16 ` Jan Harkes
2007-07-20 0:45 ` David Chinner
2007-07-20 0:53 ` Al Viro
2007-07-20 2:36 ` David Chinner
2007-07-20 3:16 ` Al Viro
2007-07-20 4:10 ` Jan Harkes [this message]
2007-07-20 5:38 ` [PATCH] coda: file count cannot be used to discover last close Al Viro
2007-07-20 14:26 ` Jan Harkes
2007-07-20 6:03 ` [PATCH] coda: kill file_count abuse David Chinner
2007-07-20 2:40 ` Jan Harkes
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=20070720040959.GK8857@delft.aura.cs.cmu.edu \
--to=jaharkes@cs.cmu.edu \
--cc=akpm@osdl.org \
--cc=hch@lst.de \
--cc=linux-fsdevel@vger.kernel.org \
--cc=viro@ftp.linux.org.uk \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).