From owner-freebsd-arch@FreeBSD.ORG Sat Mar 14 00:15:32 2015 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D9DE1CF9; Sat, 14 Mar 2015 00:15:31 +0000 (UTC) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 668A9CDF; Sat, 14 Mar 2015 00:15:31 +0000 (UTC) Received: by webcq43 with SMTP id cq43so2618431web.2; Fri, 13 Mar 2015 17:15:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=8vJSl0ejEwo197LUGo/c8l5cr6TVHx4WCnYJONbAl8s=; b=hXxpRjPM3KsrMBDYHc3MUa69uSEvzUsbu0BxqnQeRgJzNDAlJX0+aNGqDagzZbbxMG Wy4u/7T9/lj1DVnzRLWsTLI6aJ9h3ZMes1NodJmnh6NQee31hZQ7/hOP2+8VGL7U0OT3 UyTVyjhxD5Gn87MDR1DHywL0u1sklSAUFC+S/z1qOXPD20iQbOzenbKhV9+Cut97OrKD 2l1zUiSwLh3Vi/dbpgSzpS4T3vtHeOVr0MI2/eyu1bPBim8OL0p/MiAau43tbkxK6HTJ pLgfL245u3KNJYY20QLG2E+V/ZlX4eV5uYooDmSL0zmIrnrvMsrjz+czP2PRf+I3kHf7 PLEg== X-Received: by 10.180.105.40 with SMTP id gj8mr147563248wib.67.1426292129783; Fri, 13 Mar 2015 17:15:29 -0700 (PDT) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPSA id n6sm4868661wjy.8.2015.03.13.17.15.28 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Fri, 13 Mar 2015 17:15:28 -0700 (PDT) Date: Sat, 14 Mar 2015 01:15:26 +0100 From: Mateusz Guzik To: John-Mark Gurney Subject: Re: refcount_release_take_##lock Message-ID: <20150314001526.GC32157@dft-labs.eu> References: <20141025184448.GA19066@dft-labs.eu> <201410281413.58414.jhb@freebsd.org> <20141028193404.GB12014@dft-labs.eu> <201411111427.15407.jhb@freebsd.org> <20150313231607.GB32157@dft-labs.eu> <20150313235838.GM32288@funkthat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20150313235838.GM32288@funkthat.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2015 00:15:32 -0000 On Fri, Mar 13, 2015 at 04:58:38PM -0700, John-Mark Gurney wrote: > Mateusz Guzik wrote this message on Sat, Mar 14, 2015 at 00:16 +0100: > > In the meantime I wrote a new version. > > > > Apart from locking-handling primitives this time we get > > refcount_acquire_if_greater and refcount_release_if_greater helpers. > > I don't see how this is of any benefit... The smallest value you can > provide is 0, which means the only time a reference can be obtained is > if the caller already has a reference. If you don't have a reference > (making it =0), it isn't safe to call this function on the object, as > it could be free'd, and point to a different type of object... Even if > you implement type-safe memory (which we shouldn't use more of), it's > less than ideal, since you then have to check if the object is the same > object you were expecting, and need to release it... > > The release_if is even more problematic IMO... > I see I forgot to note the rationale in my e-mail. The kernel already uses 'refing an object with ref = 0' extensively in vfs. For instance entering a name to the namecache does not increase hold count of the vnode. A thread doing lookup locks the cache shared, locks the interlock, unlocks the cache and calls vget which blindly vholds the vnode, which quite often does transition 0->1. What prevents freeing of the vnode is name cache lock and later the interlock. All v_holdcnt manipulation is done with the interlock held. Crucial value changes are 0->1 and 1->0 and we need the lock here to ensure consistency. However, as long as we modify this counter in a way which does not go 0->1 nor 1->0 we don't have take the interlock and not doing so increases scalability. So for instance in aforementioned case of namecache, the vnode is kept stable by namecache lock and if v_holdcnt is >=1, we can increase it without taking the interlock which I plan to do. But in order to do that I need primitives which wrap such functionality. Once more, stability of the object in question has to be ensured in other manners. > After reading the previous discussion, I really don't like this. If > this gets approved (others override my objection), we need some docs > that say this should never be used, and it's use is only in the unsafe > case where the containing data structure does NOT have a reference to > the object. Well it should be quite obvious you can't just ref random objects. :> -- Mateusz Guzik