Hey Linus,

/* Summary */

This adds case-insensitive support for tmpfs.

The work contained in here adds support for case-insensitive file names
lookups in tmpfs. The main difference from other casefold filesystems is
that tmpfs has no information on disk, just on RAM, so we can't use mkfs
to create a case-insensitive tmpfs. For this implementation, there's a
mount option for casefolding. The rest of the patchset follows a similar
approach as ext4 and f2fs.

The use case for this feature is similar to the use case for ext4, to
better support compatibility layers (like Wine), particularly in
combination with sandboxing/container tools (like Flatpak).

Those containerization tools can share a subset of the host filesystem
with an application. In the container, the root directory and any parent
directories required for a shared directory are on tmpfs, with the
shared directories bind-mounted into the container's view of the
filesystem.

If the host filesystem is using case-insensitive directories, then the
application can do lookups inside those directories in a
case-insensitive way, without this needing to be implemented in
user-space. However, if the host is only sharing a subset of a
case-insensitive directory with the application, then the parent
directories of the mount point will be part of the container's root
tmpfs. When the application tries to do case-insensitive lookups of
those parent directories on a case-sensitive tmpfs, the lookup will
fail.

/* Testing */

gcc version 14.2.0 (Debian 14.2.0-6)
Debian clang version 16.0.6 (27+b1)

All patches are based on v6.12-rc4 and have been sitting in linux-next.
No build failures or warnings were observed.

/* Conflicts */

Merge conflicts with mainline
=============================

No known conflicts.

Merge conflicts with other trees
================================

No known conflicts.

This will have a minor merge conflict with the vfs-6.13.file pull request I
sent as:

https://lore.kernel.org/r/20241115-vfs-file-f2297d7c58ee@brauner

The resolution for the conflict should look like this:

diff --cc include/linux/fs.h
index 3e53ba079f17,001d580af862..eae7ce884030
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@@ -45,7 -45,7 +45,8 @@@
  #include <linux/slab.h>
  #include <linux/maple_tree.h>
  #include <linux/rw_hint.h>
 +#include <linux/file_ref.h>
+ #include <linux/unicode.h>

The following changes since commit 42f7652d3eb527d03665b09edac47f85fb600924:

  Linux 6.12-rc4 (2024-10-20 15:19:38 -0700)

are available in the Git repository at:

  git@gitolite.kernel.org:pub/scm/linux/kernel/git/vfs/vfs tags/vfs-6.13.tmpfs

for you to fetch changes up to 552b15103db404c7971d4958e6e28d4e7123a325:

  Merge patch series "tmpfs: Casefold fixes" (2024-11-06 11:22:30 +0100)

Please consider pulling these changes from the signed vfs-6.13.tmpfs tag.

Thanks!
Christian

----------------------------------------------------------------
vfs-6.13.tmpfs

----------------------------------------------------------------
André Almeida (12):
      libfs: Create the helper function generic_ci_validate_strict_name()
      ext4: Use generic_ci_validate_strict_name helper
      unicode: Export latest available UTF-8 version number
      unicode: Recreate utf8_parse_version()
      libfs: Export generic_ci_ dentry functions
      tmpfs: Add casefold lookup support
      tmpfs: Add flag FS_CASEFOLD_FL support for tmpfs dirs
      tmpfs: Expose filesystem features via sysfs
      docs: tmpfs: Add casefold options
      libfs: Fix kernel-doc warning in generic_ci_validate_strict_name
      tmpfs: Fix type for sysfs' casefold attribute
      tmpfs: Initialize sysfs during tmpfs init

Christian Brauner (2):
      Merge patch series "tmpfs: Add case-insensitive support for tmpfs"
      Merge patch series "tmpfs: Casefold fixes"

 Documentation/filesystems/tmpfs.rst |  24 ++++
 fs/ext4/namei.c                     |   5 +-
 fs/libfs.c                          |  12 +-
 fs/unicode/utf8-core.c              |  26 ++++
 fs/unicode/utf8-selftest.c          |   3 -
 include/linux/fs.h                  |  49 +++++++
 include/linux/shmem_fs.h            |   6 +-
 include/linux/unicode.h             |   4 +
 mm/shmem.c                          | 265 ++++++++++++++++++++++++++++++++++--
 9 files changed, 371 insertions(+), 23 deletions(-)

The pull request you sent on Fri, 15 Nov 2024 15:06:58 +0100:

> git@gitolite.kernel.org:pub/scm/linux/kernel/git/vfs/vfs tags/vfs-6.13.tmpfs

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/7956186e751bc15541ede638008feedc0e427883

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html

On Fri, 15 Nov 2024 at 06:07, Christian Brauner <brauner@kernel.org> wrote:
>
> This adds case-insensitive support for tmpfs.

Ugh.

I've pulled this, but I don't love it.

This pattern:

    if (IS_ENABLED(CONFIG_UNICODE) && IS_CASEFOLDED(dir))
        d_add(dentry, inode);
    else
        d_instantiate(dentry, inode);

needs an explanation, and probably a helper.

And

>  include/linux/shmem_fs.h            |   6 +-
>  mm/shmem.c                          | 265 ++++++++++++++++++++++++++++++++++--

I'm starting to think this should be renamed and/or possibly split up
a bit. The actual path component handling functions should be moved
out of mm/shmem.c.

The whole "mm/shmem.c" thing made sense back in the days when this was
mainly about memory management functions with some thing wrappers for
exposing them as a filesystem, and tmpfs was kind of an odd special
case.

Those thin wrappers aren't very thin any more, and "shmem" is becoming
something of a misnomer with the actual filesystem being called
"tmpfs".

We also actually have *two* different implementations of "tmpfs" -
both in that same file - which is really annoying. The other one is
based on the ramfs code.

Would it be possible to try to make this a bit saner?

           Linus

On Mon, Nov 18, 2024 at 11:26:12AM -0800, Linus Torvalds wrote:
> On Fri, 15 Nov 2024 at 06:07, Christian Brauner <brauner@kernel.org> wrote:
> >
> > This adds case-insensitive support for tmpfs.
> 
> Ugh.
> 
> I've pulled this, but I don't love it.
> 
> This pattern:
> 
>     if (IS_ENABLED(CONFIG_UNICODE) && IS_CASEFOLDED(dir))
>         d_add(dentry, inode);
>     else
>         d_instantiate(dentry, inode);
> 
> needs an explanation, and probably a helper.

I think we had this discussion before where we decided to move all the
checks inline. But yes, this could probably be refactored to be easier
to understand.

> 
> And
> 
> >  include/linux/shmem_fs.h            |   6 +-
> >  mm/shmem.c                          | 265 ++++++++++++++++++++++++++++++++++--
> 
> I'm starting to think this should be renamed and/or possibly split up
> a bit. The actual path component handling functions should be moved
> out of mm/shmem.c.
> 
> The whole "mm/shmem.c" thing made sense back in the days when this was
> mainly about memory management functions with some thing wrappers for
> exposing them as a filesystem, and tmpfs was kind of an odd special
> case.
> 
> Those thin wrappers aren't very thin any more, and "shmem" is becoming
> something of a misnomer with the actual filesystem being called
> "tmpfs".
> 
> We also actually have *two* different implementations of "tmpfs" -
> both in that same file - which is really annoying. The other one is
> based on the ramfs code.
> 
> Would it be possible to try to make this a bit saner?

So one possibility would be to move tmpfs into fs and have fs/tmpfs/ (or
mm/tmpfs/) which would also be nice because mm/shmem.c is actively
confusing when you're looking for the tmpfs code. And then it could
simply be split up. I'm all for it.