From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-fsdevel-owner@vger.kernel.org>
Received: from zeniv.linux.org.uk ([195.92.253.2]:53396 "EHLO
	ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S932288AbcCJVRb (ORCPT
	<rfc822;linux-fsdevel@vger.kernel.org>);
	Thu, 10 Mar 2016 16:17:31 -0500
Date: Thu, 10 Mar 2016 21:17:29 +0000
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: linux-fsdevel@vger.kernel.org
Subject: Re: do we need that smp_wmb() in __d_alloc()?
Message-ID: <20160310211729.GN17997@ZenIV.linux.org.uk>
References: <498D5A19-9E55-48D7-B5CF-34CA5769FF7F@intel.com>
 <20160308211148.GX17997@ZenIV.linux.org.uk>
 <A5CA4682-77B1-4DF4-A784-7C7C2FAFC9AF@intel.com>
 <20160309003416.GY17997@ZenIV.linux.org.uk>
 <7C3EBB6F-54AC-4744-BEC1-33EA82216F85@intel.com>
 <20160309012658.GZ17997@ZenIV.linux.org.uk>
 <34C2B1C3-2B7F-490B-A03A-3BCDDFC8BE48@intel.com>
 <20160310022041.GF17997@ZenIV.linux.org.uk>
 <20160310195951.GL17997@ZenIV.linux.org.uk>
 <20160310203428.GM17997@ZenIV.linux.org.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20160310203428.GM17997@ZenIV.linux.org.uk>
Sender: linux-fsdevel-owner@vger.kernel.org
List-ID: <linux-fsdevel.vger.kernel.org>

On Thu, Mar 10, 2016 at 08:34:28PM +0000, Al Viro wrote:

> Speaking of barriers - why do we need one there at all?  In __d_alloc(), that
> is.  Look: callers of __d_alloc() are:
> 	* d_alloc() - cycles parent's ->d_lock, inserts into the list of
> parent's children.  Anyone observing it on that list of children will be
> holding the same parent's ->d_lock.  And anyone finding it in any other way
> will have to observe the effect of store done after the write barrier in
> spin_unlock.

... which still leaves the possibility of both stores migrating inside the
lock/unlock pair and past each other.  IOW,
	lock parent's d_lock
	lock child's d_lock
	put into hash
	store terminating NUL in ->d_name
	unlock parent's d_lock
	unlock child's d_lock
is a possible sequence of events, with RCU access on another CPU observing
the damn without seeing the NUL-terminated name ;-/

Oh, well...