Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753885Ab3CVBdh (ORCPT ); Thu, 21 Mar 2013 21:33:37 -0400 Received: from mail-vb0-f54.google.com ([209.85.212.54]:48394 "EHLO mail-vb0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751077Ab3CVBdg (ORCPT ); Thu, 21 Mar 2013 21:33:36 -0400 MIME-Version: 1.0 In-Reply-To: <20130322012208.GJ21522@ZenIV.linux.org.uk> References: <20130321204704.GZ21522@ZenIV.linux.org.uk> <20130321210255.GD16406@redhat.com> <20130321221256.GA30620@redhat.com> <20130321233630.GE21522@ZenIV.linux.org.uk> <20130322001257.GH21522@ZenIV.linux.org.uk> <20130322012208.GJ21522@ZenIV.linux.org.uk> Date: Thu, 21 Mar 2013 18:33:35 -0700 X-Google-Sender-Auth: _sr8YvtWC_8w-n6_90cfS1jEwgo Message-ID: Subject: Re: VFS deadlock ? From: Linus Torvalds To: Al Viro Cc: Dave Jones , Linux Kernel , "Eric W. Biederman" 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: 1098 Lines: 23 On Thu, Mar 21, 2013 at 6:22 PM, Al Viro wrote: > > In theory, we can make vfs_rmdir() and vfs_unlink() check the presense of > the corresponding method before locking the victim; that would suffice to > kludge around that mess on procfs. Along with ->d_inode comparison in > lock_rename() it *might* suffice. Hmm, yes. Maybe we can do that as a stopgap, backport that, and leave any bigger changes for the development tree. That would make the issue less urgent, never mind all the other worries about backporting complicated patches for subtle issues. I realize you aren't entirely thrilled about it, but we actually already seem to do that check in both vfs_rmdir().and vfs_unlink() before getting the child i_mutex. I wonder if that is because we've already seen lockdep splats for this case... 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/