From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965687AbdGTOVl convert rfc822-to-8bit (ORCPT ); Thu, 20 Jul 2017 10:21:41 -0400 Received: from mx1.redhat.com ([209.132.183.28]:35262 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754397AbdGTOVh (ORCPT ); Thu, 20 Jul 2017 10:21:37 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com C217FC001CD7 Authentication-Results: ext-mx08.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx08.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=longman@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com C217FC001CD7 Subject: Re: [PATCH 1/4] fs/dcache: Limit numbers of negative dentries To: Miklos Szeredi Cc: Alexander Viro , Jonathan Corbet , lkml , linux-doc@vger.kernel.org, linux-fsdevel , "Paul E. McKenney" , Andrew Morton , Ingo Molnar References: <1500298773-7510-1-git-send-email-longman@redhat.com> <1500298773-7510-2-git-send-email-longman@redhat.com> <470a8774-9491-85a2-5353-1498f336e69f@redhat.com> From: Waiman Long Organization: Red Hat Message-ID: Date: Thu, 20 Jul 2017 10:21:35 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT Content-Language: en-US X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Thu, 20 Jul 2017 14:21:37 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 07/20/2017 03:20 AM, Miklos Szeredi wrote: > On Wed, Jul 19, 2017 at 10:42 PM, Waiman Long wrote: >> >>>> @@ -603,7 +698,13 @@ static struct dentry *dentry_kill(struct dentry *dentry) >>>> >>>> if (!IS_ROOT(dentry)) { >>>> parent = dentry->d_parent; >>>> - if (unlikely(!spin_trylock(&parent->d_lock))) { >>>> + /* >>>> + * Force the killing of this negative dentry when >>>> + * DCACHE_KILL_NEGATIVE flag is set. >>>> + */ >>>> + if (unlikely(dentry->d_flags & DCACHE_KILL_NEGATIVE)) { >>>> + spin_lock(&parent->d_lock); >>> This looks like d_lock ordering problem (should be parent first, child >>> second). Why is this needed, anyway? >>> >> Yes, that is a bug. I should have used lock_parent() instead. > lock_parent() can release dentry->d_lock, which means it's perfectly > useless for this. As the reference count is kept at 1 in dentry_kill(), the dentry won't go away even if the dentry lock is temporarily released. > I still feel forcing free is wrong here. Why not just block until > the number of negatives goes below the limit (start reclaim if not > already doing so, etc...)? Force freeing is the simplest. Any other ways will require adding more code and increasing code complexity. One reason why I prefer this is to avoid adding unpredictable latency to the regular directory lookup and other dentry related operations. We can always change the code later on if there is a better way of doing it. Cheers, Longman