From owner-freebsd-arch@FreeBSD.ORG Thu Jan 12 21:39:57 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 27B9A106564A; Thu, 12 Jan 2012 21:39:57 +0000 (UTC) (envelope-from rwatson@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 0011A8FC0C; Thu, 12 Jan 2012 21:39:56 +0000 (UTC) Received: from [192.168.2.105] (host86-161-238-124.range86-161.btcentralplus.com [86.161.238.124]) by cyrus.watson.org (Postfix) with ESMTPSA id B0CD346B2E; Thu, 12 Jan 2012 16:39:55 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: "Robert N. M. Watson" In-Reply-To: Date: Thu, 12 Jan 2012 21:39:53 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <86sjjobzmn.fsf@kopusha.home.net> <86fwfnti5t.fsf@kopusha.home.net> To: Mikolaj Golub X-Mailer: Apple Mail (2.1251.1) Cc: Kostik Belousov , 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: Thu, 12 Jan 2012 21:39:57 -0000 On 12 Jan 2012, at 21:17, Mikolaj Golub wrote: > If we agree to have only the new behavior then nullfs won't need = modification > at all, it will work as expected automatically. The patch could be = (with updated > locking for the connect case): >=20 > http://people.freebsd.org/~trociny/VOP_UNP.1.patch Greatly simplified. > --- sys/kern/uipc_usrreq.c (revision 229979) > +++ sys/kern/uipc_usrreq.c (working copy) > @@ -542,7 +542,7 @@ > =20 > UNP_LINK_WLOCK(); > UNP_PCB_LOCK(unp); > - vp->v_socket =3D unp->unp_socket; > + VOP_UNPBIND(vp, unp->unp_socket); > unp->unp_vnode =3D vp; > unp->unp_addr =3D soun; > unp->unp_flags &=3D ~UNP_BINDING; 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 :-). Robert=