From: Andrew Morton <akpm@linux-foundation.org>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [patch 09/12] fuse: add list of writable files to fuse_inode
Date: Thu, 4 Oct 2007 15:51:28 -0700 [thread overview]
Message-ID: <20071004155128.62fc1098.akpm@linux-foundation.org> (raw)
In-Reply-To: <20071002155222.373341208@szeredi.hu>
On Tue, 02 Oct 2007 17:50:35 +0200
Miklos Szeredi <miklos@szeredi.hu> wrote:
> From: Miklos Szeredi <mszeredi@suse.cz>
>
> Each WRITE request must carry a valid file descriptor. When a page is
> written back from a memory mapping, the file through which the page
> was dirtied is not available, so a new mechananism is needed to find a
> suitable file in ->writepage(s).
>
> A list of fuse_files is added to fuse_inode. The file is removed from
> the list in fuse_release().
>
> This patch is in preparation for writable mmap support.
>
> Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
> ---
>
> Index: linux/fs/fuse/file.c
> ===================================================================
> --- linux.orig/fs/fuse/file.c 2007-10-01 22:42:26.000000000 +0200
> +++ linux/fs/fuse/file.c 2007-10-01 22:42:27.000000000 +0200
> @@ -56,6 +56,7 @@ struct fuse_file *fuse_file_alloc(void)
> kfree(ff);
> ff = NULL;
> }
> + INIT_LIST_HEAD(&ff->write_entry);
> atomic_set(&ff->count, 0);
> }
> return ff;
> @@ -150,12 +151,18 @@ int fuse_release_common(struct inode *in
> {
> struct fuse_file *ff = file->private_data;
> if (ff) {
> + struct fuse_conn *fc = get_fuse_conn(inode);
> +
> fuse_release_fill(ff, get_node_id(inode), file->f_flags,
> isdir ? FUSE_RELEASEDIR : FUSE_RELEASE);
>
> /* Hold vfsmount and dentry until release is finished */
> ff->reserved_req->vfsmount = mntget(file->f_path.mnt);
> ff->reserved_req->dentry = dget(file->f_path.dentry);
> +
> + spin_lock(&fc->lock);
> + list_del(&ff->write_entry);
> + spin_unlock(&fc->lock);
> /*
> * Normally this will send the RELEASE request,
> * however if some asynchronous READ or WRITE requests
> Index: linux/fs/fuse/fuse_i.h
> ===================================================================
> --- linux.orig/fs/fuse/fuse_i.h 2007-10-01 22:42:24.000000000 +0200
> +++ linux/fs/fuse/fuse_i.h 2007-10-01 22:43:15.000000000 +0200
> @@ -70,6 +70,9 @@ struct fuse_inode {
>
> /** Version of last attribute change */
> u64 attr_version;
> +
> + /** Files usable in writepage. Protected by fc->lock */
> + struct list_head write_files;
> };
>
> /** FUSE specific file data */
> @@ -82,6 +85,9 @@ struct fuse_file {
>
> /** Refcount */
> atomic_t count;
> +
> + /** Entry on inode's write_files list */
> + struct list_head write_entry;
> };
>
> /** One input argument of a request */
> Index: linux/fs/fuse/inode.c
> ===================================================================
> --- linux.orig/fs/fuse/inode.c 2007-10-01 22:42:24.000000000 +0200
> +++ linux/fs/fuse/inode.c 2007-10-01 22:42:27.000000000 +0200
> @@ -56,6 +56,7 @@ static struct inode *fuse_alloc_inode(st
> fi->i_time = 0;
> fi->nodeid = 0;
> fi->nlookup = 0;
> + INIT_LIST_HEAD(&fi->write_files);
> fi->forget_req = fuse_request_alloc();
> if (!fi->forget_req) {
> kmem_cache_free(fuse_inode_cachep, inode);
> @@ -68,6 +69,7 @@ static struct inode *fuse_alloc_inode(st
> static void fuse_destroy_inode(struct inode *inode)
> {
> struct fuse_inode *fi = get_fuse_inode(inode);
> + BUG_ON(!list_empty(&fi->write_files));
> if (fi->forget_req)
> fuse_request_free(fi->forget_req);
> kmem_cache_free(fuse_inode_cachep, inode);
hm. At no point in this patch series does anything actually get added to
these lists, so this patch is presently a no-op.
I'll assume that it will get used later. But it is a bit odd to add
infrastructure in a patch series, then not use it. Why not hold the patch
back and include it in the patch series which actually uses these lists for
something?
next prev parent reply other threads:[~2007-10-04 22:52 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-02 15:50 [patch 00/12] fuse update Miklos Szeredi
2007-10-02 15:50 ` [patch 01/12] fuse: fix allowing operations Miklos Szeredi
2007-10-02 15:50 ` [patch 02/12] fuse: fix race between getattr and write Miklos Szeredi
2007-10-04 22:43 ` Andrew Morton
2007-10-04 22:53 ` Miklos Szeredi
2007-10-02 15:50 ` [patch 03/12] fuse: add file handle to getattr operation Miklos Szeredi
2007-10-02 15:50 ` [patch 04/12] fuse: clean up open file passing in setattr Miklos Szeredi
2007-10-02 15:50 ` [patch 05/12] VFS: allow filesystems to implement atomic open+truncate Miklos Szeredi
2007-10-02 15:50 ` [patch 06/12] fuse: improve utimes support Miklos Szeredi
2007-10-02 15:50 ` [patch 07/12] fuse: add atomic open+truncate support Miklos Szeredi
2007-10-02 15:50 ` [patch 08/12] fuse: support BSD locking semantics Miklos Szeredi
2007-10-02 15:50 ` [patch 09/12] fuse: add list of writable files to fuse_inode Miklos Szeredi
2007-10-04 22:51 ` Andrew Morton [this message]
2007-10-04 23:16 ` Miklos Szeredi
2007-10-02 15:50 ` [patch 10/12] fuse: add helper for asynchronous writes Miklos Szeredi
2007-10-02 15:50 ` [patch 11/12] fuse: add support for mandatory locking Miklos Szeredi
2007-10-02 15:50 ` [patch 12/12] fuse: add blksize field to fuse_attr Miklos Szeredi
2007-10-04 22:55 ` Andrew Morton
2007-10-04 23:15 ` Miklos Szeredi
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=20071004155128.62fc1098.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=miklos@szeredi.hu \
/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