Re: [RFC] atomic create+open

[Miklos Szeredi]

> > 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
->open().

> > 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.

Miklos
-
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/