From owner-svn-src-all@freebsd.org Fri Jun 8 18:30:26 2018 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E5B05FD03B6; Fri, 8 Jun 2018 18:30:25 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-it0-x242.google.com (mail-it0-x242.google.com [IPv6:2607:f8b0:4001:c0b::242]) (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 7EDDA6E526; Fri, 8 Jun 2018 18:30:25 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-it0-x242.google.com with SMTP id u4-v6so3522746itg.0; Fri, 08 Jun 2018 11:30:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=OBUycBvq5IIeXbDY2myqnOGNf6ptjGXn38taexhEZVw=; b=h5uhzTm4JudcGMPm/30MIbvyZE9lmaLG+YuED1BTSYl7Xwn/Z0J0Z2UUoMoJ026YuU FBT5KF/ifFBYOnnMLpFhWkuDrVUsygqTG2r20YUJScN/3fg8Tqu0lPwl3YegkVFnPtaG OFLJW2RCbpSwIs45EWQhVdeDMzHVpBNm5RvyM93w3HLEP0EQS1JFPee88vRy4p9oq3vx ni424dUl4KxzTEE+ZgqC9lXsSfRXJACkmgjhPutorTq/0t3eeZXDKrZypOvyZQ4hHAJJ iJVVKWy+X26RL+2tJB+aKGMocjJcNqAJfCmNOkGtRq+8QWNXkiM+vpLf81Tdr6BIhR8f 5vvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=OBUycBvq5IIeXbDY2myqnOGNf6ptjGXn38taexhEZVw=; b=Ww60yoN53uI4QtyF11ERTaEHghVy1QTnErMXGrwxG9N0Hyl/yXfFS4f3s5ta0vG/+W i0Ti/nzsottxeHoOEQTRzyTu7UBxR8MzXi21KDzxt6M+equNmIgj0uIP9VOq3wIrQPDF 4L4d+FOBUzZRYqqbB8n4VlIIzHh9joOZDzm6krfJjcCizpI6OhPyQKr7XzhM94taU4Ef WJ1ClPhbKRQDoKAJuOUZEt8hdIl1jQiH4O4Xr5aQ5WUPlKhpmb0H/fIfMvOtWQvS3P6O 1AquG/LXV98RVp+7mvRMn6+K/+Rv5S15GBgEYZr83OD0cGH+gMbrPui8MCvEtDC3dAK3 bLKA== X-Gm-Message-State: APt69E3n6A/hB0lM2YlaawPIwzMjs/HJyoJLlZhySwcEorh8/RpElyK2 7BpXRcT8z/glgsOnQFidydQ= X-Google-Smtp-Source: ADUXVKKFHRVt/iZxgxpY8LIqc6hFAL5Ln8bDyMgQZbtZed+gnuuiWKa58kr7B9UDHbaEDCSwa2tLNA== X-Received: by 2002:a24:28c9:: with SMTP id h192-v6mr2789714ith.124.1528482624810; Fri, 08 Jun 2018 11:30:24 -0700 (PDT) Received: from pesky ([137.122.64.159]) by smtp.gmail.com with ESMTPSA id h68-v6sm1075525ith.28.2018.06.08.11.30.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 08 Jun 2018 11:30:23 -0700 (PDT) Sender: Mark Johnston Date: Fri, 8 Jun 2018 14:30:10 -0400 From: Mark Johnston To: Konstantin Belousov Cc: Ryan Libby , Mateusz Guzik , Justin Hibbits , src-committers , svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r334708 - head/sys/kern Message-ID: <20180608183010.GC65388@pesky> References: <201806061257.w56CvCwq089369@repo.freebsd.org> <20180606140311.GU2450@kib.kiev.ua> <20180608033242.GA54099@pesky> <20180608173755.GJ2450@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180608173755.GJ2450@kib.kiev.ua> User-Agent: Mutt/1.10.0 (2018-05-17) X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2018 18:30:26 -0000 On Fri, Jun 08, 2018 at 08:37:55PM +0300, Konstantin Belousov wrote: > On Thu, Jun 07, 2018 at 11:02:29PM -0700, Ryan Libby wrote: > > On Thu, Jun 7, 2018 at 10:03 PM, Mateusz Guzik wrote: > > > Checking it without any locks is perfectly valid in this case. It is done > > > after v_holdcnt gets bumped from a non-zero value. So at that time it > > > is at least two. Of course that result is stale as an arbitrary number of > > > other threads could have bumped and dropped the ref past that point. > > > The minimum value is 1 since we hold the ref. But this means the > > > vnode must not be on the free list and that's what the assertion is > > > verifying. > > > > > > The problem is indeed lack of ordering against the code clearing the > > > flag for the case where 2 threads to vhold and one does the 0->1 > > > transition. > > > > > > That said, the fence is required for the assertion to work. > > > > > > > Yeah, I agree with this logic. What I mean is that reordering between > > v_holdcnt 0->1 and v_iflag is normally settled by the release and > > acquisition of the vnode interlock, which we are supposed to hold for > > v_*i*flag. A quick scan seems to show all of the checks of VI_FREE that > > are not asserts do hold the vnode interlock. So, I'm just saying that I > > don't think the possible reordering affects them. > But do we know that only VI_FREE checks are affected ? > > My concern is that users of _vhold() rely on seeing up to date state of the > vnode, and VI_FREE is only an example of the problem. Most likely, the > code which fetched the vnode pointer before _vhold() call, should guarantee > visibility. Wouldn't this be a problem only if we permit lockless accesses of vnode state outside of _vhold() and other vnode subroutines? The current protocol requires that the interlock be held, and this synchronizes with code which performs 0->1 and 1->0 transitions of the hold count. If this requirement is relaxed in the future, then fences would indeed be needed.