tree b6e06cc44d01d75e3e87559be354f79865998d6c
parent 4db814d5ee48904d827b276160b04117f9b42e9d
author Zim <zezeozue@google.com> 1591699833 +0100
committer Zimuzo Ezeozue <zezeozue@google.com> 1591890304 +0000

Reuse nodes for case-insensitive lookups

Previously, node lookups were case-sensitive. This meant that if the
kernel did a lookup for foo and FOO, the FuseDaemon will create two
different nodes.

This led to some unexpected behavior when doing IO with
case-insensitive files.
1. The kernel may have a dentry left in its cache even after an unlink
2. It may use different page caches when two case-insensitive matching
files are open at the same time.

Previous attempts at fixing this,
Id45f2fe398e962ca0b16f41f628ad2fc5d849481 explicitly invalidated
case-insensitive dentries but still created a new FUSE (userspace)
node. Unfortunately, this fixed only (1) and had resulted in a
segfault, b/158313907 introduced in
Ic7613d1b5325bf7466cd94fe6c713bc55aeacd79.

Now, we fix all issues by reusing nodes. So there is only one
userspace node per case-insensitive match. This causes the kernel to
reuse inodes for case-insensitive matches even though it still has two
different dentries. This fixes (2) and we still rely on explicit
invalidations to keep (1) fixed.

Refcounting while reusing nodes should be correct because:

ref(foo{kernel}) + ref(FOO{kernel}) = ref{foo{userspace}}

And since we invalidate dentries in the kernel, at the end of a
case-insensitive lookup, the userspace refcounts should still match
the refcount of the one dentry in the kernel.

Test: ScopedStorageTest#testCaseInsensitivity
Bug: 158313907
Bug: 157676443
Change-Id: I83ffd660bc3d6843901e838a53eacec6883fef52