]> git.ipfire.org Git - thirdparty/kernel/linux.git/commit
struct filename: use names_cachep only for getname() and friends
authorAl Viro <viro@zeniv.linux.org.uk>
Thu, 20 Nov 2025 00:19:24 +0000 (19:19 -0500)
committerAl Viro <viro@zeniv.linux.org.uk>
Tue, 13 Jan 2026 20:16:44 +0000 (15:16 -0500)
commitc3a3577cdb351e74d6ff6bc328c3bee18ce69298
treea6cc8bf639f141fc70be2fcb0d17114100e30487
parent8f2ac8481731fb5d01ad54f66aa0334a8913b3c2
struct filename: use names_cachep only for getname() and friends

        Instances of struct filename come from names_cachep (via
__getname()).  That is done by getname_flags() and getname_kernel()
and these two are the main callers of __getname().  However, there are
other callers that simply want to allocate PATH_MAX bytes for uses that
have nothing to do with struct filename.

We want saner allocation rules for long pathnames, so that struct
filename would *always* come from names_cachep, with the out-of-line
pathname getting kmalloc'ed.  For that we need to be able to change the
size of objects allocated by getname_flags()/getname_kernel().

That requires the rest of __getname() users to stop using
names_cachep; we could explicitly switch all of those to kmalloc(),
but that would cause quite a bit of noise.  So the plan is to switch
getname_...() to new helpers and turn __getname() into a wrapper for
kmalloc().  Remaining __getname() users could be converted to explicit
kmalloc() at leisure, hopefully along with figuring out what size do
they really want - PATH_MAX is an overkill for some of them, used out
of laziness ("we have a convenient helper that does 4K allocations and
that's large enough, let's use it").

As a side benefit, names_cachep is no longer used outside
of fs/namei.c, so we can move it there and be done with that.

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
fs/dcache.c
fs/internal.h
fs/namei.c
include/linux/fs.h