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>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->>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
Please read the FAQ at