On 10/30/26 19:36, Jimmy Zuber wrote:
> On Fri, 30 Oct 2026, NeilBrown wrote:
>> The /proc different seems cosmetic and probably of no consequence.
>> The nlink issue might be significant - I cannot say.
>> It might be nice to include a comment where d_instantiate() is used,
>> explaining why d_tmpfile() was avoided(?).
>
> I dug into this a bit more. I couldn't find a FUSE server that actually
> implements FUSE_TMPFILE, besides the example servers in some FUSE
> libraries. However, switching to d_tmpfile() is a behavior change that's
> unrelated to the core of the atomic open series. I'd be happy to cut a
> separate patch series for it if you think it's an important improvement,
> but I want to keep things decoupled. In v7 of the atomic open series
> I'll make the "why" of d_instantiate() clear, i.e. that it is uniform
> with the rest of the fuse kernel module.
It took me a while to find the link.
https://lore.kernel.org/all/[email protected]/
In [PATCH v4 09/10] vfs: open inside ->tmpfile()
<quote>
This is in preparation for adding tmpfile support to fuse, which requires
that the tmpfile creation and opening are done as a single operation.
Replace the 'struct dentry *' argument of i_op->tmpfile with
'struct file *'.
Call finish_open_simple() as the last thing in ->tmpfile() instances (may
be omitted in the error case).
Change d_tmpfile() argument to 'struct file *' as well to make callers more
readable.
</quote>
