Received-SPF: pass (google.com: best guess record for domain of linux-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Fri, 24 May 2019 23:58:47 -0400
From:   "Theodore Ts'o" <tytso@mit.edu>
To:     Gabriel Krisman Bertazi <krisman@collabora.com>
Cc:     linux-ext4@vger.kernel.org
Subject: Re: [PATCH] ext4: Fix dcache lookup of !casefolded directories
Message-ID: <20190525035847.GC4225@mit.edu>
References: <20190524224129.28525-1-krisman@collabora.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20190524224129.28525-1-krisman@collabora.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Sender: linux-ext4-owner@vger.kernel.org
Precedence: bulk

On Fri, May 24, 2019 at 06:41:29PM -0400, Gabriel Krisman Bertazi wrote:
> Found by visual inspection, this wasn't caught by my xfstest, since it's
> effect is ignoring positive dentries in the cache the fallback just goes
> to the disk.  it was introduced in the last iteration of the
> case-insensitive patch.
> 
> d_compare should return 0 when the entries match, so make sure we are
> correctly comparing the entire string if the encoding feature is set and
> we are on a case-INsensitive directory.
> 
> Fixes: b886ee3e778e ("ext4: Support case-insensitive file name lookups")
> Signed-off-by: Gabriel Krisman Bertazi <krisman@collabora.com>

Applied, thanks.

I'll note that half the implementations of *_d_compare seem to use
!!memcmp(), and half use memcmp().

The callers of d_compare only seems to care if it's 0 or != 0, so I
guess it doesn't matter...

				- Ted