Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753993AbaFKJdE (ORCPT ); Wed, 11 Jun 2014 05:33:04 -0400 Received: from mail04-md.ns.itscom.net ([175.177.155.114]:33604 "EHLO mail04-md.ns.itscom.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753251AbaFKJdD (ORCPT ); Wed, 11 Jun 2014 05:33:03 -0400 From: "J. R. Okajima" Subject: Re: Linux 3.15 .. and continuation of merge window To: Al Viro Cc: Linus Torvalds , Linux Kernel Mailing List In-Reply-To: <20140611011036.GV18016@ZenIV.linux.org.uk> References: <13591.1402284634@jrobl> <20140611011036.GV18016@ZenIV.linux.org.uk> Date: Wed, 11 Jun 2014 18:32:58 +0900 Message-ID: <26914.1402479178@jrobl> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Al Viro: > So I suspect that the right fix is a bit trickier - in addition to check > on the fast path (i.e. when trylock gets us the lock on parent), we need > to > * get rcu_read_lock() before dropping ->d_lock. > * check if dentry is already doomed right after taking rcu_read_lock(); > if not, any value we might see in ->d_parent afterwards will point to object > not freed until we drop rcu_read_lock. > > IOW, something like the delta below. Comments? I will try testing later. For now, as a comment before testing, the patch looks weird for me. It checks d_lockref.count twice during d_lockref.lock held. It must be the same result, isn't it? Or does it mean that denty can be handled by lockref_mark_dead() even if d_lockref.lock is held? J. R. Okajima -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/