From owner-freebsd-arch@FreeBSD.ORG Sun Apr 22 13:37:00 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 2043E1065670; Sun, 22 Apr 2012 13:37:00 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id D9A098FC0A; Sun, 22 Apr 2012 13:36:58 +0000 (UTC) Received: by lbbgm6 with SMTP id gm6so4922197lbb.13 for ; Sun, 22 Apr 2012 06:36:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:references:x-comment-to:sender:date:in-reply-to :message-id:user-agent:mime-version:content-type; bh=EpOWNLFLdgKv4pNLMf45st6+cPZGIV/mmUNqRiIxCEo=; b=Ti8PoH03ufecxfyCbMCH6kmU/rKaZtvCTUqKxcifR3EaW56aS971XZWwth+DHdfRCj lhLch8FyltO0TXlcZ++RKVvZyoKdLhPfdI6U238ANazlpNQ8O+st0XBxBemWm2a507D9 w5tFCWt3DHZsAUSN3pf+1gKL4Z9690HJf9q6CAhVvaMpMwc/cMMd3shvUdnfGOK4iCm8 Jfy76m63xjrbVl/F6OOj68aTYmF9cM1+qXOEVwYpdL1KMESmUUel89E5FzMor6cKJshc NJ1uC17B1T3kxVwJP6vzPeesx1dr2GBpqYBmUkue5YnDoCB45LVDNzlsFxLv6GLhlYLi ta8g== Received: by 10.152.132.233 with SMTP id ox9mr12464994lab.4.1335101816867; Sun, 22 Apr 2012 06:36:56 -0700 (PDT) Received: from localhost ([95.69.173.122]) by mx.google.com with ESMTPS id uc6sm15708430lbb.3.2012.04.22.06.36.52 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 22 Apr 2012 06:36:53 -0700 (PDT) From: Mikolaj Golub To: freebsd-arch@freebsd.org References: <20120112215106.GC31224@deviant.kiev.zoral.com.ua> <86hazntwmu.fsf@kopusha.home.net> <20120123031238.GL31224@deviant.kiev.zoral.com.ua> <86zkcfu9ac.fsf@kopusha.home.net> <20120218215003.GM3283@deviant.kiev.zoral.com.ua> <86ehtrf8qf.fsf@kopusha.home.net> <20120219170151.GS3283@deviant.kiev.zoral.com.ua> <86d393dvqr.fsf@kopusha.home.net> <20120225174818.GC55074@deviant.kiev.zoral.com.ua> <8B0B7D86-1EE6-4901-9E36-EA1918315163@freebsd.org> X-Comment-To: Robert N. M. Watson Sender: Mikolaj Golub Date: Sun, 22 Apr 2012 16:36:50 +0300 In-Reply-To: <8B0B7D86-1EE6-4901-9E36-EA1918315163@freebsd.org> (Robert N. M. Watson's message of "Sat, 25 Feb 2012 19:16:08 +0000") Message-ID: <86wr57lwgd.fsf@kopusha.home.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (berkeley-unix) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Cc: Konstantin Belousov , "Bjoern A. Zeeb" , "Robert N. M. Watson" 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: Sun, 22 Apr 2012 13:37:00 -0000 --=-=-= Hi, On Sat, 25 Feb 2012 19:16:08 +0000 Robert N. M. Watson wrote: RNMW> On 25 Feb 2012, at 17:48, Konstantin Belousov wrote: >>> I am thinking now about 'MFC after'. Thanks to jhb's spare vops it looks like >>> it is possible to merge it in stable/9 without breaking the KBI, but then I >>> will consume 3 of 5 available spare vops. So is it worth doing? >> I do not think that we shall be so restrained on the use of spare VOPs. RNMW> I think the only real question here is whether John had specific things RNMW> in mind when he added the spares, or whether they are open for general RNMW> use. Assuming they are open for general use, this use seems a quite RNMW> beneficial one :-). I am going to MFC VOP_UNP_* operations (r232317) and this is just to ask the last time if someone sees problems with this or would like to reserve them for other things. Also could you please look at the merge diff I am going to commit if it looks ok? -- Mikolaj Golub --=-=-= Content-Type: text/x-patch Content-Disposition: inline; filename=r232317.diff Index: UPDATING =================================================================== --- UPDATING (revision 234553) +++ UPDATING (working copy) @@ -9,6 +9,14 @@ handbook. Items affecting the ports and packages system can be found in /usr/ports/UPDATING. Please read that file before running portupgrade. +20120422: + Now unix domain sockets behave "as expected" on nullfs(5). Previously + nullfs(5) did not pass through all behaviours to the underlying layer, + as a result if we bound to a socket on the lower layer we could connect + only to the lower path; if we bound to the upper layer we could connect + only to the upper path. The new behavior is one can connect to both the + lower and the upper paths regardless what layer path one binds to. + 20120109: The acpi_wmi(4) status device /dev/wmistat has been renamed to /dev/wmistat0. Property changes on: UPDATING ___________________________________________________________________ Modified: svn:mergeinfo Merged /head/UPDATING:r232317 Index: sys =================================================================== --- sys (revision 234553) +++ sys (working copy) Property changes on: sys ___________________________________________________________________ Modified: svn:mergeinfo Merged /head/sys:r232317 Index: sys/sys/vnode.h =================================================================== --- sys/sys/vnode.h (revision 234553) +++ sys/sys/vnode.h (working copy) @@ -707,6 +707,9 @@ int vop_stdpathconf(struct vop_pathconf_args *); int vop_stdpoll(struct vop_poll_args *); int vop_stdvptocnp(struct vop_vptocnp_args *ap); int vop_stdvptofh(struct vop_vptofh_args *ap); +int vop_stdunp_bind(struct vop_unp_bind_args *ap); +int vop_stdunp_connect(struct vop_unp_connect_args *ap); +int vop_stdunp_detach(struct vop_unp_detach_args *ap); int vop_eopnotsupp(struct vop_generic_args *ap); int vop_ebadf(struct vop_generic_args *ap); int vop_einval(struct vop_generic_args *ap); Index: sys/kern/uipc_usrreq.c =================================================================== --- sys/kern/uipc_usrreq.c (revision 234553) +++ sys/kern/uipc_usrreq.c (working copy) @@ -541,7 +541,7 @@ restart: UNP_LINK_WLOCK(); UNP_PCB_LOCK(unp); - vp->v_socket = unp->unp_socket; + VOP_UNP_BIND(vp, unp->unp_socket); unp->unp_vnode = vp; unp->unp_addr = soun; unp->unp_flags &= ~UNP_BINDING; @@ -637,7 +637,7 @@ uipc_detach(struct socket *so) * XXXRW: Should assert vp->v_socket == so. */ if ((vp = unp->unp_vnode) != NULL) { - unp->unp_vnode->v_socket = NULL; + VOP_UNP_DETACH(vp); unp->unp_vnode = NULL; } unp2 = unp->unp_conn; @@ -1307,7 +1307,7 @@ unp_connect(struct socket *so, struct sockaddr *na * and to protect simultaneous locking of multiple pcbs. */ UNP_LINK_WLOCK(); - so2 = vp->v_socket; + VOP_UNP_CONNECT(vp, &so2); if (so2 == NULL) { error = ECONNREFUSED; goto bad2; @@ -2317,17 +2317,15 @@ vfs_unp_reclaim(struct vnode *vp) active = 0; UNP_LINK_WLOCK(); - so = vp->v_socket; + VOP_UNP_CONNECT(vp, &so); if (so == NULL) goto done; unp = sotounpcb(so); if (unp == NULL) goto done; UNP_PCB_LOCK(unp); - if (unp->unp_vnode != NULL) { - KASSERT(unp->unp_vnode == vp, - ("vfs_unp_reclaim: vp != unp->unp_vnode")); - vp->v_socket = NULL; + if (unp->unp_vnode == vp) { + VOP_UNP_DETACH(vp); unp->unp_vnode = NULL; active = 1; } Index: sys/kern/vfs_default.c =================================================================== --- sys/kern/vfs_default.c (revision 234553) +++ sys/kern/vfs_default.c (working copy) @@ -123,6 +123,9 @@ struct vop_vector default_vnodeops = { .vop_unlock = vop_stdunlock, .vop_vptocnp = vop_stdvptocnp, .vop_vptofh = vop_stdvptofh, + .vop_unp_bind = vop_stdunp_bind, + .vop_unp_connect = vop_stdunp_connect, + .vop_unp_detach = vop_stdunp_detach, }; /* @@ -1037,6 +1040,30 @@ vop_stdadvise(struct vop_advise_args *ap) return (error); } +int +vop_stdunp_bind(struct vop_unp_bind_args *ap) +{ + + ap->a_vp->v_socket = ap->a_socket; + return (0); +} + +int +vop_stdunp_connect(struct vop_unp_connect_args *ap) +{ + + *ap->a_socket = ap->a_vp->v_socket; + return (0); +} + +int +vop_stdunp_detach(struct vop_unp_detach_args *ap) +{ + + ap->a_vp->v_socket = NULL; + return (0); +} + /* * vfs default ops * used to fill the vfs function table to get reasonable default return values. Index: sys/kern/vnode_if.src =================================================================== --- sys/kern/vnode_if.src (revision 234553) +++ sys/kern/vnode_if.src (working copy) @@ -640,23 +640,31 @@ vop_advise { IN int advice; }; -# The VOPs below are spares at the end of the table to allow new VOPs to be -# added in stable branches without breaking the KBI. New VOPs in HEAD should -# be added above these spares. When merging a new VOP to a stable branch, -# the new VOP should replace one of the spares. +%% unp_bind vp E E E -vop_spare1 { +vop_unp_bind { IN struct vnode *vp; + IN struct socket *socket; }; -vop_spare2 { +%% unp_connect vp L L L + +vop_unp_connect { IN struct vnode *vp; + OUT struct socket **socket; }; -vop_spare3 { +%% unp_detach vp = = = + +vop_unp_detach { IN struct vnode *vp; }; +# The VOPs below are spares at the end of the table to allow new VOPs to be +# added in stable branches without breaking the KBI. New VOPs in HEAD should +# be added above these spares. When merging a new VOP to a stable branch, +# the new VOP should replace one of the spares. + vop_spare4 { IN struct vnode *vp; }; --=-=-=-- From owner-freebsd-arch@FreeBSD.ORG Sun Apr 22 16:08:40 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 625151065674; Sun, 22 Apr 2012 16:08:40 +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 C74EA8FC17; Sun, 22 Apr 2012 16:08:39 +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 q3MG8YhI081977; Sun, 22 Apr 2012 19:08:34 +0300 (EEST) (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 q3MG8XkS041841; Sun, 22 Apr 2012 19:08:33 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q3MG8XSQ041840; Sun, 22 Apr 2012 19:08:33 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 22 Apr 2012 19:08:33 +0300 From: Konstantin Belousov To: Mikolaj Golub Message-ID: <20120422160833.GH2358@deviant.kiev.zoral.com.ua> References: <86hazntwmu.fsf@kopusha.home.net> <20120123031238.GL31224@deviant.kiev.zoral.com.ua> <86zkcfu9ac.fsf@kopusha.home.net> <20120218215003.GM3283@deviant.kiev.zoral.com.ua> <86ehtrf8qf.fsf@kopusha.home.net> <20120219170151.GS3283@deviant.kiev.zoral.com.ua> <86d393dvqr.fsf@kopusha.home.net> <20120225174818.GC55074@deviant.kiev.zoral.com.ua> <8B0B7D86-1EE6-4901-9E36-EA1918315163@freebsd.org> <86wr57lwgd.fsf@kopusha.home.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4WsPgToo9ew/WzEx" Content-Disposition: inline In-Reply-To: <86wr57lwgd.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=-4.0 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: "Bjoern A. Zeeb" , "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: Sun, 22 Apr 2012 16:08:40 -0000 --4WsPgToo9ew/WzEx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Apr 22, 2012 at 04:36:50PM +0300, Mikolaj Golub wrote: > Hi, >=20 > On Sat, 25 Feb 2012 19:16:08 +0000 Robert N. M. Watson wrote: >=20 > RNMW> On 25 Feb 2012, at 17:48, Konstantin Belousov wrote: >=20 > >>> I am thinking now about 'MFC after'. Thanks to jhb's spare vops it l= ooks like > >>> it is possible to merge it in stable/9 without breaking the KBI, but= then I > >>> will consume 3 of 5 available spare vops. So is it worth doing? > >> I do not think that we shall be so restrained on the use of spare VOP= s. >=20 > RNMW> I think the only real question here is whether John had specific t= hings > RNMW> in mind when he added the spares, or whether they are open for gen= eral > RNMW> use. Assuming they are open for general use, this use seems a quite > RNMW> beneficial one :-). >=20 > I am going to MFC VOP_UNP_* operations (r232317) and this is just to ask = the > last time if someone sees problems with this or would like to reserve the= m for > other things. >=20 > Also could you please look at the merge diff I am going to commit if it l= ooks > ok? Looks fine. --4WsPgToo9ew/WzEx Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk+ULQEACgkQC3+MBN1Mb4gdXgCfe2FRqhJYPEQaWhTpRj58aiD/ kCAAn14BwTp9f1+ow3NII9lXJRLe3QTh =XUVq -----END PGP SIGNATURE----- --4WsPgToo9ew/WzEx-- From owner-freebsd-arch@FreeBSD.ORG Tue Apr 24 19:16:40 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 17BB81065677; Tue, 24 Apr 2012 19:16:40 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id D3A3D8FC14; Tue, 24 Apr 2012 19:16:38 +0000 (UTC) Received: by lagv3 with SMTP id v3so1020622lag.13 for ; Tue, 24 Apr 2012 12:16:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:references:x-comment-to:sender:date:in-reply-to :message-id:user-agent:mime-version:content-type; bh=opLLZqclWG9BbSbjeX7APwjamYbdBTEaS/YPyMxGw1I=; b=o8n3Mk5rczc5Yuwaao7qt0CYsR0BlpGSgwhjv3vTluKVmSBTOFKFwVPLfhS5aqS6Zk pRkwVEsWBNlJeBEk4suzBli9pOiSK0dwKjqG1PlmhhXv3OpIUril5GBtH5miQuF+RAaq Qzbv9CUrc5eEeuYAGThHbFE7e5Kxogp1/xZ/l8VwW/eWpFygp1cV/s41W1OW2BiytoLq 4AAwSI88YzaxxokflGzvb5rI4G/OwEJTuHHfYTE7R7lHDVJi006sUU4A1hHtNhtZfc/0 d5VjNseO98QqFTHOU65EZQZsS4iaIKZochPxkx0V6bowhiViI0ddmKbJarE5IHMoHPz2 3vUw== Received: by 10.112.45.230 with SMTP id q6mr9913702lbm.103.1335294992157; Tue, 24 Apr 2012 12:16:32 -0700 (PDT) Received: from localhost ([95.69.173.122]) by mx.google.com with ESMTPS id pj20sm19933411lab.13.2012.04.24.12.16.28 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 24 Apr 2012 12:16:29 -0700 (PDT) From: Mikolaj Golub To: Konstantin Belousov References: <86hazntwmu.fsf@kopusha.home.net> <20120123031238.GL31224@deviant.kiev.zoral.com.ua> <86zkcfu9ac.fsf@kopusha.home.net> <20120218215003.GM3283@deviant.kiev.zoral.com.ua> <86ehtrf8qf.fsf@kopusha.home.net> <20120219170151.GS3283@deviant.kiev.zoral.com.ua> <86d393dvqr.fsf@kopusha.home.net> <20120225174818.GC55074@deviant.kiev.zoral.com.ua> <8B0B7D86-1EE6-4901-9E36-EA1918315163@freebsd.org> <86wr57lwgd.fsf@kopusha.home.net> <20120422160833.GH2358@deviant.kiev.zoral.com.ua> X-Comment-To: Konstantin Belousov Sender: Mikolaj Golub Date: Tue, 24 Apr 2012 22:16:26 +0300 In-Reply-To: <20120422160833.GH2358@deviant.kiev.zoral.com.ua> (Konstantin Belousov's message of "Sun, 22 Apr 2012 19:08:33 +0300") Message-ID: <864ns9ey9h.fsf@kopusha.home.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "Bjoern A. Zeeb" , "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: Tue, 24 Apr 2012 19:16:40 -0000 On Sun, 22 Apr 2012 19:08:33 +0300 Konstantin Belousov wrote: KB> On Sun, Apr 22, 2012 at 04:36:50PM +0300, Mikolaj Golub wrote: >> Hi, >> >> On Sat, 25 Feb 2012 19:16:08 +0000 Robert N. M. Watson wrote: >> >> RNMW> On 25 Feb 2012, at 17:48, Konstantin Belousov wrote: >> >> >>> I am thinking now about 'MFC after'. Thanks to jhb's spare vops it looks like >> >>> it is possible to merge it in stable/9 without breaking the KBI, but then I >> >>> will consume 3 of 5 available spare vops. So is it worth doing? >> >> I do not think that we shall be so restrained on the use of spare VOPs. >> >> RNMW> I think the only real question here is whether John had specific things >> RNMW> in mind when he added the spares, or whether they are open for general >> RNMW> use. Assuming they are open for general use, this use seems a quite >> RNMW> beneficial one :-). >> >> I am going to MFC VOP_UNP_* operations (r232317) and this is just to ask the >> last time if someone sees problems with this or would like to reserve them for >> other things. >> >> Also could you please look at the merge diff I am going to commit if it looks >> ok? KB> Looks fine. Thanks, merged. -- Mikolaj Golub