Date: Mon, 23 Jan 2012 05:12:38 +0200 From: Kostik Belousov <kostikbel@gmail.com> To: Mikolaj Golub <trociny@freebsd.org> Cc: "Robert N. M. Watson" <rwatson@freebsd.org>, freebsd-arch@freebsd.org Subject: Re: unix domain sockets on nullfs(5) Message-ID: <20120123031238.GL31224@deviant.kiev.zoral.com.ua> In-Reply-To: <86hazntwmu.fsf@kopusha.home.net> 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> <86hazntwmu.fsf@kopusha.home.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--bxfpw+NNV0U2roqL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jan 22, 2012 at 08:33:45PM +0200, Mikolaj Golub wrote: >=20 > 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) wh= ere > the vnode is not locked. >=20 > 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 access= ed is > in unp_connect(), and it is protected by the linkage lock. >=20 > So I updated my patch to have "=3D =3D =3D" for unpdetach vp. >=20 > http://people.freebsd.org/~trociny/VOP_UNP.2.patch >=20 >=20 > On Thu, 12 Jan 2012 23:51:06 +0200 Kostik Belousov wrote: >=20 > KB> On Thu, Jan 12, 2012 at 09:39:53PM +0000, Robert N. M. Watson wrote: > >>=20 > >> 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 manage= d to > >> identify any actual bugs that would result. I'll continue pondering it > >> over the weekend :-). >=20 > KB> I think I know what could go wrong there, but due to other bug, this > KB> wrongness cannot be realized now. >=20 > 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. >=20 > 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. >=20 > Could you please tell what is the other bug? I see that after force unmou= nt, > in vflush() we call vgonel() for every vnode, and vgonel() does VOP_CLOSE= (), > VOP_INACTIVE(), VOP_RECLAIM(), sets v_type =3D VBAD, but vnode's usecount= is not > decreased so if a node was active it may not be freed when vdropl() is ca= lled. The lack of the cleanup in the reclamation code. >=20 > 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 e= lse? 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. >=20 > Currently the usecount (for both VREG and VSOCK) is deacreased when the > process finaly closes the discriptor. >=20 > KB> Probably, some helper should provided by uipc_usrreq, called from VO= P_RECLAIM() > KB> implementations for VSOCK types of vnodes. >=20 > I would not be very happy with adding the helper to every fs's VOP_RECLAI= M() > implementation :-). Couldn't it be somevere in the common code, e.g. in > vflush()? Here is the patch I tried: >=20 > http://people.freebsd.org/~trociny/vsock_reclaim.patch Not in the vflush(). I think vgonel() would be better place. >=20 > I don't know though how to export this helper function and what name woul= d be > appropriate: there are no other exported functions in uipc_usrreq.c. >=20 > Thanks, >=20 > --=20 > Mikolaj Golub --bxfpw+NNV0U2roqL Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk8c0CYACgkQC3+MBN1Mb4igBgCePsf2rnJEcCW+O8gCzFalOyiI 62QAni+3kpxCrOTA86kolmPY4PM4K0Gh =Xyx8 -----END PGP SIGNATURE----- --bxfpw+NNV0U2roqL--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120123031238.GL31224>