kern/159663: sockets don't work though nullfs mounts

Mikolaj Golub trociny at freebsd.org
Sat Oct 15 18:41:15 UTC 2011


On Mon, 26 Sep 2011 00:58:03 +0300 Mikolaj Golub wrote to Robert Millan:

 MG> Hi,

 MG> On Sun, 25 Sep 2011 17:32:27 +0200 Robert Millan wrote:

 RM>> 2011/9/24 Robert Millan <rmh at freebsd.org>:
 >>> I found a thread from 2007 with further discussion about this problem:
 >>>
 >>> http://lists.freebsd.org/pipermail/freebsd-fs/2007-February/002669.html

 RM>> Hi,

 RM>> I've looked at the situation in a bit more detail, for now only with
 RM>> sockets in mind (not named pipes).  My understanding is (please
 RM>> correct me if I'm wrong):

 RM>> - nullfs holds reference counts for each vnode, but sockets have their
 RM>> own mechanism for reference counting (so_count / soref / sorele).
 RM>> vnode reference counting doesn't protect against socket being closed,
 RM>> which would leave a stale pointer in the upper nullfs layer.

 RM>> - Increasing the reference count of the socket itself can't be done in
 RM>> null_nodeget() because this function is merely a getter whose call
 RM>> doesn't indicate any meaningful event.

 RM>> - It's not clear to me that there's any event in time where the socket
 RM>> reference can be increased.  If mounting a nullfs were that event,
 RM>> then all existing sockets would be soref'ed but we wouldn't be
 RM>> soref'ing future sockets created in the lower layer after the mount.
 RM>> This doesn't seem correct.

 RM>> - Possible solution: null_nodeget() semantics are replaced with
 RM>> something that actually allows vnodes in the upper layer to be created
 RM>> and destroyed.

 RM>> - Possible solution: upper layer has a memory structure to keep track
 RM>> of which sockets in the lower layer have been soref'ed.

 MG> It looks like there is no need in setting vp->v_un = lowervp->v_un for
 MG> VFIFO. They work without this modification bypassing vnode operations to lover
 MG> node and lowervp->v_un is used.

 MG> The issue is only with local sockets, because when bind or connnect is called
 MG> for nullfs file the upper v_un is used.

 MG> For me the approach "vp->v_un = lowervp->v_un" has many complications. May be
 MG> it is much easier to use always only lower vnode? What we need for this is to
 MG> make bind and connect get the lower vnode when they are called on nullfs file.

Thinking more about "vp->v_un = lowervp->v_un" approach it looks for me that
there should not be any coherency issues on contents of v_un between the two
file system layers (the main worry about this approach in the thread mentioned
above).

Consider a scenario when binding to lower fs vnode and then connnecting to the
upper fs path.

On connect lookup returns nullfs node with:

lvnp->v_un = bind_socket
uvnp->v_un = bind_socket

uvnp is locked (usecount is 1).

bind_socket is used to establish the connection. After the connection is
established uvnp is released by vput(), usecount is 0, so nullfs vnode is
deactivated and destroyed.

Thus uvnp->v_un has short time of life and it looks like it can't be stale
during this time.

When we bind to the upper fs vnode, in bind VOP_CREATE will return nullfs
node with:

lvnp->v_un = NULL
uvnp->v_un = NULL

bind sets uvnp->v_un, lvnp->v_un remains NULL. The nullfs node remains active
until bind socket is closed, so on connect uvnp->v_un of this node is used.
The connection to lower fs will return ECONNREFUSE.

Thus I don't see a scenario when uvnp->v_un would be stale. I did some crash
testing and did not manage to panic the system.

But the issue is that if we bind to an upper fs path, we can't connect to the
lower fs path. This behavior contradicts with overall nullfs behavior (all
changes done on the upper layer are seen from the lower layer) and is more
unionfs-like.  That is why my proposal (return lover vnode instead of upper
vnode in null_lookup and null_create if the vnode type is VSOCK) looks for me
more interesting. But as I wrote it also has an issue: you can bind using the
upper fs path and then unmount nullfs without force while the socket is still
bound.

The updated patch can be found here:

http://people.freebsd.org/~trociny/nullfs.VSOCK.patch

Anyway, for me any of these solutions, although not ideal, looks like better
than having nothing at all, maybe just documenting the behavior in BUGS
section.

 MG> As a proof of concept below is a patch that implements it. Currently I am not
 MG> sure that vrele/vref magic is done properly, but it looks like it works for
 MG> me.

 MG> The issues with this approach I see so far:

 MG> - we need an additional flag for namei;

 MG> - nullfs can be unmounted with a socket file still being opened.

 MG> -- 
 MG> Mikolaj Golub

-- 
Mikolaj Golub


More information about the freebsd-fs mailing list