linux-kernel - Re: [GIT PULL] vfs tmpfs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20241120-annahme-tilgen-cfa206be31ce@brauner>
Date: Wed, 20 Nov 2024 09:54:06 +0100
From: Christian Brauner <brauner@...nel.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [GIT PULL] vfs tmpfs

On Mon, Nov 18, 2024 at 11:26:12AM -0800, Linus Torvalds wrote:
> On Fri, 15 Nov 2024 at 06:07, Christian Brauner <brauner@...nel.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.