Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752039AbaBOWvR (ORCPT ); Sat, 15 Feb 2014 17:51:17 -0500 Received: from mail-ve0-f169.google.com ([209.85.128.169]:47210 "EHLO mail-ve0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750808AbaBOWvP (ORCPT ); Sat, 15 Feb 2014 17:51:15 -0500 MIME-Version: 1.0 In-Reply-To: <87bny8kqik.fsf_-_@xmission.com> References: <87a9kkax0j.fsf@xmission.com> <8761v7h2pt.fsf@tw-ebiederman.twitter.com> <87li281wx6.fsf_-_@xmission.com> <87ob28kqks.fsf_-_@xmission.com> <87bny8kqik.fsf_-_@xmission.com> Date: Sat, 15 Feb 2014 14:51:14 -0800 X-Google-Sender-Auth: W9loE_-WFT2tvgl6GGbqhpu8LmQ Message-ID: Subject: Re: [PATCH 02/11] vfs: More precise tests in d_invalidate From: Linus Torvalds To: "Eric W. Biederman" Cc: Al Viro , "Serge E. Hallyn" , Linux-Fsdevel , Kernel Mailing List , Andy Lutomirski , Rob Landley , Miklos Szeredi , Christoph Hellwig , Karel Zak , "J. Bruce Fields" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Feb 15, 2014 at 1:36 PM, Eric W. Biederman wrote: > > The one difference between d_invalidate and check_submounts_and_drop > is that d_invalidate must respect it when a d_revalidate method has > earlier called d_drop so preserve the d_unhashed check in > d_invalidate. What? There's another *huge* difference, namely locking. Your change has huge detrimental effects wrt d_lock - not only do you drop it for the local dentry (to then re-take it in check_submounts_and_drop()), but the whole check_submounts_and_drop thing walks the parent chain and locks each parent with the renamelock held for writing. So NAK on this patch, if for no other reason that you are not talking about the *huge* locking changes at all, and apparently completely ignored them. It's possible that you can argue that performance doesn't matter, and that all the extra huge locking overhead is immaterial because this is not commonly called, but no way in hell can I accept a patch with a commit message that basically lies by omission about what it is doing. This kills the whole series for me. I'm not going to bother trying to review the rest of the patches when the second patch already makes me go "Eric is trying to hide things". Because the locking changes aren't obvious in the patch without knowing what else is going on, and they certainly aren't mentioned in the commit message. 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/