From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com ([209.132.183.28]:51642 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S935387AbdGTPqk (ORCPT ); Thu, 20 Jul 2017 11:46:40 -0400 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 Message-ID: <2e2d4e3a-0d86-1683-8f45-31e02e67ba10@redhat.com> Date: Thu, 20 Jul 2017 11:46:38 -0400 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT Content-Language: en-US Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On 07/20/2017 11:08 AM, Miklos Szeredi wrote: > On Thu, Jul 20, 2017 at 4:21 PM, Waiman Long wrote: >> 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. > It won't go away, but anything else might happen to it (ref grabbed by > somebody else, instantiated, etc). Don't see how it's going to be > better than the existing trylock. > > Thanks, > Miklos In the unlikely event that the reference count or the d_flags changes, we can abort the killing. Cheers, Longman