From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from zeniv.linux.org.uk ([195.92.253.2]:54522 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750917AbcGUF5M (ORCPT ); Thu, 21 Jul 2016 01:57:12 -0400 Date: Thu, 21 Jul 2016 06:57:07 +0100 From: Al Viro To: hejianet Cc: Feifei Xu , linux-fsdevel@vger.kernel.org, xuhilar@gmail.com, boqun.feng@gmail.com Subject: Re: [Bug] fs/dcache.c: NULL pointer dereference on dentry_string_cmp Message-ID: <20160721055707.GL2356@ZenIV.linux.org.uk> References: <83724554-69c8-2b87-8e43-7ad252ec18c8@linux.vnet.ibm.com> <20160720055941.GJ2356@ZenIV.linux.org.uk> <57903F70.5030206@gmail.com> <20160721041857.GK2356@ZenIV.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160721041857.GK2356@ZenIV.linux.org.uk> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Thu, Jul 21, 2016 at 05:18:57AM +0100, Al Viro wrote: > Hash insertion does smp_store_release(). Hash chain traversal - > smp_read_barrier_depends(). On ppc the former is lwsync, while the latter > is no-op, so it boils down to > store dentry->d_name.name > lwsync > store mangled address of dentry into hash chain > vs. > fetch mangled address of dentry > demangle it > fetch dentry->d_name.name > which should be enough - lwsync paired with address dependency gives the > ordering. IOW, it's not about the barriers in __d_alloc(), it's those in > hlist_bl_add_head_rcu() and hlist_bl_for_each_entry_rcu(). > > And it couldn't be a missing barrier anyway - crash dump shows that > sucker with NULL ->d_name.name. FWIW, originally I thought it might be a missing barrier; Paul McKenney had pointed to barriers in RCU lists primitives. And crashdump is pretty much conclusive - broken barriers or not, having a store in some thread *not* seen by crashdump writer is hard to believe...