From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-fsdevel-owner@vger.kernel.org>
Received: from zeniv.linux.org.uk ([195.92.253.2]:53740 "EHLO
	ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1753550AbcBXAhH (ORCPT
	<rfc822;linux-fsdevel@vger.kernel.org>);
	Tue, 23 Feb 2016 19:37:07 -0500
Date: Wed, 24 Feb 2016 00:37:04 +0000
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Mikulas Patocka <mikulas@artax.karlin.mff.cuni.cz>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	linux-fsdevel@vger.kernel.org
Subject: [RFC] hpfs_unlink() deadlock
Message-ID: <20160224003704.GO17997@ZenIV.linux.org.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: linux-fsdevel-owner@vger.kernel.org
List-ID: <linux-fsdevel.vger.kernel.org>

	Since "HPFS: Introduce a global mutex and lock it on every callback
from VFS" we had a deadlock in the "can't delete directory entry due to
lack of space, try to truncate the sucker first" path - hpfs_lock() held
through the area that contains notify_change() and hpfs_setattr() grabs
it again.  BKL != mutex...

	We could try to deal with that, but really, why not simply fail with
-ENOSPC there?  It still can happen, even after truncate, so it's not as if
the userland didn't have to cope with it.  And doing that would eliminate
the last user of dentry_unhash(), allowing to kill that crap as well...