unix domain sockets on nullfs(5)

[Mikolaj Golub]

On Mon, 23 Jan 2012 05:12:38 +0200 Kostik Belousov wrote:

 KB> On Sun, Jan 22, 2012 at 08:33:45PM +0200, Mikolaj Golub wrote:
 >> 
 >> There was a bug in my patch: for vop_unpdetach it wanted the vnode to be
 >> exclusively locked, while it was called from the context (uipc_detach) where
 >> the vnode is not locked.
 >> 
 >> It looks it is OK that the vnode is not locked here: the operation is to null
 >> vp->v_socket, and currently the only place where it is concurently accessed is
 >> in unp_connect(), and it is protected by the linkage lock.
 >> 
 >> So I updated my patch to have  "= = =" for unpdetach vp.
 >> 
 >> http://people.freebsd.org/~trociny/VOP_UNP.2.patch
 >> 
 >> 
 >> On Thu, 12 Jan 2012 23:51:06 +0200 Kostik Belousov wrote:
 >> 
 >>  KB> On Thu, Jan 12, 2012 at 09:39:53PM +0000, Robert N. M. Watson wrote:
 >>  >> 
 >>  >> I still find myself worried by the fact that unp->unp_vnode points at the
 >>  >> nullfs vnode rather than the underlying vnode, but haven't yet managed to
 >>  >> identify any actual bugs that would result. I'll continue pondering it
 >>  >> over the weekend :-).
 >> 
 >>  KB> I think I know what could go wrong there, but due to other bug, this
 >>  KB> wrongness cannot be realized now.
 >> 
 >>  KB> Issue is that for the forced unmount, the unp_vnode is reclaimed, so that
 >>  KB> the unix domain sockets code references freed memory after reclaim.
 >> 
 >> Just to have this clear, as I understand this problem with reclaim is
 >> orthogonal to the initial issue and would also exist without my patch too?
 KB> Yes.

 >> 
 >> Could you please tell what is the other bug? I see that after force unmount,
 >> in vflush() we call vgonel() for every vnode, and vgonel() does VOP_CLOSE(),
 >> VOP_INACTIVE(), VOP_RECLAIM(), sets v_type = VBAD, but vnode's usecount is not
 >> decreased so if a node was active it may not be freed when vdropl() is called.
 KB> The lack of the cleanup in the reclamation code.

 >> 
 >> Was the usecount supposed to be dropped somewere in this path (when
 >> VOP_CLOSE() is called?) and this is the bug you mean or it is something else?
 KB> No, usecount must not be dropped. The hold count counts the owners of
 KB> the pointer to the vnode, preventing the freeing of the struct vnode
 KB> itself. Usecount is to avoid non-forced unmounts from reclaiming the
 KB> vnode.

 >> 
 >> Currently the usecount (for both VREG and VSOCK) is deacreased when the
 >> process finaly closes the discriptor.
 >> 
 >>  KB> Probably, some helper should provided by uipc_usrreq, called from VOP_RECLAIM()
 >>  KB> implementations for VSOCK types of vnodes.
 >> 
 >> I would not be very happy with adding the helper to every fs's VOP_RECLAIM()
 >> implementation :-). Couldn't it be somevere in the common code, e.g. in
 >> vflush()?  Here is the patch I tried:
 >> 
 >> http://people.freebsd.org/~trociny/vsock_reclaim.patch
 KB> Not in the vflush(). I think vgonel() would be better place.

After collecting all suggestions and additional testing I have got this patch
set:

http://people.freebsd.org/~trociny/unp_prepare_reclaim.1.patch
http://people.freebsd.org/~trociny/unp_connect.LOCKSHARED.1.patch
http://people.freebsd.org/~trociny/VOP_UNP.3.patch

It has survived some bind/connect/force umount stress testing revealing only
some issues that are also observed without patching.

-- 
Mikolaj Golub