tmpfs questions

[Jack Humphries]

Thanks a lot, Konstantin. I also noticed that the tmpfs_mount
structure is not necessarily protected by a lock when an access is
made to the tm_nodes_inuse member in the if statement at the beginning
of the tmpfs_alloc_node function in tmpfs_subr.c (though this member
is protected by the allnode_lock when it is modified). Thus
conceivably it is possible to create more nodes than the maximum
number allowed if multiple threads try to do so at the same time. Do
you know how this situation is handled? What am I looking at
incorrectly? Thanks again!

Jack

On Sat, Jul 14, 2018 at 12:48 AM, Konstantin Belousov
<kostikbel at gmail.com> wrote:
> On Fri, Jul 13, 2018 at 05:42:59PM -0700, Jack Humphries wrote:
>> Hi everyone,
>>
>> I'm trying to study the FreeBSD tmpfs implementation as a personal
>> project, and I had a couple questions. I've been looking through the
>> code for a week and modifying various parts. I appreciate any help!
>>
>> 1. It seems that vnodes are locked before being passed to the various
>> VOP functions in tmpfs (because there is a call to
>> MPASS(VOP_ISLOCKED(vp)) near the beginning of each function).
>> Therefore, is the implicit assumption that a thread that holds the
>> vnode lock has exclusive access to the corresponding tmpfs_node
>> struct? In other words, is this why there are accesses to the tmpfs
>> node variables even though the tmpfs node is not locked? Note: I see
>> tn_interlock, but based on a comment above it in the source, it only
>> protects tn_vpstate and tn_status.
> tmpfs nodes are protected by the vnode locks.  Note that vnode lock
> can be held exclusive or shared.  Typically, only exclusive lock allows
> the code to modify the node, owning shared vnode lock only means that
> the node can be read safely.
>
> Interlock exists because node state must be examined sometimes without
> owning the vnode lock, in non-sleepable context.
>
>>
>> 2. What is the duplicate node list for (tn_dupindex)? If I had to
>> guess, it seems to have something to do with the case where one thread
>> calls readdir on a directory while another is modifying the directory,
>> but I'm not sure. Can someone explain this deeper?
> As an optimization, children of the directory node are organized into
> red/black tree, which cannot hold two entries with the same key value.
> If a second entry with the existing key is attempted to be created in
> the directory, it is added to the dup list instead.