unix domain sockets on nullfs(5)

Kostik Belousov kostikbel at gmail.com
Mon Jan 23 03:12:46 UTC 2012


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?
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.
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?
No, usecount must not be dropped. The hold count counts the owners of
the pointer to the vnode, preventing the freeing of the struct vnode
itself. Usecount is to avoid non-forced unmounts from reclaiming the
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
Not in the vflush(). I think vgonel() would be better place.

> 
> I don't know though how to export this helper function and what name would be
> appropriate: there are no other exported functions in uipc_usrreq.c.
> 
> Thanks,
> 
> -- 
> Mikolaj Golub
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20120123/fdf1e4e2/attachment.pgp


More information about the freebsd-arch mailing list