Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Thu, 25 Oct 2018 13:43:44 +0200
From:   Martin Schwidefsky <schwidefsky@de.ibm.com>
To:     Al Viro <viro@zeniv.linux.org.uk>
Cc:     linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: dcache endless loop in d_invalidate
In-Reply-To: <20181016131528.6aac4876@mschwideX1>
References: <20181016131528.6aac4876@mschwideX1>
MIME-Version: 1.0
Message-Id: <20181025134344.75484f14@mschwideX1>
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 8bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Tue, 16 Oct 2018 13:15:28 +0200
Martin Schwidefsky <schwidefsky@de.ibm.com> wrote:

> In short, this if-statement in select_collect:
> 
>         if (dentry->d_flags & DCACHE_SHRINK_LIST) {
>                 data->found++;
>         }
> 
> with assumption that "somebody else" will do the shrinking seems broken.
> 
> Do you agree?

If I am not mistaken this problem should be fixed by upstream commit
4fb4887140 "restore cond_resched() in shrink_dcache_parent()"
which goes on top of
ff17fa561a "d_invalidate(): unhash immediately"

Due to the cond_resched() the task that set DCACHE_SHRINK_LIST for the
remaining two dcache entries will be scheduled eventually. This will
allow the task waiting for the deletion of these dcache entries 
to continue, although some CPU cycles may get wasted.

-- 
blue skies,
   Martin.

"Reality continues to ruin my life." - Calvin.