linux-stable.git/fs/d_path.c, branch v7.0.10 Linux kernel stable tree dcache: permit dynamic_dname()s up to NAME_MAX 2026-05-23T11:08:27+00:00 Aleksa Sarai aleksa@amutable.com 2026-03-31T14:46:21+00:00 13ac062c45e436737b27f5e98c65d9154b79a6a1 [ Upstream commit 97b67e64affb0e709eeecc50f6a9222fc20bd14b ] dynamic_dname() has had an implicit limit of 64 characters since it was introduced in commit c23fbb6bcb3e ("VFS: delay the dentry name generation on sockets and pipes"), however it seems that this was a fairly arbitrary number (suspiciously it was double the previously hardcoded buffer size). NAME_MAX seems like a more reasonable and consistent limit for d_name lengths. While we're at it, we can also remove the unnecessary stack-allocated array and just memmove() the formatted string to the end of the buffer. It should also be noted that at least one driver (in particular, liveupdate's usage of anon_inode for session files) already exceeded this limit without noticing that readlink(/proc/self/fd/$n) always returns -ENAMETOOLONG, so this fixes those drivers as well. Fixes: 0153094d03df ("liveupdate: luo_session: add sessions support") Fixes: c23fbb6bcb3e ("VFS: delay the dentry name generation on sockets and pipes") Signed-off-by: Aleksa Sarai <aleksa@amutable.com> Link: https://patch.msgid.link/20260401-dynamic-dname-name_max-v1-1-8ca20ab2642e@amutable.com Tested-by: Luca Boccassi <luca.boccassi@gmail.com> Signed-off-by: Christian Brauner <brauner@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 97b67e64affb0e709eeecc50f6a9222fc20bd14b ]

dynamic_dname() has had an implicit limit of 64 characters since it was
introduced in commit c23fbb6bcb3e ("VFS: delay the dentry name
generation on sockets and pipes"), however it seems that this was a
fairly arbitrary number (suspiciously it was double the previously
hardcoded buffer size).

NAME_MAX seems like a more reasonable and consistent limit for d_name
lengths. While we're at it, we can also remove the unnecessary
stack-allocated array and just memmove() the formatted string to the end
of the buffer.

It should also be noted that at least one driver (in particular,
liveupdate's usage of anon_inode for session files) already exceeded
this limit without noticing that readlink(/proc/self/fd/$n) always
returns -ENAMETOOLONG, so this fixes those drivers as well.

Fixes: 0153094d03df ("liveupdate: luo_session: add sessions support")
Fixes: c23fbb6bcb3e ("VFS: delay the dentry name generation on sockets and pipes")
Signed-off-by: Aleksa Sarai <aleksa@amutable.com>
Link: https://patch.msgid.link/20260401-dynamic-dname-name_max-v1-1-8ca20ab2642e@amutable.com
Tested-by: Luca Boccassi <luca.boccassi@gmail.com>
Signed-off-by: Christian Brauner <brauner@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
fold fs_struct->{lock,seq} into a seqlock 2025-07-08T08:25:19+00:00 Al Viro viro@zeniv.linux.org.uk 2025-07-02T05:34:37+00:00 a683a5b2ba23598ad343e5ec10a4ef4077497fc9 The combination of spinlock_t lock and seqcount_spinlock_t seq in struct fs_struct is an open-coded seqlock_t (see linux/seqlock_types.h). Combine and switch to equivalent seqlock_t primitives. AFAICS, that does end up with the same sequence of underlying operations in all cases. While we are at it, get_fs_pwd() is open-coded verbatim in get_path_from_fd(); rather than applying conversion to it, replace with the call of get_fs_pwd() there. Not worth splitting the commit for that, IMO... A bit of historical background - conversion of seqlock_t to use of seqcount_spinlock_t happened several months after the same had been done to struct fs_struct; switching fs_struct to seqlock_t could've been done immediately after that, but it looks like nobody had gotten around to that until now. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Link: https://lore.kernel.org/20250702053437.GC1880847@ZenIV Acked-by: Ahmed S. Darwish <darwi@linutronix.de> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Christian Brauner <brauner@kernel.org> Signed-off-by: Christian Brauner <brauner@kernel.org> 
	The combination of spinlock_t lock and seqcount_spinlock_t seq
in struct fs_struct is an open-coded seqlock_t (see linux/seqlock_types.h).
	Combine and switch to equivalent seqlock_t primitives.  AFAICS,
that does end up with the same sequence of underlying operations in all
cases.
	While we are at it, get_fs_pwd() is open-coded verbatim in
get_path_from_fd(); rather than applying conversion to it, replace with
the call of get_fs_pwd() there.  Not worth splitting the commit for that,
IMO...

	A bit of historical background - conversion of seqlock_t to
use of seqcount_spinlock_t happened several months after the same
had been done to struct fs_struct; switching fs_struct to seqlock_t
could've been done immediately after that, but it looks like nobody
had gotten around to that until now.

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Link: https://lore.kernel.org/20250702053437.GC1880847@ZenIV
Acked-by: Ahmed S. Darwish <darwi@linutronix.de>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Christian Brauner <brauner@kernel.org>
Signed-off-by: Christian Brauner <brauner@kernel.org>
fs: d_path: include internal.h 2023-05-17T07:16:59+00:00 Arnd Bergmann arnd@arndb.de 2023-05-16T19:54:38+00:00 df67cb4c58fbb80399a99d47a554a67829f90dda make W=1 warns about a missing prototype that is defined but not visible at point where simple_dname() is defined: fs/d_path.c:317:7: error: no previous prototype for 'simple_dname' [-Werror=missing-prototypes] Signed-off-by: Arnd Bergmann <arnd@arndb.de> Message-Id: <20230516195444.551461-1-arnd@kernel.org> Signed-off-by: Christian Brauner <brauner@kernel.org> 
make W=1 warns about a missing prototype that is defined but
not visible at point where simple_dname() is defined:

fs/d_path.c:317:7: error: no previous prototype for 'simple_dname' [-Werror=missing-prototypes]

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Message-Id: <20230516195444.551461-1-arnd@kernel.org>
Signed-off-by: Christian Brauner <brauner@kernel.org>
d_path.c: typo fix... 2022-08-20T15:34:33+00:00 Al Viro viro@zeniv.linux.org.uk 2022-01-31T02:12:26+00:00 c4c8451147da569a79eff5edcd2864e8ee21d7aa Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> 
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
dynamic_dname(): drop unused dentry argument 2022-08-20T15:34:04+00:00 Al Viro viro@zeniv.linux.org.uk 2022-01-30T20:03:49+00:00 0f60d28828dd94779c6527440289e1c36a05115a Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> 
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
d_path: fix Kernel doc validator complaining 2021-11-06T20:30:32+00:00 Jia He justin.he@arm.com 2021-11-05T20:35:04+00:00 d41b60359ffb24a39c93ea1f4bffaafd651118c3 Kernel doc validator complains: Function parameter or member 'p' not described in 'prepend_name' Excess function parameter 'buffer' description in 'prepend_name' Link: https://lkml.kernel.org/r/20211011005614.26189-1-justin.he@arm.com Fixes: ad08ae586586 ("d_path: introduce struct prepend_buffer") Signed-off-by: Jia He <justin.he@arm.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Randy Dunlap <rdunlap@infradead.org> Cc: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 
Kernel doc validator complains:
  Function parameter or member 'p' not described in 'prepend_name'
  Excess function parameter 'buffer' description in 'prepend_name'

Link: https://lkml.kernel.org/r/20211011005614.26189-1-justin.he@arm.com
Fixes: ad08ae586586 ("d_path: introduce struct prepend_buffer")
Signed-off-by: Jia He <justin.he@arm.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
d_path: make 'prepend()' fill up the buffer exactly on overflow 2021-09-02T17:07:29+00:00 Linus Torvalds torvalds@linux-foundation.org 2021-07-16T21:01:12+00:00 b0cfcdd9b9672ea90642f33d6c0dd8516553adf2 Instead of just marking the buffer as having overflowed, fill it up as much as we can. That will allow the overflow case to then return whatever truncated result if it wants to. Cc: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 
Instead of just marking the buffer as having overflowed, fill it up as
much as we can.  That will allow the overflow case to then return
whatever truncated result if it wants to.

Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
getcwd(2): clean up error handling 2021-05-19T00:15:58+00:00 Al Viro viro@zeniv.linux.org.uk 2021-05-17T00:24:00+00:00 e4b275531887fef7f7d8a7284bfc32f0fbbd4208 Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> 
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
d_path: prepend_path() is unlikely to return non-zero 2021-05-19T00:15:58+00:00 Al Viro viro@zeniv.linux.org.uk 2021-05-17T00:19:06+00:00 cf4febc1adc8e5cd11ca3386e1e3ea356e0792f0 Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> 
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
d_path: prepend_path(): lift the inner loop into a new helper 2021-05-19T00:15:57+00:00 Al Viro viro@zeniv.linux.org.uk 2021-05-12T20:38:11+00:00 008673ff74a513ac2c282db8825b6118151ee660 ... and leave the rename_lock/mount_lock handling in prepend_path() itself Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> 
... and leave the rename_lock/mount_lock handling in prepend_path()
itself

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>