| 0/0 |
2026/05/20 01:29 |
flow |
assessment-security |
33m
Results: map[DenialOfService:false Explanation:The reported bug is a data race between a write to `dentry->d_flags` in
`d_make_discardable()` and a read of `dentry->d_flags` in `do_readlinkat()` (via
`d_is_symlink()` -> `__d_entry_type()`).
**Analysis:**
1. **The Write:** In `d_make_discardable()`, the code clears the
`DCACHE_PERSISTENT` bit (bit 27) of `dentry->d_flags` using a read-modify-write
operation (`dentry->d_flags &= ~DCACHE_PERSISTENT;`). This is done while holding
the `dentry->d_lock` spinlock. Later in the same `vfs_unlink` path,
`dont_mount()` sets the `DCACHE_CANT_MOUNT` bit (bit 8), also under `d_lock`.
2. **The Read:** In `do_readlinkat()`, the code checks if the dentry is a
symlink by reading `dentry->d_flags` and masking it with `DCACHE_ENTRY_TYPE`
(bits 19..21). This read is performed without holding the `d_lock`.
3. **The Race:** Because the read is performed without a lock, KCSAN detects a
data race. The KCSAN report shows the value of `d_flags` changing from
`0x08300080` (where bit 27 is set) to `0x00300180` (where bit 27 is cleared and
bit 8 is set).
4. **Impact:** The `DCACHE_ENTRY_TYPE` bits (`0x00380000`) are `0x00300000` in
both the old and new values. Since the writer only modifies bits 27 and 8, and
the reader only cares about bits 19..21, the reader will always observe the
correct `DCACHE_ENTRY_TYPE` regardless of whether it reads the old or new value.
On all architectures supported by Linux, 32-bit aligned memory accesses are
atomic, meaning there is no risk of a "torn read" that could produce a corrupted
value for the type bits.
**Conclusion:**
This is a completely benign data race. It does not lead to any memory
corruption, logic errors, or crashes. It is not exploitable and cannot cause a
denial of service. While the code paths (`unlink` and `readlink`) are easily
reachable by unprivileged users, the race itself has no security impact. Exploitable:false FilesystemTrigger:false NetworkTrigger:false PeripheralTrigger:false RemoteTrigger:false Unprivileged:true UserNamespace:true VMGuestTrigger:false VMHostTrigger:false]
|
| 1/1 |
2026/05/20 01:29 |
action |
syz-repro-to-c-repro |
0m
Results:
|
| 2/1 |
2026/05/20 01:29 |
action |
kernel-checkouter |
1m
Results: map[KernelSrc:/app/workdir/cache/src/53b098f27ed2e7a7660842a26c211f5e49d61b42]
|
| 3/1 |
2026/05/20 01:31 |
action |
kernel-builder |
17m
Results: map[KernelObj:/app/workdir/cache/build/18a8ce1b91438c4c09ea43c19fc290036f274a64]
|
| 4/1 |
2026/05/20 01:48 |
action |
codesearch-prepare |
11m
Results: map[Index:codesearch-index]
|
| 5/1 |
2026/05/20 01:59 |
agent |
expert |
2m
Model:
Results: map[DenialOfService:false Exploitable:false FilesystemTrigger:false NetworkTrigger:false PeripheralTrigger:false RemoteTrigger:false Unprivileged:true UserNamespace:true VMGuestTrigger:false VMHostTrigger:false]
Instruction:
You are an experienced Linux kernel security engineer. Your task is to analyze given kernel bug report
and determine its security impact based on the following dimensions.
Use the provided tools to examine the source code, check for capability checks (e.g., capable(), ns_capable()),
and understand the nature of the bug. Analyze the given kernel build and configuration.
You can check the kernel config by grepping ".config" file; you can check kernel cmdline by greeping
".config" file for "CONFIG_CMDLINE=". Assume sysctl parameters have default values.
But analyze for the corresponding production build w/o debugging tools enabled (like KASAN, KMSAN, UBSAN).
Don't make assumptions; verify them with source code access. Try different strategies when analyzing the bug:
- think of ways in which the vulnerable code is unreachable
- or the other way around: try to come up with different ideas of how an unprivileged user can reach the bug
If still unsure err on the side of the bug being non-exploitable/not-accessible.
In the final reply, provide a reasoning for your assessment.
Analysis dimensions:
* Exploitable:
Determine if the bug can result in memory corruption or elevated privileges.
Memory safety issues are almost always exploitable (KASAN or UBSAN reports for use-after-free, out-of-bounds;
refcounting issues, corrupted lists, etc). When kernel is crashing on a completly wild pointer access
(e.g. user-space address, or non-canonical address, but not on NULL or address corresponding to KASAN shadow
for NULL address), including both data accesses and control tranfers, that's also usually implies possibility
of exploitation. Such reports usually say "unable to handle kernel paging request".
Uses of uninitialized values detected by KMSAN may be exploitable b/c attacker frequently can affect uninit
values with spraying techniques. However, for these exploitabability depends on how exactly the uninit value
is used in the code, and what it affects.
Think of what happens after the bug is triggered. Some bugs cause kernel panic and halt execution,
they are harder to exploit. For example, BUG reports halts the kernel. However, WARNING reports don't halt
execution in production builds. Debug bug detection tools (like KASAN, KMSAN, KCSAN, UBSAN) are also not enabled
in production builds, so attacker can freely exploit these bugs w/o being detected by these tools.
If you see an integer overflow, think how the overflowed value used later (if it's used as allocation size,
or an array index). If you see an out-of-bounds read, think if it's followed by an out-of-bounds write as well.
Some KCSAN data-races may be exploitable by skilled attackers as well. Think what data structures got corrupted
as the result of data races and how. However, note that kernel has lots of "benign" data races that don't lead
to any runtime misbehavior at all.
* Denial Of Service:
Determine if the bug can result in denial-of-service. Most bugs can, since they cause system crash,
hangs, deadlocks, or resource leaks. This is mostly applicable to WARNING bugs that won't cause system crash
in production. For these think what will be consequences of the violation of the kernel assumptions flagged
by the WARNING. In some cases the unexpected condition is also properly handled by the normal control flow
(e.g. with "if (WARN_ON(...))"), these won't cause denial-of-service. If the condition is not handled,
then it may or may not cause denial-of-service.
* Accessible From Unprivileged Processes:
Determine if the bug can be reached from a typical (non-root) user process that does NOT have any special capabilities
(like CAP_SYS_ADMIN, CAP_NET_ADMIN, CAP_NET_RAW, CAP_PERFMON) or access to device nodes restricted to root.
Assume that unprivileged_bpf_disabled=1, that is eBPF loading is not accessible. However, cBPF (classical BPF)
is still accessible to non-root processes.
Assume that user namespaces are not accessible, that is, the process cannot get the mentioned capabilities even
within a new user namespace (checked by ns_capable() function in the kernel sources).
* Accessible From User Namespaces:
Determine if the bug can be reached within a user-namespace where the process has all capabilities
(including CAP_SYS_ADMIN, CAP_NET_ADMIN, CAP_NET_RAW, CAP_PERFMON). Such capabilities are checked with ns_capable()
function in the kernel sources.
* VM Guest Trigger:
Determine if the bug can be triggered from the context of a typical KVM guest (e.g., set up by a QEMU VMM).
Consider accesses to standard Linux host paravirtualized features (virtio-blk, virtio-net, etc.),
and handling of VM exits in the KVM code.
* VM Host Trigger in The Confidetial Computing Context:
Determine if the bug can be triggered in a confidential computing guest kernel from the context of a KVM host.
Consider access to standard Linux guest paravirtualized features (virtio-blk, virtio-net, etc.).
* Ethernet Network Trigger:
Determine if the bug can be triggered by processing ingress network Ethernet traffic, either directly (network stack)
or via drivers exposed to network data.
* Other Remote Trigger:
Determine if the bug can be triggered by processing remote traffic other than Ethernet (Wifi, Bluetooth, NFC, etc).
* Peripheral Trigger:
Determine if the bug can be triggered via an untrusted peripheral device that can be physically plugged
into a system, such as a USB device or a niche hardware driver handling external hardware inputs.
This is particularly important for mobile and desktop environments where users can plug in unknown devices.
* Malicious Filesystem Trigger:
Determine if the bug can be triggered by the kernel mounting and parsing a malicious filesystem image.
This is highly critical for Desktop and Mobile environments where external media or downloaded images
might be auto-mounted.
Prefer calling several tools at the same time to save round-trips.
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.
Prompt:
The kernel bug report is:
==================================================================
BUG: KCSAN: data-race in d_make_discardable / do_readlinkat
write to 0xffff88811b001300 of 4 bytes by task 20596 on cpu 0:
d_make_discardable+0x4f/0xa0 fs/dcache.c:984
simple_unlink+0x68/0x80 fs/libfs.c:808
shmem_unlink+0x12d/0x140 mm/shmem.c:3981
vfs_unlink+0x1c7/0x490 fs/namei.c:5498
filename_unlinkat+0x1e2/0x410 fs/namei.c:5568
__do_sys_unlink fs/namei.c:5603 [inline]
__se_sys_unlink+0x2b/0xe0 fs/namei.c:5600
__x64_sys_unlink+0x1f/0x30 fs/namei.c:5600
x64_sys_call+0x2eb6/0x3020 arch/x86/include/generated/asm/syscalls_64.h:88
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x12c/0x3b0 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
read to 0xffff88811b001300 of 4 bytes by task 2984 on cpu 1:
__d_entry_type include/linux/dcache.h:429 [inline]
d_is_symlink include/linux/dcache.h:459 [inline]
do_readlinkat+0xa0/0x2f0 fs/stat.c:578
__do_sys_readlink fs/stat.c:605 [inline]
__se_sys_readlink fs/stat.c:602 [inline]
__x64_sys_readlink+0x47/0x60 fs/stat.c:602
x64_sys_call+0x2b51/0x3020 arch/x86/include/generated/asm/syscalls_64.h:90
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x12c/0x3b0 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
value changed: 0x08300080 -> 0x00300180
Reported by Kernel Concurrency Sanitizer on:
CPU: 1 UID: 0 PID: 2984 Comm: udevd Tainted: G W syzkaller #0 PREEMPT(full)
Tainted: [W]=WARN
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/18/2026
==================================================================
Reply: The reported bug is a data race between a write to `dentry->d_flags` in `d_make_discardable()` and a read of `dentry->d_flags` in `do_readlinkat()` (via `d_is_symlink()` -> `__d_entry_type()`).
**Analysis:**
1. **The Write:** In `d_make_discardable()`, the code clears the `DCACHE_PERSISTENT` bit (bit 27) of `dentry->d_flags` using a read-modify-write operation (`dentry->d_flags &= ~DCACHE_PERSISTENT;`). This is done while holding the `dentry->d_lock` spinlock. Later in the same `vfs_unlink` path, `dont_mount()` sets the `DCACHE_CANT_MOUNT` bit (bit 8), also under `d_lock`.
2. **The Read:** In `do_readlinkat()`, the code checks if the dentry is a symlink by reading `dentry->d_flags` and masking it with `DCACHE_ENTRY_TYPE` (bits 19..21). This read is performed without holding the `d_lock`.
3. **The Race:** Because the read is performed without a lock, KCSAN detects a data race. The KCSAN report shows the value of `d_flags` changing from `0x08300080` (where bit 27 is set) to `0x00300180` (where bit 27 is cleared and bit 8 is set).
4. **Impact:** The `DCACHE_ENTRY_TYPE` bits (`0x00380000`) are `0x00300000` in both the old and new values. Since the writer only modifies bits 27 and 8, and the reader only cares about bits 19..21, the reader will always observe the correct `DCACHE_ENTRY_TYPE` regardless of whether it reads the old or new value. On all architectures supported by Linux, 32-bit aligned memory accesses are atomic, meaning there is no risk of a "torn read" that could produce a corrupted value for the type bits.
**Conclusion:**
This is a completely benign data race. It does not lead to any memory corruption, logic errors, or crashes. It is not exploitable and cannot cause a denial of service. While the code paths (`unlink` and `readlink`) are easily reachable by unprivileged users, the race itself has no security impact.
|
| 6/2 |
2026/05/20 01:59 |
llm |
expert |
0m
Model:
Tokens:
input: 5208
output: 80
thoughts: 103
Thoughts: **Analyzing a Data Race Bug Report**
Okay, so I've got this bug report, and it looks like it's pointing to a data race. Specifically, the report flags a potential issue between `d_make_discardable` and `do_readlinkat`. The write operation, where the problematic change is happening, is happening in `d_make_discardable` at `fs/dcache.c:984`. The read, the thing that could be interfering with the write, is happening in `do_readlinkat` at `fs/stat.c:578`. This read path goes through `d_is_symlink` which eventually touches `__d_entry_type`.
Time to dig into the code and see exactly what's going on in those functions, and confirm whether we have a legitimate race condition. I need to understand the memory access patterns and synchronization mechanisms (or lack thereof) in detail. This looks like it could be interesting!
|
| 7/2 |
2026/05/20 02:00 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:fs/dcache.c IncludeLines:true Name:d_make_discardable]
Results: map[SourceCode: 980: void d_make_discardable(struct dentry *dentry)
981: {
982: spin_lock(&dentry->d_lock);
983: WARN_ON(!(dentry->d_flags & DCACHE_PERSISTENT));
984: dentry->d_flags &= ~DCACHE_PERSISTENT;
985: dentry->d_lockref.count--;
986: rcu_read_lock();
987: finish_dput(dentry);
988: }
SourceFile:fs/dcache.c]
|
| 8/2 |
2026/05/20 02:00 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:fs/stat.c IncludeLines:true Name:do_readlinkat]
Results: map[SourceCode: 559: static int do_readlinkat(int dfd, const char __user *pathname,
560: char __user *buf, int bufsiz)
561: {
562: struct path path;
563: int error;
564: unsigned int lookup_flags = 0;
565:
566: if (bufsiz <= 0)
567: return -EINVAL;
568:
569: CLASS(filename_flags, name)(pathname, LOOKUP_EMPTY);
570: retry:
571: error = filename_lookup(dfd, name, lookup_flags, &path, NULL);
572: if (unlikely(error))
573: return error;
574:
575: /*
576: * AFS mountpoints allow readlink(2) but are not symlinks
577: */
578: if (d_is_symlink(path.dentry) ||
579: d_backing_inode(path.dentry)->i_op->readlink) {
580: error = security_inode_readlink(path.dentry);
581: if (!error) {
582: touch_atime(&path);
583: error = vfs_readlink(path.dentry, buf, bufsiz);
584: }
585: } else {
586: error = (name->name[0] == '\0') ? -ENOENT : -EINVAL;
587: }
588: path_put(&path);
589: if (retry_estale(error, lookup_flags)) {
590: lookup_flags |= LOOKUP_REVAL;
591: goto retry;
592: }
593: return error;
594: }
SourceFile:fs/stat.c]
|
| 9/2 |
2026/05/20 02:00 |
llm |
expert |
0m
Model:
Tokens:
input: 6326
output: 86
thoughts: 77
Thoughts: Okay, let's break this down.
**Investigating a Possible Cache Invalidation Issue**
Alright, so I'm seeing a potential issue related to how we handle the `DCACHE_PERSISTENT` flag in the dentry cache, specifically concerning symlinks. The crux of it seems to be centered around a write operation using `dentry->d_flags &= ~DCACHE_PERSISTENT;` within `d_make_discardable`, and a subsequent read operation that checks `d_is_symlink(path.dentry)` within `do_readlinkat`.
I need to understand if the clearing of the `DCACHE_PERSISTENT` flag in `d_make_discardable` could be causing a problem when `do_readlinkat` is trying to determine if it is a symlink. We're potentially seeing a race condition, or perhaps an incorrect cache state. I know `DCACHE_PERSISTENT` is supposed to prevent dentries from being prematurely evicted, so any mismatch here is problematic.
Let's dive into `d_is_symlink`. Specifically, I need to see how it interacts with the underlying dentry flags, and how `__d_entry_type` is involved in resolving the dentry type. I also need to understand the implications of `d_make_discardable` on this flag and how it relates to cache eviction policies. My intuition says there is a chance the write and read operations are desynchronized. I suspect the issue could be some sort of cache invalidation that we aren't handling correctly in relation to symbolic links.
I'll start with those two functions, `d_is_symlink` and `__d_entry_type`, to get a better handle on the potential bug.
|
| 10/2 |
2026/05/20 02:00 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:include/linux/dcache.h IncludeLines:true Name:d_is_symlink]
Results: map[SourceCode: 457: static inline bool d_is_symlink(const struct dentry *dentry)
458: {
459: return __d_entry_type(dentry) == DCACHE_SYMLINK_TYPE;
460: }
SourceFile:include/linux/dcache.h]
|
| 11/2 |
2026/05/20 02:00 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:include/linux/dcache.h IncludeLines:true Name:__d_entry_type]
Results: map[SourceCode: 424: /*
425: * Directory cache entry type accessor functions.
426: */
427: static inline unsigned __d_entry_type(const struct dentry *dentry)
428: {
429: return dentry->d_flags & DCACHE_ENTRY_TYPE;
430: }
SourceFile:include/linux/dcache.h]
|
| 12/2 |
2026/05/20 02:00 |
llm |
expert |
0m
Model:
Tokens:
input: 7089
output: 22
thoughts: 98
Thoughts: Here's my analysis of this code snippet:
**Dentry Flag Consistency Analysis**
Okay, so I'm seeing a potential race condition here, and it's got my attention. `__d_entry_type` is reading the `dentry->d_flags` without any protection, right? Meanwhile, `d_make_discardable` is modifying the same `dentry->d_flags` field, but it *is* using a `spin_lock` on `dentry->d_lock` to ensure atomicity. The specific modification being made is `dentry->d_flags &= ~DCACHE_PERSISTENT;`. That's a bitwise AND with the complement of `DCACHE_PERSISTENT`, effectively clearing that specific flag.
So, the crux of the matter is whether this flag manipulation can be observed in a way that causes an issue by `__d_entry_type`, because `__d_entry_type` lacks locking. I need to understand what `DCACHE_PERSISTENT` actually *means* in the context of `dentry` lifecycle. I should check the definition of `DCACHE_PERSISTENT` to be certain. Is this flag's state critical for a decision made by `__d_entry_type`? If so, this is a textbook race condition, requiring either a read-side lock, or using atomic variables, or something else. I'm going to dig into the surrounding code and the usage of `__d_entry_type` to assess the severity. This needs a closer look.
|
| 13/2 |
2026/05/20 02:00 |
tool |
grepper |
0m
Error:
Args: map[Expression:#define DCACHE_PERSISTENT]
Results:
|
| 14/2 |
2026/05/20 02:00 |
llm |
expert |
0m
Model:
Tokens:
input: 7557
output: 20
thoughts: 21
Thoughts: Okay, here's my thought process summarized from the prompt, as if it were my own:
**Navigating the Linux Dcache Structure**
Right, time to dive into the dcache again. I need to refresh my memory on how persistence is handled. Let's start with a focused search. Specifically, I should be looking for `DCACHE_PERSISTENT`. That macro is a key indicator of how persistent data is handled. My first move will be to check `include/linux/dcache.h`. That's where I'd expect to find the relevant definitions and flags for the dcache subsystem. Locating that macro will give me a good jumping-off point to understand the broader implications and design choices made around persistent dcache entries.
|
| 15/2 |
2026/05/20 02:00 |
tool |
grepper |
0m
Args: map[Expression:DCACHE_PERSISTENT]
Results: map[Output:Documentation/filesystems/porting.rst=1326=end_creating() and the parent will be unlocked precisely when necessary.
--
Documentation/filesystems/porting.rst-1331-
Documentation/filesystems/porting.rst:1332:kill_litter_super() is gone; convert to DCACHE_PERSISTENT use (as all
Documentation/filesystems/porting.rst-1333-in-tree filesystems have done).
--
fs/dcache.c=980=void d_make_discardable(struct dentry *dentry)
--
fs/dcache.c-982- spin_lock(&dentry->d_lock);
fs/dcache.c:983: WARN_ON(!(dentry->d_flags & DCACHE_PERSISTENT));
fs/dcache.c:984: dentry->d_flags &= ~DCACHE_PERSISTENT;
fs/dcache.c-985- dentry->d_lockref.count--;
--
fs/dcache.c=1596=static enum d_walk_ret select_collect_umount(void *_data, struct dentry *dentry)
fs/dcache.c-1597-{
fs/dcache.c:1598: if (dentry->d_flags & DCACHE_PERSISTENT) {
fs/dcache.c:1599: dentry->d_flags &= ~DCACHE_PERSISTENT;
fs/dcache.c-1600- dentry->d_lockref.count--;
--
fs/dcache.c=2863=struct dentry *d_make_persistent(struct dentry *dentry, struct inode *inode)
--
fs/dcache.c-2870- __d_instantiate(dentry, inode);
fs/dcache.c:2871: dentry->d_flags |= DCACHE_PERSISTENT;
fs/dcache.c-2872- dget_dlock(dentry);
--
include/linux/dcache.h=192=enum dentry_flags {
--
include/linux/dcache.h-238- DCACHE_NORCU = BIT(26), /* No RCU delay for freeing */
include/linux/dcache.h:239: DCACHE_PERSISTENT = BIT(27)
include/linux/dcache.h-240-};
]
|
| 16/2 |
2026/05/20 02:00 |
llm |
expert |
0m
Model:
Tokens:
input: 8370
output: 20
thoughts: 46
Thoughts: Okay, here's my take on those thoughts, tailored for an expert audience:
**Analyzing `DCACHE_PERSISTENT` and `DCACHE_ENTRY_TYPE`**
Right, so `DCACHE_PERSISTENT` is defined as `BIT(27)`. That's straightforward enough, I know exactly what that means in terms of the bitmask and how it interacts with the cache entry flags. I'm already thinking about what that implies for persistent dentry management and how that bit is set and tested.
Now, `DCACHE_ENTRY_TYPE`...ah yes, that should be defined in `include/linux/dcache.h`. I need to refresh my memory on the possible values there. I'm assuming it defines different dentry types, probably including things like directory, regular file, symbolic link, etc. Let me quickly check the header file to refresh my memory, confirm my assumptions, and verify what the numerical value is. It's important to understand the relationship between these two, I'm already thinking about what these flags mean in the context of persistent dentry management. Time to dig into the details.
|
| 17/2 |
2026/05/20 02:00 |
tool |
grepper |
0m
Args: map[Expression:DCACHE_ENTRY_TYPE]
Results: map[Output:fs/dcache.c=401=static inline void __d_set_inode_and_type(struct dentry *dentry,
--
fs/dcache.c-408- flags = READ_ONCE(dentry->d_flags);
fs/dcache.c:409: flags &= ~DCACHE_ENTRY_TYPE;
fs/dcache.c-410- flags |= type_flags;
--
fs/dcache.c=414=static inline void __d_clear_type_and_inode(struct dentry *dentry)
--
fs/dcache.c-417-
fs/dcache.c:418: flags &= ~DCACHE_ENTRY_TYPE;
fs/dcache.c-419- WRITE_ONCE(dentry->d_flags, flags);
--
include/linux/dcache.h=192=enum dentry_flags {
--
include/linux/dcache.h-225- DCACHE_LRU_LIST = BIT(18),
include/linux/dcache.h:226: DCACHE_ENTRY_TYPE = (7 << 19), /* bits 19..21 are for storing type: */
include/linux/dcache.h-227- DCACHE_MISS_TYPE = (0 << 19), /* Negative dentry */
--
include/linux/dcache.h=427=static inline unsigned __d_entry_type(const struct dentry *dentry)
include/linux/dcache.h-428-{
include/linux/dcache.h:429: return dentry->d_flags & DCACHE_ENTRY_TYPE;
include/linux/dcache.h-430-}
--
include/linux/dcache.h=483=static inline bool d_flags_negative(unsigned flags)
include/linux/dcache.h-484-{
include/linux/dcache.h:485: return (flags & DCACHE_ENTRY_TYPE) == DCACHE_MISS_TYPE;
include/linux/dcache.h-486-}
]
|
| 18/2 |
2026/05/20 02:00 |
llm |
expert |
0m
Model:
Tokens:
input: 9208
output: 20
thoughts: 170
Thoughts: **Analyzing a Kernel Data Structure Modification**
Okay, so I'm looking at this bit of code, and I need to be sure I understand the interaction of these flags. Let's see, `DCACHE_ENTRY_TYPE` is defined as `(7 << 19)`. Right, so that's a bitmask with bits 19, 20, and 21 set. `DCACHE_PERSISTENT` is `BIT(27)`, so that's just bit 27.
Now, the code reads `dentry->d_flags` and checks if it has the `DCACHE_ENTRY_TYPE` set. The important part I'm focused on is the modification of the value. The code does a write operation `dentry->d_flags &= ~DCACHE_PERSISTENT`, and the important thing to verify is that this operation doesn't mess with the `DCACHE_ENTRY_TYPE` bits. Since they occupy different bit positions, that should be correct, and the write shouldn't affect the check.
However, I'm just quickly confirming my mental model here. `dentry->d_flags` is a bitfield (or rather an integer) so I should be sure. And since the code is a read-modify-write operation, I need to check the exact type of this variable. Okay, time to double-check the definition and confirm it's an `unsigned int` or something similar, just to be absolutely certain. Better safe than sorry when dealing with kernel data structures.
|
| 19/2 |
2026/05/20 02:00 |
tool |
codesearch-struct-layout |
0m
Args:
Results: map[Fields:[map[Name:d_flags OffsetBits:0 SizeBits:32] map[Name:d_seq OffsetBits:32 SizeBits:32] map[Name:d_hash OffsetBits:64 SizeBits:128] map[Name:d_parent OffsetBits:192 SizeBits:64] map[Name: OffsetBits:256 SizeBits:128] map[Name:d_inode OffsetBits:384 SizeBits:64] map[Name:d_shortname OffsetBits:448 SizeBits:320] map[Name:d_op OffsetBits:768 SizeBits:64] map[Name:d_sb OffsetBits:832 SizeBits:64] map[Name:d_time OffsetBits:896 SizeBits:64] map[Name:d_fsdata OffsetBits:960 SizeBits:64] map[Name:d_lockref OffsetBits:1024 SizeBits:64] map[Name: OffsetBits:1088 SizeBits:128] map[Name:d_sib OffsetBits:1216 SizeBits:128] map[Name:d_children OffsetBits:1344 SizeBits:64] map[Name: OffsetBits:1408 SizeBits:128]]]
|
| 20/2 |
2026/05/20 02:00 |
llm |
expert |
0m
Model:
Tokens:
input: 10078
output: 45
thoughts: 1049
Thoughts: **Analyzing a Potential Data Race in Dentry Flags**
Okay, so I'm looking at this KCSAN report. It highlights a potential data race with `dentry->d_flags`. It seems like one task is writing to this 32-bit integer by clearing the `DCACHE_PERSISTENT` bit using `&= ~DCACHE_PERSISTENT;`, while another task is reading the same memory location, using `dentry->d_flags & DCACHE_ENTRY_TYPE;`. The report shows the value changing, but let's break down if this is actually problematic.
The key is that this is a non-atomic read-modify-write. The values reported are `0x08300080` and `0x00300180`. I notice that the bit being changed (bit 27) corresponds to `DCACHE_PERSISTENT`, while the `DCACHE_ENTRY_TYPE` bits (`7 << 19` which is `0x00380000`) are unaffected by this write. The `DCACHE_ENTRY_TYPE` bits stay at `0x00300000` in both cases, which means the type of the entry isn't changing.
Now, a plain read-modify-write on x86 for 32-bit aligned data is atomic. The write is either a single store instruction, or could be two, but they aren't protected. The read is just a single load. So the read will either see the old or new value, it won't see some "torn" value. Since the critical bits for `DCACHE_ENTRY_TYPE` are not modified, this read will always see the correct entry type, and there is no risk of an incorrect type.
This looks like a benign data race. Let me think a bit more, just to be sure...
Could the compiler optimize things in a way that introduces problems? Specifically, the `d_is_symlink` function is called in `do_readlinkat`, and it does the same type of check: `dentry->d_flags & DCACHE_ENTRY_TYPE == DCACHE_SYMLINK_TYPE`. If the compiler reads the flags multiple times, it won't be an issue because the bits involved will remain stable during the execution of this section, regardless of the read order.
Okay, let's consider another CPU potentially modifying the entry type. The only places where I've seen `DCACHE_ENTRY_TYPE` getting modified are in `__d_set_inode_and_type` and `__d_clear_type_and_inode`. But those use `READ_ONCE` and `WRITE_ONCE` or are protected by `d_lock`. This particular write, `dentry->d_flags &= ~DCACHE_PERSISTENT;`, happens under `spin_lock(&dentry->d_lock);`. If the entry type is modified by another CPU it would also be under the same lock because those functions are called under `d_lock` too. This confirms that these accesses are always protected.
Therefore, the write and read have no impact on the stability of the entry type. I'm reasonably confident this is a false positive.
|
| 21/2 |
2026/05/20 02:00 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:fs/dcache.c IncludeLines:true Name:__d_set_inode_and_type]
Results: map[SourceCode: 401: static inline void __d_set_inode_and_type(struct dentry *dentry,
402: struct inode *inode,
403: unsigned type_flags)
404: {
405: unsigned flags;
406:
407: dentry->d_inode = inode;
408: flags = READ_ONCE(dentry->d_flags);
409: flags &= ~DCACHE_ENTRY_TYPE;
410: flags |= type_flags;
411: smp_store_release(&dentry->d_flags, flags);
412: }
SourceFile:fs/dcache.c]
|
| 22/2 |
2026/05/20 02:00 |
llm |
expert |
0m
Model:
Tokens:
input: 12080
output: 28
thoughts: 97
Thoughts: Okay, let me think this through.
**Analyzing Dentry Flag Manipulation in the Linux Kernel**
Right, so I'm looking at how dentry flags are handled, specifically focusing on `__d_set_inode_and_type`. It's using `smp_store_release(&dentry->d_flags, flags);` to write to the `d_flags` field. That's a strong memory barrier, ensuring the write is visible across CPUs. Now, I have to consider the implications of this atomic operation in relation to other accesses.
Then, I see that `d_make_discardable` is doing a clear on the `DCACHE_PERSISTENT` flag, but it's doing so under the protection of `spin_lock(&dentry->d_lock);`. This creates a critical section to ensure that no concurrent modifications happen at the same time.
My central question is whether `__d_set_inode_and_type` *ever* gets called without the dentry's spinlock being held. If it does, then the atomic write might not be sufficient to guarantee data consistency, especially if we have a concurrent modification happening in `d_make_discardable`. This is a crucial detail to investigate further. A data race here could lead to some nasty bugs. I need to trace the call paths to be sure.
|
| 23/2 |
2026/05/20 02:00 |
tool |
codesearch-find-references |
0m
Args: map[Name:__d_set_inode_and_type]
Results: map[References:[map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:__d_add SourceFile:fs/dcache.c SourceLine:2832] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:__d_instantiate SourceFile:fs/dcache.c SourceLine:2052] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:__d_obtain_alias SourceFile:fs/dcache.c SourceLine:2156]] TruncatedOutput:false]
|
| 24/2 |
2026/05/20 02:00 |
llm |
expert |
0m
Model:
Tokens:
input: 12660
output: 40
thoughts: 11
Thoughts: Okay, here's my interpretation of that thought process, assuming I'm an expert in this field, presented as a first-person summary:
**Digging into the Instantiate Logic**
Alright, time to dive in. My mind immediately goes to the `__d_instantiate` mechanism. This is a critical point in the system, and it's where the rubber meets the road. I need to understand what's happening here, specifically. Given my experience, I'm thinking about the low-level instantiation process - what's being built, how dependencies are resolved, and potential points of failure. I want to see exactly how this handles whatever the current task is, and if it aligns with my expectations. This check of `__d_instantiate` should reveal what's currently going on.
|
| 25/2 |
2026/05/20 02:00 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:fs/dcache.c IncludeLines:true Name:__d_instantiate]
Results: map[SourceCode:2038: static void __d_instantiate(struct dentry *dentry, struct inode *inode)
2039: {
2040: unsigned add_flags = d_flags_for_inode(inode);
2041: WARN_ON(d_in_lookup(dentry));
2042:
2043: /*
2044: * The negative counter only tracks dentries on the LRU. Don't dec if
2045: * d_lru is on another list.
2046: */
2047: if ((dentry->d_flags &
2048: (DCACHE_LRU_LIST|DCACHE_SHRINK_LIST)) == DCACHE_LRU_LIST)
2049: this_cpu_dec(nr_dentry_negative);
2050: hlist_add_head(&dentry->d_alias, &inode->i_dentry);
2051: raw_write_seqcount_begin(&dentry->d_seq);
2052: __d_set_inode_and_type(dentry, inode, add_flags);
2053: raw_write_seqcount_end(&dentry->d_seq);
2054: fsnotify_update_flags(dentry);
2055: }
SourceFile:fs/dcache.c]
|
| 26/2 |
2026/05/20 02:00 |
llm |
expert |
0m
Model:
Tokens:
input: 13249
output: 23
thoughts: 27
Thoughts: Here's a summary of my thought process:
**Investigating a Potentially Synchronous Instantiation**
Okay, so `__d_instantiate` is being called while `d_lock` is held. That's a potential concurrency issue, or at least something that needs careful consideration. I need to understand the context of this. Let's trace back and see *exactly* where `__d_instantiate` is called. Finding the callers will give me the information I need to assess whether this is an intended behavior with a valid justification, or a bug that needs to be addressed. This requires a quick, precise code dive to identify the paths that lead to this call and understand what's happening around it.
|
| 27/2 |
2026/05/20 02:00 |
tool |
codesearch-find-references |
0m
Args: map[Name:__d_instantiate]
Results: map[References:[map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:d_instantiate SourceFile:fs/dcache.c SourceLine:2079] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:d_instantiate_new SourceFile:fs/dcache.c SourceLine:2100] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:d_make_persistent SourceFile:fs/dcache.c SourceLine:2870]] TruncatedOutput:false]
|
| 28/2 |
2026/05/20 02:00 |
llm |
expert |
0m
Model:
Tokens:
input: 13617
output: 39
thoughts: 10
Thoughts: Okay, here's my interpretation of that thought process, tailored for an expert audience, and written in the first person:
**Initial Checkpoint: Examining `d_instantiate`**
Alright, let's zero in on `d_instantiate`. My immediate thought is, what are we checking *for* precisely? Given the context, I'm assuming we're either looking for a specific behavior, a bug, or an optimization opportunity within that function. My intuition tells me that `d_instantiate` is likely a core component, maybe a factory method, a class constructor or a resource allocation module, so any issue there could cascade throughout the system. I will need to consider its inputs, outputs, and any potential side-effects that it may introduce into the environment. Time to dig in and determine the critical path, test coverage and dependency injection.
|
| 29/2 |
2026/05/20 02:00 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:fs/dcache.c IncludeLines:true Name:d_instantiate]
Results: map[SourceCode:2072: void d_instantiate(struct dentry *entry, struct inode * inode)
2073: {
2074: BUG_ON(d_really_is_positive(entry));
2075: if (inode) {
2076: security_d_instantiate(entry, inode);
2077: spin_lock(&inode->i_lock);
2078: spin_lock(&entry->d_lock);
2079: __d_instantiate(entry, inode);
2080: spin_unlock(&entry->d_lock);
2081: spin_unlock(&inode->i_lock);
2082: }
2083: }
SourceFile:fs/dcache.c]
|
| 30/2 |
2026/05/20 02:00 |
llm |
expert |
0m
Model:
Tokens:
input: 14058
output: 18
thoughts: 1106
Thoughts: **Benign Data Race in d_flags: Analysis and Assessment**
Okay, let's break this down. From what I've gathered, the core issue revolves around a potential data race on the `d_flags` field of a dentry structure within the kernel's dcache implementation. The function `__d_instantiate` is called with the `d_lock` held, so any modifications related to `DCACHE_ENTRY_TYPE` are synchronized. Similarly, the write operation `dentry->d_flags &= ~DCACHE_PERSISTENT;` is protected by `d_lock`. This means that writer-writer races are not present.
The vulnerability stems from a potential read-write race between a writer (holding `d_lock`) and a reader (without `d_lock`). The reader in question is the `d_is_symlink` function, which, in turn, performs a bitwise AND operation with `dentry->d_flags` using `DCACHE_ENTRY_TYPE`. The key here is that the writer is only modifying `DCACHE_PERSISTENT` (bit 27), while the reader is interested in `DCACHE_ENTRY_TYPE` bits (19-21).
Now, the important consideration is atomicity. The writer *could* implement the modification as a smaller than 32-bit (or architecture native word size) write that doesn't touch the `DCACHE_ENTRY_TYPE` bits. Even if it *is* implemented as a 32-bit read-modify-write, the read will be a valid 32-bit read. Given that Linux supports 32-bit and 64-bit architectures where 32-bit memory accesses are atomic when aligned, the data race is benign. The reader will either see the old or new value, but the `DCACHE_ENTRY_TYPE` bits remain consistent either way, therefore the reader will return the correct information.
The KCSAN report flagged `d_is_symlink` within `do_readlinkat`, specifically, which further confirms this is a classic benign data race.
Now, let's assess the implications:
* **Exploitability:** No. It's benign, not exploitable.
* **Denial of Service:** No. It's benign, and doesn't trigger any serious errors.
* **Accessibility:** Unprivileged processes and user namespaces have access through `unlink` and `readlink`.
* **Other Trigger:** The bug is not VM-specific, triggered by network, or via peripherals.
A final check involves the possibility of `d_make_discardable` being called on a dentry concurrently being freed. This scenario involves a sequence where `d_make_discardable` is called from `simple_unlink` -> `shmem_unlink` -> `vfs_unlink`. The dentry is unlinked, but still alive and found by `filename_lookup`. So `do_readlinkat` is called on the dentry. The path and hence dentry are referenced via `path_get`. Therefore, the dentry cannot be freed whilst `do_readlinkat` is running, so there is no use-after-free scenario.
The KCSAN report shows the value change from `0x08300080` to `0x00300180`. The difference is that bit 27 (`0x08000000`) representing `DCACHE_PERSISTENT` was cleared. However, bit 8 (`0x00000100`) was set. I need to investigate what bit 8 represents in the `d_flags`.
|
| 31/2 |
2026/05/20 02:01 |
tool |
grepper |
0m
Args:
Results: map[Output:
Full output is too long, showing 500 out of 19492 lines.
Use more precise expression if possible.
[Documentation/ABI/testing/sysfs-devices-platform-ACPI-TAD=6=Description:
--
Documentation/ABI/testing/sysfs-devices-platform-ACPI-TAD-18- BIT(7): The DC timer wakes up from S4 if set
Documentation/ABI/testing/sysfs-devices-platform-ACPI-TAD:19: BIT(8): The DC timer wakes up from S5 if set
Documentation/ABI/testing/sysfs-devices-platform-ACPI-TAD-20- ======= ======================================================
--
Documentation/ABI/testing/sysfs-driver-zynqmp-fpga=5=Description: (RO) Read fpga status.
--
Documentation/ABI/testing/sysfs-driver-zynqmp-fpga-35-
Documentation/ABI/testing/sysfs-driver-zynqmp-fpga:36: BIT(8) to BIT(10) Status of the mode pins
Documentation/ABI/testing/sysfs-driver-zynqmp-fpga-37-
--
arch/arm/boot/dts/ti/omap/omap3-beagle-xm.dts=325=&twl_gpio {
--
arch/arm/boot/dts/ti/omap/omap3-beagle-xm.dts-330- * pulldowns:
arch/arm/boot/dts/ti/omap/omap3-beagle-xm.dts:331: * BIT(2), BIT(6), BIT(7), BIT(8), BIT(13)
arch/arm/boot/dts/ti/omap/omap3-beagle-xm.dts-332- * BIT(15), BIT(16), BIT(17)
--
arch/arm/boot/dts/ti/omap/omap3-beagle.dts=307=&twl_gpio {
--
arch/arm/boot/dts/ti/omap/omap3-beagle.dts-312- * pulldowns:
arch/arm/boot/dts/ti/omap/omap3-beagle.dts:313: * BIT(2), BIT(6), BIT(7), BIT(8), BIT(13)
arch/arm/boot/dts/ti/omap/omap3-beagle.dts-314- * BIT(15), BIT(16), BIT(17)
--
arch/arm/boot/dts/ti/omap/omap3-devkit8000-common.dtsi=179=&twl_gpio {
--
arch/arm/boot/dts/ti/omap/omap3-devkit8000-common.dtsi-182- * pulldowns:
arch/arm/boot/dts/ti/omap/omap3-devkit8000-common.dtsi:183: * BIT(1), BIT(2), BIT(6), BIT(7), BIT(8), BIT(13)
arch/arm/boot/dts/ti/omap/omap3-devkit8000-common.dtsi-184- * BIT(15), BIT(16), BIT(17)
--
arch/arm/boot/dts/ti/omap/omap3-gta04.dtsi=681=&twl_gpio {
--
arch/arm/boot/dts/ti/omap/omap3-gta04.dtsi-685- * pulldowns:
arch/arm/boot/dts/ti/omap/omap3-gta04.dtsi:686: * BIT(0), BIT(1), BIT(6), BIT(7), BIT(8), BIT(13)
arch/arm/boot/dts/ti/omap/omap3-gta04.dtsi-687- * BIT(15), BIT(16), BIT(17)
arch/arm/boot/dts/ti/omap/omap3-gta04.dtsi-688- */
arch/arm/boot/dts/ti/omap/omap3-gta04.dtsi:689: ti,pulldowns = <(BIT(0) | BIT(1) | BIT(6) | BIT(7) | BIT(8) |
arch/arm/boot/dts/ti/omap/omap3-gta04.dtsi-690- BIT(13) | BIT(15) | BIT(16) | BIT(17))>;
--
arch/arm/boot/dts/ti/omap/omap3-n950-n9.dtsi=164=&twl_gpio {
arch/arm/boot/dts/ti/omap/omap3-n950-n9.dtsi-165- ti,pullups = <0x000001>; /* BIT(0) */
arch/arm/boot/dts/ti/omap/omap3-n950-n9.dtsi:166: ti,pulldowns = <0x008106>; /* BIT(1) | BIT(2) | BIT(8) | BIT(15) */
arch/arm/boot/dts/ti/omap/omap3-n950-n9.dtsi-167-};
--
arch/arm/boot/dts/ti/omap/omap3-tao3530.dtsi=241=&twl_gpio {
--
arch/arm/boot/dts/ti/omap/omap3-tao3530.dtsi-246- * pulldowns:
arch/arm/boot/dts/ti/omap/omap3-tao3530.dtsi:247: * BIT(2), BIT(6), BIT(7), BIT(8), BIT(13)
arch/arm/boot/dts/ti/omap/omap3-tao3530.dtsi-248- * BIT(15), BIT(16), BIT(17)
--
arch/arm/mach-bcm/bcm63xx_pmb.c-19-#define CORE_PWR_CTRL_MASK 0x3
arch/arm/mach-bcm/bcm63xx_pmb.c:20:#define PLL_PWR_ON BIT(8)
arch/arm/mach-bcm/bcm63xx_pmb.c-21-#define PLL_LDO_PWR_ON BIT(9)
--
arch/arm/mach-davinci/clock.h-18-#define PLLCTL_PLLENSRC BIT(5)
arch/arm/mach-davinci/clock.h:19:#define PLLCTL_CLKMODE BIT(8)
arch/arm/mach-davinci/clock.h-20-
--
arch/arm/mach-davinci/psc.h-134-#define PDSTAT_STATE_MASK 0x1f
arch/arm/mach-davinci/psc.h:135:#define MDCTL_LRST BIT(8)
arch/arm/mach-davinci/psc.h-136-#define MDCTL_FORCE BIT(31)
arch/arm/mach-davinci/psc.h-137-#define PDCTL_NEXT BIT(0)
arch/arm/mach-davinci/psc.h:138:#define PDCTL_EPCGOOD BIT(8)
arch/arm/mach-davinci/psc.h-139-
--
arch/arm/mach-lpc32xx/lpc32xx.h-207-#define LPC32XX_CLKPWR_GPIOSRC_P1IO1_BIT _BIT(9)
arch/arm/mach-lpc32xx/lpc32xx.h:208:#define LPC32XX_CLKPWR_GPIOSRC_P1IO0_BIT _BIT(8)
arch/arm/mach-lpc32xx/lpc32xx.h-209-#define LPC32XX_CLKPWR_GPIOSRC_P0IO7_BIT _BIT(7)
--
arch/arm/mach-lpc32xx/lpc32xx.h-270-#define LPC32XX_CLKPWR_EXTSRC_SYSCLKEN_BIT _BIT(9)
arch/arm/mach-lpc32xx/lpc32xx.h:271:#define LPC32XX_CLKPWR_EXTSRC_SPI1_DATIN_BIT _BIT(8)
arch/arm/mach-lpc32xx/lpc32xx.h-272-#define LPC32XX_CLKPWR_EXTSRC_GPI_07_BIT _BIT(7)
--
arch/arm/mach-lpc32xx/lpc32xx.h-291-#define LPC32XX_CLKPWR_SDRAM_SELF_RFSH _BIT(9)
arch/arm/mach-lpc32xx/lpc32xx.h:292:#define LPC32XX_CLKPWR_UPD_SDRAM_SELF_RFSH _BIT(8)
arch/arm/mach-lpc32xx/lpc32xx.h-293-#define LPC32XX_CLKPWR_AUTO_SDRAM_SELF_RFSH _BIT(7)
--
arch/arm/mach-lpc32xx/lpc32xx.h-365-#define LPC32XX_CLKPWR_ADCCTRL1_RTDIV(n) (((n) & 0xFF) << 0)
arch/arm/mach-lpc32xx/lpc32xx.h:366:#define LPC32XX_CLKPWR_ADCCTRL1_PCLK_SEL _BIT(8)
arch/arm/mach-lpc32xx/lpc32xx.h-367-
--
arch/arm/mach-lpc32xx/lpc32xx.h-399-#define LPC32XX_CLKPWR_SDRCLK_USE_CAL _BIT(9)
arch/arm/mach-lpc32xx/lpc32xx.h:400:#define LPC32XX_CLKPWR_SDRCLK_DO_CAL _BIT(8)
arch/arm/mach-lpc32xx/lpc32xx.h-401-#define LPC32XX_CLKPWR_SDRCLK_CAL_ON_RTC _BIT(7)
--
arch/arm/mach-lpc32xx/lpc32xx.h-431-#define LPC32XX_CLKPWR_MSCARD_MSDIO_PU_EN _BIT(9)
arch/arm/mach-lpc32xx/lpc32xx.h:432:#define LPC32XX_CLKPWR_MSCARD_MSDIO23_DIS _BIT(8)
arch/arm/mach-lpc32xx/lpc32xx.h-433-#define LPC32XX_CLKPWR_MSCARD_MSDIO1_DIS _BIT(7)
--
arch/arm/mach-omap2/soc.h=423=extern u32 omap_features;
--
arch/arm/mach-omap2/soc.h-432-#define OMAP3_HAS_SDRC BIT(7)
arch/arm/mach-omap2/soc.h:433:#define OMAP3_HAS_IO_CHAIN_CTRL BIT(8)
arch/arm/mach-omap2/soc.h-434-#define OMAP4_HAS_PERF_SILICON BIT(9)
--
arch/arm/mach-omap2/vc.c-29-#define OMAP4430_VDD_IVA_PRESENCE BIT(9)
arch/arm/mach-omap2/vc.c:30:#define OMAP4430_VDD_MPU_PRESENCE BIT(8)
arch/arm/mach-omap2/vc.c-31-#define OMAP4430_AUTO_CTRL_VDD_IVA(x) ((x) << 4)
--
arch/arm/mach-qcom/platsmp.c-26-#define APCS_CPU_PWR_CTL 0x04
arch/arm/mach-qcom/platsmp.c:27:#define PLL_CLAMP BIT(8)
arch/arm/mach-qcom/platsmp.c-28-#define CORE_PWRD_UP BIT(7)
--
arch/arm/mach-rockchip/pm.h=22=static inline void rockchip_suspend_init(void)
--
arch/arm/mach-rockchip/pm.h-46-#define SGRF_PCLK_WDT_GATE_WRITE BIT(22)
arch/arm/mach-rockchip/pm.h:47:#define SGRF_FAST_BOOT_EN BIT(8)
arch/arm/mach-rockchip/pm.h-48-#define SGRF_FAST_BOOT_EN_WRITE BIT(24)
--
arch/arm/mach-socfpga/ocram.c=15=void socfpga_init_ocram_ecc(void)
--
arch/arm/mach-socfpga/ocram.c-47-#define ALTR_A10_ECC_INITCOMPLETEA BIT(0)
arch/arm/mach-socfpga/ocram.c:48:#define ALTR_A10_ECC_INITCOMPLETEB BIT(8)
arch/arm/mach-socfpga/ocram.c-49-
--
arch/arm/mach-socfpga/ocram.c-54-#define ALTR_A10_ECC_SERRPENA BIT(0)
arch/arm/mach-socfpga/ocram.c:55:#define ALTR_A10_ECC_DERRPENA BIT(8)
arch/arm/mach-socfpga/ocram.c-56-#define ALTR_A10_ECC_ERRPENA_MASK (ALTR_A10_ECC_SERRPENA | \
--
arch/arm/mach-sunxi/mc_smp.c-53-#define CPUCFG_CX_RST_CTRL_H_RST BIT(12)
arch/arm/mach-sunxi/mc_smp.c:54:#define CPUCFG_CX_RST_CTRL_L2_RST BIT(8)
arch/arm/mach-sunxi/mc_smp.c-55-#define CPUCFG_CX_RST_CTRL_CX_RST(n) BIT(4 + (n))
--
arch/arm64/include/asm/kvm_host.h=860=struct kvm_vcpu_arch {
--
arch/arm64/include/asm/kvm_host.h-1113-/* SError pending for nested guest */
arch/arm64/include/asm/kvm_host.h:1114:#define NESTED_SERROR_PENDING __vcpu_single_flag(sflags, BIT(8))
arch/arm64/include/asm/kvm_host.h-1115-
--
arch/arm64/include/asm/sysreg.h-327-#define SYS_PAR_EL1_FST GENMASK(6, 1)
arch/arm64/include/asm/sysreg.h:328:#define SYS_PAR_EL1_PTW BIT(8)
arch/arm64/include/asm/sysreg.h-329-#define SYS_PAR_EL1_S BIT(9)
--
arch/arm64/kernel/cpu_errata.c=442=static const struct arm64_cpu_capabilities erratum_843419_list[] = {
--
arch/arm64/kernel/cpu_errata.c-446- ERRATA_MIDR_REV_RANGE(MIDR_CORTEX_A53, 0, 0, 4),
arch/arm64/kernel/cpu_errata.c:447: MIDR_FIXED(0x4, BIT(8)),
arch/arm64/kernel/cpu_errata.c-448- },
--
arch/loongarch/include/asm/loongarch.h-84-#define CPUCFG2_LASX BIT(7)
arch/loongarch/include/asm/loongarch.h:85:#define CPUCFG2_COMPLEX BIT(8)
arch/loongarch/include/asm/loongarch.h-86-#define CPUCFG2_CRYPTO BIT(9)
--
arch/loongarch/include/asm/loongarch.h-149-#define CPUCFG16_L2_DPRE BIT(7)
arch/loongarch/include/asm/loongarch.h:150:#define CPUCFG16_L2_DPRIV BIT(8)
arch/loongarch/include/asm/loongarch.h-151-#define CPUCFG16_L2_DINCL BIT(9)
--
arch/mips/fw/cfe/cfe_api.c=421=void __init cfe_die(char *fmt, ...)
--
arch/mips/fw/cfe/cfe_api.c-455- __write_32bit_c0_register($22, 5,
arch/mips/fw/cfe/cfe_api.c:456: __read_32bit_c0_register($22, 5) & ~BIT(8));
arch/mips/fw/cfe/cfe_api.c-457- break;
--
arch/mips/include/asm/ip32/crime.h=20=struct sgi_crime {
--
arch/mips/include/asm/ip32/crime.h-57-#define MACE_PCI_BRIDGE_INT BIT(7)
arch/mips/include/asm/ip32/crime.h:58:#define MACEPCI_SCSI0_INT BIT(8)
arch/mips/include/asm/ip32/crime.h-59-#define MACEPCI_SCSI1_INT BIT(9)
--
arch/mips/include/asm/ip32/mace.h=23=struct mace_pci {
--
arch/mips/include/asm/ip32/mace.h-51-#define MACEPCI_CONTROL_INT_MASK 0xff
arch/mips/include/asm/ip32/mace.h:52:#define MACEPCI_CONTROL_SERR_ENA BIT(8)
arch/mips/include/asm/ip32/mace.h-53-#define MACEPCI_CONTROL_ARB_N6 BIT(9)
--
arch/mips/include/asm/ip32/mace.h=181=struct mace_isactrl {
--
arch/mips/include/asm/ip32/mace.h-203-#define MACEISA_AUDIO3_MERR_INT BIT(7)
arch/mips/include/asm/ip32/mace.h:204:#define MACEISA_RTC_INT BIT(8)
arch/mips/include/asm/ip32/mace.h-205-#define MACEISA_KEYB_INT BIT(9)
--
arch/mips/include/asm/mach-ath79/ar71xx_regs.h-173-#define QCA956X_MAC_CFG1_TX_RST BIT(18)
arch/mips/include/asm/mach-ath79/ar71xx_regs.h:174:#define QCA956X_MAC_CFG1_LOOPBACK BIT(8)
arch/mips/include/asm/mach-ath79/ar71xx_regs.h-175-#define QCA956X_MAC_CFG1_RX_EN BIT(2)
--
arch/mips/include/asm/mach-ath79/ar71xx_regs.h-179-#define QCA956X_MAC_CFG2_IF_1000 BIT(9)
arch/mips/include/asm/mach-ath79/ar71xx_regs.h:180:#define QCA956X_MAC_CFG2_IF_10_100 BIT(8)
arch/mips/include/asm/mach-ath79/ar71xx_regs.h-181-#define QCA956X_MAC_CFG2_HUGE_FRAME_EN BIT(5)
--
arch/mips/include/asm/mach-ath79/ar71xx_regs.h-557-#define MISC_INT_TIMER3 BIT(9)
arch/mips/include/asm/mach-ath79/ar71xx_regs.h:558:#define MISC_INT_TIMER2 BIT(8)
arch/mips/include/asm/mach-ath79/ar71xx_regs.h-559-#define MISC_INT_DMA BIT(7)
--
arch/mips/include/asm/mach-ath79/ar71xx_regs.h-579-#define AR71XX_RESET_GE0_MAC BIT(9)
arch/mips/include/asm/mach-ath79/ar71xx_regs.h:580:#define AR71XX_RESET_GE0_PHY BIT(8)
arch/mips/include/asm/mach-ath79/ar71xx_regs.h-581-#define AR71XX_RESET_USB_OHCI_DLL BIT(6)
--
arch/mips/include/asm/mach-ath79/ar71xx_regs.h-635-#define AR934X_RESET_GE0_MAC BIT(9)
arch/mips/include/asm/mach-ath79/ar71xx_regs.h:636:#define AR934X_RESET_ETH_SWITCH BIT(8)
arch/mips/include/asm/mach-ath79/ar71xx_regs.h-637-#define AR934X_RESET_PCIE_PHY BIT(7)
--
arch/mips/include/asm/mach-ath79/ar71xx_regs.h-659-#define QCA953X_RESET_GE0_MAC BIT(9)
arch/mips/include/asm/mach-ath79/ar71xx_regs.h:660:#define QCA953X_RESET_ETH_SWITCH BIT(8)
arch/mips/include/asm/mach-ath79/ar71xx_regs.h-661-#define QCA953X_RESET_PCIE_PHY BIT(7)
--
arch/mips/include/asm/mach-ath79/ar71xx_regs.h-689-#define QCA955X_RESET_GE0_MAC BIT(9)
arch/mips/include/asm/mach-ath79/ar71xx_regs.h:690:#define QCA955X_RESET_SGMII BIT(8)
arch/mips/include/asm/mach-ath79/ar71xx_regs.h-691-#define QCA955X_RESET_PCIE_PHY BIT(7)
--
arch/mips/include/asm/mach-ath79/ar71xx_regs.h-711-#define QCA956X_RESET_GE0_MAC BIT(9)
arch/mips/include/asm/mach-ath79/ar71xx_regs.h:712:#define QCA956X_RESET_SGMII BIT(8)
arch/mips/include/asm/mach-ath79/ar71xx_regs.h-713-#define QCA956X_RESET_USB_HOST BIT(5)
--
arch/mips/include/asm/mach-ath79/ar71xx_regs.h-757-#define AR934X_PCIE_WMAC_INT_PCIE_RC2 BIT(7)
arch/mips/include/asm/mach-ath79/ar71xx_regs.h:758:#define AR934X_PCIE_WMAC_INT_PCIE_RC3 BIT(8)
arch/mips/include/asm/mach-ath79/ar71xx_regs.h-759-#define AR934X_PCIE_WMAC_INT_WMAC_ALL \
--
arch/mips/include/asm/mach-ath79/ar71xx_regs.h-775-#define QCA953X_PCIE_WMAC_INT_PCIE_RC2 BIT(7)
arch/mips/include/asm/mach-ath79/ar71xx_regs.h:776:#define QCA953X_PCIE_WMAC_INT_PCIE_RC3 BIT(8)
arch/mips/include/asm/mach-ath79/ar71xx_regs.h-777-#define QCA953X_PCIE_WMAC_INT_WMAC_ALL \
--
arch/mips/include/asm/mach-ath79/ar71xx_regs.h-793-#define QCA955X_EXT_INT_PCIE_RC1_INT2 BIT(7)
arch/mips/include/asm/mach-ath79/ar71xx_regs.h:794:#define QCA955X_EXT_INT_PCIE_RC1_INT3 BIT(8)
arch/mips/include/asm/mach-ath79/ar71xx_regs.h-795-#define QCA955X_EXT_INT_PCIE_RC2 BIT(12)
--
arch/mips/include/asm/mach-ath79/ar71xx_regs.h-824-#define QCA956X_EXT_INT_PCIE_RC1_INT2 BIT(7)
arch/mips/include/asm/mach-ath79/ar71xx_regs.h:825:#define QCA956X_EXT_INT_PCIE_RC1_INT3 BIT(8)
arch/mips/include/asm/mach-ath79/ar71xx_regs.h-826-#define QCA956X_EXT_INT_PCIE_RC2 BIT(12)
--
arch/mips/include/asm/mach-ath79/ar71xx_regs.h-905-#define AR71XX_SPI_IOC_DO BIT(0) /* Data Out pin */
arch/mips/include/asm/mach-ath79/ar71xx_regs.h:906:#define AR71XX_SPI_IOC_CLK BIT(8) /* CLK pin */
arch/mips/include/asm/mach-ath79/ar71xx_regs.h-907-#define AR71XX_SPI_IOC_CS(n) BIT(16 + (n))
--
arch/mips/include/asm/mach-ath79/ar71xx_regs.h-1029-#define AR71XX_GPIO_FUNC_SPI_CS1_EN BIT(12)
arch/mips/include/asm/mach-ath79/ar71xx_regs.h:1030:#define AR71XX_GPIO_FUNC_UART_EN BIT(8)
arch/mips/include/asm/mach-ath79/ar71xx_regs.h-1031-#define AR71XX_GPIO_FUNC_USB_OC_EN BIT(4)
--
arch/mips/include/asm/mach-ath79/ar71xx_regs.h-1041-#define AR724X_GPIO_FUNC_CLK_OBS2_EN BIT(9)
arch/mips/include/asm/mach-ath79/ar71xx_regs.h:1042:#define AR724X_GPIO_FUNC_CLK_OBS1_EN BIT(8)
arch/mips/include/asm/mach-ath79/ar71xx_regs.h-1043-#define AR724X_GPIO_FUNC_ETH_SWITCH_LED4_EN BIT(7)
--
arch/mips/include/asm/mach-ath79/ar71xx_regs.h-1059-#define AR913X_GPIO_FUNC_UART_RTSCTS_EN BIT(9)
arch/mips/include/asm/mach-ath79/ar71xx_regs.h:1060:#define AR913X_GPIO_FUNC_UART_EN BIT(8)
arch/mips/include/asm/mach-ath79/ar71xx_regs.h-1061-#define AR913X_GPIO_FUNC_USB_CLK_EN BIT(4)
--
arch/mips/include/asm/mach-ath79/ar71xx_regs.h-1083-#define AR934X_GPIO_FUNC_CLK_OBS7_EN BIT(9)
arch/mips/include/asm/mach-ath79/ar71xx_regs.h:1084:#define AR934X_GPIO_FUNC_CLK_OBS6_EN BIT(8)
arch/mips/include/asm/mach-ath79/ar71xx_regs.h-1085-#define AR934X_GPIO_FUNC_CLK_OBS5_EN BIT(7)
--
arch/mips/include/asm/mach-ath79/ar71xx_regs.h-1103-#define QCA955X_GPIO_FUNC_CLK_OBS7_EN BIT(9)
arch/mips/include/asm/mach-ath79/ar71xx_regs.h:1104:#define QCA955X_GPIO_FUNC_CLK_OBS6_EN BIT(8)
arch/mips/include/asm/mach-ath79/ar71xx_regs.h-1105-#define QCA955X_GPIO_FUNC_CLK_OBS5_EN BIT(7)
--
arch/mips/include/asm/mach-ath79/ar71xx_regs.h-1200-#define AR933X_ETH_CFG_SW_PHY_SWAP BIT(7)
arch/mips/include/asm/mach-ath79/ar71xx_regs.h:1201:#define AR933X_ETH_CFG_SW_PHY_ADDR_SWAP BIT(8)
arch/mips/include/asm/mach-ath79/ar71xx_regs.h-1202-#define AR933X_ETH_CFG_RMII_GE0 BIT(9)
--
arch/mips/include/asm/mach-ath79/ar71xx_regs.h-1284-#define QCA956X_ETH_CFG_SW_ONLY_MODE BIT(7)
arch/mips/include/asm/mach-ath79/ar71xx_regs.h:1285:#define QCA956X_ETH_CFG_SW_PHY_SWAP BIT(8)
arch/mips/include/asm/mach-ath79/ar71xx_regs.h-1286-#define QCA956X_ETH_CFG_SW_PHY_ADDR_SWAP BIT(9)
--
arch/mips/include/asm/mach-ath79/ar71xx_regs.h-1304-#define QCA956X_SGMII_SERDES_TX_DR_CTRL_SHIFT 4
arch/mips/include/asm/mach-ath79/ar71xx_regs.h:1305:#define QCA956X_SGMII_SERDES_PLL_BW BIT(8)
arch/mips/include/asm/mach-ath79/ar71xx_regs.h-1306-#define QCA956X_SGMII_SERDES_VCO_FAST BIT(9)
--
arch/mips/include/asm/mach-ath79/ar933x_uart.h-20-#define AR933X_UART_DATA_TX_RX_MASK 0xff
arch/mips/include/asm/mach-ath79/ar933x_uart.h:21:#define AR933X_UART_DATA_RX_CSR BIT(8)
arch/mips/include/asm/mach-ath79/ar933x_uart.h-22-#define AR933X_UART_DATA_TX_CSR BIT(9)
--
arch/mips/include/asm/mach-ath79/ar933x_uart.h-37-#define AR933X_UART_CS_TX_READY_ORIDE BIT(7)
arch/mips/include/asm/mach-ath79/ar933x_uart.h:38:#define AR933X_UART_CS_RX_READY_ORIDE BIT(8)
arch/mips/include/asm/mach-ath79/ar933x_uart.h-39-#define AR933X_UART_CS_TX_READY BIT(9)
--
arch/mips/include/asm/mach-ath79/ar933x_uart.h-59-#define AR933X_UART_INT_RX_BREAK_OFF BIT(7)
arch/mips/include/asm/mach-ath79/ar933x_uart.h:60:#define AR933X_UART_INT_RX_FULL BIT(8)
arch/mips/include/asm/mach-ath79/ar933x_uart.h-61-#define AR933X_UART_INT_TX_EMPTY BIT(9)
--
arch/mips/include/asm/mach-loongson64/loongson_regs.h=19=static inline u32 read_cpucfg(u32 reg)
--
arch/mips/include/asm/mach-loongson64/loongson_regs.h-47-#define LOONGSON_CFG1_CGP BIT(7)
arch/mips/include/asm/mach-loongson64/loongson_regs.h:48:#define LOONGSON_CFG1_WRP BIT(8)
arch/mips/include/asm/mach-loongson64/loongson_regs.h-49-#define LOONGSON_CFG1_LSX1 BIT(9)
--
arch/mips/include/asm/mach-loongson64/loongson_regs.h-82-#define LOONGSON_CFG2_LBTMMU BIT(7)
arch/mips/include/asm/mach-loongson64/loongson_regs.h:83:#define LOONGSON_CFG2_LPMP BIT(8)
arch/mips/include/asm/mach-loongson64/loongson_regs.h-84-#define LOONGSON_CFG2_LPMREV GENMASK(11, 9)
--
arch/mips/include/asm/mach-ralink/rt3883.h-95-#define RT3883_SYSCFG1_USB0_HOST_MODE BIT(10)
arch/mips/include/asm/mach-ralink/rt3883.h:96:#define RT3883_SYSCFG1_PCIE_RC_MODE BIT(8)
arch/mips/include/asm/mach-ralink/rt3883.h-97-#define RT3883_SYSCFG1_PCI_HOST_MODE BIT(7)
--
arch/mips/include/asm/mach-ralink/rt3883.h-176-#define RT3883_RSTCTRL_INTC BIT(9)
arch/mips/include/asm/mach-ralink/rt3883.h:177:#define RT3883_RSTCTRL_TIMER BIT(8)
arch/mips/include/asm/mach-ralink/rt3883.h-178-#define RT3883_RSTCTRL_SYS BIT(0)
--
arch/mips/include/asm/mach-ralink/rt3883.h-187-#define RT3883_INTC_INT_DMA BIT(7)
arch/mips/include/asm/mach-ralink/rt3883.h:188:#define RT3883_INTC_INT_NAND BIT(8)
arch/mips/include/asm/mach-ralink/rt3883.h-189-#define RT3883_INTC_INT_PERFC BIT(9)
--
arch/mips/include/asm/mips-cm.h=287=GCR_ACCESSOR_RW(32, 0x300, l2_pft_control)
arch/mips/include/asm/mips-cm.h-288-#define CM_GCR_L2_PFT_CONTROL_PAGEMASK GENMASK(31, 12)
arch/mips/include/asm/mips-cm.h:289:#define CM_GCR_L2_PFT_CONTROL_PFTEN BIT(8)
arch/mips/include/asm/mips-cm.h-290-#define CM_GCR_L2_PFT_CONTROL_NPFT GENMASK(7, 0)
--
arch/mips/include/asm/mips-cm.h=293=GCR_ACCESSOR_RW(32, 0x308, l2_pft_control_b)
arch/mips/include/asm/mips-cm.h:294:#define CM_GCR_L2_PFT_CONTROL_B_CEN BIT(8)
arch/mips/include/asm/mips-cm.h-295-#define CM_GCR_L2_PFT_CONTROL_B_PORTID GENMASK(7, 0)
--
arch/mips/include/asm/sgi/heart.h=79=struct ip30_heart_regs { /* 0x0ff00000 */
--
arch/mips/include/asm/sgi/heart.h-194-#define HM_BAD_SYSRD_ERE BIT(9)
arch/mips/include/asm/sgi/heart.h:195:#define HM_SYSSTATE_ERE BIT(8)
arch/mips/include/asm/sgi/heart.h-196-#define HM_SYSCMD_ERE BIT(7)
--
arch/mips/include/asm/sgi/heart.h-235-#define HEART_STAT_R4K BIT(9)
arch/mips/include/asm/sgi/heart.h:236:#define HEART_STAT_BIG_ENDIAN BIT(8)
arch/mips/include/asm/sgi/heart.h-237-#define HEART_STAT_PROC_SHFT 4
--
arch/mips/lantiq/xway/dma.c-35-#define DMA_DESCPT BIT(3) /* descriptor complete irq */
arch/mips/lantiq/xway/dma.c:36:#define DMA_TX BIT(8) /* TX channel direction */
arch/mips/lantiq/xway/dma.c-37-#define DMA_CHAN_ON BIT(0) /* channel on / off bit */
--
arch/mips/lantiq/xway/gptu.c-44-#define CON_EDGE_ANY (BIT(7) | BIT(6))
arch/mips/lantiq/xway/gptu.c:45:#define CON_SYNC BIT(8)
arch/mips/lantiq/xway/gptu.c-46-#define CON_CLK_INT BIT(10)
--
arch/mips/lantiq/xway/gptu.c-52-/* set clock to runmode */
arch/mips/lantiq/xway/gptu.c:53:#define CLC_RMC BIT(8)
arch/mips/lantiq/xway/gptu.c-54-/* bring core out of suspend */
--
arch/mips/lantiq/xway/sysctrl.c=76=static u32 pmu_clk_cr_b[] = {
--
arch/mips/lantiq/xway/sysctrl.c-94-#define PMU_USIF BIT(7) /* from vr9 until grx390 */
arch/mips/lantiq/xway/sysctrl.c:95:#define PMU_SPI BIT(8)
arch/mips/lantiq/xway/sysctrl.c-96-#define PMU_DFE BIT(9)
--
arch/mips/lantiq/xway/sysctrl.c-137-#define PMU_ANALOG_USB1_P BIT(1)
arch/mips/lantiq/xway/sysctrl.c:138:#define PMU_ANALOG_PCIE0_P BIT(8)
arch/mips/lantiq/xway/sysctrl.c-139-#define PMU_ANALOG_PCIE1_P BIT(9)
--
arch/powerpc/platforms/512x/clock-commonclk.c=1014=static void __init mpc5121_clk_provide_backwards_compat(void)
--
arch/powerpc/platforms/512x/clock-commonclk.c-1024- DID_REG_FEC = BIT(7),
arch/powerpc/platforms/512x/clock-commonclk.c:1025: DID_REG_USB = BIT(8),
arch/powerpc/platforms/512x/clock-commonclk.c-1026- DID_REG_PATA = BIT(9),
--
arch/riscv/include/asm/csr.h-210-#define HVICTL_DPR BIT(9)
arch/riscv/include/asm/csr.h:211:#define HVICTL_IPRIOM BIT(8)
arch/riscv/include/asm/csr.h-212-#define HVICTL_IPRIO GENMASK(7, 0)
--
arch/riscv/kvm/aia_aplic.c=18=struct aplic_irq {
--
arch/riscv/kvm/aia_aplic.c-25- APLIC_IRQ_STATE_ENABLED)
arch/riscv/kvm/aia_aplic.c:26:#define APLIC_IRQ_STATE_INPUT BIT(8)
arch/riscv/kvm/aia_aplic.c-27- u32 target;
--
arch/sh/drivers/pci/pci-sh4.h-46- #define SH4_PCIINTM_TMTOIM BIT(9) /* Target retry timeout */
arch/sh/drivers/pci/pci-sh4.h:47: #define SH4_PCIINTM_MDEIM BIT(8) /* Master function disable error */
arch/sh/drivers/pci/pci-sh4.h-48- #define SH4_PCIINTM_APEDIM BIT(7) /* Address parity error detection */
--
arch/sparc/include/asm/hypervisor.h=994=unsigned long sun4v_ccb_submit(unsigned long ccb_buf,
--
arch/sparc/include/asm/hypervisor.h-1009-#define HV_CCB_ALL_OR_NOTHING BIT(7)
arch/sparc/include/asm/hypervisor.h:1010:#define HV_CCB_QUEUE_INFO BIT(8)
arch/sparc/include/asm/hypervisor.h-1011-#define HV_CCB_VA_REJECT 0UL
--
arch/um/drivers/vhost_user.h-19-#define VHOST_USER_VRING_INDEX_MASK 0xff
arch/um/drivers/vhost_user.h:20:#define VHOST_USER_VRING_POLL_MASK BIT(8)
arch/um/drivers/vhost_user.h-21-
--
arch/x86/coco/sev/vc-shared.c=168=static enum es_result vc_insn_string_write(struct es_em_ctxt *ctxt,
--
arch/x86/coco/sev/vc-shared.c-202-#define IOIO_ADDR_64 BIT(9)
arch/x86/coco/sev/vc-shared.c:203:#define IOIO_ADDR_32 BIT(8)
arch/x86/coco/sev/vc-shared.c-204-#define IOIO_ADDR_16 BIT(7)
--
arch/x86/events/intel/pt.c=52=static struct pt_cap_desc {
--
arch/x86/events/intel/pt.c-65- PT_CAP(event_trace, 0, CPUID_EBX, BIT(7)),
arch/x86/events/intel/pt.c:66: PT_CAP(tnt_disable, 0, CPUID_EBX, BIT(8)),
arch/x86/events/intel/pt.c-67- PT_CAP(topa_output, 0, CPUID_ECX, BIT(0)),
--
arch/x86/include/asm/imr.h-27-#define IMR_VC0_SAI_ID1 BIT(9)
arch/x86/include/asm/imr.h:28:#define IMR_VC0_SAI_ID0 BIT(8)
arch/x86/include/asm/imr.h-29-#define IMR_CPU_0 BIT(1) /* SMM mode */
--
arch/x86/include/asm/msr-index.h-149-#define ARCH_CAP_TSX_CTRL_MSR BIT(7) /* MSR for TSX control is available. */
arch/x86/include/asm/msr-index.h:150:#define ARCH_CAP_TAA_NO BIT(8) /*
arch/x86/include/asm/msr-index.h-151- * Not susceptible to
--
arch/x86/include/asm/msr-index.h-367-#define RTIT_CTL_CR3EN BIT(7)
arch/x86/include/asm/msr-index.h:368:#define RTIT_CTL_TOPA BIT(8)
arch/x86/include/asm/msr-index.h-369-#define RTIT_CTL_MTC_EN BIT(9)
--
arch/x86/include/asm/sgx.h=128=enum sgx_attribute {
--
arch/x86/include/asm/sgx.h-136- SGX_ATTR_KSS = BIT(7),
arch/x86/include/asm/sgx.h:137: /* BIT(8) is reserved */
arch/x86/include/asm/sgx.h-138- /* BIT(9) is reserved */
--
arch/x86/include/asm/shared/tdx.h-92-#define TDX_RDI BIT(7)
arch/x86/include/asm/shared/tdx.h:93:#define TDX_R8 BIT(8)
arch/x86/include/asm/shared/tdx.h-94-#define TDX_R9 BIT(9)
--
arch/x86/include/asm/vmx.h=595=enum vm_entry_failure_code {
--
arch/x86/include/asm/vmx.h-615-#define EPT_VIOLATION_GVA_IS_VALID BIT(7)
arch/x86/include/asm/vmx.h:616:#define EPT_VIOLATION_GVA_TRANSLATED BIT(8)
arch/x86/include/asm/vmx.h-617-
--
arch/x86/kernel/cpu/amd_cache_disable.c=19=static void amd_calc_l3_indices(struct amd_northbridge *nb)
--
arch/x86/kernel/cpu/amd_cache_disable.c-35-
arch/x86/kernel/cpu/amd_cache_disable.c:36: l3->subcaches[2] = sc2 = !(val & BIT(8)) + !(val & BIT(9));
arch/x86/kernel/cpu/amd_cache_disable.c-37- l3->subcaches[3] = sc3 = !(val & BIT(12)) + !(val & BIT(13));
--
arch/x86/kernel/cpu/common.c=1135=static void identify_cpu_without_cpuid(struct cpuinfo_x86 *c)
--
arch/x86/kernel/cpu/common.c-1166-#define NO_ITLB_MULTIHIT BIT(7)
arch/x86/kernel/cpu/common.c:1167:#define NO_SPECTRE_V2 BIT(8)
arch/x86/kernel/cpu/common.c-1168-#define NO_MMIO BIT(9)
--
arch/x86/kernel/cpu/common.c=1184=static const __initconst struct x86_cpu_id cpu_vuln_whitelist[] = {
--
arch/x86/kernel/cpu/common.c-1278-/* CPU is affected by Indirect Target Selection */
arch/x86/kernel/cpu/common.c:1279:#define ITS BIT(8)
arch/x86/kernel/cpu/common.c-1280-/* CPU is affected by Indirect Target Selection, but guest-host isolation is not affected */
--
arch/x86/kernel/cpu/mce/amd.c=277=static void smca_configure(unsigned int bank, unsigned int cpu)
--
arch/x86/kernel/cpu/mce/amd.c-328- __set_bit(bank, data->thr_intr_banks);
arch/x86/kernel/cpu/mce/amd.c:329: high |= BIT(8);
arch/x86/kernel/cpu/mce/amd.c-330- }
arch/x86/kernel/cpu/mce/amd.c-331-
arch/x86/kernel/cpu/mce/amd.c:332: this_cpu_ptr(mce_banks_array)[bank].lsb_in_status = !!(low & BIT(8));
arch/x86/kernel/cpu/mce/amd.c-333-
--
arch/x86/kernel/cpu/mce/core.c=533=bool mce_is_memory_error(struct mce *m)
--
arch/x86/kernel/cpu/mce/core.c-555- return (m->status & 0xef80) == BIT(7) ||
arch/x86/kernel/cpu/mce/core.c:556: (m->status & 0xef00) == BIT(8) ||
arch/x86/kernel/cpu/mce/core.c-557- (m->status & 0xeffc) == 0xc;
--
arch/x86/kernel/vsmp_64.c=26=static void __init set_vsmp_ctl(void)
--
arch/x86/kernel/vsmp_64.c-40-#ifdef CONFIG_SMP
arch/x86/kernel/vsmp_64.c:41: if (cap & ctl & BIT(8)) {
arch/x86/kernel/vsmp_64.c:42: ctl &= ~BIT(8);
arch/x86/kernel/vsmp_64.c-43-
--
drivers/accel/habanalabs/gaudi/gaudiP.h-166-#define HW_CAP_CPU_Q BIT(7)
drivers/accel/habanalabs/gaudi/gaudiP.h:167:#define HW_CAP_HBM_DMA BIT(8)
drivers/accel/habanalabs/gaudi/gaudiP.h-168-#define HW_CAP_SRAM_SCRAMBLER BIT(10)
--
drivers/accel/habanalabs/include/gaudi/asic_reg/gaudi_regs.h-109-#define GAUDI_ECC_MEM_INFO_CLR_OFFSET 0xF28
drivers/accel/habanalabs/include/gaudi/asic_reg/gaudi_regs.h:110:#define GAUDI_ECC_MEM_INFO_CLR_SERR_MASK BIT(8)
drivers/accel/habanalabs/include/gaudi/asic_reg/gaudi_regs.h-111-#define GAUDI_ECC_MEM_INFO_CLR_DERR_MASK BIT(9)
--
drivers/accel/ivpu/ivpu_drv.h-74-#define IVPU_DBG_IPC BIT(7)
drivers/accel/ivpu/ivpu_drv.h:75:#define IVPU_DBG_BO BIT(8)
drivers/accel/ivpu/ivpu_drv.h-76-#define IVPU_DBG_JOB BIT(9)
--
drivers/accel/ivpu/ivpu_drv.h=218=extern bool ivpu_force_snoop;
--
drivers/accel/ivpu/ivpu_drv.h-225-#define IVPU_TEST_MODE_MIP_DISABLE BIT(6)
drivers/accel/ivpu/ivpu_drv.h:226:#define IVPU_TEST_MODE_DISABLE_TIMEOUTS BIT(8)
drivers/accel/ivpu/ivpu_drv.h-227-#define IVPU_TEST_MODE_TURBO_ENABLE BIT(9)
--
drivers/accel/qaic/qaic_ssr.c-28-#define DEBUG_TRANSFER_DONE_RSP BIT(5)
drivers/accel/qaic/qaic_ssr.c:29:#define SSR_EVENT BIT(8)
drivers/accel/qaic/qaic_ssr.c-30-#define SSR_EVENT_RSP BIT(9)
--
drivers/acpi/acpi_tad.c=37=MODULE_AUTHOR("Rafael J. Wysocki");
--
drivers/acpi/acpi_tad.c-47-#define ACPI_TAD_DC_S4_WAKE BIT(7)
drivers/acpi/acpi_tad.c:48:#define ACPI_TAD_DC_S5_WAKE BIT(8)
drivers/acpi/acpi_tad.c-49-
--
drivers/acpi/apei/einj-core.c=806=static struct { u32 mask; const char *str; } const einj_error_type_string[] = {
--
drivers/acpi/apei/einj-core.c-814- { BIT(7), "PCI Express Uncorrectable non-fatal" },
drivers/acpi/apei/einj-core.c:815: { BIT(8), "PCI Express Uncorrectable fatal" },
drivers/acpi/apei/einj-core.c-816- { BIT(9), "Platform Correctable" },
--
drivers/ata/ahci.h=40=enum {
--
drivers/ata/ahci.h-60- AHCI_CMD_PREFETCH = BIT(7),
drivers/ata/ahci.h:61: AHCI_CMD_RESET = BIT(8),
drivers/ata/ahci.h-62- AHCI_CMD_CLR_BUSY = BIT(10),
--
drivers/ata/ahci.h-219- AHCI_HFLAG_NO_PMP = BIT(6), /* no PMP */
drivers/ata/ahci.h:220: AHCI_HFLAG_SECT255 = BIT(8), /* max 255 sectors */
drivers/ata/ahci.h-221- AHCI_HFLAG_YES_NCQ = BIT(9), /* force NCQ cap on */
--
drivers/ata/ahci.h-265- EM_CTL_RST = BIT(9), /* Reset */
drivers/ata/ahci.h:266: EM_CTL_TM = BIT(8), /* Transmit Message */
drivers/ata/ahci.h-267- EM_CTL_MR = BIT(0), /* Message Received */
--
drivers/ata/ahci_dwc.c-73-#define AHCI_DWC_HOST_RX_MEM_M BIT(9)
drivers/ata/ahci_dwc.c:74:#define AHCI_DWC_HOST_RX_MEM_S BIT(8)
drivers/ata/ahci_dwc.c-75-#define AHCI_DWC_HOST_TXFIFO_DEPTH GENMASK(7, 4)
--
drivers/ata/ahci_tegra.c-36-#define T_SATA0_CFG_1_BUS_MASTER BIT(2)
drivers/ata/ahci_tegra.c:37:#define T_SATA0_CFG_1_SERR BIT(8)
drivers/ata/ahci_tegra.c-38-
--
drivers/ata/sata_rcar.c-69-#define SATAPHYADDR_PHYCMD_READ BIT(9)
drivers/ata/sata_rcar.c:70:#define SATAPHYADDR_PHYCMD_WRITE BIT(8)
drivers/ata/sata_rcar.c-71-
--
]
]
|
| 32/2 |
2026/05/20 02:01 |
llm |
expert |
0m
Model:
Tokens:
input: 30635
output: 21
thoughts: 123
Thoughts: **Analyzing a D-Cache Value Change**
Okay, hold on a second. I'm seeing something here. The value just flipped from `0x08300080` to `0x00300180`. Let me write that down: `0x08300080` became `0x00300180`. Right, let's calculate the difference. That's `0x08000100`. Now, what does this tell us? Looks like bit 27 was cleared β that's `DCACHE_PERSISTENT`, I'm pretty sure. But bit 8 was set. Hmm, I need to figure out what that represents. I don't remember off the top of my head what that bit signifies within the D-cache flags. Time to check the `include/linux/dcache.h` header for `BIT(8)`. That should tell me everything I need to know.
|
| 33/2 |
2026/05/20 02:01 |
tool |
grepper |
0m
Error:
Args: map[Expression:BIT\(8\).*DCACHE]
Results:
|
| 34/2 |
2026/05/20 02:01 |
llm |
expert |
0m
Model:
Tokens:
input: 31009
output: 27
thoughts: 21
Thoughts: Okay, let's dive into this. Here's my thought process summarized, assuming I'm already pretty familiar with the Linux kernel:
**Checking for BIT(8) in dcache.h**
Alright, I need to understand how `BIT(8)` is being used in relation to the dcache. That's a classic bit manipulation macro, so I immediately think I need to figure out where and how that specific bit is being used within the `include/linux/dcache.h` header file. It's likely associated with a flag or a bitfield related to dentry or inode caching, but I can't assume. Let's start by looking at that header. My main goal is to understand what that specific bit represents within the broader context of the dcache implementation. Knowing its definition will provide a crucial starting point for digging into the relevant code, whether it is flag settings, or bitmasks.
|
| 35/2 |
2026/05/20 02:01 |
tool |
grepper |
0m
Error:
Args: map[Expression:BIT\(8\).*include/linux/dcache.h]
Results:
|
| 36/2 |
2026/05/20 02:01 |
llm |
expert |
0m
Model:
Tokens:
input: 31264
output: 18
thoughts: 21
Thoughts: Okay, here's my interpretation of that thought process, assuming I'm an expert in this field, presented as a first-person summary:
**Digging into the dcache.h for Bit Shifts**
Alright, so the task at hand is to investigate what's happening with `1 << 8`. My initial instinct, given that this is likely kernel-related code judging by the file path, is to dive straight into `include/linux/dcache.h`. The bit shift operator is a common and efficient method used for calculations related to things like power-of-two alignments, offsets, or flags. "1 << 8" specifically would be equivalent to 256. It's likely involved in calculating some size, mask, or index related to the dcache's internal structures. I need to understand what it is being used for, and that requires knowing the context around it. I anticipate seeing this used in conjunction with a mask operation, or to define sizes. Let's see what the dcache header tells us...
|
| 37/2 |
2026/05/20 02:01 |
tool |
grepper |
0m
Args:
Results: map[Output:
Full output is too long, showing 500 out of 11392 lines.
Use more precise expression if possible.
[Documentation/admin-guide/java.rst=160=javaclassname.c:
--
Documentation/admin-guide/java.rst-243- eof_error();
Documentation/admin-guide/java.rst:244: return (u_int16_t)((b1 << 8) | b2);
Documentation/admin-guide/java.rst-245- }
--
Documentation/devicetree/bindings/pinctrl/cix,sky1-pinctrl.yaml=77=examples:
Documentation/devicetree/bindings/pinctrl/cix,sky1-pinctrl.yaml-78- - |
Documentation/devicetree/bindings/pinctrl/cix,sky1-pinctrl.yaml:79: #define CIX_PAD_GPIO012_FUNC_GPIO012 (11 << 8 | 0x0)
Documentation/devicetree/bindings/pinctrl/cix,sky1-pinctrl.yaml-80- pinctrl@4170000 {
--
Documentation/devicetree/bindings/pinctrl/fsl,imx25-pinctrl.txt=6=CONFIG bits definition:
Documentation/devicetree/bindings/pinctrl/fsl,imx25-pinctrl.txt:7:PAD_CTL_HYS (1 << 8)
Documentation/devicetree/bindings/pinctrl/fsl,imx25-pinctrl.txt-8-PAD_CTL_PKE (1 << 7)
--
Documentation/devicetree/bindings/pinctrl/fsl,imx35-pinctrl.yaml=42=patternProperties:
--
Documentation/devicetree/bindings/pinctrl/fsl,imx35-pinctrl.yaml-75- PAD_CTL_DRIVE_VOLAGAGE_33 (0 << 13)
Documentation/devicetree/bindings/pinctrl/fsl,imx35-pinctrl.yaml:76: PAD_CTL_HYS (1 << 8)
Documentation/devicetree/bindings/pinctrl/fsl,imx35-pinctrl.yaml-77- PAD_CTL_PKE (1 << 7)
--
Documentation/devicetree/bindings/pinctrl/fsl,imx35-pinctrl.yaml-91- PAD_CTL_HVE (1 << 13)
Documentation/devicetree/bindings/pinctrl/fsl,imx35-pinctrl.yaml:92: PAD_CTL_HYS (1 << 8)
Documentation/devicetree/bindings/pinctrl/fsl,imx35-pinctrl.yaml-93- PAD_CTL_PKE (1 << 7)
--
arch/alpha/include/asm/core_cia.h-84-# define CIA_CTRL_PCI_ACK64_EN (1 << 7)
arch/alpha/include/asm/core_cia.h:85:# define CIA_CTRL_ADDR_PE_EN (1 << 8)
arch/alpha/include/asm/core_cia.h-86-# define CIA_CTRL_PERR_EN (1 << 9)
--
arch/alpha/include/asm/core_cia.h-104-# define CIA_CNFG_PCI_DWEN (1 << 5)
arch/alpha/include/asm/core_cia.h:105:# define CIA_CNFG_PCI_WLEN (1 << 8)
arch/alpha/include/asm/core_cia.h-106-#define CIA_IOC_FLASH_CTRL (IDENT_ADDR + 0x8740000200UL)
--
arch/alpha/include/asm/core_cia.h-142-# define CIA_ERR_RCVD_MAS_ABT (1 << 7)
arch/alpha/include/asm/core_cia.h:143:# define CIA_ERR_RCVD_TAR_ABT (1 << 8)
arch/alpha/include/asm/core_cia.h-144-# define CIA_ERR_PA_PTE_INV (1 << 9)
--
arch/arc/include/asm/pgtable-bits-arcv2.h-25-#define _PAGE_SPECIAL (1 << 6)
arch/arc/include/asm/pgtable-bits-arcv2.h:26:#define _PAGE_GLOBAL (1 << 8) /* ASID agnostic (H) */
arch/arc/include/asm/pgtable-bits-arcv2.h-27-#define _PAGE_PRESENT (1 << 9) /* PTE/TLB Valid (H) */
--
arch/arm/include/asm/cp15.h-17-#define CR_B (1 << 7) /* Big endian */
arch/arm/include/asm/cp15.h:18:#define CR_S (1 << 8) /* System MMU protection */
arch/arm/include/asm/cp15.h-19-#define CR_R (1 << 9) /* ROM MMU protection */
--
arch/arm/include/asm/hardware/dec21285.h-69-#define SA110_CNTL_DMASDRAMPARITY (1 << 6)
arch/arm/include/asm/hardware/dec21285.h:70:#define SA110_CNTL_DISCARDTIMER (1 << 8)
arch/arm/include/asm/hardware/dec21285.h-71-#define SA110_CNTL_PCINRESET (1 << 9)
--
arch/arm/include/asm/hardware/sa1111.h-300-
arch/arm/include/asm/hardware/sa1111.h:301:#define GPIO_B0 (1 << 8)
arch/arm/include/asm/hardware/sa1111.h-302-#define GPIO_B1 (1 << 9)
--
arch/arm/include/asm/hardware/sa1111.h=371=extern const struct bus_type sa1111_bus_type;
--
arch/arm/include/asm/hardware/sa1111.h-381-#define SA1111_DEVID_GPIO (1 << 7)
arch/arm/include/asm/hardware/sa1111.h:382:#define SA1111_DEVID_INT (1 << 8)
arch/arm/include/asm/hardware/sa1111.h-383-#define SA1111_DEVID_PCMCIA (1 << 9)
--
arch/arm/include/asm/hardware/scoop.h-29-#define SCOOP_GPCR_PA19 (1 << 9)
arch/arm/include/asm/hardware/scoop.h:30:#define SCOOP_GPCR_PA18 (1 << 8)
arch/arm/include/asm/hardware/scoop.h-31-#define SCOOP_GPCR_PA17 (1 << 7)
--
arch/arm/include/asm/mpu.h-48-#define PMSAv7_AP_PL1RW_PL0R0 (0x2 << 8)
arch/arm/include/asm/mpu.h:49:#define PMSAv7_AP_PL1RW_PL0NA (0x1 << 8)
arch/arm/include/asm/mpu.h-50-
--
arch/arm/include/asm/uaccess.h=294=do { \
--
arch/arm/include/asm/uaccess.h-354- __get_user_asm_byte(__b2, __gu_addr + 1, err, __t); \
arch/arm/include/asm/uaccess.h:355: (x) = (__b1 << 8) | __b2; \
arch/arm/include/asm/uaccess.h-356-})
--
arch/arm/include/uapi/asm/hwcap.h-15-#define HWCAP_EDSP (1 << 7)
arch/arm/include/uapi/asm/hwcap.h:16:#define HWCAP_JAVA (1 << 8)
arch/arm/include/uapi/asm/hwcap.h-17-#define HWCAP_IWMMXT (1 << 9)
--
arch/arm/lib/div64.S=46=UNWIND(.fnstart)
--
arch/arm/lib/div64.S-162-
arch/arm/lib/div64.S:163: cmp yl, #(1 << 8)
arch/arm/lib/div64.S-164- movhs yl, yl, lsr #8
--
arch/arm/lib/lib1funcs.S=33=Boston, MA 02111-1307, USA. */
--
arch/arm/lib/lib1funcs.S-119-
arch/arm/lib/lib1funcs.S:120: cmp \divisor, #(1 << 8)
arch/arm/lib/lib1funcs.S-121- movhs \divisor, \divisor, lsr #8
--
arch/arm/mach-footbridge/include/mach/irqs.h-64-#define IRQ_MASK_TIMER3 (1 << 6)
arch/arm/mach-footbridge/include/mach/irqs.h:65:#define IRQ_MASK_IN0 (1 << 8)
arch/arm/mach-footbridge/include/mach/irqs.h-66-#define IRQ_MASK_IN1 (1 << 9)
--
arch/arm/mach-hisi/hotplug.c-59-#define HIX5HD2_PERI_PMC0 0x1000
arch/arm/mach-hisi/hotplug.c:60:#define PMC0_CPU1_WAIT_MTCOMS_ACK (1 << 8)
arch/arm/mach-hisi/hotplug.c-61-#define PMC0_CPU1_PMC_ENABLE (1 << 7)
--
arch/arm/mach-hisi/platmcpm.c-26-#define CORE_DEBUG_RESET_BIT(x) (1 << (x + 9))
arch/arm/mach-hisi/platmcpm.c:27:#define CLUSTER_L2_RESET_BIT (1 << 8)
arch/arm/mach-hisi/platmcpm.c-28-#define CLUSTER_DEBUG_RESET_BIT (1 << 13)
--
arch/arm/mach-hisi/platmcpm.c-36-#define CORE_DEBUG_RESET_STATUS(x) (1 << (x + 9))
arch/arm/mach-hisi/platmcpm.c:37:#define CLUSTER_L2_RESET_STATUS (1 << 8)
arch/arm/mach-hisi/platmcpm.c-38-#define CLUSTER_DEBUG_RESET_STATUS (1 << 13)
--
arch/arm/mach-hisi/platmcpm.c-50-/* bits definition in FB_SF_INVLD */
arch/arm/mach-hisi/platmcpm.c:51:#define FB_SF_INVLD_START (1 << 8)
arch/arm/mach-hisi/platmcpm.c-52-
--
arch/arm/mach-imx/crmregs-imx3.h=14=extern void __iomem *mx3_ccm_base;
--
arch/arm/mach-imx/crmregs-imx3.h-69-#define MXC_CCM_CCMR_UPE (1 << 9)
arch/arm/mach-imx/crmregs-imx3.h:70:#define MXC_CCM_CCMR_SPE (1 << 8)
arch/arm/mach-imx/crmregs-imx3.h-71-#define MXC_CCM_CCMR_MDS (1 << 7)
--
arch/arm/mach-imx/crmregs-imx3.h-220-#define MXC_CCM_PMCR1_PLLRDIS (0x1 << 7)
arch/arm/mach-imx/crmregs-imx3.h:221:#define MXC_CCM_PMCR1_EMIRQ_EN (0x1 << 8)
arch/arm/mach-imx/crmregs-imx3.h-222-
--
arch/arm/mach-imx/pm-imx5.c-29-#define MXC_CCM_CLPCR_STBY_COUNT_OFFSET 9
arch/arm/mach-imx/pm-imx5.c:30:#define MXC_CCM_CLPCR_VSTBY (0x1 << 8)
arch/arm/mach-imx/pm-imx5.c-31-#define MXC_CCM_CLPCR_SBYOS (0x1 << 6)
--
arch/arm/mach-imx/pm-imx6.c-42-#define BM_CLPCR_DIS_REF_OSC (0x1 << 7)
arch/arm/mach-imx/pm-imx6.c:43:#define BM_CLPCR_VSTBY (0x1 << 8)
arch/arm/mach-imx/pm-imx6.c-44-#define BP_CLPCR_STBY_COUNT 9
--
arch/arm/mach-mxs/mach-mxs.c=71=static inline void __mxs_togl(u32 mask, void __iomem *reg)
--
arch/arm/mach-mxs/mach-mxs.c-78-
arch/arm/mach-mxs/mach-mxs.c:79:#define BM_OCOTP_CTRL_BUSY (1 << 8)
arch/arm/mach-mxs/mach-mxs.c-80-#define BM_OCOTP_CTRL_ERROR (1 << 9)
--
arch/arm/mach-omap2/clock.h-31-#define RATE_IN_4460 (1 << 7)
arch/arm/mach-omap2/clock.h:32:#define RATE_IN_AM33XX (1 << 8)
arch/arm/mach-omap2/clock.h-33-#define RATE_IN_TI814X (1 << 9)
--
arch/arm/mach-omap2/cm-regbits-24xx.h-45-#define OMAP24XX_CORE_CLK_SRC_MASK (0x3 << 0)
arch/arm/mach-omap2/cm-regbits-24xx.h:46:#define OMAP2420_AUTOSTATE_IVA_MASK (1 << 8)
arch/arm/mach-omap2/cm-regbits-24xx.h-47-#define OMAP24XX_AUTOSTATE_DSP_MASK (1 << 0)
--
arch/arm/mach-omap2/control.h-340-#define OMAP343X_PBIASLITEPWRDNZ1 (1 << 9)
arch/arm/mach-omap2/control.h:341:#define OMAP343X_PBIASLITEVMODE1 (1 << 8)
arch/arm/mach-omap2/control.h-342-#define OMAP343X_PBIASLITESUPPLY_HIGH0 (1 << 7)
--
arch/arm/mach-omap2/omap_hwmod.h=239=struct omap_hwmod_ocp_if {
--
arch/arm/mach-omap2/omap_hwmod.h-278-#define SYSS_HAS_RESET_STATUS (1 << 7)
arch/arm/mach-omap2/omap_hwmod.h:279:#define SYSC_NO_CACHE (1 << 8) /* XXX SW flag, belongs elsewhere */
arch/arm/mach-omap2/omap_hwmod.h-280-#define SYSC_HAS_RESET_STATUS (1 << 9)
--
arch/arm/mach-omap2/omap_hwmod.h=376=struct omap_hwmod_omap4_prcm {
--
arch/arm/mach-omap2/omap_hwmod.h-452-#define HWMOD_CONTROL_OPT_CLKS_IN_RESET (1 << 7)
arch/arm/mach-omap2/omap_hwmod.h:453:#define HWMOD_16BIT_REG (1 << 8)
arch/arm/mach-omap2/omap_hwmod.h-454-#define HWMOD_EXT_OPT_MAIN_CLK (1 << 9)
--
arch/arm/mach-omap2/opp2xxx.h=43=struct prcm_config {
--
arch/arm/mach-omap2/opp2xxx.h-188-#define RVII_CLKSEL_L4 (1 << 5)
arch/arm/mach-omap2/opp2xxx.h:189:#define RVII_CLKSEL_DSS1 (1 << 8)
arch/arm/mach-omap2/opp2xxx.h-190-#define RVII_CLKSEL_DSS2 (0 << 13)
--
arch/arm/mach-omap2/opp2xxx.h-205-#define RVII_SYNC_DSP (0 << 7)
arch/arm/mach-omap2/opp2xxx.h:206:#define RVII_CLKSEL_IVA (1 << 8)
arch/arm/mach-omap2/opp2xxx.h-207-#define RVII_SYNC_IVA (0 << 13)
--
arch/arm/mach-omap2/opp2xxx.h-259-#define M5B_DPLL_MULT_19 (125 << 12)
arch/arm/mach-omap2/opp2xxx.h:260:#define M5B_DPLL_DIV_19 (31 << 8)
arch/arm/mach-omap2/opp2xxx.h-261-#define M5B_CM_CLKSEL1_PLL_19_VAL (MX_48M_SRC | MX_54M_SRC | \
--
arch/arm/mach-omap2/opp2xxx.h-288-#define M3_DPLL_MULT_12 (55 << 12)
arch/arm/mach-omap2/opp2xxx.h:289:#define M3_DPLL_DIV_12 (1 << 8)
arch/arm/mach-omap2/opp2xxx.h-290-#define M3_CM_CLKSEL1_PLL_12_VAL (MX_48M_SRC | MX_54M_SRC | \
--
arch/arm/mach-omap2/opp2xxx.h-307-#define M2_DPLL_MULT_12 (55 << 12)
arch/arm/mach-omap2/opp2xxx.h:308:#define M2_DPLL_DIV_12 (1 << 8)
arch/arm/mach-omap2/opp2xxx.h-309-#define M2_CM_CLKSEL1_PLL_12_VAL (MX_48M_SRC | MX_54M_SRC | \
--
arch/arm/mach-omap2/opp2xxx.h-354-#define MI_DPLL_MULT_12 (55 << 12)
arch/arm/mach-omap2/opp2xxx.h:355:#define MI_DPLL_DIV_12 (1 << 8)
arch/arm/mach-omap2/opp2xxx.h-356-#define MI_CM_CLKSEL1_PLL_12_VAL (MX_48M_SRC | MX_54M_SRC | \
--
arch/arm/mach-omap2/opp2xxx.h-364-#define MII_DPLL_MULT_12 (50 << 12)
arch/arm/mach-omap2/opp2xxx.h:365:#define MII_DPLL_DIV_12 (1 << 8)
arch/arm/mach-omap2/opp2xxx.h-366-#define MII_CM_CLKSEL1_PLL_12_VAL (MX_48M_SRC | MX_54M_SRC | \
--
arch/arm/mach-omap2/prcm-common.h-95-#define OMAP24XX_EN_GPT6_SHIFT 8
arch/arm/mach-omap2/prcm-common.h:96:#define OMAP24XX_EN_GPT6_MASK (1 << 8)
arch/arm/mach-omap2/prcm-common.h-97-#define OMAP24XX_EN_GPT5_SHIFT 7
--
arch/arm/mach-omap2/prcm-common.h-113-#define OMAP2430_EN_MMCHS2_SHIFT 8
arch/arm/mach-omap2/prcm-common.h:114:#define OMAP2430_EN_MMCHS2_MASK (1 << 8)
arch/arm/mach-omap2/prcm-common.h-115-#define OMAP2430_EN_MMCHS1_SHIFT 7
--
arch/arm/mach-omap2/prcm-common.h-157-#define OMAP24XX_ST_GPT6_SHIFT 8
arch/arm/mach-omap2/prcm-common.h:158:#define OMAP24XX_ST_GPT6_MASK (1 << 8)
arch/arm/mach-omap2/prcm-common.h-159-#define OMAP24XX_ST_GPT5_SHIFT 7
--
arch/arm/mach-omap2/prcm-common.h-177-#define OMAP2430_ST_MMCHS2_SHIFT 8
arch/arm/mach-omap2/prcm-common.h:178:#define OMAP2430_ST_MMCHS2_MASK (1 << 8)
arch/arm/mach-omap2/prcm-common.h-179-#define OMAP2430_ST_MMCHS1_SHIFT 7
--
arch/arm/mach-omap2/prcm-common.h-363-#define OMAP3430_EN_GPT8_SHIFT 9
arch/arm/mach-omap2/prcm-common.h:364:#define OMAP3430_EN_GPT7_MASK (1 << 8)
arch/arm/mach-omap2/prcm-common.h-365-#define OMAP3430_EN_GPT7_SHIFT 8
--
arch/arm/mach-omap2/prcm-common.h-406-#define OMAP3430_ST_GPT7_SHIFT 8
arch/arm/mach-omap2/prcm-common.h:407:#define OMAP3430_ST_GPT7_MASK (1 << 8)
arch/arm/mach-omap2/prcm-common.h-408-#define OMAP3430_ST_GPT6_SHIFT 7
--
arch/arm/mach-omap2/prm-regbits-24xx.h-20-#define OMAP24XX_SETOFF_LEVEL_SHIFT 12
arch/arm/mach-omap2/prm-regbits-24xx.h:21:#define OMAP24XX_MEMRETCTRL_MASK (1 << 8)
arch/arm/mach-omap2/prm-regbits-24xx.h-22-#define OMAP24XX_SETRET_LEVEL_SHIFT 6
--
arch/arm/mach-omap2/prm-regbits-34xx.h-44-#define OMAP3430_GRPSEL_GPT8_MASK (1 << 9)
arch/arm/mach-omap2/prm-regbits-34xx.h:45:#define OMAP3430_GRPSEL_GPT7_MASK (1 << 8)
arch/arm/mach-omap2/prm-regbits-34xx.h-46-#define OMAP3430_GRPSEL_GPT6_MASK (1 << 7)
--
arch/arm/mach-omap2/prm-regbits-34xx.h-63-#define OMAP3430_L1FLATMEMRETSTATE_MASK (1 << 9)
arch/arm/mach-omap2/prm-regbits-34xx.h:64:#define OMAP3430_SHAREDL1CACHEFLATRETSTATE_MASK (1 << 8)
arch/arm/mach-omap2/prm-regbits-34xx.h-65-#define OMAP3430_L2FLATMEMSTATEST_MASK (0x3 << 10)
--
arch/arm/mach-omap2/prm-regbits-34xx.h-89-#define OMAP3430_EN_IO_CHAIN_MASK (1 << 16)
arch/arm/mach-omap2/prm-regbits-34xx.h:90:#define OMAP3430_EN_IO_MASK (1 << 8)
arch/arm/mach-omap2/prm-regbits-34xx.h-91-#define OMAP3430_EN_GPIO1_MASK (1 << 3)
arch/arm/mach-omap2/prm-regbits-34xx.h-92-#define OMAP3430_ST_IO_CHAIN_MASK (1 << 16)
arch/arm/mach-omap2/prm-regbits-34xx.h:93:#define OMAP3430_ST_IO_MASK (1 << 8)
arch/arm/mach-omap2/prm-regbits-34xx.h-94-#define OMAP3430_SYS_CLKIN_SEL_SHIFT 0
--
arch/arm/mach-omap2/prm-regbits-44xx.h-47-#define OMAP4430_LOSTCONTEXT_DFF_MASK (1 << 0)
arch/arm/mach-omap2/prm-regbits-44xx.h:48:#define OMAP4430_LOSTMEM_AESSMEM_MASK (1 << 8)
arch/arm/mach-omap2/prm-regbits-44xx.h-49-#define OMAP4430_LOWPOWERSTATECHANGE_SHIFT 4
--
arch/arm/mach-omap2/prm-regbits-44xx.h-95-#define OMAP4430_VSTEPMIN_SHIFT 0
arch/arm/mach-omap2/prm-regbits-44xx.h:96:#define OMAP4430_WUCLK_CTRL_MASK (1 << 8)
arch/arm/mach-omap2/prm-regbits-44xx.h-97-#define OMAP4430_WUCLK_STATUS_SHIFT 9
--
arch/arm/mach-omap2/soc.h=233=IS_OMAP_TYPE(3430, 0x3430)
--
arch/arm/mach-omap2/soc.h-330-#define OMAP2420_REV_ES1_0 OMAP242X_CLASS
arch/arm/mach-omap2/soc.h:331:#define OMAP2420_REV_ES2_0 (OMAP242X_CLASS | (0x1 << 8))
arch/arm/mach-omap2/soc.h-332-
--
arch/arm/mach-omap2/soc.h-337-#define OMAP3430_REV_ES1_0 OMAP343X_CLASS
arch/arm/mach-omap2/soc.h:338:#define OMAP3430_REV_ES2_0 (OMAP343X_CLASS | (0x1 << 8))
arch/arm/mach-omap2/soc.h-339-#define OMAP3430_REV_ES2_1 (OMAP343X_CLASS | (0x2 << 8))
--
arch/arm/mach-omap2/soc.h-345-#define OMAP3630_REV_ES1_0 OMAP363X_CLASS
arch/arm/mach-omap2/soc.h:346:#define OMAP3630_REV_ES1_1 (OMAP363X_CLASS | (0x1 << 8))
arch/arm/mach-omap2/soc.h-347-#define OMAP3630_REV_ES1_2 (OMAP363X_CLASS | (0x2 << 8))
--
arch/arm/mach-omap2/soc.h-350-#define TI8168_REV_ES1_0 TI816X_CLASS
arch/arm/mach-omap2/soc.h:351:#define TI8168_REV_ES1_1 (TI816X_CLASS | (0x1 << 8))
arch/arm/mach-omap2/soc.h-352-#define TI8168_REV_ES2_0 (TI816X_CLASS | (0x2 << 8))
--
arch/arm/mach-omap2/soc.h-356-#define TI8148_REV_ES1_0 TI814X_CLASS
arch/arm/mach-omap2/soc.h:357:#define TI8148_REV_ES2_0 (TI814X_CLASS | (0x1 << 8))
arch/arm/mach-omap2/soc.h-358-#define TI8148_REV_ES2_1 (TI814X_CLASS | (0x2 << 8))
--
arch/arm/mach-omap2/soc.h-361-#define AM35XX_REV_ES1_0 AM35XX_CLASS
arch/arm/mach-omap2/soc.h:362:#define AM35XX_REV_ES1_1 (AM35XX_CLASS | (0x1 << 8))
arch/arm/mach-omap2/soc.h-363-
--
arch/arm/mach-omap2/soc.h-365-#define AM335X_REV_ES1_0 AM335X_CLASS
arch/arm/mach-omap2/soc.h:366:#define AM335X_REV_ES2_0 (AM335X_CLASS | (0x1 << 8))
arch/arm/mach-omap2/soc.h-367-#define AM335X_REV_ES2_1 (AM335X_CLASS | (0x2 << 8))
--
arch/arm/mach-omap2/soc.h-370-#define AM437X_REV_ES1_0 (AM437X_CLASS | (0x10 << 8))
arch/arm/mach-omap2/soc.h:371:#define AM437X_REV_ES1_1 (AM437X_CLASS | (0x11 << 8))
arch/arm/mach-omap2/soc.h-372-#define AM437X_REV_ES1_2 (AM437X_CLASS | (0x12 << 8))
--
arch/arm/mach-omap2/soc.h-376-#define OMAP4430_REV_ES2_0 (OMAP443X_CLASS | (0x20 << 8))
arch/arm/mach-omap2/soc.h:377:#define OMAP4430_REV_ES2_1 (OMAP443X_CLASS | (0x21 << 8))
arch/arm/mach-omap2/soc.h-378-#define OMAP4430_REV_ES2_2 (OMAP443X_CLASS | (0x22 << 8))
--
arch/arm/mach-omap2/soc.h-382-#define OMAP4460_REV_ES1_0 (OMAP446X_CLASS | (0x10 << 8))
arch/arm/mach-omap2/soc.h:383:#define OMAP4460_REV_ES1_1 (OMAP446X_CLASS | (0x11 << 8))
arch/arm/mach-omap2/soc.h-384-
--
arch/arm/mach-omap2/soc.h-396-#define DRA752_REV_ES1_0 (DRA7XX_CLASS | (0x52 << 16) | (0x10 << 8))
arch/arm/mach-omap2/soc.h:397:#define DRA752_REV_ES1_1 (DRA7XX_CLASS | (0x52 << 16) | (0x11 << 8))
arch/arm/mach-omap2/soc.h-398-#define DRA752_REV_ES2_0 (DRA7XX_CLASS | (0x52 << 16) | (0x20 << 8))
--
arch/arm/mach-omap2/soc.h-400-#define DRA722_REV_ES2_0 (DRA7XX_CLASS | (0x22 << 16) | (0x20 << 8))
arch/arm/mach-omap2/soc.h:401:#define DRA722_REV_ES2_1 (DRA7XX_CLASS | (0x22 << 16) | (0x21 << 8))
arch/arm/mach-omap2/soc.h-402-
--
arch/arm/mach-pxa/pxa27x-udc.h-67- Interrupt Enable */
arch/arm/mach-pxa/pxa27x-udc.h:68:#define UDCOTGICR_IEVV40F (1 << 8) /* OTG Vbus Valid 4.0V Falling Edge
arch/arm/mach-pxa/pxa27x-udc.h-69- Interrupt Enable */
--
arch/arm/mach-pxa/pxa27x-udc.h-97-#define UP2OCR_DMPUBE (1 << 7) /* Host Port 2 Transceiver D- Pull Up Bypass Enable */
arch/arm/mach-pxa/pxa27x-udc.h:98:#define UP2OCR_EXSP (1 << 8) /* External Transceiver Speed Control */
arch/arm/mach-pxa/pxa27x-udc.h-99-#define UP2OCR_EXSUS (1 << 9) /* External Transceiver Speed Enable */
--
arch/arm/mach-pxa/pxa27x-udc.h-140-#define UDCCSR_DPE (1 << 9) /* Data Packet Error */
arch/arm/mach-pxa/pxa27x-udc.h:141:#define UDCCSR_FEF (1 << 8) /* Flush Endpoint FIFO */
arch/arm/mach-pxa/pxa27x-udc.h-142-#define UDCCSR_SP (1 << 7) /* Short Packet Control/Status */
--
arch/arm/mach-pxa/pxa3xx-regs.h-92-#define ADXER_MFP_WSSP3 (1 << 9) /* MFP: SSP3 */
arch/arm/mach-pxa/pxa3xx-regs.h:93:#define ADXER_MFP_WMAXTRIX (1 << 8) /* MFP: matrix keypad */
arch/arm/mach-pxa/pxa3xx-regs.h-94-#define ADXER_MFP_WUART3 (1 << 7) /* MFP: UART3 */
--
arch/arm/mach-pxa/pxa3xx-regs.h-105- */
arch/arm/mach-pxa/pxa3xx-regs.h:106:#define ADXR_L2 (1 << 8)
arch/arm/mach-pxa/pxa3xx-regs.h-107-#define ADXR_R5 (1 << 5)
--
arch/arm/mach-rpc/include/mach/uncompress.h=112=static void arch_decomp_setup(void)
--
arch/arm/mach-rpc/include/mach/uncompress.h-150- (i & 64 ? 1 << 4 : 0) |
arch/arm/mach-rpc/include/mach/uncompress.h:151: (i & 32 ? 1 << 8 : 0) |
arch/arm/mach-rpc/include/mach/uncompress.h-152- (i & 16 ? 1 << 12 : 0) |
--
arch/arm/mach-rpc/include/mach/uncompress.h-160- (i & 8 ? 1 << 0 : 0) |
arch/arm/mach-rpc/include/mach/uncompress.h:161: (i & 4 ? 1 << 8 : 0) |
arch/arm/mach-rpc/include/mach/uncompress.h-162- (i & 2 ? 1 << 16 : 0) |
--
arch/arm/mach-s3c/mach-crag6410.c=232=static struct resource crag6410_dm9k_resource[] = {
arch/arm/mach-s3c/mach-crag6410.c-233- [0] = DEFINE_RES_MEM(S3C64XX_PA_XM0CSN5, 2),
arch/arm/mach-s3c/mach-crag6410.c:234: [1] = DEFINE_RES_MEM(S3C64XX_PA_XM0CSN5 + (1 << 8), 2),
arch/arm/mach-s3c/mach-crag6410.c-235- [2] = DEFINE_RES_NAMED(S3C_EINT(17), 1, NULL, IORESOURCE_IRQ \
--
arch/arm/mach-s3c/regs-gpio-s3c64xx.h-105-#define S3C64XX_SPCON_MEM0_D_PUD_DISABLED (0x0 << 8)
arch/arm/mach-s3c/regs-gpio-s3c64xx.h:106:#define S3C64XX_SPCON_MEM0_D_PUD_DOWN (0x1 << 8)
arch/arm/mach-s3c/regs-gpio-s3c64xx.h-107-#define S3C64XX_SPCON_MEM0_D_PUD_UP (0x2 << 8)
--
arch/arm/mach-s3c/regs-syscon-power-s3c64xx.h-24-#define S3C64XX_PWRCFG_MSM_DISABLE (1 << 9)
arch/arm/mach-s3c/regs-syscon-power-s3c64xx.h:25:#define S3C64XX_PWRCFG_KEY_DISABLE (1 << 8)
arch/arm/mach-s3c/regs-syscon-power-s3c64xx.h-26-#define S3C64XX_PWRCFG_BATF_DISABLE (1 << 7)
--
arch/arm/mach-s3c/regs-syscon-power-s3c64xx.h-61-#define S3C64XX_STOPCFG_ARM_LOGIC_ON (1 << 17)
arch/arm/mach-s3c/regs-syscon-power-s3c64xx.h:62:#define S3C64XX_STOPCFG_TOP_LOGIC_ON (1 << 8)
arch/arm/mach-s3c/regs-syscon-power-s3c64xx.h-63-#define S3C64XX_STOPCFG_OSC_EN (1 << 0)
--
arch/arm/mach-s3c/regs-syscon-power-s3c64xx.h-86-#define S3C64XX_WAKEUPSTAT_MMC0 (1 << 9)
arch/arm/mach-s3c/regs-syscon-power-s3c64xx.h:87:#define S3C64XX_WAKEUPSTAT_HSI (1 << 8)
arch/arm/mach-s3c/regs-syscon-power-s3c64xx.h-88-#define S3C64XX_WAKEUPSTAT_BATFLT (1 << 6)
--
arch/arm/mach-s5pv210/regs-clock.h-170-#define S5P_CFG_WFI_CLEAN (~(3 << 8))
arch/arm/mach-s5pv210/regs-clock.h:171:#define S5P_CFG_WFI_IDLE (1 << 8)
arch/arm/mach-s5pv210/regs-clock.h-172-#define S5P_CFG_WFI_STOP (2 << 8)
--
arch/arm/mach-tegra/sleep-tegra20.S-80- tst \rd, #(0x3 << 24)
arch/arm/mach-tegra/sleep-tegra20.S:81: moveq \rd, #(0x1 << 8) @ just 1 device
arch/arm/mach-tegra/sleep-tegra20.S-82- movne \rd, #(0x3 << 8) @ 2 devices
--
arch/arm/mach-tegra/sleep-tegra30.S-85- tst \rd, #0x1
arch/arm/mach-tegra/sleep-tegra30.S:86: moveq \rd, #(0x1 << 8) @ just 1 device
arch/arm/mach-tegra/sleep-tegra30.S-87- movne \rd, #(0x3 << 8) @ 2 devices
--
arch/arm/mach-tegra/sleep-tegra30.S=206=_no_cpu0_chk:
--
arch/arm/mach-tegra/sleep-tegra30.S-222- moveq r4, #(1 << 4) @ wfe bitmap
arch/arm/mach-tegra/sleep-tegra30.S:223: movne r4, #(1 << 8) @ wfi bitmap
arch/arm/mach-tegra/sleep-tegra30.S-224- ARM( orr r12, r12, r4, lsl r3 )
--
arch/arm/mach-versatile/integrator-cm.h=10=void cm_clear_irqs(void);
--
arch/arm/mach-versatile/integrator-cm.h-26- */
arch/arm/mach-versatile/integrator-cm.h:27:#define CM_CTRL_LCDBIASEN (1 << 8)
arch/arm/mach-versatile/integrator-cm.h-28-#define CM_CTRL_LCDBIASUP (1 << 9)
--
arch/arm/mm/abort-lv4t.S=18=ENTRY(v4t_late_abort)
--
arch/arm/mm/abort-lv4t.S-171- tst r8, #1 << 11 @ L = 1 -> write?
arch/arm/mm/abort-lv4t.S:172: orreq r1, r1, #1 << 8 @ yes
arch/arm/mm/abort-lv4t.S-173- and r7, r8, #15 << 12
--
arch/arm/mm/proc-v7-3level.S-12-#define TTB_IRGN_NC (0 << 8)
arch/arm/mm/proc-v7-3level.S:13:#define TTB_IRGN_WBWA (1 << 8)
arch/arm/mm/proc-v7-3level.S-14-#define TTB_IRGN_WT (2 << 8)
--
arch/arm/mm/proc-v7.S=434=__v7_pj4b_setup:
--
arch/arm/mm/proc-v7.S-438-#define PJ4B_STATIC_BP (1 << 2) /* Enable Static BP */
arch/arm/mm/proc-v7.S:439:#define PJ4B_INTER_PARITY (1 << 8) /* Disable Internal Parity Handling */
arch/arm/mm/proc-v7.S-440-#define PJ4B_CLEAN_LINE (1 << 16) /* Disable data transfer for clean line */
--
arch/arm/mm/proc-v7.S-453-#define PJ4B_L1_PAR_CHK (1 << 2) /* Support L1 parity checking */
arch/arm/mm/proc-v7.S:454:#define PJ4B_BROADCAST_CACHE (1 << 8) /* Broadcast Cache and TLB maintenance */
arch/arm/mm/proc-v7.S-455-
--
arch/arm/nwfpe/entry.S=133=ARM_BE8(rev r0, r0) @ little endian instruction
--
arch/arm/nwfpe/entry.S-143- ldr r5, [r10, #TI_FLAGS]
arch/arm/nwfpe/entry.S:144: rsbs r7, r8, #(1 << 8) @ CP 0 or 1 only
arch/arm/nwfpe/entry.S-145- movscs r7, r5, lsr #(TIF_USING_IWMMXT + 1)
--
arch/arm64/boot/dts/cix/sky1-pinfunc.h-10-#define CIX_PAD_GPIO001_FUNC_GPIO001 (0 << 8 | 0x0)
arch/arm64/boot/dts/cix/sky1-pinfunc.h:11:#define CIX_PAD_GPIO002_FUNC_GPIO002 (1 << 8 | 0x0)
arch/arm64/boot/dts/cix/sky1-pinfunc.h-12-#define CIX_PAD_GPIO003_FUNC_GPIO003 (2 << 8 | 0x0)
--
arch/arm64/boot/dts/cix/sky1-pinfunc.h-20-#define CIX_PAD_GPIO011_FUNC_GPIO011 (10 << 8 | 0x0)
arch/arm64/boot/dts/cix/sky1-pinfunc.h:21:#define CIX_PAD_GPIO012_FUNC_GPIO012 (11 << 8 | 0x0)
arch/arm64/boot/dts/cix/sky1-pinfunc.h-22-#define CIX_PAD_GPIO013_FUNC_GPIO013 (12 << 8 | 0x0)
--
arch/arm64/boot/dts/cix/sky1-pinfunc.h-30-#define CIX_PAD_SFI_I2C1_SCL_FUNC_SFI_SPI_CS0 (30 << 8 | 0x2)
arch/arm64/boot/dts/cix/sky1-pinfunc.h:31:#define CIX_PAD_SFI_I2C1_SDA_FUNC_SFI_I2C1_SDA (31 << 8 | 0x0)
arch/arm64/boot/dts/cix/sky1-pinfunc.h:32:#define CIX_PAD_SFI_I2C1_SDA_FUNC_SFI_I3C1_SDA (31 << 8 | 0x1)
arch/arm64/boot/dts/cix/sky1-pinfunc.h:33:#define CIX_PAD_SFI_I2C1_SDA_FUNC_SFI_SPI_CS1 (31 << 8 | 0x2)
arch/arm64/boot/dts/cix/sky1-pinfunc.h-34-#define CIX_PAD_SFI_GPIO0_FUNC_GPIO015 (32 << 8 | 0x0)
--
arch/arm64/boot/dts/cix/sky1-pinfunc.h-55-#define CIX_PAD_GPIO023_FUNC_SFI_I3C0_PUR_EN_L (40 << 8 | 0x2)
arch/arm64/boot/dts/cix/sky1-pinfunc.h:56:#define CIX_PAD_GPIO024_FUNC_SFI_GPIO9 (41 << 8 | 0x0)
arch/arm64/boot/dts/cix/sky1-pinfunc.h:57:#define CIX_PAD_GPIO024_FUNC_GPIO024 (41 << 8 | 0x1)
arch/arm64/boot/dts/cix/sky1-pinfunc.h:58:#define CIX_PAD_GPIO024_FUNC_SFI_I3C1_PUR_EN_L (41 << 8 | 0x2)
arch/arm64/boot/dts/cix/sky1-pinfunc.h-59-#define CIX_PAD_SPI1_MISO_FUNC_SPI1_MISO (42 << 8 | 0x0)
--
arch/arm64/boot/dts/cix/sky1-pinfunc.h-76-#define CIX_PAD_GPIO033_FUNC_USB_OC3_L (50 << 8 | 0x1)
arch/arm64/boot/dts/cix/sky1-pinfunc.h:77:#define CIX_PAD_GPIO034_FUNC_GPIO034 (51 << 8 | 0x0)
arch/arm64/boot/dts/cix/sky1-pinfunc.h:78:#define CIX_PAD_GPIO034_FUNC_USB_OC4_L (51 << 8 | 0x1)
arch/arm64/boot/dts/cix/sky1-pinfunc.h-79-#define CIX_PAD_GPIO035_FUNC_GPIO035 (52 << 8 | 0x0)
--
arch/arm64/boot/dts/cix/sky1-pinfunc.h-96-#define CIX_PAD_SE_QSPI_CLK_FUNC_QSPI_CLK (60 << 8 | 0x1)
arch/arm64/boot/dts/cix/sky1-pinfunc.h:97:#define CIX_PAD_SE_QSPI_CS_L_FUNC_SE_QSPI_CS_L (61 << 8 | 0x0)
arch/arm64/boot/dts/cix/sky1-pinfunc.h:98:#define CIX_PAD_SE_QSPI_CS_L_FUNC_QSPI_CS_L (61 << 8 | 0x1)
arch/arm64/boot/dts/cix/sky1-pinfunc.h-99-#define CIX_PAD_SE_QSPI_DATA0_FUNC_SE_QSPI_DATA0 (62 << 8 | 0x0)
--
arch/arm64/boot/dts/cix/sky1-pinfunc.h-108-#define CIX_PAD_GPIO043_FUNC_GPIO043 (0 << 8 | 0x0)
arch/arm64/boot/dts/cix/sky1-pinfunc.h:109:#define CIX_PAD_GPIO044_FUNC_GPIO044 (1 << 8 | 0x0)
arch/arm64/boot/dts/cix/sky1-pinfunc.h-110-#define CIX_PAD_GPIO045_FUNC_GPIO045 (2 << 8 | 0x0)
--
arch/arm64/boot/dts/cix/sky1-pinfunc.h-114-#define CIX_PAD_DP2_VARY_BL_FUNC_DP2_VARY_BL (20 << 8 | 0x0)
arch/arm64/boot/dts/cix/sky1-pinfunc.h:115:#define CIX_PAD_I2C7_SCL_FUNC_I2C7_SCL (21 << 8 | 0x0)
arch/arm64/boot/dts/cix/sky1-pinfunc.h-116-#define CIX_PAD_I2C7_SDA_FUNC_I2C7_SDA (22 << 8 | 0x0)
--
arch/arm64/boot/dts/cix/sky1-pinfunc.h-126-#define CIX_PAD_I2C0_CLK_FUNC_GPIO051 (30 << 8 | 0x1)
arch/arm64/boot/dts/cix/sky1-pinfunc.h:127:#define CIX_PAD_I2C0_SDA_FUNC_I2C0_SDA (31 << 8 | 0x0)
arch/arm64/boot/dts/cix/sky1-pinfunc.h:128:#define CIX_PAD_I2C0_SDA_FUNC_GPIO052 (31 << 8 | 0x1)
arch/arm64/boot/dts/cix/sky1-pinfunc.h-129-#define CIX_PAD_I2C1_CLK_FUNC_I2C1_CLK (32 << 8 | 0x0)
--
arch/arm64/boot/dts/cix/sky1-pinfunc.h-150-#define CIX_PAD_I2C4_CLK_FUNC_GPIO061 (40 << 8 | 0x1)
arch/arm64/boot/dts/cix/sky1-pinfunc.h:151:#define CIX_PAD_I2C4_SDA_FUNC_I2C4_SDA (41 << 8 | 0x0)
arch/arm64/boot/dts/cix/sky1-pinfunc.h:152:#define CIX_PAD_I2C4_SDA_FUNC_GPIO062 (41 << 8 | 0x1)
arch/arm64/boot/dts/cix/sky1-pinfunc.h-153-#define CIX_PAD_HDA_BITCLK_FUNC_HDA_BITCLK (42 << 8 | 0x0)
--
arch/arm64/boot/dts/cix/sky1-pinfunc.h-177-#define CIX_PAD_I2S1_SCK_FUNC_GPIO066 (50 << 8 | 0x1)
arch/arm64/boot/dts/cix/sky1-pinfunc.h:178:#define CIX_PAD_I2S1_WS_FUNC_I2S1_WS (51 << 8 | 0x0)
arch/arm64/boot/dts/cix/sky1-pinfunc.h:179:#define CIX_PAD_I2S1_WS_FUNC_GPIO067 (51 << 8 | 0x1)
arch/arm64/boot/dts/cix/sky1-pinfunc.h-180-#define CIX_PAD_I2S1_DATA_IN_FUNC_I2S1_DATA_IN (52 << 8 | 0x0)
--
arch/arm64/boot/dts/cix/sky1-pinfunc.h-209-#define CIX_PAD_I2S2_DATA_IN1_FUNC_I2S6_DATA_IN1_DBG (60 << 8 | 0x3)
arch/arm64/boot/dts/cix/sky1-pinfunc.h:210:#define CIX_PAD_I2S2_DATA_OUT0_FUNC_I2S2_DATA_OUT0 (61 << 8 | 0x0)
arch/arm64/boot/dts/cix/sky1-pinfunc.h:211:#define CIX_PAD_I2S2_DATA_OUT0_FUNC_GPIO077 (61 << 8 | 0x1)
arch/arm64/boot/dts/cix/sky1-pinfunc.h:212:#define CIX_PAD_I2S2_DATA_OUT0_FUNC_I2S5_DATA_OUT0_DBG (61 << 8 | 0x2)
arch/arm64/boot/dts/cix/sky1-pinfunc.h:213:#define CIX_PAD_I2S2_DATA_OUT0_FUNC_I2S6_DATA_OUT0_DBG (61 << 8 | 0x3)
arch/arm64/boot/dts/cix/sky1-pinfunc.h-214-#define CIX_PAD_I2S2_DATA_OUT1_FUNC_I2S2_DATA_OUT1 (62 << 8 | 0x0)
--
arch/arm64/boot/dts/cix/sky1-pinfunc.h-244-#define CIX_PAD_I2S3_DATA_IN0_FUNC_I2S8_DATA_IN0_DBG (70 << 8 | 0x3)
arch/arm64/boot/dts/cix/sky1-pinfunc.h:245:#define CIX_PAD_I2S3_DATA_IN1_FUNC_I2S3_DATA_IN1 (71 << 8 | 0x0)
arch/arm64/boot/dts/cix/sky1-pinfunc.h:246:#define CIX_PAD_I2S3_DATA_IN1_FUNC_GPIO087 (71 << 8 | 0x1)
arch/arm64/boot/dts/cix/sky1-pinfunc.h:247:#define CIX_PAD_I2S3_DATA_IN1_FUNC_I2S7_DATA_IN1_DBG (71 << 8 | 0x2)
arch/arm64/boot/dts/cix/sky1-pinfunc.h:248:#define CIX_PAD_I2S3_DATA_IN1_FUNC_I2S8_DATA_IN1_DBG (71 << 8 | 0x3)
arch/arm64/boot/dts/cix/sky1-pinfunc.h-249-#define CIX_PAD_I2S3_DATA_OUT0_FUNC_I2S3_DATA_OUT0 (72 << 8 | 0x0)
--
arch/arm64/boot/dts/cix/sky1-pinfunc.h-272-#define CIX_PAD_UART0_RXD_FUNC_GPIO096 (80 << 8 | 0x2)
arch/arm64/boot/dts/cix/sky1-pinfunc.h:273:#define CIX_PAD_UART0_CTS_FUNC_UART0_CTS (81 << 8 | 0x0)
arch/arm64/boot/dts/cix/sky1-pinfunc.h:274:#define CIX_PAD_UART0_CTS_FUNC_FAN_OUT2 (81 << 8 | 0x1)
arch/arm64/boot/dts/cix/sky1-pinfunc.h:275:#define CIX_PAD_UART0_CTS_FUNC_GPIO097 (81 << 8 | 0x2)
arch/arm64/boot/dts/cix/sky1-pinfunc.h-276-#define CIX_PAD_UART0_RTS_FUNC_UART0_RTS (82 << 8 | 0x0)
--
arch/arm64/boot/dts/cix/sky1-pinfunc.h-298-#define CIX_PAD_UART3_RXD_FUNC_GPIO106 (90 << 8 | 0x1)
arch/arm64/boot/dts/cix/sky1-pinfunc.h:299:#define CIX_PAD_UART3_CTS_FUNC_UART3_CTS (91 << 8 | 0x0)
arch/arm64/boot/dts/cix/sky1-pinfunc.h:300:#define CIX_PAD_UART3_CTS_FUNC_GPIO107 (91 << 8 | 0x1)
arch/arm64/boot/dts/cix/sky1-pinfunc.h:301:#define CIX_PAD_UART3_CTS_FUNC_TRIGIN0 (91 << 8 | 0x2)
arch/arm64/boot/dts/cix/sky1-pinfunc.h-302-#define CIX_PAD_UART3_RTS_FUNC_UART3_RTS (92 << 8 | 0x0)
--
arch/arm64/boot/dts/cix/sky1-pinfunc.h-320-#define CIX_PAD_CLK_REQ4_L_FUNC_GPIO116 (100 << 8 | 0x1)
arch/arm64/boot/dts/cix/sky1-pinfunc.h:321:#define CIX_PAD_CSI0_MCLK0_FUNC_CSI0_MCLK0 (101 << 8 | 0x0)
arch/arm64/boot/dts/cix/sky1-pinfunc.h:322:#define CIX_PAD_CSI0_MCLK0_FUNC_GPIO117 (101 << 8 | 0x1)
arch/arm64/boot/dts/cix/sky1-pinfunc.h-323-#define CIX_PAD_CSI0_MCLK1_FUNC_CSI0_MCLK1 (102 << 8 | 0x0)
--
arch/arm64/boot/dts/cix/sky1-pinfunc.h-340-#define CIX_PAD_GPIO126_FUNC_GMAC0_TXD3 (110 << 8 | 0x1)
arch/arm64/boot/dts/cix/sky1-pinfunc.h:341:#define CIX_PAD_GPIO127_FUNC_GPIO127 (111 << 8 | 0x0)
arch/arm64/boot/dts/cix/sky1-pinfunc.h:342:#define CIX_PAD_GPIO127_FUNC_GMAC0_TX_CLK (111 << 8 | 0x1)
arch/arm64/boot/dts/cix/sky1-pinfunc.h-343-#define CIX_PAD_GPIO128_FUNC_GPIO128 (112 << 8 | 0x0)
--
arch/arm64/boot/dts/cix/sky1-pinfunc.h-360-#define CIX_PAD_GPIO136_FUNC_GMAC1_REFCLK_25M (120 << 8 | 0x1)
arch/arm64/boot/dts/cix/sky1-pinfunc.h:361:#define CIX_PAD_GPIO137_FUNC_GPIO137 (121 << 8 | 0x0)
arch/arm64/boot/dts/cix/sky1-pinfunc.h:362:#define CIX_PAD_GPIO137_FUNC_GMAC1_TX_CTL (121 << 8 | 0x1)
arch/arm64/boot/dts/cix/sky1-pinfunc.h-363-#define CIX_PAD_GPIO138_FUNC_GPIO138 (122 << 8 | 0x0)
--
arch/arm64/boot/dts/cix/sky1-pinfunc.h-385-#define CIX_PAD_GPIO146_FUNC_GMAC1_RXD2 (130 << 8 | 0x1)
arch/arm64/boot/dts/cix/sky1-pinfunc.h:386:#define CIX_PAD_GPIO147_FUNC_GPIO147 (131 << 8 | 0x0)
arch/arm64/boot/dts/cix/sky1-pinfunc.h:387:#define CIX_PAD_GPIO147_FUNC_GMAC1_RXD3 (131 << 8 | 0x1)
arch/arm64/boot/dts/cix/sky1-pinfunc.h-388-#define CIX_PAD_GPIO148_FUNC_GPIO148 (132 << 8 | 0x0)
--
arch/arm64/include/asm/hwcap.h-18-#define COMPAT_HWCAP_EDSP (1 << 7)
arch/arm64/include/asm/hwcap.h:19:#define COMPAT_HWCAP_JAVA (1 << 8)
arch/arm64/include/asm/hwcap.h-20-#define COMPAT_HWCAP_IWMMXT (1 << 9)
--
arch/arm64/include/asm/kvm_arm.h-276-#define CPTR_EL2_TFP (1 << CPTR_EL2_TFP_SHIFT)
arch/arm64/include/asm/kvm_arm.h:277:#define CPTR_EL2_TZ (1 << 8)
arch/arm64/include/asm/kvm_arm.h-278-#define CPTR_NVHE_EL2_RES1 (BIT(13) | BIT(9) | GENMASK(7, 0))
--
arch/arm64/include/uapi/asm/hwcap.h-33-#define HWCAP_CRC32 (1 << 7)
arch/arm64/include/uapi/asm/hwcap.h:34:#define HWCAP_ATOMICS (1 << 8)
arch/arm64/include/uapi/asm/hwcap.h-35-#define HWCAP_FPHP (1 << 9)
--
]
]
|
| 38/2 |
2026/05/20 02:01 |
llm |
expert |
0m
Model:
Tokens:
input: 48709
output: 20
thoughts: 158
Thoughts: **Analyzing a Potential Data Structure Overlap**
Okay, hold on a second. I'm looking at this memory address transformation: `0x08300080` to `0x00300180`. The difference is precisely `0x08000100`. Now, that sticks out to me. I know bit 27 is `DCACHE_PERSISTENT`, that's usually important for how the cache behaves. But what about bit 8? It's the other bit that changed, which doesn't seem right,
Right, let me double-check the definition. I need to refresh my memory on what `BIT(8)` or `1 << 8` translates to within the dentry structure. Let's see...I'll quickly reference `include/linux/dcache.h`.
Wait a minute, this is concerning. I see `dentry->d_lockref.count--` being called *right after* `dentry->d_flags &= ~DCACHE_PERSISTENT;`. That's making me wonder...is there a potential overlap between `d_lockref` and `d_flags` within the `dentry` struct? That wouldn't be good. I need to verify the struct layout of the dentry structure again to make sure my assumptions are valid. I need to make sure this code is safe.
|
| 39/2 |
2026/05/20 02:01 |
tool |
codesearch-struct-layout |
0m
Args:
Results: map[Fields:[map[Name:d_flags OffsetBits:0 SizeBits:32] map[Name:d_seq OffsetBits:32 SizeBits:32] map[Name:d_hash OffsetBits:64 SizeBits:128] map[Name:d_parent OffsetBits:192 SizeBits:64] map[Name: OffsetBits:256 SizeBits:128] map[Name:d_inode OffsetBits:384 SizeBits:64] map[Name:d_shortname OffsetBits:448 SizeBits:320] map[Name:d_op OffsetBits:768 SizeBits:64] map[Name:d_sb OffsetBits:832 SizeBits:64] map[Name:d_time OffsetBits:896 SizeBits:64] map[Name:d_fsdata OffsetBits:960 SizeBits:64] map[Name:d_lockref OffsetBits:1024 SizeBits:64] map[Name: OffsetBits:1088 SizeBits:128] map[Name:d_sib OffsetBits:1216 SizeBits:128] map[Name:d_children OffsetBits:1344 SizeBits:64] map[Name: OffsetBits:1408 SizeBits:128]]]
|
| 40/2 |
2026/05/20 02:01 |
llm |
expert |
0m
Model:
Tokens:
input: 49540
output: 22
thoughts: 437
Thoughts: **Decoding the d_flags Field**
Okay, so `d_flags` is at offset 0, that's straightforward. But hold on, what's going on at offset `0xffff88811b001300`? The report indicates that task 20596 is writing 4 bytes to that address, and task 2984 is reading from it. The kernel is pointing to this as a `d_make_discardable` write and a `__d_entry_type` read. It looks like the same location is being accessed, so that has to be `d_flags`.
The value changed from `0x08300080` to `0x00300180`. Let's break this down. In the first value, `0x08300080`, bit 27 is set, as is bit 8, and bit 7. The second value, `0x00300180`, now has bits 8 and 7, but bit 27 is cleared. `0x00300000` translates to `3 << 20` , and `DCACHE_ENTRY_TYPE` is `7 << 19` so that `0x00300000` is actually `6 << 19`. I need to review what flags correspond to these bits. I'll need to check `DCACHE_SYMLINK_TYPE` as well.
|
| 41/2 |
2026/05/20 02:01 |
tool |
grepper |
0m
Args: map[Expression:DCACHE_SYMLINK_TYPE]
Results: map[Output:fs/dcache.c=2003=static unsigned d_flags_for_inode(struct inode *inode)
--
fs/dcache.c-2022- if (unlikely(inode->i_op->get_link)) {
fs/dcache.c:2023: add_flags = DCACHE_SYMLINK_TYPE;
fs/dcache.c-2024- goto type_determined;
--
include/linux/dcache.h=192=enum dentry_flags {
--
include/linux/dcache.h-232- DCACHE_SPECIAL_TYPE = (5 << 19), /* Other file type */
include/linux/dcache.h:233: DCACHE_SYMLINK_TYPE = (6 << 19), /* Symlink */
include/linux/dcache.h-234- DCACHE_NOKEY_NAME = BIT(22), /* Encrypted name encoded without key */
--
include/linux/dcache.h=457=static inline bool d_is_symlink(const struct dentry *dentry)
include/linux/dcache.h-458-{
include/linux/dcache.h:459: return __d_entry_type(dentry) == DCACHE_SYMLINK_TYPE;
include/linux/dcache.h-460-}
]
|
| 42/2 |
2026/05/20 02:01 |
llm |
expert |
0m
Model:
Tokens:
input: 50685
output: 21
thoughts: 55
Thoughts: Okay, here's my interpretation of that thought process, assuming I'm deep in the weeds of kernel-level file system implementation:
**Decoding the Dentry Type**
Right, so I've confirmed that `DCACHE_SYMLINK_TYPE` is equal to `6 << 19`, which neatly translates to `0x00300000` in hexadecimal. That directly tells me the dentry I'm looking at *is* indeed a symbolic link. Now, the next logical question β and the one I'm immediately focused on β is understanding the significance of bits 7 and 8 within this context. Those two bits are critical to understanding the dentry and how it is represented. I need to know what additional information they provide about the nature or the attributes of this symlink. I'm going to need to figure out what they mean.
|
| 43/2 |
2026/05/20 02:01 |
tool |
grepper |
0m
Error:
Args: map[Expression:BIT\(7\).*DCACHE]
Results:
|
| 44/2 |
2026/05/20 02:01 |
llm |
expert |
0m
Model:
Tokens:
input: 50961
output: 41
thoughts: 22
Thoughts: Here's my take on those thoughts:
**Analyzing dentry_flags in linux/dcache.h**
Okay, let's dive right in. My immediate thought is to check out the definition of `enum dentry_flags` within the `include/linux/dcache.h` header file. I know the dentry flags are critical for understanding how the dentry cache functions, and therefore, how the VFS and filesystems interact. I need a clear view of the available flags to understand any behaviors I'm observing, debugging, or optimizing related to the dentry cache. I'm hoping I'll find a concise definition there that jogs my memory, or presents a clue to an area I might've overlooked. I need to refresh the flag's meanings and how they are used, for my current task.
|
| 45/2 |
2026/05/20 02:01 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:include/linux/dcache.h IncludeLines:true Name:dentry_flags]
Results: map[SourceCode: 191: /* d_flags entries */
192: enum dentry_flags {
193: DCACHE_OP_HASH = BIT(0),
194: DCACHE_OP_COMPARE = BIT(1),
195: DCACHE_OP_REVALIDATE = BIT(2),
196: DCACHE_OP_DELETE = BIT(3),
197: DCACHE_OP_PRUNE = BIT(4),
198: /*
199: * This dentry is possibly not currently connected to the dcache tree,
200: * in which case its parent will either be itself, or will have this
201: * flag as well. nfsd will not use a dentry with this bit set, but will
202: * first endeavour to clear the bit either by discovering that it is
203: * connected, or by performing lookup operations. Any filesystem which
204: * supports nfsd_operations MUST have a lookup function which, if it
205: * finds a directory inode with a DCACHE_DISCONNECTED dentry, will
206: * d_move that dentry into place and return that dentry rather than the
207: * passed one, typically using d_splice_alias.
208: */
209: DCACHE_DISCONNECTED = BIT(5),
210: DCACHE_REFERENCED = BIT(6), /* Recently used, don't discard. */
211: DCACHE_DONTCACHE = BIT(7), /* Purge from memory on final dput() */
212: DCACHE_CANT_MOUNT = BIT(8),
213: DCACHE_SHRINK_LIST = BIT(10),
214: DCACHE_OP_WEAK_REVALIDATE = BIT(11),
215: /*
216: * this dentry has been "silly renamed" and has to be deleted on the
217: * last dput()
218: */
219: DCACHE_NFSFS_RENAMED = BIT(12),
220: DCACHE_FSNOTIFY_PARENT_WATCHED = BIT(13), /* Parent inode is watched by some fsnotify listener */
221: DCACHE_DENTRY_KILLED = BIT(14),
222: DCACHE_MOUNTED = BIT(15), /* is a mountpoint */
223: DCACHE_NEED_AUTOMOUNT = BIT(16), /* handle automount on this dir */
224: DCACHE_MANAGE_TRANSIT = BIT(17), /* manage transit from this dirent */
225: DCACHE_LRU_LIST = BIT(18),
226: DCACHE_ENTRY_TYPE = (7 << 19), /* bits 19..21 are for storing type: */
227: DCACHE_MISS_TYPE = (0 << 19), /* Negative dentry */
228: DCACHE_WHITEOUT_TYPE = (1 << 19), /* Whiteout dentry (stop pathwalk) */
229: DCACHE_DIRECTORY_TYPE = (2 << 19), /* Normal directory */
230: DCACHE_AUTODIR_TYPE = (3 << 19), /* Lookupless directory (presumed automount) */
231: DCACHE_REGULAR_TYPE = (4 << 19), /* Regular file type */
232: DCACHE_SPECIAL_TYPE = (5 << 19), /* Other file type */
233: DCACHE_SYMLINK_TYPE = (6 << 19), /* Symlink */
234: DCACHE_NOKEY_NAME = BIT(22), /* Encrypted name encoded without key */
235: DCACHE_OP_REAL = BIT(23),
236: DCACHE_PAR_LOOKUP = BIT(24), /* being looked up (with parent locked shared) */
237: DCACHE_DENTRY_CURSOR = BIT(25),
238: DCACHE_NORCU = BIT(26), /* No RCU delay for freeing */
239: DCACHE_PERSISTENT = BIT(27)
240: };
SourceFile:include/linux/dcache.h]
|
| 46/2 |
2026/05/20 02:01 |
llm |
expert |
0m
Model:
Tokens:
input: 52375
output: 26
thoughts: 352
Thoughts: **Analyzing a Dentry Flag Change**
Okay, so I'm looking at this dentry flag change from `0x08300080` to `0x00300180`. Let's break it down. Right, `DCACHE_DONTCACHE` is `BIT(7)` and `DCACHE_CANT_MOUNT` is `BIT(8)`. The change indicates that `DCACHE_PERSISTENT` was cleared and `DCACHE_CANT_MOUNT` got set. The `d_make_discardable` function only clears `DCACHE_PERSISTENT` though, using a bitwise AND.
That doesn't make sense; why would `DCACHE_CANT_MOUNT` be set? Let's re-examine the KCSAN report. Wait, the report format is "value changed: old -> new". So, KCSAN is showing the value *before* and *after* a change. That means the value moved from `0x08300080` to `0x00300180` somewhere between the two accesses, or during an observation period. `d_make_discardable` is definitely clearing `DCACHE_PERSISTENT`, but there has to be another write that's setting `DCACHE_CANT_MOUNT`. Time to track down where that flag is being set.
|
| 47/2 |
2026/05/20 02:01 |
tool |
codesearch-find-references |
0m
Error:
Args: map[Name:DCACHE_CANT_MOUNT]
Results: map[References:<nil> TruncatedOutput:false]
|
| 48/2 |
2026/05/20 02:01 |
llm |
expert |
0m
Model:
Tokens:
input: 53081
output: 22
thoughts: 15
Thoughts: Okay, here's my interpretation of that thought process, tailored for an expert audience, and written in the first person:
**Initial Diagnostic Query**
Right, time to get to the root of this. My first instinct is to zero in on a specific error signature. Let's start with a targeted search. I'm going to leverage my existing knowledge of kernel debugging and system internals to quickly isolate the problem area. Let's see... I'm thinking, I'll `grep` for `DCACHE_CANT_MOUNT`. This string, or something close to it, typically indicates a problem with the dentry cache or, more broadly, the file system mounting process. It could point to a variety of issues β resource exhaustion, conflicting mounts, permissions problems, or even a deeper, more fundamental filesystem corruption. The goal here is efficient triage; I expect this to immediately turn up the relevant code paths and, with luck, provide some clues in the surrounding context. If that search hits nothing, I'll need to broaden the scope with similar key words.
|
| 49/2 |
2026/05/20 02:02 |
tool |
grepper |
0m
Args: map[Expression:DCACHE_CANT_MOUNT]
Results: map[Output:fs/dcache.c=2584=void d_delete(struct dentry * dentry)
--
fs/dcache.c-2595- __d_drop(dentry);
fs/dcache.c:2596: dentry->d_flags &= ~DCACHE_CANT_MOUNT;
fs/dcache.c-2597- dentry_unlink_inode(dentry);
--
include/linux/dcache.h=192=enum dentry_flags {
--
include/linux/dcache.h-211- DCACHE_DONTCACHE = BIT(7), /* Purge from memory on final dput() */
include/linux/dcache.h:212: DCACHE_CANT_MOUNT = BIT(8),
include/linux/dcache.h-213- DCACHE_SHRINK_LIST = BIT(10),
--
include/linux/dcache.h=387=static inline int cant_mount(const struct dentry *dentry)
include/linux/dcache.h-388-{
include/linux/dcache.h:389: return (dentry->d_flags & DCACHE_CANT_MOUNT);
include/linux/dcache.h-390-}
--
include/linux/dcache.h=392=static inline void dont_mount(struct dentry *dentry)
--
include/linux/dcache.h-394- spin_lock(&dentry->d_lock);
include/linux/dcache.h:395: dentry->d_flags |= DCACHE_CANT_MOUNT;
include/linux/dcache.h-396- spin_unlock(&dentry->d_lock);
]
|
| 50/2 |
2026/05/20 02:02 |
llm |
expert |
0m
Model:
Tokens:
input: 53784
output: 21
thoughts: 32
Thoughts: Okay, here's my take on those thoughts, framed as my own:
**Investigating the `dont_mount` Flag**
Right, so `dont_mount` is setting the `DCACHE_CANT_MOUNT` flag. My immediate thought is, "Okay, that's straightforward, but what triggers this?" I need to understand the contexts in which `dont_mount` gets called. This flag is crucial because it directly impacts the ability of the dcache to handle mount operations. Understanding its usage is key to understanding potential filesystem behavior or debugging mount-related issues. Time to trace the call paths to get the bigger picture.
|
| 51/2 |
2026/05/20 02:02 |
tool |
codesearch-find-references |
0m
Args:
Results: map[References:[map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:configfs_attach_group SourceFile:fs/configfs/dir.c SourceLine:908] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:configfs_attach_item SourceFile:fs/configfs/dir.c SourceLine:864] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:configfs_unregister_group SourceFile:fs/configfs/dir.c SourceLine:1818] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:configfs_unregister_subsystem SourceFile:fs/configfs/dir.c SourceLine:1967] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:detach_groups SourceFile:fs/configfs/dir.c SourceLine:672] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:proc_splice_unmountable SourceFile:fs/proc/internal.h SourceLine:432] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:vfs_rename SourceFile:fs/namei.c SourceLine:6064] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:vfs_rmdir SourceFile:fs/namei.c SourceLine:5372] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:vfs_unlink SourceFile:fs/namei.c SourceLine:5500]] TruncatedOutput:false]
|
| 52/2 |
2026/05/20 02:02 |
llm |
expert |
0m
Model:
Tokens:
input: 54442
output: 39
thoughts: 23
Thoughts: Here's my summary, as though I'm thinking through this process:
**Unpacking the `vfs_unlink` Mystery**
Okay, so `vfs_unlink` calls `dont_mount`. That's the starting point. I need to understand *why* this call is happening and what the relationship is. It's a bit of a curious jump, usually `unlink` deals with removing files, and "dont_mount" suggests...well, not mounting something. So I better delve into the `vfs_unlink` function itself. Let's dig in and see what's actually going on in there. I'll need to trace the execution path and identify how `dont_mount` comes into play within the `unlink` operation. What's it doing? Is this related to unmounting something or preventing mounting after removal? This requires some deep code diving. Time to start reading that source.
|
| 53/2 |
2026/05/20 02:02 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:fs/namei.c IncludeLines:true Name:vfs_unlink]
Results: map[SourceCode:5447: /**
5448: * vfs_unlink - unlink a filesystem object
5449: * @idmap: idmap of the mount the inode was found from
5450: * @dir: parent directory
5451: * @dentry: victim
5452: * @delegated_inode: returns victim inode, if the inode is delegated.
5453: *
5454: * The caller must hold dir->i_rwsem exclusively.
5455: *
5456: * If vfs_unlink discovers a delegation, it will return -EWOULDBLOCK and
5457: * return a reference to the inode in delegated_inode. The caller
5458: * should then break the delegation on that inode and retry. Because
5459: * breaking a delegation may take a long time, the caller should drop
5460: * dir->i_rwsem before doing so.
5461: *
5462: * Alternatively, a caller may pass NULL for delegated_inode. This may
5463: * be appropriate for callers that expect the underlying filesystem not
5464: * to be NFS exported.
5465: *
5466: * If the inode has been found through an idmapped mount the idmap of
5467: * the vfsmount must be passed through @idmap. This function will then take
5468: * care to map the inode according to @idmap before checking permissions.
5469: * On non-idmapped mounts or if permission checking is to be performed on the
5470: * raw inode simply pass @nop_mnt_idmap.
5471: */
5472: int vfs_unlink(struct mnt_idmap *idmap, struct inode *dir,
5473: struct dentry *dentry, struct delegated_inode *delegated_inode)
5474: {
5475: struct inode *target = dentry->d_inode;
5476: int error = may_delete_dentry(idmap, dir, dentry, false);
5477:
5478: if (error)
5479: return error;
5480:
5481: if (!dir->i_op->unlink)
5482: return -EPERM;
5483:
5484: inode_lock(target);
5485: if (IS_SWAPFILE(target))
5486: error = -EPERM;
5487: else if (is_local_mountpoint(dentry))
5488: error = -EBUSY;
5489: else {
5490: error = security_inode_unlink(dir, dentry);
5491: if (!error) {
5492: error = try_break_deleg(dir, delegated_inode);
5493: if (error)
5494: goto out;
5495: error = try_break_deleg(target, delegated_inode);
5496: if (error)
5497: goto out;
5498: error = dir->i_op->unlink(dir, dentry);
5499: if (!error) {
5500: dont_mount(dentry);
5501: detach_mounts(dentry);
5502: }
5503: }
5504: }
5505: out:
5506: inode_unlock(target);
5507:
5508: /* We don't d_delete() NFS sillyrenamed files--they still exist. */
5509: if (!error && dentry->d_flags & DCACHE_NFSFS_RENAMED) {
5510: fsnotify_unlink(dir, dentry);
5511: } else if (!error) {
5512: fsnotify_link_count(target);
5513: d_delete_notify(dir, dentry);
5514: }
5515:
5516: return error;
5517: }
SourceFile:fs/namei.c]
|
| 54/2 |
2026/05/20 02:02 |
llm |
expert |
0m
Model:
Tokens:
input: 55817
output: 66
thoughts: 1750
Thoughts: **Benign Data Race in VFS Unlink and Readlink**
Okay, let's break this down. From the KCSAN report, it looks like `vfs_unlink` calls `dir->i_op->unlink`, which in this specific case, translates to `shmem_unlink` via `shmem_unlink -> simple_unlink -> d_make_discardable`. `d_make_discardable` is where the action happens. It clears `DCACHE_PERSISTENT`. Meanwhile, `vfs_unlink` also calls `dont_mount(dentry)`, setting `DCACHE_CANT_MOUNT`.
The critical observation is that both the clearing of `DCACHE_PERSISTENT` in `d_make_discardable` and the setting of `DCACHE_CANT_MOUNT` in `dont_mount` are protected by `spin_lock(&dentry->d_lock)`. However, the code in `do_readlinkat` accesses `d_flags` without holding `d_lock`. This is where the data race arises.
The report indicates a change in `d_flags` from `0x08300080` to `0x00300180`. `DCACHE_PERSISTENT` (`0x08000000`) is being cleared, and `DCACHE_CANT_MOUNT` (`0x00000100`) is being set. However, and this is key, `__d_entry_type` only masks with `DCACHE_ENTRY_TYPE` (`0x00380000`). Regardless of the timing of the read in `do_readlinkat`, whether before, during, or after the modifications to `d_flags`, the `DCACHE_ENTRY_TYPE` bits (`0x00300000`) remain unchanged.
Let's double check... Could the compiler optimize `d_is_symlink` in a way that it reads `d_flags` multiple times, and yield different values? No. Because the `DCACHE_ENTRY_TYPE` bits are invariant. Thus, `d_is_symlink` will consistently return `true`, regardless of the race.
Let's consider possible repercussions. The KCSAN report specifically flags `d_is_symlink` in `do_readlinkat`, which confirms this is a classic benign data race.
Now, let's assess exploitability and other dimensions.
* **Exploitable:** No. This is a benign data race.
* **Denial of Service:** No. Again, benign. KCSAN flags a data race, but there's no visible impact on functionality.
* **Accessible From Unprivileged Processes:** Yes, `unlink` and `readlink` are system calls available to non-root processes.
* **Accessible From User Namespaces:** Yes, these syscalls are accessible.
* **VM Guest Trigger:** N/A, not VM-specific.
* **VM Host Trigger:** N/A
* **Network Trigger:** N/A
* **Remote Trigger:** N/A
* **Peripheral Trigger:** N/A
* **Malicious Filesystem Trigger:** N/A
Therefore: Exploitable = false, DenialOfService = false, Unprivileged = true, UserNamespace = true. The rest are false.
|
| 55/2 |
2026/05/20 02:02 |
tool |
set-results |
0m
Args: map[DenialOfService:false Exploitable:false FilesystemTrigger:false NetworkTrigger:false PeripheralTrigger:false RemoteTrigger:false Unprivileged:true UserNamespace:true VMGuestTrigger:false VMHostTrigger:false]
Results: map[DenialOfService:false Exploitable:false FilesystemTrigger:false NetworkTrigger:false PeripheralTrigger:false RemoteTrigger:false Unprivileged:true UserNamespace:true VMGuestTrigger:false VMHostTrigger:false]
|
| 56/2 |
2026/05/20 02:02 |
llm |
expert |
0m
Model:
Tokens:
input: 58438
output: 571
thoughts: 121
Thoughts: **Finalizing the Analysis**
Okay, the analysis is complete, and the results are definitive. Time to craft the final response. I need to clearly articulate why this apparent data race is, in fact, benign. My explanation will hinge on a few key points, specifically addressing why this isn't a security concern.
Essentially, the writerβthat's me, in this contextβis only modifying `DCACHE_PERSISTENT` initially (and `DCACHE_CANT_MOUNT` later), while the reader is solely interested in `DCACHE_ENTRY_TYPE`. Hereβs the key: these are distinct bitfields within the same 32-bit integer. Given that we're dealing with 32-bit aligned accesses, and that these architectures are, thankfully, known to guarantee atomicity for such operations, the reader is guaranteed to retrieve the correct `DCACHE_ENTRY_TYPE` value, regardless of any potential race condition. Therefore, there's absolutely no possibility of a security vulnerability manifesting due to this. The reader will *always* see a valid value, no matter what.
|
| 57/1 |
2026/05/20 02:02 |
action |
format-explanation |
0m
Results: map[Explanation:The reported bug is a data race between a write to `dentry->d_flags` in
`d_make_discardable()` and a read of `dentry->d_flags` in `do_readlinkat()` (via
`d_is_symlink()` -> `__d_entry_type()`).
**Analysis:**
1. **The Write:** In `d_make_discardable()`, the code clears the
`DCACHE_PERSISTENT` bit (bit 27) of `dentry->d_flags` using a read-modify-write
operation (`dentry->d_flags &= ~DCACHE_PERSISTENT;`). This is done while holding
the `dentry->d_lock` spinlock. Later in the same `vfs_unlink` path,
`dont_mount()` sets the `DCACHE_CANT_MOUNT` bit (bit 8), also under `d_lock`.
2. **The Read:** In `do_readlinkat()`, the code checks if the dentry is a
symlink by reading `dentry->d_flags` and masking it with `DCACHE_ENTRY_TYPE`
(bits 19..21). This read is performed without holding the `d_lock`.
3. **The Race:** Because the read is performed without a lock, KCSAN detects a
data race. The KCSAN report shows the value of `d_flags` changing from
`0x08300080` (where bit 27 is set) to `0x00300180` (where bit 27 is cleared and
bit 8 is set).
4. **Impact:** The `DCACHE_ENTRY_TYPE` bits (`0x00380000`) are `0x00300000` in
both the old and new values. Since the writer only modifies bits 27 and 8, and
the reader only cares about bits 19..21, the reader will always observe the
correct `DCACHE_ENTRY_TYPE` regardless of whether it reads the old or new value.
On all architectures supported by Linux, 32-bit aligned memory accesses are
atomic, meaning there is no risk of a "torn read" that could produce a corrupted
value for the type bits.
**Conclusion:**
This is a completely benign data race. It does not lead to any memory
corruption, logic errors, or crashes. It is not exploitable and cannot cause a
denial of service. While the code paths (`unlink` and `readlink`) are easily
reachable by unprivileged users, the race itself has no security impact.]
|