From mboxrd@z Thu Jan 1 00:00:00 1970 From: Al Viro Subject: Re: dcache shrink list corruption? Date: Sat, 3 May 2014 19:25:28 +0100 Message-ID: <20140503182528.GO18016@ZenIV.linux.org.uk> References: <20140430023142.GN18016@ZenIV.linux.org.uk> <20140430091515.GB3113@tucsk.piliscsaba.szeredi.hu> <20140502055127.GH18016@ZenIV.linux.org.uk> <20140502210813.GB32527@tucsk.piliscsaba.szeredi.hu> <20140502224022.GJ18016@ZenIV.linux.org.uk> <20140503042604.GM18016@ZenIV.linux.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Miklos Szeredi , Dave Chinner , 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 Sat, May 03, 2014 at 11:07:57AM -0700, Linus Torvalds wrote: > Sure, umount itself should be serialized by the sb lock, so there > should be only one umount dentry collector. But why wouldn't there be > shrinkers active due to memory pressure? > > generic_unmount_super() is called by ->kill_sb(), which is done > *before* the superblock shrinker is unregistered So any memory > pressure during that will cause dentries to be shrunk other ways. > > What am I missing? This: if (!grab_super_passive(sb)) return SHRINK_STOP; before calling prune_dcache_sb(). grab_super_passive() returns with ->s_umount held shared on success (with down_read_trylock()) and ->kill_sb() is called only with ->s_umount held exclusive.