Re: [PATCH v3] tracefs: Use dentry name snapshots instead of heap allocation
From: Steven Rostedt
Date: Fri Mar 06 2026 - 16:41:59 EST
On Fri, 6 Mar 2026 15:04:58 -0500
AnishMulay <anishm7030@xxxxxxxxx> wrote:
Thanks for the update, but please do not have a new patch as a reply to the
old one. It makes it harder to find. As I'll only look at top level emails
for patches in my inbox which means all new versions should be their own
thread.
> In fs/tracefs/inode.c, tracefs_syscall_mkdir() and tracefs_syscall_rmdir()
> previously used a local helper, get_dname(), which allocated a temporary
> buffer on the heap via kmalloc() to hold the dentry name. This introduced
> unnecessary overhead, an ENOMEM failure path, and required manual memory
> cleanup via kfree().
>
> As suggested by Al Viro, replace this heap allocation with the VFS dentry
> name snapshot API. By stack-allocating a `struct name_snapshot` and using
> take_dentry_name_snapshot() and release_dentry_name_snapshot(), we safely
> capture the dentry name locklessly, eliminate the heap allocation entirely,
> and remove the now-obsolete error handling paths. The get_dname() helper
> is completely removed.
>
> Testing:
> Booted a custom kernel natively in virtme-ng (ARM64). Triggered tracefs
> inode and dentry allocation by creating and removing a custom directory
> under a temporary tracefs mount. Verified that the instance is created
> successfully and that no memory errors or warnings are emitted in dmesg.
>
> Signed-off-by: AnishMulay <anishm7030@xxxxxxxxx>
> ---
> Changes in v3:
The above should have been:
Changes since v2: https://lore.kernel.org/all/20260227211505.226643-1-anishm7030@xxxxxxxxx/
> - Rebased into a single clean commit against upstream.
>
> Changes in v2:
> - Link to v1: https://lore.kernel.org/linux-trace-kernel/20260227194453.213095-1-anishm7030@xxxxxxxxx/
> - Use the helper functions take/release_dentry_name_snapshot() instead of allocating the name. (Al Viro)
The above isn't needed as the above link will give it to you.
No need to resend (unless I find something wrong with the code of the
patch).
-- Steve