On Fri, Jan 17, 2025 at 08:07:48PM -0700, Daniel Xu wrote:
> In addition to the points Andrii makes below, tracepoints also have a
> nice documenting property. They tend to get added to "places of
> interest". They're a great starting point for non kernel developers to
> dig into kernel internals. Often times tracepoint naming (as well as the
> exported fields) provide helpful hints.
>
> At least for me, if I'm mucking around new places (mostly net/) I'll
> tend to go look at the tracepoints to find the interesting codepaths.
Here's one for you:
trace_ocfs2_file_splice_read(inode, in, in->f_path.dentry,
(unsigned long long)OCFS2_I(inode)->ip_blkno,
in->f_path.dentry->d_name.len,
in->f_path.dentry->d_name.name,
flags);
The trouble is, what happens if your ->splice_read() races
with rename()? Yes, it is allowed to happen in parallel with
splice(2). Or with read(2), for that matter. Or close(2) (and
dup2(2) or exit(2) of something that happens to have the file
opened).
What happens is that
* you get len and name that might not match each other - you might
see len being 200 and name pointing to 40-byte array inside dentry.
* you get name that is not guaranteed to be *there* - you might
pick one before rename and have it freed and reused by the time you
try to access it.
* you get name that points to a string that might be modified
by another CPU right under you (for short names).
Doing that inside ->mkdir() - sure, no problem, the name _is_ stable
there. Doing that inside ->lookup() - fine on the entry, may be not
safe on the way out.
In filesystems it's living dangerously, but as long as you know what
you are doing you can get away with that (ocfs2 folks hadn't, but
it's not just ocfs2 - similar tracepoints exist for nfs, etc.)...
