syzbot

unknown

map[Benign:true Confident:true Explanation:The data race reported by KCSAN occurs between `dentry_unlink_inode()` (which sets `dentry->d_inode` to `NULL`) and `step_into_slowpath()` (which reads `dentry->d_inode`).

### Analysis

The write access is in `__d_clear_type_and_inode()` (inlined in `dentry_unlink_inode()`):
```c
// fs/dcache.c
static inline void __d_clear_type_and_inode(struct dentry *dentry)
{
    ...
    WRITE_ONCE(dentry->d_flags, flags);
    dentry->d_inode = NULL; // Write reported by KCSAN
    ...
}
```
This write is wrapped by a sequence counter update in `dentry_unlink_inode()`:
```c
// fs/dcache.c
static void dentry_unlink_inode(struct dentry * dentry)
{
    ...
    raw_write_seqcount_begin(&dentry->d_seq);
    __d_clear_type_and_inode(dentry);
    hlist_del_init(&dentry->d_u.d_alias);
    raw_write_seqcount_end(&dentry->d_seq);
    ...
}
```

The read access is in `step_into_slowpath()`:
```c
// fs/namei.c
static noinline const char *step_into_slowpath(struct nameidata *nd, int flags, struct dentry *dentry)
{
    ...
    inode = path.dentry->d_inode; // Read reported by KCSAN
    if (likely(!d_is_symlink(path.dentry)) || ...) {
        if (nd->flags & LOOKUP_RCU) {
            if (read_seqcount_retry(&path.dentry->d_seq, nd->next_seq))
                return ERR_PTR(-ECHILD);
            if (unlikely(!inode))
                return ERR_PTR(-ENOENT);
        }
        ...
    }
    return pick_link(nd, &path, inode, flags);
}
```
If `step_into_slowpath()` is in RCU mode (`LOOKUP_RCU`), it performs a seqlock retry check using `read_seqcount_retry()` at line 2059. If the read of `d_inode` raced with `dentry_unlink_inode()`, the sequence counter `d_seq` will have changed, and `read_seqcount_retry()` will fail, causing the path walk to drop out of RCU mode and retry safely (returning `-ECHILD`).

If the read is NOT in RCU mode, the caller must hold a reference to the dentry. As demonstrated by the logic in `d_delete()` and `__dentry_kill()`, a dentry's `d_inode` is only cleared when its reference count is effectively 1 (the caller's own reference) or 0. Thus, a non-RCU reader holding a reference would not see a concurrent `d_inode` nullification from these paths.

The data race is a classic example of a seqlock-protected access during RCU path walk. While the individual access to `d_inode` is not marked with `READ_ONCE`/`WRITE_ONCE`, the overall consistency is guaranteed by the sequence counter. On supported architectures (like x86-64), aligned pointer loads and stores are atomic, so no partial/torn values are read.

### Conclusion
The data race is **benign**. It is a known and intentional part of the VFS RCU path walk design, where the seqlock retry mechanism handles any inconsistency caused by concurrent modifications.]

unknown

map[KernelSrc:/usr/local/google/home/dvyukov/syzkaller/agent/workdir/cache/src/1f429dd96942f440820ba459da1839bc25538d0c]

unknown

map[KernelObj:/usr/local/google/home/dvyukov/syzkaller/agent/workdir/cache/build/9bb9e95fd27aa4ec1d713fac9574710c61d3811b]

unknown

map[Index:codesearch-index]

unknown

map[Benign:true Confident:true]

You are an experienced Linux kernel developer tasked with determining if the given kernel
data race is benign or not. The data race report is from KCSAN tool.
It contains 2 stack traces of the memory accesses that constitute a data race.

A "benign" data races are on a simple int/bool variable or similar field,
and the accesses are not supposed to be protected by any mutual exclusion primitives.
Common examples of such "benign" data races are accesses to various flags fields,
statistics counters, and similar. A "benign" data race does not lead to memory corruption/crash
with a conservative compiler that compiles memory accesses to primitive types
effectively as atomic.

A non-benign (or "harmful" data race) can lead to corruption/crash even with
a conservative compiler that compiles memory accesses to primitive types
effectively as atomic. A common example of a "harmful" data races is race on
a complex container (list/hashmap/etc), where accesses are supposed to be protected
by a mutual exclusion primitive.

In the final reply explain why you think the given data race is benign or is harmful.

Use the provided tools to confirm any assumptions, variables/fields being accessed, etc.
In particular, don't make assumptions about the kernel source code,
use codesearch tools to read the actual source code.


Use set-results tool to provide results of the analysis.
It must be called exactly once before the final reply.
Ignore results of this tool.

The data race report is:

==================================================================
BUG: KCSAN: data-race in dentry_unlink_inode / step_into_slowpath

write to 0xffff88811ad03270 of 8 bytes by task 4022 on cpu 1:
 __d_clear_type_and_inode fs/dcache.c:420 [inline]
 dentry_unlink_inode+0x65/0x260 fs/dcache.c:457
 d_delete+0x164/0x180 fs/dcache.c:2520
 d_delete_notify+0x32/0x100 include/linux/fsnotify.h:375
 vfs_unlink+0x32c/0x440 fs/namei.c:5393
 do_unlinkat+0x1cd/0x4b0 fs/namei.c:5448
 __do_sys_unlink fs/namei.c:5483 [inline]
 __se_sys_unlink fs/namei.c:5481 [inline]
 __x64_sys_unlink+0x2e/0x40 fs/namei.c:5481
 x64_sys_call+0x2f48/0x3000 arch/x86/include/generated/asm/syscalls_64.h:88
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0xca/0x2b0 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

read to 0xffff88811ad03270 of 8 bytes by task 3005 on cpu 0:
 step_into_slowpath+0x113/0x480 fs/namei.c:2054
 step_into fs/namei.c:2099 [inline]
 walk_component fs/namei.c:2235 [inline]
 lookup_last fs/namei.c:2730 [inline]
 path_lookupat+0x330/0x500 fs/namei.c:2754
 filename_lookup+0x147/0x340 fs/namei.c:2783
 do_readlinkat+0x7d/0x320 fs/stat.c:576
 __do_sys_readlink fs/stat.c:613 [inline]
 __se_sys_readlink fs/stat.c:610 [inline]
 __x64_sys_readlink+0x47/0x60 fs/stat.c:610
 x64_sys_call+0x2af1/0x3000 arch/x86/include/generated/asm/syscalls_64.h:90
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0xca/0x2b0 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

value changed: 0xffff88811c4114d8 -> 0x0000000000000000

Reported by Kernel Concurrency Sanitizer on:
CPU: 0 UID: 0 PID: 3005 Comm: udevd Not tainted syzkaller #0 PREEMPT(voluntary) 
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025
==================================================================

The data race reported by KCSAN occurs between `dentry_unlink_inode()` (which sets `dentry->d_inode` to `NULL`) and `step_into_slowpath()` (which reads `dentry->d_inode`).

### Analysis

The write access is in `__d_clear_type_and_inode()` (inlined in `dentry_unlink_inode()`):
```c
// fs/dcache.c
static inline void __d_clear_type_and_inode(struct dentry *dentry)
{
    ...
    WRITE_ONCE(dentry->d_flags, flags);
    dentry->d_inode = NULL; // Write reported by KCSAN
    ...
}
```
This write is wrapped by a sequence counter update in `dentry_unlink_inode()`:
```c
// fs/dcache.c
static void dentry_unlink_inode(struct dentry * dentry)
{
    ...
    raw_write_seqcount_begin(&dentry->d_seq);
    __d_clear_type_and_inode(dentry);
    hlist_del_init(&dentry->d_u.d_alias);
    raw_write_seqcount_end(&dentry->d_seq);
    ...
}
```

The read access is in `step_into_slowpath()`:
```c
// fs/namei.c
static noinline const char *step_into_slowpath(struct nameidata *nd, int flags, struct dentry *dentry)
{
    ...
    inode = path.dentry->d_inode; // Read reported by KCSAN
    if (likely(!d_is_symlink(path.dentry)) || ...) {
        if (nd->flags & LOOKUP_RCU) {
            if (read_seqcount_retry(&path.dentry->d_seq, nd->next_seq))
                return ERR_PTR(-ECHILD);
            if (unlikely(!inode))
                return ERR_PTR(-ENOENT);
        }
        ...
    }
    return pick_link(nd, &path, inode, flags);
}
```
If `step_into_slowpath()` is in RCU mode (`LOOKUP_RCU`), it performs a seqlock retry check using `read_seqcount_retry()` at line 2059. If the read of `d_inode` raced with `dentry_unlink_inode()`, the sequence counter `d_seq` will have changed, and `read_seqcount_retry()` will fail, causing the path walk to drop out of RCU mode and retry safely (returning `-ECHILD`).

If the read is NOT in RCU mode, the caller must hold a reference to the dentry. As demonstrated by the logic in `d_delete()` and `__dentry_kill()`, a dentry's `d_inode` is only cleared when its reference count is effectively 1 (the caller's own reference) or 0. Thus, a non-RCU reader holding a reference would not see a concurrent `d_inode` nullification from these paths.

The data race is a classic example of a seqlock-protected access during RCU path walk. While the individual access to `d_inode` is not marked with `READ_ONCE`/`WRITE_ONCE`, the overall consistency is guaranteed by the sequence counter. On supported architectures (like x86-64), aligned pointer loads and stores are atomic, so no partial/torn values are read.

### Conclusion
The data race is **benign**. It is a known and intentional part of the VFS RCU path walk design, where the seqlock retry mechanism handles any inconsistency caused by concurrent modifications.

unknown

**Investigating a Potential Data Race**

Okay, so the report indicates a data race. Specifically, it's on memory address `0xffff88811ad03270`. `dentry_unlink_inode` is writing to it, and `step_into_slowpath` is reading from it. The value changed from a non-zero address, `0xffff88811c4114d8`, to null, which is `0x0000000000000000`. This is pretty telling, right? Given the context, it almost certainly means we're dealing with a pointer to an inode within a dentry.

Let's dive into the code and confirm this. First, we need to look at the write location – that's `dentry_unlink_inode`. The report gives us the exact line numbers: `__d_clear_type_and_inode fs/dcache.c:420 [inline]` and then `dentry_unlink_inode+0x65/0x260 fs/dcache.c:457`.

Next, we look at the read access in `step_into_slowpath`, which the report notes at `step_into_slowpath+0x113/0x480 fs/namei.c:2054`.

Alright, I'll start by checking out `fs/dcache.c` around line 420. Let's see what's happening there with that write operation. This should give us a good start to understand this race.

unknown

map[IncludeLines:true Name:dentry_unlink_inode SourceFile:fs/dcache.c]

map[Missing:false SourceCode: 445:	/*
 446:	 * Release the dentry's inode, using the filesystem
 447:	 * d_iput() operation if defined.
 448:	 */
 449:	static void dentry_unlink_inode(struct dentry * dentry)
 450:		__releases(dentry->d_lock)
 451:		__releases(dentry->d_inode->i_lock)
 452:	{
 453:		struct inode *inode = dentry->d_inode;
 454:	
 455:		raw_write_seqcount_begin(&dentry->d_seq);
 456:		__d_clear_type_and_inode(dentry);
 457:		hlist_del_init(&dentry->d_u.d_alias);
 458:		raw_write_seqcount_end(&dentry->d_seq);
 459:		spin_unlock(&dentry->d_lock);
 460:		spin_unlock(&inode->i_lock);
 461:		if (!inode->i_nlink)
 462:			fsnotify_inoderemove(inode);
 463:		if (dentry->d_op && dentry->d_op->d_iput)
 464:			dentry->d_op->d_iput(dentry, inode);
 465:		else
 466:			iput(inode);
 467:	}
 SourceFile:fs/dcache.c]

unknown

Okay, here's my take on those thoughts, framed as an expert's internal monologue:

**Diving Deep into the Dentry Cleanup**

Alright, the clue's dropped: the write happens within `__d_clear_type_and_inode(dentry)`. Time to zoom in. I need to understand what's happening at this critical juncture – specifically, how the dentry's type and inode association are being cleared. This is where the core of the cleanup operation resides, so I'll need to dissect that function thoroughly. I need to be sure I understand the implications of any modifications to the dentry's metadata at this point. I'll need to ensure any subtle interactions are accounted for in the broader context of the filesystem's lifecycle. Let's see what secrets this function holds. I'm especially interested in concurrency concerns and any potential race conditions that might arise here. Time to get to the code and see exactly what's going on.

unknown

map[IncludeLines:true Name:__d_clear_type_and_inode SourceFile:fs/dcache.c]

map[Missing:false SourceCode: 413:	static inline void __d_clear_type_and_inode(struct dentry *dentry)
 414:	{
 415:		unsigned flags = READ_ONCE(dentry->d_flags);
 416:	
 417:		flags &= ~DCACHE_ENTRY_TYPE;
 418:		WRITE_ONCE(dentry->d_flags, flags);
 419:		dentry->d_inode = NULL;
 420:		/*
 421:		 * The negative counter only tracks dentries on the LRU. Don't inc if
 422:		 * d_lru is on another list.
 423:		 */
 424:		if ((flags & (DCACHE_LRU_LIST|DCACHE_SHRINK_LIST)) == DCACHE_LRU_LIST)
 425:			this_cpu_inc(nr_dentry_negative);
 426:	}
 SourceFile:fs/dcache.c]

unknown

**Investigating a Potential Data Race**

Okay, first things first, I need to understand this report. The report highlights `dentry->d_inode = NULL;` on line 419, and it *isn't* using `WRITE_ONCE`. Hmm, I need to be absolutely sure about that. The report mentions `__d_clear_type_and_inode fs/dcache.c:420 [inline]`, but that's a comment in my `codesearch-definition-source` output. It seems the line numbers might be off by a little bit, or my source might be slightly out of sync.

Let me just quickly verify the `dentry` struct definition and confirm the placement of `d_inode`.

Ah, here's a crucial bit of information. The report specifies a write to `0xffff88811ad03270` of 8 bytes. It looks like it is really the assignment of `dentry->d_inode = NULL;` . The write is indeed happening in `dentry_unlink_inode`. Here is the trace:

In `dentry_unlink_inode`:
`456:		__d_clear_type_and_inode(dentry);`
In `__d_clear_type_and_inode`:
`419:		dentry->d_inode = NULL;`

So, that confirms the write is `dentry->d_inode = NULL;`.

Now, I'm going to shift my focus to the read side of the equation. I'll need to locate the read operation in `step_into_slowpath`. It looks like it occurs at `step_into_slowpath+0x113/0x480 fs/namei.c:2054`. I'm starting to get a better handle on the situation now.

unknown

map[IncludeLines:true Name:step_into_slowpath SourceFile:fs/namei.c]

map[Missing:false SourceCode:2035:	/*
2036:	 * Do we need to follow links? We _really_ want to be able
2037:	 * to do this check without having to look at inode->i_op,
2038:	 * so we keep a cache of "no, this doesn't need follow_link"
2039:	 * for the common case.
2040:	 *
2041:	 * NOTE: dentry must be what nd->next_seq had been sampled from.
2042:	 */
2043:	static noinline const char *step_into_slowpath(struct nameidata *nd, int flags,
2044:			     struct dentry *dentry)
2045:	{
2046:		struct path path;
2047:		struct inode *inode;
2048:		int err;
2049:	
2050:		err = handle_mounts(nd, dentry, &path);
2051:		if (unlikely(err < 0))
2052:			return ERR_PTR(err);
2053:		inode = path.dentry->d_inode;
2054:		if (likely(!d_is_symlink(path.dentry)) ||
2055:		   ((flags & WALK_TRAILING) && !(nd->flags & LOOKUP_FOLLOW)) ||
2056:		   (flags & WALK_NOFOLLOW)) {
2057:			/* not a symlink or should not follow */
2058:			if (nd->flags & LOOKUP_RCU) {
2059:				if (read_seqcount_retry(&path.dentry->d_seq, nd->next_seq))
2060:					return ERR_PTR(-ECHILD);
2061:				if (unlikely(!inode))
2062:					return ERR_PTR(-ENOENT);
2063:			} else {
2064:				dput(nd->path.dentry);
2065:				if (nd->path.mnt != path.mnt)
2066:					mntput(nd->path.mnt);
2067:			}
2068:			nd->path = path;
2069:			nd->inode = inode;
2070:			nd->seq = nd->next_seq;
2071:			return NULL;
2072:		}
2073:		return pick_link(nd, &path, inode, flags);
2074:	}
 SourceFile:fs/namei.c]

unknown

**RCU Data Race Investigation**

Okay, here's what I'm seeing. I'm deep into a path lookup, specifically at line 2053, where the code grabs the `inode` from `path.dentry->d_inode`. This seems straightforward enough, but it's happening within the path lookup process, and things are about to get interesting.

Now, line 2058 catches my eye. It's the start of a block that checks the `nd->flags` for `LOOKUP_RCU`. If we're in RCU mode, there's a `read_seqcount_retry` call at line 2059, which *should* provide some protection against concurrent modification. But...

My concern stems from another piece of code, specifically the `dentry_unlink_inode` function. Lines 455 through 458: We have a write sequence starting, `__d_clear_type_and_inode` is called, which ultimately sets `dentry->d_inode = NULL`.

The potential data race is screaming at me: `dentry->d_inode` is being written to NULL, and this initial read from `inode = path.dentry->d_inode` **happens without any apparent protection like `READ_ONCE`**. That’s a serious red flag.

The problem is, the check for `LOOKUP_RCU` comes *after* the initial read of `inode`, which means that `path.dentry->d_inode` could be read *before* the check and protection are in place. This has me worried.

But hold on, am I missing something? `step_into_slowpath` is doing an RCU path walk, or so it seems. I need to re-evaluate this initial read in light of the larger picture. I was a bit hasty in my assessment.

I need to back up and look at where `step_into_slowpath` is actually called from. Let's trace back... to `step_into`. Okay, now I have a better context of where the vulnerability lies.

unknown

map[IncludeLines:true Name:step_into SourceFile:fs/namei.c]

map[Missing:false SourceCode:2076:	static __always_inline const char *step_into(struct nameidata *nd, int flags,
2077:	                    struct dentry *dentry)
2078:	{
2079:		/*
2080:		 * In the common case we are in rcu-walk and traversing over a non-mounted on
2081:		 * directory (as opposed to e.g., a symlink).
2082:		 *
2083:		 * We can handle that and negative entries with the checks below.
2084:		 */
2085:		if (likely((nd->flags & LOOKUP_RCU) &&
2086:		    !d_managed(dentry) && !d_is_symlink(dentry))) {
2087:			struct inode *inode = dentry->d_inode;
2088:			if (read_seqcount_retry(&dentry->d_seq, nd->next_seq))
2089:				return ERR_PTR(-ECHILD);
2090:			if (unlikely(!inode))
2091:				return ERR_PTR(-ENOENT);
2092:			nd->path.dentry = dentry;
2093:			/* nd->path.mnt is retained on purpose */
2094:			nd->inode = inode;
2095:			nd->seq = nd->next_seq;
2096:			return NULL;
2097:		}
2098:		return step_into_slowpath(nd, flags, dentry);
2099:	}
 SourceFile:fs/namei.c]

unknown

**Debugging a Potential RCU Walk Issue**

Okay, so the report points to `step_into_slowpath+0x113/0x480`. I'm immediately drawn to the fact that this specific point in the code is where we're seeing the issue. The inline code also reads `dentry->d_inode` at line 2087, but the stack trace is specifically highlighting this offset. Interesting.

Looking at `step_into_slowpath`, I see that it calls `handle_mounts`. This function has the potential to return the same `dentry` or, critically, a *different* `dentry` if we're dealing with a mount point. We know the RCU walk is involved here. That's a key piece of information.

The RCU walk context means there's the usual dance with `dentry->d_seq` for validation. Specifically, `handle_mounts` is using some logic here. If `dentry_unlink_inode` is in play and holding `dentry->d_lock`, it will increment `dentry->d_seq` using `raw_write_seqcount_begin`.

So, the theory is this: If `step_into_slowpath` is reading `dentry->d_inode` *concurrently* with `dentry_unlink_inode` nullifying it, the `read_seqcount_retry` at line 2059 (or related checks later in the code) *should* detect this concurrent modification and the RCU walk will fail. It would be highly unusual if the code got this far.

Also, I have to consider the call to `d_is_symlink(path.dentry)` at line 2054. That likely accesses `dentry->d_flags`, and that field is updated in `__d_clear_type_and_inode` just before the `d_inode` is set to NULL.

Time to dive deeper into `d_is_symlink` to see what's happening there.

unknown

map[IncludeLines:true Name:d_is_symlink SourceFile:include/linux/dcache.h]

map[Missing:false SourceCode: 443:	static inline bool d_is_symlink(const struct dentry *dentry)
 444:	{
 445:		return __d_entry_type(dentry) == DCACHE_SYMLINK_TYPE;
 446:	}
 SourceFile:include/linux/dcache.h]

unknown

Okay, I understand. I'll summarize the following thoughts as if they were my own, assuming I'm an expert in the relevant field. I'll pay close attention to any details about "__d_entry_type" and integrate that into the summary.

Here's the format I'll use:

**Bolded Header: My Interpretation of the Situation**

Your Summary: (Where I'll summarize the provided text in the first person)
***
Let's assume the text is:

**Thoughts:**

I'm wrestling with a piece of file system code. I'm trying to understand how directory entries are handled, particularly how the kernel differentiates between file types within a directory. My main focus is on the `__d_entry_type` field. I remember seeing this in the `dentry` struct definition, and it seems to hold the key to this distinction. I need to figure out the possible values and what each value signifies in the context of the VFS. Is it an enum? A bitmask? How is it used by the inode layer? How does it relate to the `inode->i_mode` bits? I have a feeling the answer lies in understanding how the different file systems register themselves with the VFS. This is a crucial concept, and I need to solidify my knowledge of it.

**`__d_entry_type`**: This field likely holds a bitmask representing the type of file that the directory entry represents. This can be regular file, directory, symlink, etc.
***
**Bolded Header: Deciphering the Directory Entry Puzzle**

Your Summary:

Alright, so I'm digging into this file system code again, specifically the mechanics of directory entries. I'm hitting a roadblock trying to grasp the `__d_entry_type` field. It's screaming at me that this is how the VFS differentiates between different file types within a directory. I'm remembering the `dentry` structure, and I'm pretty sure `__d_entry_type` is part of it. My immediate thought is that it *has* to be some form of file type identifier; my gut tells me it's likely a bitmask, although an enum is also plausible. I need to find out precisely how the kernel uses this.

I'm thinking about the bigger picture now; I'm curious about the interaction with the inode layer. Does it have a relationship with the `inode->i_mode` bits? I know they relate to file permissions, but are there overlaps? Is the `__d_entry_type` used in conjunction with `i_mode`? The critical thing is how all of this is initialized. That registration process, where filesystems hook into the VFS, that's what I need to focus on. That's where I'll find how the different filesystem implementations actually *set* this crucial type indicator. That registration process is where this whole puzzle's pieces come together. Knowing that, I can follow the control flow and understand how directory lookups and file operations really work under the hood. So, understanding that `__d_entry_type` field and its role in distinguishing between regular files, directories, symlinks, and other special files within a directory is the key.

unknown

map[IncludeLines:true Name:__d_entry_type SourceFile:include/linux/dcache.h]

map[Missing:false SourceCode: 410:	/*
 411:	 * Directory cache entry type accessor functions.
 412:	 */
 413:	static inline unsigned __d_entry_type(const struct dentry *dentry)
 414:	{
 415:		return dentry->d_flags & DCACHE_ENTRY_TYPE;
 416:	}
 SourceFile:include/linux/dcache.h]

unknown

**Diving Deep into a Kernel Conundrum: The Curious Case of d_inode and RCU**

Okay, so I'm digging into this code, and a few things are immediately jumping out. We've got `__d_clear_type_and_inode` clearing a `dentry`'s inode, and it uses `WRITE_ONCE` for `d_flags` but not for `d_inode`. Seems odd, doesn't it? Then I see `d_is_symlink` *doesn't* use `READ_ONCE`, and later we have a `likely(!d_is_symlink(path.dentry))` check – all these are clues.

My primary concern is this apparent data race around `dentry->d_inode`. If we're in RCU mode, `step_into_slowpath` is supposed to rely on `dentry->d_seq` for consistency. But we're *not* using `READ_ONCE` when reading `dentry->d_inode`! That's a compiler's playground for reloads and strange behavior. The race is pretty clear: one CPU's nullifying `dentry->d_inode`, while another CPU's trying to read it.

The RCU path is designed to check `read_seqcount_retry` after the read. And if `nd->flags & LOOKUP_RCU` is true, the `read_seqcount_retry` is our safety net, and in `dentry_unlink_inode`, the sequence count is updated *before* clearing the `d_inode`. Thus, if the `d_inode` has changed when the RCU check is performed, it's caught.

But what if we *aren't* in RCU mode? Who's protecting that `dentry->d_inode` then? We should have a reference to the `dentry`, right? Yet, `dentry_unlink_inode` can happen even with references, essentially turning a dentry into a negative one. `d_delete` handles this by either making a dentry negative or removing it from the hash queues. And `vfs_unlink` does call `d_delete`. The parent's lock protects us in non-RCU mode.

`step_into_slowpath` is called from `step_into`, which in turn is from `walk_component`. In non-RCU, we might have used `lookup_fast` or `lookup_slow` which calls `__d_lookup` and `d_revalidate`. It seems `step_into_slowpath` is called with a pre-existing `dentry`, and `handle_mounts` is invoked.

The KCSAN is screaming, which means that the code isn't using `READ_ONCE`/`WRITE_ONCE`. Even if we have a sequence counter, the Linux kernel memory model deems such races as undefined behavior. The compiler could misbehave, but more importantly, can we get into a scenario where we read a NULL `inode` *without* being in RCU mode? If `!LOOKUP_RCU` we end up setting `nd->inode = inode`, which might become NULL, and the caller sees the negative dentry. However, is a `d_inode` becoming NULL *while* someone is holding a reference to the dentry a valid condition? Yes, as the documentation for `d_delete` implies this is the case. So, the reader would just see a negative dentry.

The real challenge is about atomicity. If the compiler decides to reload the value, we could have problems. If the reader is *not* in RCU mode, shouldn't we be safe because the reader is holding a reference to the dentry? Well, not exactly; `d_inode` changing from non-NULL to NULL is *precisely* what `d_delete` does. The reader should be protected, but if it is not, then the reader would be seeing a negative dentry.

The KCSAN report is very specific: `value changed: 0xffff88811c4114d8 -> 0x0000000000000000`, so the race is: if we *are* in RCU mode, `READ_ONCE` *must* be used, but in `step_into`, it is not. However, is `d_inode` the kind of thing that *needs* `READ_ONCE`? It seems like it is.

The sequence counter is there for a reason! `raw_write_seqcount_begin` increments it, `__d_clear_type_and_inode` clears the `d_inode`, and then

unknown

map[IncludeLines:true Name:d_inode SourceFile:include/linux/dcache.h]

map[Missing:false SourceCode: 524:	/**
 525:	 * d_inode - Get the actual inode of this dentry
 526:	 * @dentry: The dentry to query
 527:	 *
 528:	 * This is the helper normal filesystems should use to get at their own inodes
 529:	 * in their own dentries and ignore the layering superimposed upon them.
 530:	 */
 531:	static inline struct inode *d_inode(const struct dentry *dentry)
 532:	{
 533:		return dentry->d_inode;
 534:	}
 SourceFile:include/linux/dcache.h]

unknown

**Race Condition in Dentry Lookup**

Okay, so I'm looking at this code and a potential data race jumps out at me. Specifically, it seems like `d_inode` isn't using `READ_ONCE` or `WRITE_ONCE` consistently in the context of `dentry_unlink_inode` and related functions. This feels like a plain, old-fashioned data race. 

In `__d_clear_type_and_inode`, I see that the `d_flags` are handled with `READ_ONCE` and `WRITE_ONCE`, which is good. But then, it just does a plain store (`dentry->d_inode = NULL`). Simultaneously, in `step_into_slowpath`, a simple load is used to get the inode (`inode = path.dentry->d_inode`).  

Now, if this was happening during an RCU walk, it's a known pattern, and the kernel would handle it. But KCSAN is reporting it. This suggests the KCSAN heuristics are being tripped up. The fact that the race involves `d_inode` and not the "typical" seqlock-protected data is relevant.

The key question is what happens if `dentry_unlink_inode` is called *while* a reader is looking at the dentry. If the reader is using RCU, it will retry and everything is fine. But if it's *not* in RCU mode, what happens?  If the reader isn't in RCU mode, it has a reference to the dentry, but a reference to a dentry doesn't stop it from being unlinked. 

If `vfs_unlink` is running on another CPU, it's allowed. If the reader is doing a *non*-RCU lookup, they shouldn't be holding the parent's `i_rwsem`. Right, `lookup_fast` doesn't hold it. 

So, if a `lookup_fast` finds a dentry, it returns it with a reference. `vfs_unlink` can proceed and set `d_inode = NULL` (after taking the parent's `i_rwsem`), even though the dentry is still "alive" as a negative dentry.

The scenario is this: a non-RCU reader reads `d_inode`, sees a non-NULL inode. Then, on another CPU, `vfs_unlink` runs and sets `d_inode = NULL`. The reader continues with the non-NULL inode it read. Is that okay?  If the reader has a reference to the dentry, does it guarantee that the inode stays alive? No, the dentry can become negative.

And this is a serious problem. If the reader *doesn't* have an additional reference to the inode, the inode could be freed before the reader is done with it. The `iput(inode)` in `dentry_unlink_inode` ensures this.

Looking at `nd->inode = inode;` in line 2069, in non-RCU mode this inode is used later. But where is the reference? If you have a positive dentry, the dentry itself *should* hold a reference to the inode. But `d_delete` *makes* the dentry negative.

The critical issue is this: if `dentry_unlink_inode` (called by things like `vfs_unlink`) runs *after* the reader has read `d_inode` but before anything is done to keep it alive (like taking a reference to the inode), we're in trouble.  

If the reader is in non-RCU mode, shouldn't it be protected by the dentry's lock (`dentry->d_lock`) or something? No, `d_inode` access is generally NOT protected by `d_lock` if you just want to check if it's there. But if you want to USE the inode, you need to make sure it doesn't go away.

For a non-RCU path walk, `walk_component` calls `step_into`, and `step_into_slowpath` is often called to follow a symlink or because it's a mount point.

So, if we are *not* in RCU mode, how do we ensure the inode stays alive? In a non-RCU walk, we have a pinned dentry. If it's positive, it pins the inode. If someone calls `d_delete` on it, they are making it negative and will eventually call `iput(inode)`. If we just read the `d_inode` pointer, then they do `iput(inode)` and it's the last reference, the inode is freed, and our `inode` pointer is now

unknown

map[IncludeLines:true Name:d_delete SourceFile:fs/dcache.c]

map[Missing:false SourceCode:2506:	void d_delete(struct dentry * dentry)
2507:	{
2508:		struct inode *inode = dentry->d_inode;
2509:	
2510:		spin_lock(&inode->i_lock);
2511:		spin_lock(&dentry->d_lock);
2512:		/*
2513:		 * Are we the only user?
2514:		 */
2515:		if (dentry->d_lockref.count == 1) {
2516:			if (dentry_negative_policy)
2517:				__d_drop(dentry);
2518:			dentry->d_flags &= ~DCACHE_CANT_MOUNT;
2519:			dentry_unlink_inode(dentry);
2520:		} else {
2521:			__d_drop(dentry);
2522:			spin_unlock(&dentry->d_lock);
2523:			spin_unlock(&inode->i_lock);
2524:		}
2525:	}
 SourceFile:fs/dcache.c]

unknown

**Delving into a VFS Conundrum: The RCU Path Walk and Dentry Deletion**

Okay, so I'm digging into this code, and my initial thought is, "Line 2515, `if (dentry->d_lockref.count == 1)`... Why this condition?" If that count is greater than one, like, say, some other process has the dentry pinned, the code flows to the `else` block and `__d_drop(dentry)` is called. But importantly, the inode isn't unlinked from the dentry just yet. It remains positive, basically pointing to an inode, until the very last user calls `dput`. That's where the unlink *might* happen.

Now, if `dentry_unlink_inode` *is* called, that strongly implies `dentry->d_lockref.count == 1`. The current thread calling `d_delete` has a reference to the dentry. But `vfs_unlink` calls `d_delete` with a dentry it previously looked up. That lookup created another reference. So if `d_lockref.count` is 1, it means *only* the thread calling `d_delete` has a reference.

But then, I consider the case where another thread also has a reference, which would make `d_lockref.count` greater than 1. In that scenario, `d_delete` just calls `__d_drop`. The dentry stays "positive" until it's eventually destroyed.

However, there are other paths to `dentry_unlink_inode`, like through `dentry_kill`.

Let's circle back to `d_delete`. If the count is 1, it's safe to unlink. But *wait*. The code in `step_into_slowpath` is reading `path.dentry->d_inode`. If that slow path is running concurrently on another CPU, then `d_lockref.count` must be *at least* 1.

Aha! RCU mode. If `step_into_slowpath` is running in RCU mode, it *doesn't* increment the `d_lockref.count`. It's relying on RCU to keep the memory alive, and it uses `d_seq` to ensure it sees a consistent snapshot.

So, here's the race:

CPU 1 (`d_delete`):
*   `d_lockref.count` is 1.
*   `raw_write_seqcount_begin(&dentry->d_seq)`
*   `d_inode = NULL`
*   ...
*   `raw_write_seqcount_end(&dentry->d_seq)`

CPU 0 (RCU walk):
*   Read `d_inode`
*   `read_seqcount_retry`

This is textbook seqlock pattern. KCSAN normally doesn't complain about these races if the access is marked or it's a known pattern. However, setting `d_inode` to `NULL` isn't `WRITE_ONCE`. KCSAN flags it because of the memory model.

The Linux Kernel Memory Model says that even if a seqlock protects it, a data race on a variable is still a race unless it's atomic. It only protects consistency. Usually, it's fine for simple pointers, but KCSAN flags it.

But is it benign? It *is* a standard RCU VFS path walk pattern. The `d_seq` retry will catch any inconsistency. It ensures that the walker will retry if a write happened in the middle.

Why did the value become NULL? Because it's being unlinked. 0xffff88811c4114d8 -> 0x0000000000000000.

What if `step_into_slowpath` reads NULL?

```c
inode = path.dentry->d_inode;
if (likely(!d_is_symlink(path.dentry)) || ...
...
if (nd->flags & LOOKUP_RCU) {
	if (read_seqcount_retry(&path.dentry->d_seq, nd->next_seq))
		return ERR_PTR(-ECHILD);
	if (unlikely(!inode))
		return ERR_PTR(-ENOENT);
```

If the read yields NULL but `read_seqcount_retry` *fails*, we return `-ECHILD`. That's correct, it drops out of RCU. If it reads NULL, and the retry *succeeds*, it returns `-ENOENT`. That makes sense;

unknown

map[SourceFile:fs/dcache.c]

map[Entities:[map[Kind:function Name:___d_drop] map[Kind:function Name:__d_add] map[Kind:function Name:__d_alloc] map[Kind:function Name:__d_clear_type_and_inode] map[Kind:function Name:__d_drop] map[Kind:function Name:__d_drop] map[Kind:function Name:__d_find_alias] map[Kind:function Name:__d_find_any_alias] map[Kind:function Name:__d_free] map[Kind:function Name:__d_free_external] map[Kind:function Name:__d_instantiate] map[Kind:function Name:__d_lookup] map[Kind:function Name:__d_lookup_rcu] map[Kind:function Name:__d_lookup_rcu_op_compare] map[Kind:function Name:__d_lookup_unhash] map[Kind:function Name:__d_lookup_unhash_wake] map[Kind:function Name:__d_lookup_unhash_wake] map[Kind:function Name:__d_move] map[Kind:function Name:__d_obtain_alias] map[Kind:function Name:__d_rehash] map[Kind:function Name:__d_set_inode_and_type] map[Kind:function Name:__d_unalias] map[Kind:function Name:__dentry_kill] map[Kind:function Name:copy_name] map[Kind:function Name:d_add] map[Kind:function Name:d_add] map[Kind:function Name:d_add_ci] map[Kind:function Name:d_add_ci] map[Kind:function Name:d_alloc] map[Kind:function Name:d_alloc] map[Kind:function Name:d_alloc_anon] map[Kind:function Name:d_alloc_anon] map[Kind:function Name:d_alloc_cursor] map[Kind:function Name:d_alloc_name] map[Kind:function Name:d_alloc_name] map[Kind:function Name:d_alloc_parallel] map[Kind:function Name:d_alloc_parallel] map[Kind:function Name:d_alloc_pseudo] map[Kind:function Name:d_ancestor] map[Kind:function Name:d_delete] map[Kind:function Name:d_delete] map[Kind:function Name:d_dispose_if_unused] map[Kind:function Name:d_dispose_if_unused] map[Kind:function Name:d_drop] map[Kind:function Name:d_drop] map[Kind:function Name:d_exchange] map[Kind:function Name:d_exchange] map[Kind:function Name:d_find_alias] map[Kind:function Name:d_find_alias] map[Kind:function Name:d_find_alias_rcu] map[Kind:function Name:d_find_any_alias] map[Kind:function Name:d_find_any_alias] map[Kind:function Name:d_flags_for_inode] map[Kind:function Name:d_hash] map[Kind:function Name:d_hash_and_lookup] map[Kind:function Name:d_instantiate] map[Kind:function Name:d_instantiate] map[Kind:function Name:d_instantiate_new] map[Kind:function Name:d_instantiate_new] map[Kind:function Name:d_invalidate] map[Kind:function Name:d_invalidate] map[Kind:function Name:d_lookup] map[Kind:function Name:d_lookup] map[Kind:function Name:d_lru_add] map[Kind:function Name:d_lru_del] map[Kind:function Name:d_lru_isolate] map[Kind:function Name:d_lru_shrink_move] map[Kind:function Name:d_make_discardable] map[Kind:function Name:d_make_discardable] map[Kind:function Name:d_make_persistent] map[Kind:function Name:d_make_persistent] map[Kind:function Name:d_make_root] map[Kind:function Name:d_make_root] map[Kind:function Name:d_mark_dontcache] map[Kind:function Name:d_mark_dontcache] map[Kind:function Name:d_mark_tmpfile] map[Kind:function Name:d_mark_tmpfile] map[Kind:function Name:d_move] map[Kind:function Name:d_move] map[Kind:function Name:d_obtain_alias] map[Kind:function Name:d_obtain_alias] map[Kind:function Name:d_obtain_root] map[Kind:function Name:d_obtain_root] map[Kind:function Name:d_op_flags] map[Kind:function Name:d_parent_ino] map[Kind:function Name:d_parent_ino] map[Kind:function Name:d_prune_aliases] map[Kind:function Name:d_prune_aliases] map[Kind:function Name:d_rehash] map[Kind:function Name:d_rehash] map[Kind:function Name:d_same_name] map[Kind:function Name:d_same_name] map[Kind:function Name:d_set_d_op] map[Kind:function Name:d_set_mounted] map[Kind:function Name:d_shrink_add] map[Kind:function Name:d_shrink_del] map[Kind:function Name:d_splice_alias] map[Kind:function Name:d_splice_alias] map[Kind:function Name:d_splice_alias_ops] map[Kind:function Name:d_tmpfile] map[Kind:function Name:d_tmpfile] map[Kind:function Name:d_wait_lookup] map[Kind:function Name:d_walk] map[Kind:function Name:dcache_init] map[Kind:function Name:dcache_init_early] map[Kind:function Name:dentry_cmp] map[Kind:function Name:dentry_free] map[Kind:function Name:dentry_lru_isolate] map[Kind:function Name:dentry_lru_isolate_shrink] map[Kind:function Name:dentry_string_cmp] map[Kind:function Name:dentry_unlink_inode] map[Kind:function Name:dentry_unlist] map[Kind:function Name:dget_parent] map[Kind:function Name:dget_parent] map[Kind:function Name:dname_external] map[Kind:function Name:do_one_tree] map[Kind:function Name:dput] map[Kind:function Name:dput] map[Kind:function Name:dput_to_list] map[Kind:function Name:end_dir_add] map[Kind:function Name:external_name] map[Kind:function Name:fast_dput] map[Kind:function Name:find_submount] map[Kind:function Name:finish_dput] map[Kind:function Name:get_nr_dentry] map[Kind:function Name:get_nr_dentry_negative] map[Kind:function Name:get_nr_dentry_unused] map[Kind:function Name:in_lookup_hash] map[Kind:function Name:init_fs_dcache_sysctls] map[Kind:function Name:is_subdir] map[Kind:function Name:is_subdir] map[Kind:function Name:lock_for_kill] map[Kind:function Name:path_check_mount] map[Kind:function Name:path_has_submounts] map[Kind:function Name:path_has_submounts] map[Kind:function Name:proc_nr_dentry] map[Kind:function Name:prune_dcache_sb] map[Kind:function Name:release_dentry_name_snapshot] map[Kind:function Name:release_dentry_name_snapshot] map[Kind:function Name:retain_dentry] map[Kind:function Name:select_collect] map[Kind:function Name:select_collect2] map[Kind:function Name:select_collect_umount] map[Kind:function Name:set_default_d_op] map[Kind:function Name:set_default_d_op] map[Kind:function Name:set_dhash_entries] map[Kind:function Name:shrink_dcache_for_umount] map[Kind:function Name:shrink_dcache_parent] map[Kind:function Name:shrink_dcache_parent] map[Kind:function Name:shrink_dcache_sb] map[Kind:function Name:shrink_dcache_sb] map[Kind:function Name:shrink_dcache_tree] map[Kind:function Name:shrink_dentry_list] map[Kind:function Name:shrink_dentry_list] map[Kind:function Name:shrink_kill] map[Kind:function Name:start_dir_add] map[Kind:function Name:swap_names] map[Kind:function Name:take_dentry_name_snapshot] map[Kind:function Name:take_dentry_name_snapshot] map[Kind:function Name:to_shrink_list] map[Kind:function Name:umount_check] map[Kind:function Name:vfs_caches_init] map[Kind:function Name:vfs_caches_init_early] map[Kind:function Name:vfs_pressure_ratio] map[Kind:function Name:vfs_pressure_ratio]] Missing:false]

unknown

**Delving into RCU Path Walk and Concurrent Unlinks**

Okay, so this race report is really focusing on how the RCU path walk interacts with concurrent unlinks. This has been a recurring conversation on the kernel mailing lists, hasn't it? Generally, we think it's harmless due to the seqlock, but KCSAN is flagging it because of the memory model violation – that data race on a concurrently accessed variable.

Let me refresh my memory of `fs/namei.c`. I'm going back to line 2053... aha!

```c
2053:		inode = path.dentry->d_inode;
2054:		if (likely(!d_is_symlink(path.dentry)) ||
...
2058:			if (nd->flags & LOOKUP_RCU) {
2059:				if (read_seqcount_retry(&path.dentry->d_seq, nd->next_seq))
2060:					return ERR_PTR(-ECHILD);
```

Right, if we're in RCU mode, we access `path.dentry`. We read `path.dentry->d_inode` and *then* retry if necessary.

Now, hold on... is this the *only* place where `d_inode` is accessed with `READ_ONCE`? I need to check. Let me search for `READ_ONCE(dentry->d_inode)` to be sure.

unknown

map[IncludeLines:true Name:d_backing_inode SourceFile:include/linux/dcache.h]

map[Missing:false SourceCode: 548:	/**
 549:	 * d_backing_inode - Get upper or lower inode we should be using
 550:	 * @upper: The upper layer
 551:	 *
 552:	 * This is the helper that should be used to get at the inode that will be used
 553:	 * if this dentry were to be opened as a file.  The inode may be on the upper
 554:	 * dentry or it may be on a lower dentry pinned by the upper.
 555:	 *
 556:	 * Normal filesystems should not use this to access their own inodes.
 557:	 */
 558:	static inline struct inode *d_backing_inode(const struct dentry *upper)
 559:	{
 560:		struct inode *inode = upper->d_inode;
 561:	
 562:		return inode;
 563:	}
 SourceFile:include/linux/dcache.h]

unknown

**Debugging a Potential Data Race in the Filesystem**

Okay, so I'm still stuck on this `READ_ONCE` issue. But I'm starting to think about this a bit differently now. What if `d_inode` is used for something more than just checking for NULL? Let's trace this back. I see `inode` passed to `pick_link` from `step_into_slowpath`.

If we're *not* in RCU mode, then `nd->flags & LOOKUP_RCU` is false. If that's the case, and we have a reference to the dentry, then `d_delete` shouldn't be running concurrently. Actually, from looking at the code, if `d_lockref.count > 1`, `d_delete` *won't* call `dentry_unlink_inode`. Meaning if the reader has a reference, `dentry_unlink_inode` won't happen.

Are there other callers of `dentry_unlink_inode`? Yes, `__dentry_kill` calls it. `__dentry_kill` is called when the last reference is dropped. If the reader has a reference, `__dentry_kill` won't be called.

Hang on...`d_delete` *can* call `dentry_unlink_inode` if `count == 1`. If `count == 1`, only the thread calling `d_delete` has a reference. No other thread should have a reference. But an RCU reader doesn't have a reference! So an RCU reader *can* see `d_inode` being cleared.

Aha! So the race *must* be in RCU mode. My stack trace from the reader, showing `path_lookupat`, confirms that's the entry point for a path lookup. And that can be in RCU mode.

Let's check if the reader *is* in RCU mode. The stack trace leads us to `step_into_slowpath`.

In `path_lookupat`, we see a loop that calls `walk_component`. If it's in RCU mode, `nd->flags & LOOKUP_RCU` will be set. The fact that we hit `step_into_slowpath` means it's either *not* in RCU mode or some condition in `step_into` sent it there.

Looking at `step_into`, even in RCU mode, we hit `step_into_slowpath` if `d_managed(dentry)` or `d_is_symlink(dentry)`. If it's a symlink, we definitely go to `step_into_slowpath`.

Okay, in `step_into_slowpath` we deal with mount points and eventually get `inode = path.dentry->d_inode`. It *does* seem to be doing the seqlock check, as we know the code does.

So, the data race is on `dentry->d_inode`. Is that a problem? If the compiler reloads `path.dentry->d_inode` between line 2053 and line 2073 (if it gets there), it might see different values. The `inode` variable *is* local, but the compiler still might optimize. However, if it's in RCU mode, `read_seqcount_retry` should catch any inconsistency.

Wait, what if it's *not* in RCU mode? I already said that if we're *not* in RCU mode, the reader has a reference, so `dentry_unlink_inode` shouldn't be called because `count > 1`. Is that true? Time to double-check `__dentry_kill`.

unknown

map[IncludeLines:true Name:__dentry_kill SourceFile:fs/dcache.c]

map[Missing:false SourceCode: 645:	static struct dentry *__dentry_kill(struct dentry *dentry)
 646:	{
 647:		struct dentry *parent = NULL;
 648:		bool can_free = true;
 649:	
 650:		/*
 651:		 * The dentry is now unrecoverably dead to the world.
 652:		 */
 653:		lockref_mark_dead(&dentry->d_lockref);
 654:	
 655:		/*
 656:		 * inform the fs via d_prune that this dentry is about to be
 657:		 * unhashed and destroyed.
 658:		 */
 659:		if (dentry->d_flags & DCACHE_OP_PRUNE)
 660:			dentry->d_op->d_prune(dentry);
 661:	
 662:		if (dentry->d_flags & DCACHE_LRU_LIST) {
 663:			if (!(dentry->d_flags & DCACHE_SHRINK_LIST))
 664:				d_lru_del(dentry);
 665:		}
 666:		/* if it was on the hash then remove it */
 667:		__d_drop(dentry);
 668:		if (dentry->d_inode)
 669:			dentry_unlink_inode(dentry);
 670:		else
 671:			spin_unlock(&dentry->d_lock);
 672:		this_cpu_dec(nr_dentry);
 673:		if (dentry->d_op && dentry->d_op->d_release)
 674:			dentry->d_op->d_release(dentry);
 675:	
 676:		cond_resched();
 677:		/* now that it's negative, ->d_parent is stable */
 678:		if (!IS_ROOT(dentry)) {
 679:			parent = dentry->d_parent;
 680:			spin_lock(&parent->d_lock);
 681:		}
 682:		spin_lock_nested(&dentry->d_lock, DENTRY_D_LOCK_NESTED);
 683:		dentry_unlist(dentry);
 684:		if (dentry->d_flags & DCACHE_SHRINK_LIST)
 685:			can_free = false;
 686:		spin_unlock(&dentry->d_lock);
 687:		if (likely(can_free))
 688:			dentry_free(dentry);
 689:		if (parent && --parent->d_lockref.count) {
 690:			spin_unlock(&parent->d_lock);
 691:			return NULL;
 692:		}
 693:		return parent;
 694:	}
 SourceFile:fs/dcache.c]

unknown

**Reasoning Through a Potential Race Condition**

Okay, so I'm digging into this `__dentry_kill` business and a potential race condition. The key seems to be that `__dentry_kill` fires when `d_lockref.count` hits zero, which means that any active reader reference should prevent its execution. The implication is that if there is a race, it's specific to the RCU readers. But even for RCU readers, the seqlock mechanisms should provide consistency. So, where's the weak spot?

My initial concern was over the missing `READ_ONCE` on `d_inode` within the context of an RCU read. Technically, it *could* be a problem. The compiler might, in theory, optimize a load of `d_inode`, see a non-NULL value, and then, due to some strange reordering, see a NULL value on a subsequent load. If that second NULL value gets used, we have a problem. However, the code assigns `d_inode` to a local variable named `inode`, which should mitigate this.

But here is where the problem creeps in. What if the compiler decides to reload `path.dentry->d_inode` later in the code? Let's trace it: line 2061 has `if (unlikely(!inode))` followed by line 2069 with `nd->inode = inode;` and then line 2073 with `return pick_link(nd, &path, inode, flags);`. The compiler *could* reload `path.dentry->d_inode` and use that for a subsequent check, instead of using the local variable `inode` if it thinks they're the same. This is particularly relevant across function calls like `pick_link`. If `d_inode` is volatile, it can't assume that. But it's *not* volatile.

The `read_seqcount_retry` call is there! It's at line 2059. If the compiler were to reload *after* `read_seqcount_retry`, that would be a problem. However, I know `read_seqcount_retry` includes a memory barrier, which, on most architectures, and most definitely prevents many compiler optimizations. Let's look: ah, it's `smp_rmb()`.

Wait, does this `read_seqcount_retry` have a *compiler* barrier? Yes! `smp_rmb()` is also a compiler barrier. That's the key.

So the sequence is this: 1) `inode = path.dentry->d_inode`, 2) `smp_rmb()` (within `read_seqcount_retry`), 3) `if (retry) return -ECHILD`, and finally, 4) use `inode`. The `smp_rmb()` acts as a compiler barrier. The compiler *can't* reload `path.dentry->d_inode` after the barrier and assume it's the same value as `inode`! If the compiler reloads it after the barrier, that must be intentional, in order to get the *current* value, but the code still uses the local variable.

So, the only risk is *before* the barrier: the compiler could reload before the barrier and see two different values. But that doesn't matter. No! The real issue without `READ_ONCE` is compiler "invented" reads or "load tearing." On x86-64, load tearing of a pointer (an 8-byte load) is impossible. But *invented* reads are the concern: multiple reads before the barrier, different results.

Right! KCSAN probably flagged this because KCSAN wants us to use `READ_ONCE`/`WRITE_ONCE` for any shared variable subject to concurrent modification. It's a prophylactic measure.

I should see if this *specific* race has been discussed before. Yes! A similar issue on `d_inode` was reported and debated previously. The standard fix is to add `READ_ONCE`/`WRITE_ONCE` or at least `data_race()`.

Wait, let's look at `__d_set_inode_and_type` in `fs/dcache.c`. I have an idea...

unknown

map[IncludeLines:true Name:__d_set_inode_and_type SourceFile:fs/dcache.c]

map[Missing:false SourceCode: 400:	static inline void __d_set_inode_and_type(struct dentry *dentry,
 401:						  struct inode *inode,
 402:						  unsigned type_flags)
 403:	{
 404:		unsigned flags;
 405:	
 406:		dentry->d_inode = inode;
 407:		flags = READ_ONCE(dentry->d_flags);
 408:		flags &= ~DCACHE_ENTRY_TYPE;
 409:		flags |= type_flags;
 410:		smp_store_release(&dentry->d_flags, flags);
 411:	}
 SourceFile:fs/dcache.c]

unknown

**VFS dentry's `d_inode` and `d_flags` Memory Ordering**

Okay, so I'm looking at this dentry code and immediately I see some interesting choices in memory ordering. It uses a plain store for `dentry->d_inode` but `smp_store_release` for `d_flags` in `__d_set_inode_and_type`. Why? And why is it `WRITE_ONCE` in `__d_clear_type_and_inode`? That inconsistency sparks my attention.

I recall that in `__d_set_inode_and_type`, the `smp_store_release` on `d_flags` ensures that the new inode becomes visible before the new type.  Now, the `__d_clear_type_and_inode` seems to be doing the opposite – clearing the type *before* nulling the inode.  This makes the dentry appear negative (`d_is_negative` returns true). If the reader then sees the negative type but the inode is still non-NULL, that seems like a race condition.

I'm thinking about how the path walk works – it might use `d_inode` directly or via `d_is_symlink`. If `d_is_symlink` returns false because the type is gone, and then the code tries to use `d_inode`, we could have a problem. However, the path walk uses `read_seqcount_retry` so that should catch any inconsistency.

Now, this seems to be a classic data race between a plain store and a plain load. Is it *harmful*? I recall Linux kernel folks often consider these benign, but KCSAN picks them up. I wonder if the performance optimization might be playing a role, but `READ_ONCE` on a pointer is essentially a volatile cast so there's no real performance penalty on modern architectures.

The fact that `d_inode` isn't `READ_ONCE` is intentional, I remember – it's supposed to be protected by a seqlock.  But KCSAN doesn't know this unless it is within the `read_seqcount_begin/retry` block. Ah, but it *is*!  The reader samples `d_seq` (e.g. `lookup_fast`, `step_into`), reads `d_inode`, and then retries.

This KCSAN report is on `step_into_slowpath`.  I'm curious about the source of `nd->next_seq`. In `step_into`, I see it calls `read_seqcount_retry` with `nd->next_seq`, which was either passed in or set earlier. It looks like the race is real, but is it benign?

Yes, because the seqlock retry mechanism *is* designed to deal with this, which will discard the results if there is any inconsistency. The memory is kept alive by RCU. So, is there any possibility that `d_inode` changes while it is NOT NULL? In `__d_move`, `d_inode` doesn't change – `d_move` keeps the same inode. `d_exchange` swaps them. `d_instantiate` sets it from NULL to non-NULL, and `d_delete` sets it from non-NULL to NULL.

Both of these happen within the `d_seq` write-side lock.  If KCSAN is reporting this, it's a data race that could be avoided by using `READ_ONCE`/`WRITE_ONCE`. But is it *harmful*?  A non-benign race would lead to a crash or corruption. Here, the seqlock retry prevents using the "corrupted" value, so the race is likely "benign".

I'm checking if a compiler could mess this up. Can the compiler move the load of `d_inode` out of the seqlock-protected region? The sampling of `next_seq` also happens before the load, and `read_seqcount_retry` has a compiler barrier.  So the load cannot be moved after the retry. The load of `d_inode` has to be after `__d_lookup_rcu`. So, the seqlock protocol appears to be correctly implemented.

Is the value of `d_inode` torn? No, not on x86-64 for an aligned pointer, and the `struct dentry` is likely aligned.

So, this data race is benign. The seqlock will catch it.  The question from a KCSAN perspective is whether we consider this "benign" or "harmful". It's a "benign data race" because it is protected by a seqlock,

unknown

map[IncludeLines:true Name:pick_link SourceFile:fs/namei.c]

map[Missing:false SourceCode:1953:	static noinline const char *pick_link(struct nameidata *nd, struct path *link,
1954:			     struct inode *inode, int flags)
1955:	{
1956:		struct saved *last;
1957:		const char *res;
1958:		int error;
1959:	
1960:		if (nd->flags & LOOKUP_RCU) {
1961:			/* make sure that d_is_symlink from step_into_slowpath() matches the inode */
1962:			if (read_seqcount_retry(&link->dentry->d_seq, nd->next_seq))
1963:				return ERR_PTR(-ECHILD);
1964:		} else {
1965:			if (link->mnt == nd->path.mnt)
1966:				mntget(link->mnt);
1967:		}
1968:	
1969:		error = reserve_stack(nd, link);
1970:		if (unlikely(error)) {
1971:			if (!(nd->flags & LOOKUP_RCU))
1972:				path_put(link);
1973:			return ERR_PTR(error);
1974:		}
1975:		last = nd->stack + nd->depth++;
1976:		last->link = *link;
1977:		clear_delayed_call(&last->done);
1978:		last->seq = nd->next_seq;
1979:	
1980:		if (flags & WALK_TRAILING) {
1981:			error = may_follow_link(nd, inode);
1982:			if (unlikely(error))
1983:				return ERR_PTR(error);
1984:		}
1985:	
1986:		if (unlikely(nd->flags & LOOKUP_NO_SYMLINKS) ||
1987:				unlikely(link->mnt->mnt_flags & MNT_NOSYMFOLLOW))
1988:			return ERR_PTR(-ELOOP);
1989:	
1990:		if (unlikely(atime_needs_update(&last->link, inode))) {
1991:			if (nd->flags & LOOKUP_RCU) {
1992:				if (!try_to_unlazy(nd))
1993:					return ERR_PTR(-ECHILD);
1994:			}
1995:			touch_atime(&last->link);
1996:			cond_resched();
1997:		}
1998:	
1999:		error = security_inode_follow_link(link->dentry, inode,
2000:						   nd->flags & LOOKUP_RCU);
2001:		if (unlikely(error))
2002:			return ERR_PTR(error);
2003:	
2004:		res = READ_ONCE(inode->i_link);
2005:		if (!res) {
2006:			const char * (*get)(struct dentry *, struct inode *,
2007:					struct delayed_call *);
2008:			get = inode->i_op->get_link;
2009:			if (nd->flags & LOOKUP_RCU) {
2010:				res = get(NULL, inode, &last->done);
2011:				if (res == ERR_PTR(-ECHILD) && try_to_unlazy(nd))
2012:					res = get(link->dentry, inode, &last->done);
2013:			} else {
2014:				res = get(link->dentry, inode, &last->done);
2015:			}
2016:			if (!res)
2017:				goto all_done;
2018:			if (IS_ERR(res))
2019:				return res;
2020:		}
2021:		if (*res == '/') {
2022:			error = nd_jump_root(nd);
2023:			if (unlikely(error))
2024:				return ERR_PTR(error);
2025:			while (unlikely(*++res == '/'))
2026:				;
2027:		}
2028:		if (*res)
2029:			return res;
2030:	all_done: // pure jump
2031:		put_link(nd);
2032:		return NULL;
2033:	}
 SourceFile:fs/namei.c]

unknown

**VFS RCU Path Walk Data Race Investigation**

Okay, so I'm looking at this potential data race in the VFS RCU path walk, specifically around handling symlinks and unlinking. The core of the issue seems to be the access to `dentry->d_inode` within `step_into_slowpath` and `pick_link` and how it interacts with an ongoing unlink operation.

First, I see the code is retrying the `read_seqcount_retry` call to validate the `inode` pointer. My initial thought was that if `inode` is NULL after `step_into_slowpath`, `pick_link` would crash on `READ_ONCE(inode->i_link)`, but `step_into_slowpath` checks if `inode` is NULL and returns `-ENOENT`. Then I saw the race condition: in `__d_clear_type_and_inode`, the type is cleared *before* `dentry->d_inode` is set to NULL. This means a reader could observe the dentry as *not* a symlink, get a *non-NULL* `inode` pointer (because it's read *before* the NULL write), and then call `read_seqcount_retry`, which should fail due to the sequence number increment.

My initial line of thinking was:
*   If the read happens *before* the type is cleared, we treat the dentry as a symlink, get a non-NULL `inode`, then `read_seqcount_retry` would fail.
*   If the read happens *after* `d_inode` is set to NULL, we treat it as no symlink, reads `inode` as NULL, the `read_seqcount_retry` fails.
*   If the read happens *between* the two, it should be fine because `read_seqcount_retry` should catch the fact that `d_seq` changed.

The question then became: is it possible to call `pick_link` with a NULL `inode`? That should be impossible given the checks and state transitions. A dentry is a symlink only if its type is `DCACHE_SYMLINK_TYPE`, and both the type and `d_inode` are set together. When unlinking, the type is cleared *before* the `inode` is set to NULL. So, no, we should not.

So the race is between `dentry->d_inode = NULL` and `inode = path.dentry->d_inode`. My thinking is if a reader sees NULL, did it crash? No, the code checks `read_seqcount_retry` which catches if the sequence changed. This should be fine.

I then considered what if `nd->next_seq` matches, which should not be possible since sequence numbers are incremented every time.

So, it seems the race is protected by the seqlock. The seqlock provides synchronization to prevent memory corruption or a crash.

The KCSAN report is likely flagging this because it looks for any data race unless it is `data_race()` or uses atomic accessors. In the Linux kernel, a "benign" race means the seqlock or other high level logic handles it correctly and does not need a fix. Because `d_inode` is a pointer (aligned), it's atomic on x86-64.

I found `step_into` has the same pattern (reads `dentry->d_inode` and then checks `read_seqcount_retry`). This suggests a known design of the VFS RCU path walk. The race is likely "benign".

I need to confirm if there are any known issues with `d_inode` not having `READ_ONCE` or `WRITE_ONCE`. Perhaps I should search kernel history. But for now, I should be able to check the current source code. `include/linux/dcache.h` has `d_inode_rcu`.

unknown

map[IncludeLines:true Name:d_inode_rcu SourceFile:include/linux/dcache.h]

map[Missing:false SourceCode: 536:	/**
 537:	 * d_inode_rcu - Get the actual inode of this dentry with READ_ONCE()
 538:	 * @dentry: The dentry to query
 539:	 *
 540:	 * This is the helper normal filesystems should use to get at their own inodes
 541:	 * in their own dentries and ignore the layering superimposed upon them.
 542:	 */
 543:	static inline struct inode *d_inode_rcu(const struct dentry *dentry)
 544:	{
 545:		return READ_ONCE(dentry->d_inode);
 546:	}
 SourceFile:include/linux/dcache.h]

unknown

**Delving into a Potential RCU Race in `step_into_slowpath`**

Okay, so I've stumbled upon a potential issue within `step_into_slowpath` and it has to do with RCU and `d_inode`. I noticed there's a helper function, `d_inode_rcu`, which specifically uses `READ_ONCE` for accessing `d_inode` in an RCU context. This is the first clue something may be off. It's a bit jarring that the code in line 2053, `inode = path.dentry->d_inode;`, doesn't use this helper, especially given its purpose.

If `d_inode_rcu` exists, it strongly suggests that using `READ_ONCE` is the *preferred* method to safely access `d_inode` in RCU mode. I'm seeing a pattern, however, where many parts of the code still use plain access to `d_inode`. Given the existence of `d_inode_rcu` and its aim to avoid these KCSAN reports and potential compiler optimization issues, the plain access does look like a bug. Perhaps a minor one, but a bug nonetheless.

So, if I change the code at line 2053 to `d_inode_rcu(path.dentry)`, the race condition will be "marked" but, how harmful is it? The race *is* benign. The instructions say it is because of the seqlock protecting it. It does not lead to memory corruption, so there is no issue in a conservative compiler.

However, I need to make sure `read_seqcount_retry` is always called if RCU is enabled. Within `step_into_slowpath`, if `nd->flags & LOOKUP_RCU` is false, `read_seqcount_retry` *isn't* called, which seems like a problem. But, if we're *not* in RCU mode, we have a reference to the dentry so the `dentry_unlink_inode` shouldn't be called. To double check this, let's look further.

I need to confirm if it's possible for `dentry_unlink_inode` to be called while someone else has a reference to the dentry. I've examined `d_delete` and it specifically checks if `count` equals 1 before clearing the inode. `__dentry_kill` seems to only be called when `count` drops to 0. `dentry_unlink_inode` itself, being a static function, has very specific callers: `__d_clear_type_and_inode` (which is inlined), `d_delete`, `__dentry_kill`, and `__d_instantiate`.

I'll check `__dentry_kill` callers. It looks like it's called by `dentry_kill` and then `dput`. So, it seems that if you have a reference to a dentry, its `d_inode` cannot be cleared from under you by `d_delete` or `dput`, right?

Wait, what about `d_move` or `d_exchange`? Neither function clears `d_inode`.

Could a crazy filesystem do something? Filesystems shouldn't call `dentry_unlink_inode` themselves. It's static, they use `d_delete` and the others.

What about `d_invalidate`? I'll investigate that function next.

unknown

map[IncludeLines:true Name:d_invalidate SourceFile:fs/dcache.c]

map[Missing:false SourceCode:1678:	/**
1679:	 * d_invalidate - detach submounts, prune dcache, and drop
1680:	 * @dentry: dentry to invalidate (aka detach, prune and drop)
1681:	 */
1682:	void d_invalidate(struct dentry *dentry)
1683:	{
1684:		bool had_submounts = false;
1685:		spin_lock(&dentry->d_lock);
1686:		if (d_unhashed(dentry)) {
1687:			spin_unlock(&dentry->d_lock);
1688:			return;
1689:		}
1690:		__d_drop(dentry);
1691:		spin_unlock(&dentry->d_lock);
1692:	
1693:		/* Negative dentries can be dropped without further checks */
1694:		if (!dentry->d_inode)
1695:			return;
1696:	
1697:		shrink_dcache_parent(dentry);
1698:		for (;;) {
1699:			struct dentry *victim = NULL;
1700:			d_walk(dentry, &victim, find_submount);
1701:			if (!victim) {
1702:				if (had_submounts)
1703:					shrink_dcache_parent(dentry);
1704:				return;
1705:			}
1706:			had_submounts = true;
1707:			detach_mounts(victim);
1708:			dput(victim);
1709:		}
1710:	}
 SourceFile:fs/dcache.c]

unknown

**Data Race Analysis: A Benign Seqlock-Protected Race**

Okay, let me think this through. `d_invalidate` doesn't actually clear `d_inode`; it just unhashes the dentry. The only way `d_inode` becomes NULL is if there are no other references to the dentry, excluding RCU references. So, if `step_into_slowpath` is in a non-RCU context, `d_inode` can't be NULL. The data race *must* be happening when the reader is in RCU mode. And in RCU mode, it *should* be protected by the seqlock.

Could there be a scenario where `path.dentry->d_inode` is read, the dentry is freed, and then we access the freed inode? No, the RCU walk guarantees the dentry memory isn't freed until the end of the RCU grace period. The inode memory is also kept alive by RCU, assuming the filesystem supports it, which most do for RCU path walk. Actually, both the `dentry` and `inode` structures are typically RCU-freed (marked with `SLAB_TYPESAFE_BY_RCU` or explicitly freed via RCU). The VFS ensures this for filesystems that support RCU walks.

So, here's my conclusion so far: the race is between `d_delete` (setting `d_inode = NULL` under the seqlock) and `step_into_slowpath` (reading `d_inode` during the RCU path walk and then checking the seqlock). This is a pretty standard seqlock-protected race. It's benign, right?

Wait, I just spotted something potentially problematic. In `__d_clear_type_and_inode`, the code updates `d_flags` THEN `d_inode`. In `step_into_slowpath`, the code reads `d_inode` first, and then checks `d_is_symlink` which indirectly reads `d_flags`. If the reader is between the `d_flags` and `d_inode` write:

1.  `WRITE_ONCE(dentry->d_flags, flags)` completes (no longer a symlink).
2.  The reader reads `inode = dentry->d_inode` (still non-NULL).
3.  The reader calls `d_is_symlink(path.dentry)` (returns false).
4.  The reader enters the first block.
5.  The reader checks `read_seqcount_retry`. It fails, and the code retries, which is safe.

What about if the reader reads them in reverse order?

1.  `d_is_symlink` returns TRUE.
2.  `inode = dentry->d_inode` returns NULL (because CPU 1 already did line 419).
3.  `pick_link(nd, &path, inode, flags)` is called with `inode == NULL`.
4.  `pick_link` does `read_seqcount_retry`. It fails.

Still safe, because the retry will catch the inconsistency.

Wait, what if the compiler reorders the reads in `step_into_slowpath`? Without `READ_ONCE`, the compiler is free to reorder them. But the seqlock check at the end of `step_into_slowpath` or inside `pick_link` will still catch it. That `read_seqcount_retry` is the ultimate safety net here.

Alright, I should check `next_seq` is always correct. In `step_into_slowpath`, `nd->next_seq` is used. `handle_mounts` might update `nd->next_seq` if it crosses a mount point, but for the same dentry, it should be the same as sampled during lookup.

The KCSAN report points to `step_into_slowpath+0x113/0x480`, specifically line 2053 (reading `d_inode`) and line 2054 (checking the symlink). The "value changed" is `addr -> NULL`, exactly what happens when `dentry_unlink_inode` sets `d_inode = NULL`.

I'm pretty confident this is a benign data race, the seqlock-protected kind.

Let me just check one more thing. Can `path.dentry` itself change? `handle_mounts` is called before. In RCU mode, `handle_mounts` might return the same dentry or a new one if it's a mount point. Either way, the access to `d_inode` is on the `

unknown

map[Benign:true Confident:true]

map[Benign:true Confident:true]

unknown

Okay, here's my take on those thoughts, as if I were the one thinking them:

**RCU Path Walk and Dentry Invalidation - All Clear**

Alright, the analysis is done, and it looks like that data race everyone was worried about is exactly what I expected. We've got a classic race condition between `dentry_unlink_inode` cleaning up a `d_inode` pointer and `step_into_slowpath` trying to read it. The key here, though, is how it's *protected*. It's that `d_seq` seqlock. That's a familiar pattern for this type of problem in the VFS.

The crucial bit is the reader, `step_into_slowpath`, using `read_seqcount_retry`. It's reading `d_inode` within that `read_seqcount_retry` block. Even if the reader grabs an inconsistent value initially – that transient state during the dentry's invalidation – the retry mechanism is the linchpin. That retry will fail. Boom. Either the entire path walk is restarted, or it's gracefully aborted. No actual damage is done. This is standard operating procedure for our RCU path walk implementation, so I'm not worried. This is exactly how we've designed it to work. It's robust and prevents any real issues. Case closed.