From owner-freebsd-arch@FreeBSD.ORG Mon Jan 23 03:12:46 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 727F2106566B; Mon, 23 Jan 2012 03:12:46 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 7A6808FC12; Mon, 23 Jan 2012 03:12:45 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q0N3Cc5S043169 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Jan 2012 05:12:38 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q0N3CcOD083236; Mon, 23 Jan 2012 05:12:38 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q0N3Cc2Q083235; Mon, 23 Jan 2012 05:12:38 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 23 Jan 2012 05:12:38 +0200 From: Kostik Belousov To: Mikolaj Golub Message-ID: <20120123031238.GL31224@deviant.kiev.zoral.com.ua> References: <86sjjobzmn.fsf@kopusha.home.net> <86fwfnti5t.fsf@kopusha.home.net> <20120112215106.GC31224@deviant.kiev.zoral.com.ua> <86hazntwmu.fsf@kopusha.home.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="bxfpw+NNV0U2roqL" Content-Disposition: inline In-Reply-To: <86hazntwmu.fsf@kopusha.home.net> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: "Robert N. M. Watson" , freebsd-arch@freebsd.org Subject: Re: unix domain sockets on nullfs(5) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 03:12:46 -0000 --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--