public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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?



  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