[LSF/MM/BPF TOPIC] making O_TMPFILE more atomic

[LSF/MM/BPF TOPIC] making O_TMPFILE more atomic

[Steve French]

Currently creating tmpfiles on Linux can be problematic because the
tmpfile is not created and opened at the same time  (vfs_tmpfile calls
into the fs, then later vfs_open is called to open the tmpfile).   For
some filesystems it would be more natural to create and open the
tmpfile as one operation (because the action of creating the file on
some filesystems returns an open handle, so closing it then reopening
it would cause the tmpfile to be deleted).

I would like to discuss whether the function do_tmpfile (which creates
and then opens the tmpfile) could have an option for a filesystem to
do this as one operation which would allow it to be more atomic and
allow it to work on a wider variety of filesystems.

-- 
Thanks,

Steve

Re: [LSF/MM/BPF TOPIC] making O_TMPFILE more atomic

[Miklos Szeredi]

On Thu, 24 Feb 2022 at 06:33, Steve French <smfrench@gmail.com> wrote:
>
> Currently creating tmpfiles on Linux can be problematic because the
> tmpfile is not created and opened at the same time  (vfs_tmpfile calls
> into the fs, then later vfs_open is called to open the tmpfile).   For
> some filesystems it would be more natural to create and open the
> tmpfile as one operation (because the action of creating the file on
> some filesystems returns an open handle, so closing it then reopening
> it would cause the tmpfile to be deleted).
>
> I would like to discuss whether the function do_tmpfile (which creates
> and then opens the tmpfile) could have an option for a filesystem to
> do this as one operation which would allow it to be more atomic and
> allow it to work on a wider variety of filesystems.

A related thread:

https://lore.kernel.org/all/20201109100343.3958378-3-chirantan@chromium.org/#r

There was no conclusion in the end. Not sure how hacky it would be to
store the open file in the inode...

Thanks,
Miklos

Re: [LSF/MM/BPF TOPIC] making O_TMPFILE more atomic

[Chuck Lever III]

> On May 3, 2022, at 2:52 PM, Miklos Szeredi <miklos@szeredi.hu> wrote:
> 
> On Thu, 24 Feb 2022 at 06:33, Steve French <smfrench@gmail.com> wrote:
>> 
>> Currently creating tmpfiles on Linux can be problematic because the
>> tmpfile is not created and opened at the same time  (vfs_tmpfile calls
>> into the fs, then later vfs_open is called to open the tmpfile).   For
>> some filesystems it would be more natural to create and open the
>> tmpfile as one operation (because the action of creating the file on
>> some filesystems returns an open handle, so closing it then reopening
>> it would cause the tmpfile to be deleted).
>> 
>> I would like to discuss whether the function do_tmpfile (which creates
>> and then opens the tmpfile) could have an option for a filesystem to
>> do this as one operation which would allow it to be more atomic and
>> allow it to work on a wider variety of filesystems.
> 
> A related thread:
> 
> https://lore.kernel.org/all/20201109100343.3958378-3-chirantan@chromium.org/#r
> 
> There was no conclusion in the end. Not sure how hacky it would be to
> store the open file in the inode...

I just proposed adding a VFS API to make open/create atomic.
See 8/8 in this thread:

https://lore.kernel.org/linux-nfs/20220420192418.GB27805@fieldses.org/T/#m505a59ad4e4ed1413ffc055a088de3182fb50bb4

It adds a sibling API to dentry_open(). I didn't have
O_TMPFILE in mind when I created this API.


--
Chuck Lever