linux-kernel - Re: [PATCH] Fix bug in FUSE where the attribute cache for a file was not cleared when a file is opened with O

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <E1PGq46-0002Xo-Ps@pomaz-ex.szeredi.hu>
Date:	Fri, 12 Nov 2010 10:37:02 +0100
From:	Miklos Szeredi <miklos@...redi.hu>
To:	Andrew Morton <akpm@...ux-foundation.org>
CC:	miklos@...redi.hu, ksumrall@...roid.com,
	linux-kernel@...r.kernel.org, jens.axboe@...cle.com,
	anfei.zhou@...il.com, avati@...ster.com,
	fuse-devel@...ts.sourceforge.net
Subject: Re: [PATCH] Fix bug in FUSE where the attribute cache for a file
 was not cleared when a file is opened with O_TRUNC.

On Thu, 11 Nov 2010, Andrew Morton wrote:
> On Sat, 30 Oct 2010 13:31:23 +0200
> Miklos Szeredi <miklos@...redi.hu> wrote:
> 
> > Subject: fuse: fix attributes after open(O_TRUNC)
> > From: Ken Sumrall <ksumrall@...roid.com>
> > 
> > The attribute cache for a file was not being cleared when a file is
> > opened with O_TRUNC.
> > 
> > If the filesystem's open operation truncates the file
> > ("atomic_o_trunc" feature flag is set) then the kernel should
> > invalidate the cached st_mtime and st_ctime attributes.
> > 
> > Also i_size should be explicitly be set to zero as it is used
> > sometimes without refreshing the cache.
> > 
> > Signed-off-by: Ken Sumrall <ksumrall@...roid.com>
> > Cc: Anfei <anfei.zhou@...il.com>
> > Cc: "Anand V. Avati" <avati@...ster.com>
> > Signed-off-by: Andrew Morton <akpm@...ux-foundation.org>
> > Signed-off-by: Miklos Szeredi <miklos@...redi.hu>
> > Cc: stable@...nel.org
> > ---
> > 
> >  fs/fuse/file.c |   10 ++++++++++
> >  1 file changed, 10 insertions(+)
> > 
> > Index: linux-2.6/fs/fuse/file.c
> > ===================================================================
> > --- linux-2.6.orig/fs/fuse/file.c	2010-10-27 14:04:02.000000000 +0200
> > +++ linux-2.6/fs/fuse/file.c	2010-10-30 13:14:07.000000000 +0200
> > @@ -134,6 +134,7 @@ EXPORT_SYMBOL_GPL(fuse_do_open);
> >  void fuse_finish_open(struct inode *inode, struct file *file)
> >  {
> >  	struct fuse_file *ff = file->private_data;
> > +	struct fuse_conn *fc = get_fuse_conn(inode);
> >  
> >  	if (ff->open_flags & FOPEN_DIRECT_IO)
> >  		file->f_op = &fuse_direct_io_file_operations;
> > @@ -141,6 +142,15 @@ void fuse_finish_open(struct inode *inod
> >  		invalidate_inode_pages2(inode->i_mapping);
> >  	if (ff->open_flags & FOPEN_NONSEEKABLE)
> >  		nonseekable_open(inode, file);
> > +	if (fc->atomic_o_trunc && (file->f_flags & O_TRUNC)) {
> > +		struct fuse_inode *fi = get_fuse_inode(inode);
> > +
> > +		spin_lock(&fc->lock);
> > +		fi->attr_version = ++fc->attr_version;
> > +		i_size_write(inode, 0);
> 
> i_size_write() requires that i_mutex be held, as described at the
> i_size_write() definition site.
> 
> Is it reliably the case that i_mutex is held here?

No.  AFAICS any lock will do, not just i_mutex.  Fuse consistently
uses fc->lock to protect i_size_write().

Thanks,
Miklos
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/