From mboxrd@z Thu Jan 1 00:00:00 1970 From: Al Viro Subject: Re: dcache shrink list corruption? Date: Wed, 30 Apr 2014 00:20:13 +0100 Message-ID: <20140429232013.GM18016@ZenIV.linux.org.uk> References: <20140429160139.GA3113@tucsk.piliscsaba.szeredi.hu> <20140429181610.GJ18016@ZenIV.linux.org.uk> <20140429191015.GK18016@ZenIV.linux.org.uk> <20140429211851.GA32204@dastard> <20140429214842.GL18016@ZenIV.linux.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Dave Chinner , Miklos Szeredi , Linux Kernel Mailing List , linux-fsdevel To: Linus Torvalds Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Tue, Apr 29, 2014 at 04:04:11PM -0700, Linus Torvalds wrote: > But at a minimum, we have "d_op->d_prune()" that would now be possibly > be called for the old dentry *after* a new dentry has been allocated. > Not to mention the inode not having been dropped. So it looks like a > disaster where the filesystem now ends up having concurrent "live" > dentries for the same entry. Even if one of them is on its way out, > it's still visible to the filesystem. That makes me very > uncomfortable. > > I'm starting to think that Miklos' original patch (perhaps with the > spinlock split to at least be one per superblock) is the most > straightforward approach after all. It's annoying having to add locks > here, but the whole pruning path should not be a hotpath, so maybe > it's not actually a big deal. FWIW, my solution is more or less working; I'll give more local beating and post it...