From owner-freebsd-arch@FreeBSD.ORG Sat Feb 18 21:22:11 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 F1E75106566B; Sat, 18 Feb 2012 21:22:11 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 213B18FC1C; Sat, 18 Feb 2012 21:22:10 +0000 (UTC) Received: by bkcjg1 with SMTP id jg1so5176370bkc.13 for ; Sat, 18 Feb 2012 13:22:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:subject:references:x-comment-to:sender:date:in-reply-to :message-id:user-agent:mime-version:content-type; bh=AYzxStlQ9pjU3r6CsNRbGAsGqG6qLF0UwM66gn0enNc=; b=kAC+sntgADq20MYz2kJCJDbpD6HCBf0HugFIFexKD98ItxreMIGPATRWCaglTQf/1t lrhSQ6vOGvfhJm7IowsnLihNPj14z71G0UdunyKGTrT0fqbNmKpIJguChIGYJWHw90sN +l63z+c4OgSfZo7nDGz9MY4XixCIkNbvbjQIY= Received: by 10.204.129.208 with SMTP id p16mr6534331bks.131.1329600128557; Sat, 18 Feb 2012 13:22:08 -0800 (PST) Received: from localhost ([95.69.173.122]) by mx.google.com with ESMTPS id ey8sm29979528bkb.1.2012.02.18.13.22.05 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 18 Feb 2012 13:22:06 -0800 (PST) From: Mikolaj Golub To: Kostik Belousov References: <86sjjobzmn.fsf@kopusha.home.net> <86fwfnti5t.fsf@kopusha.home.net> <20120112215106.GC31224@deviant.kiev.zoral.com.ua> <86hazntwmu.fsf@kopusha.home.net> <20120123031238.GL31224@deviant.kiev.zoral.com.ua> X-Comment-To: Kostik Belousov Sender: Mikolaj Golub Date: Sat, 18 Feb 2012 23:22:03 +0200 In-Reply-To: <20120123031238.GL31224@deviant.kiev.zoral.com.ua> (Kostik Belousov's message of "Mon, 23 Jan 2012 05:12:38 +0200") Message-ID: <86zkcfu9ac.fsf@kopusha.home.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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: Sat, 18 Feb 2012 21:22:12 -0000 On Mon, 23 Jan 2012 05:12:38 +0200 Kostik Belousov wrote: KB> On Sun, Jan 22, 2012 at 08:33:45PM +0200, Mikolaj Golub wrote: >> >> 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? KB> Yes. >> >> 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. KB> The lack of the cleanup in the reclamation code. >> >> 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? KB> No, usecount must not be dropped. The hold count counts the owners of KB> the pointer to the vnode, preventing the freeing of the struct vnode KB> itself. Usecount is to avoid non-forced unmounts from reclaiming the KB> vnode. >> >> 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 KB> Not in the vflush(). I think vgonel() would be better place. After collecting all suggestions and additional testing I have got this patch set: http://people.freebsd.org/~trociny/unp_prepare_reclaim.1.patch http://people.freebsd.org/~trociny/unp_connect.LOCKSHARED.1.patch http://people.freebsd.org/~trociny/VOP_UNP.3.patch It has survived some bind/connect/force umount stress testing revealing only some issues that are also observed without patching. -- Mikolaj Golub