Re: [PATCH 00/25] vfs: atomic open RFC

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Mar 13, 2012 at 12:00:05PM +0100, Miklos Szeredi wrote:
> > Do we really need the opendata structure?
> >
> > It seems like we could just pass a struct path instead of the dentry
> > passed directly and the vfsmount in it.  There should be no need to
> > preallocate the file before calling into ->atomic_open, as it's only
> > used to pass around f_flags - but we already pass that one to
> > ->atomic_open directly and might as well pass it on to finish_open and
> > allocate the file there.
> 
> We really don't want to get into the situation where the open fails
> after a successful create(*).  Which means the file needs to be allocated
> prior to calling ->atomic_open and needs to be passed to finish_open()
> toghether with the vfsmount and dentry.
> 
> In the first version of the patch I set filp->f_path.mnt to nd->path.mnt
> and passed the half initialized filp to ->atomic_open.  But then decided
> that it's confusing for the filesystem code to deal with a half baked
> filp (does it need to be fput on error?  etc...)
> 
> Doing it with an opaque opendata makes this cleaner I think.

Make sense.  Can you throw in another cleanup patch to really just make
it a pass-through and not also use it as a boolean flag if open_flags
should be obeyed?  This probably will change sematincs for the various
filesystems, but given that they should behave the same way that's a
good thing.
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux