From mboxrd@z Thu Jan 1 00:00:00 1970 From: Al Viro Subject: Re: dcache shrink list corruption? Date: Tue, 29 Apr 2014 22:48:42 +0100 Message-ID: <20140429214842.GL18016@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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Miklos Szeredi , Linus Torvalds , Linux Kernel Mailing List , linux-fsdevel To: Dave Chinner Return-path: Content-Disposition: inline In-Reply-To: <20140429211851.GA32204@dastard> Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Wed, Apr 30, 2014 at 07:18:51AM +1000, Dave Chinner wrote: > Seems like it would work, but it seems fragile to me - I'm > wondering how we can ensure that the private shrink list > manipulations can be kept private. > > We have a similar situation with the inode cache (private shrink > list) but the I_FREEING flag is set the entire time the inode is on > the shrink list. Any new hash lookup or attempt to grab the inode > that occurs while I_FREEING is set fails, so perhaps dentries also > need a well defined "being torn down and freed" state where new > references cannot be taken even though the dentry can still be > found... Ummm... You mean, have d_lookup() et.al. fail on something that is on a shrink list?