Re: [RFC] atomic create+open
From: Miklos Szeredi
Date: Wed Oct 12 2005 - 08:54:32 EST
> > However I don't really like that the filesystem is reentered from
> > lookup_instantiate_filp() via __dentry_open() and ->open(). Is this
> > necessary?
> If filesystems need to be able to change the value of f_mapping, then
> yes, however if none of the potential users of lookup_instantiate_filp()
> care about doing so, then we can get rid of it.
That would be nice. Filesysteem could set intent.open.file->f_mapping
before call to lookup_instantiate_filp(), which would check it before
resetting to inode->i_mapping.
> I don't care either way since we will not be supporting non-intent based
> opens for NFSv4.
I need this for FUSE, since non-create opens and non-exclusive open of
positive dentry will be done through ->open().
There is an ugly workaround: filesystem sets
nd->intent.open.file->private_data to some non-NULL value before
calling lookup_instantiate_filp() and in ->open() skip open based on
value of file->private_data.
But I'd prefer if lookup_instantiate_filp() would simply not call
> > I see you've fixed the O_TRUNC problem. The accmode==3 case is still
> > slightly broken, since now the file is being opened in read-write mode
> > instead of no-read-no-write mode. This probably won't break anything
> > too badly though.
> It is non-portable and it was never supported on NFSv4 anyway. If
> someone cares, they can fix it, but I don't see much need.
I suggest that nameidata_to_filp() to check this ((flags & O_ACCMODE)
== 3) if the file is already open and bail out with -EINVAL.
This would make sure, that things that relied on the old behavior at
least fail loudly instead of silently.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/