Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 22 Jan 2012 20:33:45 +0200
From:      Mikolaj Golub <trociny@freebsd.org>
To:        Kostik Belousov <kostikbel@gmail.com>
Cc:        "Robert N. M. Watson" <rwatson@freebsd.org>, freebsd-arch@freebsd.org
Subject:   Re: unix domain sockets on nullfs(5)
Message-ID:  <86hazntwmu.fsf@kopusha.home.net>
In-Reply-To: <20120112215106.GC31224@deviant.kiev.zoral.com.ua> (Kostik Belousov's message of "Thu, 12 Jan 2012 23:51:06 %2B0200")
References:  <86sjjobzmn.fsf@kopusha.home.net> <D1B8F00C-1E0D-4916-BD4B-FBCAE28E6F22@FreeBSD.org> <86fwfnti5t.fsf@kopusha.home.net> <CAOnPXZ_y5G6uEBWmfuH7qYBh%2B4Pw=O91ztCPEFCOTzWdCzx%2BRA@mail.gmail.com> <BBDE763A-F55E-453D-A503-2489C9040EF6@freebsd.org> <20120112215106.GC31224@deviant.kiev.zoral.com.ua>

next in thread | previous in thread | raw e-mail | index | archive | help

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?

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.

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?

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

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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?86hazntwmu.fsf>