From mboxrd@z Thu Jan 1 00:00:00 1970 From: Al Viro Subject: [git pull] vfs.git Date: Wed, 28 May 2014 07:38:48 +0100 Message-ID: <20140528063847.GX18016@ZenIV.linux.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: linux-fsdevel@vger.kernel.org To: Linus Torvalds Return-path: Received: from zeniv.linux.org.uk ([195.92.253.2]:52522 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751155AbaE1Giu (ORCPT ); Wed, 28 May 2014 02:38:50 -0400 Content-Disposition: inline Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Oh, well... Still nothing useful on that livelock (I had something that looked kinda-sorta like a non-invasive solution, but it deadlocks), so it's just Miklos' vmsplice fix for now. Please, pull from the usual place - git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git for-linus Shortlog: Miklos Szeredi (1): vfs: fix vmplice_to_user() Diffstat: fs/splice.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) PS: livelock looks triggerable without check_submounts_and_drop() anywhere in sight - vfs_rmdir() does shrink_dcache_parent() on prospective victim right before calling ->rmdir(). So rmdir a vs rmdir a/b/c will get you shrink_dcache_parent() on a and a/b/c at the same time - no locks in common there. So we'll probably need to shift those calls after successful calls of ->rmdir() (and similar in overwriting ->rename()), in addition to whatever we cook in check_submounts_and_drop()... I still would like to see detailed traces on what gets triggered by udev - hopefully the patch I've sent to Mika won't disrupt the livelock by printks it's doing ;-/