diff options
| author | Al Viro <viro@zeniv.linux.org.uk> | 2025-11-19 19:19:24 -0500 |
|---|---|---|
| committer | Al Viro <viro@zeniv.linux.org.uk> | 2026-01-13 15:16:44 -0500 |
| commit | c3a3577cdb351e74d6ff6bc328c3bee18ce69298 (patch) | |
| tree | a6cc8bf639f141fc70be2fcb0d17114100e30487 /include/linux/extcon | |
| parent | 8f2ac8481731fb5d01ad54f66aa0334a8913b3c2 (diff) | |
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>
Diffstat (limited to 'include/linux/extcon')
0 files changed, 0 insertions, 0 deletions
