Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754875Ab3I2RUE (ORCPT ); Sun, 29 Sep 2013 13:20:04 -0400 Received: from mail-ve0-f171.google.com ([209.85.128.171]:49934 "EHLO mail-ve0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754270Ab3I2RUB (ORCPT ); Sun, 29 Sep 2013 13:20:01 -0400 MIME-Version: 1.0 In-Reply-To: <20130929060601.GL13318@ZenIV.linux.org.uk> References: <20130928202728.GK13318@ZenIV.linux.org.uk> <20130929060601.GL13318@ZenIV.linux.org.uk> Date: Sun, 29 Sep 2013 10:19:59 -0700 X-Google-Sender-Auth: LtqcXp42FBJ8pKUk3eKVVyI5-Q8 Message-ID: Subject: Re: [rfc][possible solution] RCU vfsmounts From: Linus Torvalds To: Al Viro Cc: linux-fsdevel , Linux Kernel Mailing List Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1501 Lines: 31 On Sat, Sep 28, 2013 at 11:06 PM, Al Viro wrote: > > Sigh... Looks like there's a lot of fun in shrink_dcache_for_umount() - > at the very least, it needs to bump ->d_seq on everything, because with > that change we *can* walk into a filesystem in the middle of that. > We obviously don't want to slap rcu_barrier() into the final mntput() - I have to say, that when I was working with the dcache lockref code, I absolutely _detested_ the magical shrink_dcache_for_umount() code that violated all the locking rules. So I actually wouldn't mind at all if that was all forced to follow all the same rules that the live filesystem code is forced to follow. Yes, yes, it's going to slow things down, but it's not like umount() is _that_ performance critical. And I think the whole "let's ignore locking rules" actually comes from back when we had one global dcache_lock: we used to have batching in order to not hold the dcache_lock over long periods, and then it got converted to the per-dentry locking, and then that got removed entirely with the whole RCU lookup etc. So I would be *entirely* ok with having shrink_dcache_for_umount_subtree() take the d_lock on the dentry as it shrinks it etc etc. Linus -- 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/