syzbot

unknown

map[Benign:true Confident:true Explanation:The data race occurs between `evdev_pass_values()` (which updates `client->packet_head` when a new input event packet is completed) and `evdev_poll()` (which checks `client->packet_head` to determine if data is available for reading).

In `evdev_pass_values()`, the update to `client->packet_head` is performed within the `__pass_event()` function, which is called while holding `client->buffer_lock`. However, `evdev_poll()` reads `client->packet_head` without acquiring this lock. This is an intentional design choice common in many Linux kernel `poll` implementations to avoid the overhead of locking during a poll operation.

The data race is benign for several reasons:
1.  **Correctness of Notification**: Even if `evdev_poll()` reads a stale value of `packet_head` and incorrectly concludes that no data is available (returning a mask without `EPOLLIN`), the producer (`evdev_pass_values()`) calls `wake_up_interruptible_poll()` immediately after releasing the lock. This ensures that the polling task is woken up and will re-evaluate the condition, seeing the updated value.
2.  **Safety of Consumption**: The actual consumption of events happens in `evdev_read()`, which calls `evdev_fetch_next_event()`. This function correctly acquires `client->buffer_lock` before checking `packet_head` and `tail`, ensuring that it always operates on a consistent and synchronized state of the event buffer.
3.  **Primitive Type**: The field `packet_head` is a simple `unsigned int`. On the x86 architecture where this was reported, 4-byte aligned loads and stores are atomic, so there is no risk of reading a "torn" or garbage value. Even if a torn value were read on another architecture, the worst-case scenario would be an incorrect poll result, which is transient and corrected by the subsequent mandatory wakeup.
4.  **No Memory Corruption/Crash**: The racy read is only used to set a bit in the poll mask. It is not used as a pointer or an array index in the racy context, so it cannot lead to memory corruption or a kernel crash.

Conclusion: The data race is a known, intentional, and functionally safe pattern in the input subsystem's evdev driver. While KCSAN correctly identifies it as a race (as it is not marked with `READ_ONCE`/`WRITE_ONCE`), it does not pose a threat to system stability or correctness.]

unknown

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

unknown

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

unknown

map[Index:codesearch-index]

unknown

map[Benign:true Confident:true]

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

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

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

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

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


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

The data race report is:

==================================================================
BUG: KCSAN: data-race in evdev_pass_values / evdev_poll

write to 0xffff88810456a808 of 4 bytes by task 19900 on cpu 1:
 __pass_event drivers/input/evdev.c:239 [inline]
 evdev_pass_values+0x3d4/0x510 drivers/input/evdev.c:278
 evdev_events+0x8e/0xd0 drivers/input/evdev.c:306
 input_pass_values+0x123/0x390 drivers/input/input.c:128
 input_event_dispose+0x248/0x320 drivers/input/input.c:342
 input_handle_event+0x9e8/0xa20 drivers/input/input.c:370
 input_inject_event+0xbc/0x120 drivers/input/input.c:424
 evdev_write+0x1fa/0x290 drivers/input/evdev.c:528
 vfs_write+0x269/0x960 fs/read_write.c:684
 ksys_write+0xda/0x1a0 fs/read_write.c:738
 __do_sys_write fs/read_write.c:749 [inline]
 __se_sys_write fs/read_write.c:746 [inline]
 __x64_sys_write+0x40/0x50 fs/read_write.c:746
 x64_sys_call+0x2847/0x3000 arch/x86/include/generated/asm/syscalls_64.h:2
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0xca/0x2b0 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

read to 0xffff88810456a808 of 4 bytes by task 2993 on cpu 0:
 evdev_poll+0xc4/0x100 drivers/input/evdev.c:621
 vfs_poll include/linux/poll.h:82 [inline]
 select_poll_one fs/select.c:480 [inline]
 do_select+0x8f1/0xf40 fs/select.c:536
 core_sys_select+0x3dc/0x6e0 fs/select.c:677
 do_pselect fs/select.c:759 [inline]
 __do_sys_pselect6 fs/select.c:798 [inline]
 __se_sys_pselect6+0x213/0x280 fs/select.c:789
 __x64_sys_pselect6+0x78/0x90 fs/select.c:789
 x64_sys_call+0x2e98/0x3000 arch/x86/include/generated/asm/syscalls_64.h:271
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0xca/0x2b0 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

value changed: 0x00000022 -> 0x00000024

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

The data race occurs between `evdev_pass_values()` (which updates `client->packet_head` when a new input event packet is completed) and `evdev_poll()` (which checks `client->packet_head` to determine if data is available for reading).

In `evdev_pass_values()`, the update to `client->packet_head` is performed within the `__pass_event()` function, which is called while holding `client->buffer_lock`. However, `evdev_poll()` reads `client->packet_head` without acquiring this lock. This is an intentional design choice common in many Linux kernel `poll` implementations to avoid the overhead of locking during a poll operation.

The data race is benign for several reasons:
1.  **Correctness of Notification**: Even if `evdev_poll()` reads a stale value of `packet_head` and incorrectly concludes that no data is available (returning a mask without `EPOLLIN`), the producer (`evdev_pass_values()`) calls `wake_up_interruptible_poll()` immediately after releasing the lock. This ensures that the polling task is woken up and will re-evaluate the condition, seeing the updated value.
2.  **Safety of Consumption**: The actual consumption of events happens in `evdev_read()`, which calls `evdev_fetch_next_event()`. This function correctly acquires `client->buffer_lock` before checking `packet_head` and `tail`, ensuring that it always operates on a consistent and synchronized state of the event buffer.
3.  **Primitive Type**: The field `packet_head` is a simple `unsigned int`. On the x86 architecture where this was reported, 4-byte aligned loads and stores are atomic, so there is no risk of reading a "torn" or garbage value. Even if a torn value were read on another architecture, the worst-case scenario would be an incorrect poll result, which is transient and corrected by the subsequent mandatory wakeup.
4.  **No Memory Corruption/Crash**: The racy read is only used to set a bit in the poll mask. It is not used as a pointer or an array index in the racy context, so it cannot lead to memory corruption or a kernel crash.

Conclusion: The data race is a known, intentional, and functionally safe pattern in the input subsystem's evdev driver. While KCSAN correctly identifies it as a race (as it is not marked with `READ_ONCE`/`WRITE_ONCE`), it does not pose a threat to system stability or correctness.

unknown

**Digging into this evdev data race**

Okay, so I'm looking at a data race between `evdev_pass_values` and `evdev_poll` in `drivers/input/evdev.c`. The write side of this race is happening within the `__pass_event` function, which is called by `evdev_pass_values`. The read side, as expected, is in `evdev_poll`. It looks like we're dealing with a 4-byte value at memory address `0xffff88810456a808`, and the value changed from `0x00000022` to `0x00000024`.

Time to get my hands dirty. I'll open up `drivers/input/evdev.c` and start by scrutinizing the `__pass_event` function and its caller, `evdev_pass_values`. I want to see how these functions interact and what data is being shared. This is a good starting point for understanding how this race condition is triggered.

unknown

map[SourceFile:drivers/input/evdev.c]

map[Entities:[map[Kind:function Name:__evdev_flush_queue] map[Kind:function Name:__evdev_is_filtered] map[Kind:function Name:__evdev_queue_syn_dropped] map[Kind:function Name:__pass_event] map[Kind:function Name:bits_from_user] map[Kind:function Name:bits_to_user] map[Kind:function Name:evdev_attach_client] map[Kind:function Name:evdev_cleanup] map[Kind:function Name:evdev_close_device] map[Kind:function Name:evdev_compute_buffer_size] map[Kind:function Name:evdev_connect] map[Kind:function Name:evdev_detach_client] map[Kind:function Name:evdev_disconnect] map[Kind:function Name:evdev_do_ioctl] map[Kind:function Name:evdev_events] map[Kind:function Name:evdev_exit] map[Kind:function Name:evdev_fasync] map[Kind:function Name:evdev_fetch_next_event] map[Kind:function Name:evdev_free] map[Kind:function Name:evdev_get_mask] map[Kind:function Name:evdev_get_mask_cnt] map[Kind:function Name:evdev_grab] map[Kind:function Name:evdev_handle_get_keycode] map[Kind:function Name:evdev_handle_get_keycode_v2] map[Kind:function Name:evdev_handle_get_val] map[Kind:function Name:evdev_handle_mt_request] map[Kind:function Name:evdev_handle_set_keycode] map[Kind:function Name:evdev_handle_set_keycode_v2] map[Kind:function Name:evdev_hangup] map[Kind:function Name:evdev_init] map[Kind:function Name:evdev_ioctl] map[Kind:function Name:evdev_ioctl_compat] map[Kind:function Name:evdev_ioctl_handler] map[Kind:function Name:evdev_mark_dead] map[Kind:function Name:evdev_open] map[Kind:function Name:evdev_open_device] map[Kind:function Name:evdev_pass_values] map[Kind:function Name:evdev_poll] map[Kind:function Name:evdev_queue_syn_dropped] map[Kind:function Name:evdev_read] map[Kind:function Name:evdev_release] map[Kind:function Name:evdev_revoke] map[Kind:function Name:evdev_set_clk_type] map[Kind:function Name:evdev_set_mask] map[Kind:function Name:evdev_ungrab] map[Kind:function Name:evdev_write] map[Kind:function Name:handle_eviocgbit] map[Kind:function Name:str_to_user]] Missing:false]

unknown

**Examining the Input Event Processing**

Okay, so I need to dive into this input event issue. The report points me directly to the heart of the matter: `__pass_event` and `evdev_poll`. Time to dissect the code.

Based on the information, it looks like `__pass_event` is the key function; it's right there in `drivers/input/evdev.c`, specifically at line 239, and is inlined. The call trace provided shows that `evdev_pass_values` at line 278 is called after the inlined function `__pass_event`. This is the first stop.

The read stack shows that `evdev_poll` at line 621 also looks to be important.

I'll start by focusing on `__pass_event`. Understanding how it's designed is a critical first step.

unknown

map[IncludeLines:true Name:__pass_event SourceFile:drivers/input/evdev.c]

map[Missing:false SourceCode: 213:	static void __pass_event(struct evdev_client *client,
 214:				 const struct input_event *event)
 215:	{
 216:		client->buffer[client->head++] = *event;
 217:		client->head &= client->bufsize - 1;
 218:	
 219:		if (unlikely(client->head == client->tail)) {
 220:			/*
 221:			 * This effectively "drops" all unconsumed events, leaving
 222:			 * EV_SYN/SYN_DROPPED plus the newest event in the queue.
 223:			 */
 224:			client->tail = (client->head - 2) & (client->bufsize - 1);
 225:	
 226:			client->buffer[client->tail] = (struct input_event) {
 227:				.input_event_sec = event->input_event_sec,
 228:				.input_event_usec = event->input_event_usec,
 229:				.type = EV_SYN,
 230:				.code = SYN_DROPPED,
 231:				.value = 0,
 232:			};
 233:	
 234:			client->packet_head = client->tail;
 235:		}
 236:	
 237:		if (event->type == EV_SYN && event->code == SYN_REPORT) {
 238:			client->packet_head = client->head;
 239:			kill_fasync(&client->fasync, SIGIO, POLL_IN);
 240:		}
 241:	}
 SourceFile:drivers/input/evdev.c]

unknown

**Investigating a Suspected Write Operation**

Okay, so the report points to line 239 in the code, specifically the `kill_fasync` call, as the location of the write operation. But that just doesn't seem right. `kill_fasync` isn't a four-byte write, is it? Let me just double-check that. Ah, here we are, line 238: `client->packet_head = client->head;` - that looks much more promising. The report indicates a write to memory address `0xffff88810456a808` of 4 bytes. That's got my attention now.

Is it possible that `packet_head` is located at that reported address? It's the most likely candidate, isn't it? Okay, let's pull up the definition of the `struct evdev_client` and see if the memory layout gives any clues. I need to confirm whether `packet_head` has a chance of being located at that address.

unknown

map[IncludeLines:true Name:evdev_client SourceFile:drivers/input/evdev.c]

map[Missing:true SourceCode: SourceFile:]

unknown

Okay, here's my thought process on tracking down that `struct evdev_client` definition, as I would be thinking it:

**Digging into the `evdev_client` Structure**

Right, so I need to find the definition of `struct evdev_client`. Let's assume it's in the kernel source, specifically the `drivers/input/evdev.c` file. I'll mentally reach for my usual tools. First thought, `codesearch-file-index`, that's usually my go-to for quick lookups... but hang on, didn't I already try that? And I seem to recall it didn't show up as an entity. Weird. Alright, no problem. If the index isn't cooperating, let's fall back to `grep`. Or, you know what, sometimes just opening the file and quickly scanning the beginning is faster than setting up a search. I'll just check if it's there at the start and if not, then the grep is my next stop. It's usually the simplest things that are missed when under pressure, so let me just take a look.

unknown

map[IncludeLines:true Name:evdev_poll SourceFile:drivers/input/evdev.c]

map[Missing:false SourceCode: 606:	/* No kernel lock - fine */
 607:	static __poll_t evdev_poll(struct file *file, poll_table *wait)
 608:	{
 609:		struct evdev_client *client = file->private_data;
 610:		struct evdev *evdev = client->evdev;
 611:		__poll_t mask;
 612:	
 613:		poll_wait(file, &client->wait, wait);
 614:	
 615:		if (evdev->exist && !client->revoked)
 616:			mask = EPOLLOUT | EPOLLWRNORM;
 617:		else
 618:			mask = EPOLLHUP | EPOLLERR;
 619:	
 620:		if (client->packet_head != client->tail)
 621:			mask |= EPOLLIN | EPOLLRDNORM;
 622:	
 623:		return mask;
 624:	}
 SourceFile:drivers/input/evdev.c]

unknown

**Debugging a Kernel Race Condition**

Okay, so I've got this report pointing me to line 621 in `evdev.c`, specifically the `mask |= EPOLLIN | EPOLLRDNORM;` statement. The KCSAN report indicates a read of 4 bytes from that memory location by task 2993 on CPU 0.  And I see the report is focusing on `client->packet_head` and `client->tail`. Seems like line 620 is reading this value.

Now, I'm thinking, this looks like a classic race. The report also highlights a write to the *same* address, coming from `__pass_event` at line 239 of `evdev.c`, specifically during the call to `evdev_pass_values`. The code says that within `__pass_event`, when `event->type` is `EV_SYN` and `event->code` is `SYN_REPORT`, then it does this write: `client->packet_head = client->head;` – right before it calls `kill_fasync`, it's writing to `client->packet_head`.  It's probably off by a line or two, but that's where the reported memory access happens.

So, one thread is reading `client->packet_head` in `evdev_poll`, and another thread is writing it in `__pass_event`. This is definitely the source of the issue. The critical variable being raced is `client->packet_head`.

Now the question is, how is this guarded? Where are the locks? Let me trace back the call chain. `evdev_pass_values` is called by `evdev_events`, which is called by `input_pass_values`. I seem to recall that `input_pass_values` is usually called with `dev->event_lock` held. I better verify that, let me double-check the `evdev_pass_values` implementation itself.

unknown

map[IncludeLines:true Name:evdev_pass_values SourceFile:drivers/input/evdev.c]

map[Missing:false SourceCode: 243:	static void evdev_pass_values(struct evdev_client *client,
 244:				const struct input_value *vals, unsigned int count,
 245:				ktime_t *ev_time)
 246:	{
 247:		const struct input_value *v;
 248:		struct input_event event;
 249:		struct timespec64 ts;
 250:		bool wakeup = false;
 251:	
 252:		if (client->revoked)
 253:			return;
 254:	
 255:		ts = ktime_to_timespec64(ev_time[client->clk_type]);
 256:		event.input_event_sec = ts.tv_sec;
 257:		event.input_event_usec = ts.tv_nsec / NSEC_PER_USEC;
 258:	
 259:		/* Interrupts are disabled, just acquire the lock. */
 260:		spin_lock(&client->buffer_lock);
 261:	
 262:		for (v = vals; v != vals + count; v++) {
 263:			if (__evdev_is_filtered(client, v->type, v->code))
 264:				continue;
 265:	
 266:			if (v->type == EV_SYN && v->code == SYN_REPORT) {
 267:				/* drop empty SYN_REPORT */
 268:				if (client->packet_head == client->head)
 269:					continue;
 270:	
 271:				wakeup = true;
 272:			}
 273:	
 274:			event.type = v->type;
 275:			event.code = v->code;
 276:			event.value = v->value;
 277:			__pass_event(client, &event);
 278:		}
 279:	
 280:		spin_unlock(&client->buffer_lock);
 281:	
 282:		if (wakeup)
 283:			wake_up_interruptible_poll(&client->wait,
 284:				EPOLLIN | EPOLLOUT | EPOLLRDNORM | EPOLLWRNORM);
 285:	}
 SourceFile:drivers/input/evdev.c]

unknown

**Examining Potential Data Races in the evdev Driver**

Okay, so I'm digging into this `evdev` driver code, and a potential race condition has caught my eye. Specifically, I'm looking at how `evdev_poll` interacts with the event buffer and the `packet_head` and `tail` pointers, which represent the data available in the buffer.

I noticed that `evdev_pass_values` *does* acquire a spinlock (`client->buffer_lock`) before updating the buffer and pointers, like `packet_head` and `tail`. However, `evdev_poll` *doesn't* take this lock. That immediately raised a red flag.

My primary concern is that `evdev_poll` reads `client->packet_head` and `client->tail` to determine if there's data to read. Since `evdev_pass_values` writes `packet_head` and `tail`, a race condition seems possible. If `evdev_poll` reads these values *while* `evdev_pass_values` is updating them, I might get inconsistent results, right?

Thinking more deeply, `poll` itself is designed to indicate data availability, that is `packet_head != tail`. The data is considered available only after a *complete* packet (signaled by `SYN_REPORT`) has been written.

So, if `evdev_poll` sees an outdated value of `packet_head`, it *might* erroneously report that there's no data available when there actually is. But then I remembered that `evdev_pass_values` calls `wake_up_interruptible_poll` *after* it releases the spinlock and updates the `packet_head`. The purpose of `wake_up_interruptible_poll` is precisely to wake up processes waiting for data, which would include `evdev_poll`.

Okay, so the typical execution flow is like this: `evdev_poll` adds itself to a wait queue (`client->wait`), checks `packet_head != tail`. Meanwhile, if `evdev_pass_values` is running:

1.  `evdev_pass_values` updates `packet_head`.
2.  `evdev_pass_values` calls `wake_up_interruptible_poll`.

Now if `evdev_poll` runs concurrently: if it sees the old value, it might erroneously return 0. However, it will be woken up by the `wake_up_interruptible_poll` call, and the function will run again, where it should pick up the correct, updated value of `packet_head`.

That makes sense – this is a fairly standard pattern in Linux for `poll` implementations.

However, KCSAN is flagging this. The data race is because these accesses aren't protected. Which brings me to a question: are these accesses atomic? I should check the data type of `packet_head` and `tail` in the `evdev_client` struct. If it's something like an `unsigned int`, I assume they are atomic, right? Let me confirm that.

unknown

map[IncludeLines:true Name:evdev_client SourceFile:drivers/input/evdev.c]

map[Missing:true SourceCode: SourceFile:]

unknown

Okay, here's my thought process on finding the definition of `struct evdev_client`, described as if I'm thinking it:

**Tracing a Kernel Structure Definition**

Alright, I need to pinpoint the definition of `struct evdev_client`. My initial hunch is that it's nestled in `drivers/input/evdev.c`, that's the obvious place. But, since I'm trying to be thorough and I may have been a bit sloppy with my previous search, let me re-evaluate how I approached it the first time. Perhaps I missed something because it's a structure definition, and I may not have included all the necessary qualifiers. It could also just be named a slightly differently. 

Hmm, wait a moment, `codesearch-file-index` didn't turn it up at all? That's unusual, but I should probably double-check that output just to be absolutely sure. Okay, I've checked the output. It's *definitely* not there. Let me try a more precise search, specifically targeting this structure. I need to be absolutely sure where it resides.

unknown

map[Name:evdev_client SourceFile:drivers/input/evdev.c]

map[Comment: Kind: Missing:true]

unknown

**Initial Investigation into `struct evdev_client`**

Okay, that's a bit odd. I need to figure out where `struct evdev_client` is defined and used. My first instinct is to reach for `grep`. I'll try `codesearch-definition-source` with a reasonable guess at the file path: `drivers/input/evdev.c`, searching for "struct evdev_client {". Hmm, wait a second, that's probably not the most efficient approach. I can be smarter about this.

I'll just try `codesearch-definition-source` on a function that *uses* `struct evdev_client`. That's going to be far more effective. Then, I can just peek around the code where it's referenced. Actually, the most expedient method might just be to read the beginning of the `drivers/input/evdev.c` source file. Often, these kinds of definitions are right up front.

unknown

map[IncludeLines:true Name:evdev_connect SourceFile:drivers/input/evdev.c]

map[Missing:false SourceCode:1329:	/*
1330:	 * Create new evdev device. Note that input core serializes calls
1331:	 * to connect and disconnect.
1332:	 */
1333:	static int evdev_connect(struct input_handler *handler, struct input_dev *dev,
1334:				 const struct input_device_id *id)
1335:	{
1336:		struct evdev *evdev;
1337:		int minor;
1338:		int dev_no;
1339:		int error;
1340:	
1341:		minor = input_get_new_minor(EVDEV_MINOR_BASE, EVDEV_MINORS, true);
1342:		if (minor < 0) {
1343:			error = minor;
1344:			pr_err("failed to reserve new minor: %d\n", error);
1345:			return error;
1346:		}
1347:	
1348:		evdev = kzalloc(sizeof(struct evdev), GFP_KERNEL);
1349:		if (!evdev) {
1350:			error = -ENOMEM;
1351:			goto err_free_minor;
1352:		}
1353:	
1354:		INIT_LIST_HEAD(&evdev->client_list);
1355:		spin_lock_init(&evdev->client_lock);
1356:		mutex_init(&evdev->mutex);
1357:		evdev->exist = true;
1358:	
1359:		dev_no = minor;
1360:		/* Normalize device number if it falls into legacy range */
1361:		if (dev_no < EVDEV_MINOR_BASE + EVDEV_MINORS)
1362:			dev_no -= EVDEV_MINOR_BASE;
1363:		dev_set_name(&evdev->dev, "event%d", dev_no);
1364:	
1365:		evdev->handle.dev = input_get_device(dev);
1366:		evdev->handle.name = dev_name(&evdev->dev);
1367:		evdev->handle.handler = handler;
1368:		evdev->handle.private = evdev;
1369:	
1370:		evdev->dev.devt = MKDEV(INPUT_MAJOR, minor);
1371:		evdev->dev.class = &input_class;
1372:		evdev->dev.parent = &dev->dev;
1373:		evdev->dev.release = evdev_free;
1374:		device_initialize(&evdev->dev);
1375:	
1376:		error = input_register_handle(&evdev->handle);
1377:		if (error)
1378:			goto err_free_evdev;
1379:	
1380:		cdev_init(&evdev->cdev, &evdev_fops);
1381:	
1382:		error = cdev_device_add(&evdev->cdev, &evdev->dev);
1383:		if (error)
1384:			goto err_cleanup_evdev;
1385:	
1386:		return 0;
1387:	
1388:	 err_cleanup_evdev:
1389:		evdev_cleanup(evdev);
1390:		input_unregister_handle(&evdev->handle);
1391:	 err_free_evdev:
1392:		put_device(&evdev->dev);
1393:	 err_free_minor:
1394:		input_free_minor(minor);
1395:		return error;
1396:	}
 SourceFile:drivers/input/evdev.c]

unknown

Okay, here's my attempt at summarizing my thought process in the first person, assuming an expert audience:

**Hunting Down `struct evdev_client`**

Alright, let's get down to brass tacks. I need to nail down the exact definition of `struct evdev_client`. My hunch, based on experience, is that it'll be declared pretty early on in the source file. It's usually good coding practice to put the core data structures upfront, so that's where I'll start looking. I'll scan the beginning of the file, keeping an eye out for that specific `struct` declaration. It's a fundamental element, so it shouldn't be too buried. Hopefully, the naming conventions are consistent, and it's easy to spot amongst other declarations. Let's see what we can find.

unknown

map[IncludeLines:true Name:evdev_open SourceFile:drivers/input/evdev.c]

map[Missing:false SourceCode: 460:	static int evdev_open(struct inode *inode, struct file *file)
 461:	{
 462:		struct evdev *evdev = container_of(inode->i_cdev, struct evdev, cdev);
 463:		unsigned int bufsize = evdev_compute_buffer_size(evdev->handle.dev);
 464:		struct evdev_client *client;
 465:		int error;
 466:	
 467:		client = kvzalloc(struct_size(client, buffer, bufsize), GFP_KERNEL);
 468:		if (!client)
 469:			return -ENOMEM;
 470:	
 471:		init_waitqueue_head(&client->wait);
 472:		client->bufsize = bufsize;
 473:		spin_lock_init(&client->buffer_lock);
 474:		client->evdev = evdev;
 475:		evdev_attach_client(evdev, client);
 476:	
 477:		error = evdev_open_device(evdev);
 478:		if (error)
 479:			goto err_free_client;
 480:	
 481:		file->private_data = client;
 482:		stream_open(inode, file);
 483:	
 484:		return 0;
 485:	
 486:	 err_free_client:
 487:		evdev_detach_client(evdev, client);
 488:		kvfree(client);
 489:		return error;
 490:	}
 SourceFile:drivers/input/evdev.c]

unknown

**Finding the `struct evdev_client` Definition**

Alright, let's see, I need to locate the definition of `struct evdev_client`. My usual methods haven't been working quite as I'd expect. Okay, instead of the initial approach, I'll bypass the usual tools and see if I can try a different approach. Maybe I can use `codesearch-definition-source`, setting an extremely high line number with the hopes of getting some file content back. Or, I could try using a definition name I *know* exists early on in the file.

Wait a second, the simplest thing to do right now is just to quickly skim the first 100 lines of `drivers/input/evdev.c`. That should be fast enough and get me what I need. Let's start there.

unknown

map[IncludeLines:true Name:__evdev_flush_queue SourceFile:drivers/input/evdev.c]

map[Missing:false SourceCode:  99:	/* flush queued events of type @type, caller must hold client->buffer_lock */
 100:	static void __evdev_flush_queue(struct evdev_client *client, unsigned int type)
 101:	{
 102:		unsigned int i, head, num;
 103:		unsigned int mask = client->bufsize - 1;
 104:		bool is_report;
 105:		struct input_event *ev;
 106:	
 107:		BUG_ON(type == EV_SYN);
 108:	
 109:		head = client->tail;
 110:		client->packet_head = client->tail;
 111:	
 112:		/* init to 1 so a leading SYN_REPORT will not be dropped */
 113:		num = 1;
 114:	
 115:		for (i = client->tail; i != client->head; i = (i + 1) & mask) {
 116:			ev = &client->buffer[i];
 117:			is_report = ev->type == EV_SYN && ev->code == SYN_REPORT;
 118:	
 119:			if (ev->type == type) {
 120:				/* drop matched entry */
 121:				continue;
 122:			} else if (is_report && !num) {
 123:				/* drop empty SYN_REPORT groups */
 124:				continue;
 125:			} else if (head != i) {
 126:				/* move entry to fill the gap */
 127:				client->buffer[head] = *ev;
 128:			}
 129:	
 130:			num++;
 131:			head = (head + 1) & mask;
 132:	
 133:			if (is_report) {
 134:				num = 0;
 135:				client->packet_head = head;
 136:			}
 137:		}
 138:	
 139:		client->head = head;
 140:	}
 SourceFile:drivers/input/evdev.c]

unknown

Here's your summary:

**Focusing In**

Okay, so I've been presented with this document, and frankly, I don't have all day. Given my expertise, I know what sections are likely to be most relevant and where the core arguments are usually located. I'm going to skip the fluff and the introductory material for now. Let's get straight to it. I'm going to laser in on lines 30 through 90. That should give me a solid grasp of the key data or arguments presented without getting bogged down.

unknown

map[IncludeLines:true Name:__evdev_is_filtered SourceFile:drivers/input/evdev.c]

map[Missing:false SourceCode:  73:	/* requires the buffer lock to be held */
  74:	static bool __evdev_is_filtered(struct evdev_client *client,
  75:					unsigned int type,
  76:					unsigned int code)
  77:	{
  78:		unsigned long *mask;
  79:		size_t cnt;
  80:	
  81:		/* EV_SYN and unknown codes are never filtered */
  82:		if (type == EV_SYN || type >= EV_CNT)
  83:			return false;
  84:	
  85:		/* first test whether the type is filtered */
  86:		mask = client->evmasks[0];
  87:		if (mask && !test_bit(type, mask))
  88:			return true;
  89:	
  90:		/* unknown values are never filtered */
  91:		cnt = evdev_get_mask_cnt(type);
  92:		if (!cnt || code >= cnt)
  93:			return false;
  94:	
  95:		mask = client->evmasks[type];
  96:		return mask && !test_bit(code, mask);
  97:	}
 SourceFile:drivers/input/evdev.c]

unknown

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

**Hunting Down That Darned Struct Definition**

Alright, still haven't managed to spot the core `struct` definition I need to understand. Frustrating, but par for the course when diving into someone else's code. Okay, let's refocus. I need to be methodical here. I'll go back and zero in on lines 20 through 70, making that my target zone for now. Hopefully, it's in that block. Time to dig in and see if it's hiding in there!

unknown

map[IncludeLines:true Name:bits_from_user SourceFile:drivers/input/evdev.c]

map[Missing:false SourceCode: 712:	static int bits_from_user(unsigned long *bits, unsigned int maxbit,
 713:				  unsigned int maxlen, const void __user *p, int compat)
 714:	{
 715:		size_t chunk_size = compat ? sizeof(compat_long_t) : sizeof(long);
 716:		int len;
 717:	
 718:		if (maxlen % chunk_size)
 719:			return -EINVAL;
 720:	
 721:		len = compat ? BITS_TO_LONGS_COMPAT(maxbit) : BITS_TO_LONGS(maxbit);
 722:		len *= chunk_size;
 723:		if (len > maxlen)
 724:			len = maxlen;
 725:	
 726:		return copy_from_user(bits, p, len) ? -EFAULT : len;
 727:	}
 SourceFile:drivers/input/evdev.c]

unknown

**Analyzing a Data Race in the evdev Driver**

Alright, let's break this down. My initial approach with `codesearch-definition-source` wasn't giving me the full context, so I switched tactics and went straight for the `struct evdev {` search, which, of course, gives me the goods. I quickly spotted the interaction between `evdev_pass_values` and `evdev_poll` and their access to `client->packet_head`.

Looking at the code, I see `evdev_pass_values` uses `spin_lock(&client->buffer_lock)` to protect the updates to `packet_head` within its critical section. `__pass_event` updates the value *within* the lock. Meanwhile, `evdev_poll` reads `packet_head` without the protection of the lock. That's immediately a flag.

So, is `packet_head` an `unsigned int`? I dug around a bit and, yes, it seems it is. I confirmed this by checking how it's used in `__evdev_flush_queue`. With the confirmed type, the concern then turns to memory atomicity.

Multiple threads calling `evdev_pass_values` are clearly serialized, but what happens when `evdev_poll` and `evdev_pass_values` interact concurrently? `evdev_poll` is reading `packet_head`, and it could see either an old value or the new, but is a torn value possible? Given the architecture (x86), 4-byte aligned reads/writes are atomic. But it is within a structure.

Since it's just a simple check for "is there data?", an old value simply means `poll` might initially report "no data," but will be woken up by `wake_up_interruptible_poll` right after. The `wake_up_interruptible_poll` call is *after* the lock is released in `evdev_pass_values`, so we are safe from missing wakeups.

So, the process is: `evdev_poll` adds to the waitqueue, then it checks `packet_head != tail`, and later, `evdev_pass_values` updates `packet_head` and then wakes up the waitqueue. No missed wakeups.

The real problem here is the race condition itself, as flagged by KCSAN. While it's a simple `int` or `unsigned int`, and the logic doesn't depend on getting the *exact* latest value at the *exact* moment, because of the wakeup mechanism, it's generally considered benign. But ideally, it *should* use `READ_ONCE`/`WRITE_ONCE` or be marked as a known race. It's a kernel convention, though, and I've seen it done this way many times.

But, just to be sure, I should verify the race cannot lead to corrupted values. I check the value change from `0x00000022` to `0x00000024`. This looks like a normal increment, no big red flags there.

Finally, I checked for other usages of `packet_head`, finding it used in `evdev_fetch_next_event`, to complete the picture. This is a common pattern, and while a race, is generally understood to be benign in this situation.

unknown

map[IncludeLines:true Name:evdev_fetch_next_event SourceFile:drivers/input/evdev.c]

map[Missing:false SourceCode: 537:	static int evdev_fetch_next_event(struct evdev_client *client,
 538:					  struct input_event *event)
 539:	{
 540:		int have_event;
 541:	
 542:		spin_lock_irq(&client->buffer_lock);
 543:	
 544:		have_event = client->packet_head != client->tail;
 545:		if (have_event) {
 546:			*event = client->buffer[client->tail++];
 547:			client->tail &= client->bufsize - 1;
 548:		}
 549:	
 550:		spin_unlock_irq(&client->buffer_lock);
 551:	
 552:		return have_event;
 553:	}
 SourceFile:drivers/input/evdev.c]

unknown

**Data Race in evdev.c: A Deep Dive**

Okay, so I'm looking at this KCSAN report. The core issue seems to be a data race within the `evdev` driver, specifically concerning the interaction between `evdev_poll` and the `packet_head` and `tail` members of an `evdev_client` struct. This is interesting.

From what I can tell, `evdev_fetch_next_event` *is* protected by a `buffer_lock`. The `evdev_read` function also uses the locked version, so no problem there. However, `evdev_poll` uses the unlocked version. That's the key. This means that if `packet_head` is updated, the poll may be reading it at the same time and there could be garbage data.

Now, on an x86 architecture, I'd expect the 4-byte `int` to be read atomically, so a half-written value isn't likely. The critical question becomes whether `packet_head` or `tail` can be changed while `poll` is in the process of reading them, leading to an inconsistent state.

Even if `poll` sees a slightly stale value, it's designed to be relatively robust. If it sees stale "no data" (equal values), it should be woken up by the next `wake_up_interruptible_poll`. If it sees "data available" (unequal values), it returns `EPOLLIN`. The user then calls `read()`. The `read()` function calls `evdev_fetch_next_event` which *does* take the lock, and re-checks the state. So it should be safe in the long run.

Then I checked `client->tail`. That's read in `evdev_poll`. It's written in `__pass_event` (during queue overflows) and `evdev_fetch_next_event`, both under the `buffer_lock`. The same logic about races with `tail` should also apply, and it looks sound.

Wait, this KCSAN report is very specific: "write to 0xffff88810456a808 of 4 bytes... read to 0xffff88810456a808 of 4 bytes...". The value changed from `0x00000022` to `0x00000024`. And the write is in `drivers/input/evdev.c:239`, which is where `__pass_event` is inlined from `evdev_pass_values`.

Aha! Line 238 in `__pass_event` is `client->packet_head = client->head;`. And `client->head` is also incremented in `__pass_event`: `client->buffer[client->head++] = *event;`. So there's a definite write to the same address.

`__pass_event` is called by `evdev_pass_values`. This function loops and can process multiple events per call. The last event in a packet is usually a `EV_SYN/SYN_REPORT`.  `packet_head` is only updated when a packet is complete, which explains the specific race condition and the KCSAN report.

This looks like a classic "poll doesn't take lock" data race!

Now the question is, is this "benign"? In the Linux kernel, a race that doesn't cause functional issues is *often* considered benign, but KCSAN flags it. The logic appears to handle stale values (wakeup or re-check under lock), so it's likely functionally correct, but the use of `data_race()` or `READ_ONCE`/`WRITE_ONCE` would probably be more correct and safer.

Let me see if there are other members of the `evdev_client` struct at that address. I should be able to look up the struct definition. Let me try using `codesearch-definition-source` on `evdev` to get me to the definition of the struct, in case the tool I'm using fails to find it, or I'll look for where the struct is defined in general. I can use `codesearch-file-index` on `drivers/input/evdev.c` and search for `struct` to make sure.

It does not list `struct`. It only lists `Kind: function`. It's possible the tool only finds structs defined explicitly. Let me look at the tool description. Ah, "Entity can be function, struct, or global variable." So, it might not find a struct declared somewhere else! But `evdev.c` is where it *should* be. Let

unknown

map[IncludeLines:true Name:evdev SourceFile:drivers/input/evdev.c]

map[Missing:true SourceCode: SourceFile:]

unknown

Here's my thought process, as if I were in the process of debugging this myself:

**Tracing `evdev_client` Definition**

Alright, let's track down the definition of `evdev_client`. Hmm, I'm pretty sure it's in the `drivers/input/evdev.c` file. Given my experience with the kernel input subsystem, it's likely near the top. I'll start by taking a stab in the dark and check lines 1 through 100. I've glanced at this file before, so that's a reasonable first guess.

Wait a second… I think I saw `__evdev_flush_queue` near the bottom of that area. Let me double-check the line numbers real quick. Okay, that's at line 100. Let me hone in a bit and try lines 30-60. I feel like it's in that vicinity.

unknown

map[IncludeLines:true Name:evdev_compute_buffer_size SourceFile:drivers/input/evdev.c]

map[Missing:false SourceCode: 451:	static unsigned int evdev_compute_buffer_size(struct input_dev *dev)
 452:	{
 453:		unsigned int n_events =
 454:			max(dev->hint_events_per_packet * EVDEV_BUF_PACKETS,
 455:			    EVDEV_MIN_BUFFER_SIZE);
 456:	
 457:		return roundup_pow_of_two(n_events);
 458:	}
 SourceFile:drivers/input/evdev.c]

unknown

**Analyzing a Suspected Data Race in the evdev Driver**

Okay, so I'm digging into this KCSAN report. The primary concern seems to be a data race involving `packet_head` and `tail` within the `evdev_client` struct, specifically within the `evdev_poll` function. I initially tried using `codesearch-definition-comment` and `codesearch-definition-source` but it did not provide the relevant information on the evdev_client struct. I also couldn't use `codesearch-definition-source` with `evdev_client` because it kept returning `Missing: true`.

I've got the line numbers for the `spin_lock` call and it looks like it's within a protected section.

From looking at the trace and comments, it seems we have a lock being acquired but not within the `poll` call. If the race is on `packet_head`, which is an `unsigned int`, the data race is benign in terms of functionality. The value change is between two indices into a buffer.

It looks like the `poll` is just an optimization, a notification mechanism. The real check is done in `read` under the lock, and if `poll` returns 0 incorrectly, the subsequent `wake_up` will fix it. The comment in `evdev_poll` that says `/* No kernel lock - fine */` suggests that the original author knew about this.

The KCSAN report means it is a real race, even if it's "benign" in the common sense. KCSAN usually views races on simple variables where stale values are okay as benign, but it wants them marked with `READ_ONCE`/`WRITE_ONCE` to prevent compiler optimizations that could break things.

The issue is that `evdev_poll` reads `client->packet_head` and `client->tail`. If the compiler reads them multiple times, we might get inconsistent results for one check.

I need to confirm there is no risk of corruption or crash. The values are simple integers and the risk is unlikely.

The key is to consider what happens if `packet_head` update isn't atomic. On x86, it *is* atomic, which is good.

I've traced the code a bit and the report points to the read and write instructions. The report is definitely looking at the same variable.

I am feeling confident it's a benign data race, and an "intentional lack of locking in poll" style. Many `poll` implementations avoid the spinlock for performance. They rely on the fact that if they see a stale value and return 0, the following `wake_up` from the producer will trigger another `poll` call.

I need to ensure that the producer calls `wake_up` after the update, and that the consumer sees the update or gets the wakeup. I see the pattern:
Producer:
1.  `client->packet_head = new_head;`
2.  `spin_unlock(&client->buffer_lock);`
3.  `wake_up_interruptible_poll(&client->wait, ...);`

Consumer (poll):
1.  `poll_wait(file, &client->wait, wait);` // adds to waitqueue
2.  `if (client->packet_head != client->tail) ...`

The `wake_up` function and `poll_wait` provide memory barriers. The race is real, but doesn't lead to incorrect behavior, although the KCSAN report still flags it. It's not harmful, in terms of crash or memory corruption.

I'm double-checking to confirm that other writes to `packet_head` are properly locked. From what I see in `__evdev_flush_queue`, `evdev_pass_values` and `evdev_fetch_next_event`, it looks like everything should be under lock.

That comment: `No kernel lock - fine` might be old and referring to the now deprecated Big Kernel Lock.

One important check: can `packet_head` change from not-equal to equal and back in a way that causes `poll` to incorrectly return 0? I've run through the possible scenarios:  It looks safe, based on the way `tail` is updated and the `wake_up` call.

I should search for `struct evdev_client` again, this time with a different approach to locate the struct and confirm the types and locations of these fields, potentially using `bufsize` to help me locate the correct structure.

unknown

map[IncludeLines:true Name:evdev_compute_buffer_size SourceFile:drivers/input/evdev.c]

map[Missing:false SourceCode: 451:	static unsigned int evdev_compute_buffer_size(struct input_dev *dev)
 452:	{
 453:		unsigned int n_events =
 454:			max(dev->hint_events_per_packet * EVDEV_BUF_PACKETS,
 455:			    EVDEV_MIN_BUFFER_SIZE);
 456:	
 457:		return roundup_pow_of_two(n_events);
 458:	}
 SourceFile:drivers/input/evdev.c]

unknown

Okay, here's my thought process on this:

**Digging into the `evdev_attach_client` Structure**

Right, so I need to get to the bottom of that `evdev_attach_client` definition. I've been looking around, and I'm going to try a different tack. Instead of what I was doing before, I'm going to leverage my usual trick. I'll fire up the `codesearch-definition-source` tool. That usually helps me find the precise struct definition when I'm dealing with kernel code. Hopefully, that will give me what I need.

unknown

map[IncludeLines:true Name:evdev_attach_client SourceFile:drivers/input/evdev.c]

map[Missing:false SourceCode: 362:	static void evdev_attach_client(struct evdev *evdev,
 363:					struct evdev_client *client)
 364:	{
 365:		spin_lock(&evdev->client_lock);
 366:		list_add_tail_rcu(&client->node, &evdev->client_list);
 367:		spin_unlock(&evdev->client_lock);
 368:	}
 SourceFile:drivers/input/evdev.c]

unknown

Okay, here's what's going through my mind:

**Finding the `evdev_client` Structure Definition**

Right, let's get down to brass tacks. I need to pinpoint the definition of `struct evdev_client`. It's that critical component I'm after, and I'm betting its members will give me the clues I need. Let me mentally run through the important ones: `packet_head`, `head`, `tail`, `buffer_lock`, and the crucial `wait` variable. I have a feeling these are the key to the solution. I'll focus again on lines 30-80, and I'll be more diligent. It's time to refine my approach and dive back in.

unknown

map[SourceFile:drivers/input/evdev.c]

map[Entities:[map[Kind:function Name:__evdev_flush_queue] map[Kind:function Name:__evdev_is_filtered] map[Kind:function Name:__evdev_queue_syn_dropped] map[Kind:function Name:__pass_event] map[Kind:function Name:bits_from_user] map[Kind:function Name:bits_to_user] map[Kind:function Name:evdev_attach_client] map[Kind:function Name:evdev_cleanup] map[Kind:function Name:evdev_close_device] map[Kind:function Name:evdev_compute_buffer_size] map[Kind:function Name:evdev_connect] map[Kind:function Name:evdev_detach_client] map[Kind:function Name:evdev_disconnect] map[Kind:function Name:evdev_do_ioctl] map[Kind:function Name:evdev_events] map[Kind:function Name:evdev_exit] map[Kind:function Name:evdev_fasync] map[Kind:function Name:evdev_fetch_next_event] map[Kind:function Name:evdev_free] map[Kind:function Name:evdev_get_mask] map[Kind:function Name:evdev_get_mask_cnt] map[Kind:function Name:evdev_grab] map[Kind:function Name:evdev_handle_get_keycode] map[Kind:function Name:evdev_handle_get_keycode_v2] map[Kind:function Name:evdev_handle_get_val] map[Kind:function Name:evdev_handle_mt_request] map[Kind:function Name:evdev_handle_set_keycode] map[Kind:function Name:evdev_handle_set_keycode_v2] map[Kind:function Name:evdev_hangup] map[Kind:function Name:evdev_init] map[Kind:function Name:evdev_ioctl] map[Kind:function Name:evdev_ioctl_compat] map[Kind:function Name:evdev_ioctl_handler] map[Kind:function Name:evdev_mark_dead] map[Kind:function Name:evdev_open] map[Kind:function Name:evdev_open_device] map[Kind:function Name:evdev_pass_values] map[Kind:function Name:evdev_poll] map[Kind:function Name:evdev_queue_syn_dropped] map[Kind:function Name:evdev_read] map[Kind:function Name:evdev_release] map[Kind:function Name:evdev_revoke] map[Kind:function Name:evdev_set_clk_type] map[Kind:function Name:evdev_set_mask] map[Kind:function Name:evdev_ungrab] map[Kind:function Name:evdev_write] map[Kind:function Name:handle_eviocgbit] map[Kind:function Name:str_to_user]] Missing:false]

unknown

Here's my thought process, as if I were the one thinking it:

**Finding the Data Structure**

Okay, this entity list is just full of functions, which is pretty inconvenient. I need the associated struct definition, and it's not immediately obvious where it is. I'll need to dig around. Given that `__evdev_flush_queue` is on line 100, the struct I'm after has *got* to be defined before that. My gut tells me it's usually at the top, but let's be strategic. I'll start by taking a look at lines 10 to 60. That should give me a good window to spot it without getting lost in the weeds. Hopefully, this works.

unknown

map[IncludeLines:true Name:__evdev_queue_syn_dropped SourceFile:drivers/input/evdev.c]

map[Missing:false SourceCode: 142:	static void __evdev_queue_syn_dropped(struct evdev_client *client)
 143:	{
 144:		ktime_t *ev_time = input_get_timestamp(client->evdev->handle.dev);
 145:		struct timespec64 ts = ktime_to_timespec64(ev_time[client->clk_type]);
 146:		struct input_event ev;
 147:	
 148:		ev.input_event_sec = ts.tv_sec;
 149:		ev.input_event_usec = ts.tv_nsec / NSEC_PER_USEC;
 150:		ev.type = EV_SYN;
 151:		ev.code = SYN_DROPPED;
 152:		ev.value = 0;
 153:	
 154:		client->buffer[client->head++] = ev;
 155:		client->head &= client->bufsize - 1;
 156:	
 157:		if (unlikely(client->head == client->tail)) {
 158:			/* drop queue but keep our SYN_DROPPED event */
 159:			client->tail = (client->head - 1) & (client->bufsize - 1);
 160:			client->packet_head = client->tail;
 161:		}
 162:	}
 SourceFile:drivers/input/evdev.c]

unknown

Here's a summary of my thought process:

**Tracing the Source of `__evdev_is_filtered`**

Okay, so I need to figure out where `__evdev_is_filtered` is defined. My first instinct is to just go straight to the source and trace back from there. *But wait a minute...* I've already done that, haven't I? Alright, let's try a different tack. I'll just jump to the beginning of the file – line 1, and see if the answer is immediately obvious.

unknown

map[IncludeLines:true Name:evdev_init SourceFile:drivers/input/evdev.c]

map[Missing:false SourceCode:1430:	static int __init evdev_init(void)
1431:	{
1432:		return input_register_handler(&evdev_handler);
1433:	}
 SourceFile:drivers/input/evdev.c]

unknown

Here's a summary of my thought process:

**Initial File Access Attempt**

Okay, I need to get at the beginning of this file. Let me start with a name I haven't used before. There aren't many to choose from, but I'll see if I can find something. I'll need to figure out how to specify the line range. Wait... I'm getting ahead of myself, I can't do that. Darn.

I've got it! I will use `codesearch-definition-source` with `evdev_handler`. Now let's see...

unknown

map[IncludeLines:true Name:evdev_handler SourceFile:drivers/input/evdev.c]

map[Missing:true SourceCode: SourceFile:]

unknown

**Deconstructing the `packet_head` Conundrum**

Okay, so I'm diving into this `evdev` issue. My first thought was that `evdev_handler` should be global, and I should have checked that first! Now, I tried `codesearch-file-index` again, hoping I'd missed something, but it's only showing functions, even though it claims to cover structs and globals as well, which is annoying.

Anyway, I have enough to go on from the code snippets. I've figured out that `packet_head` is an index into the buffer, and `head` and `tail` are also indices. The critical point is that they're all modified under `buffer_lock`, while `evdev_poll` reads them without the lock.

This smells like a classic kernel pattern. I've seen this a million times – it's often a "benign race". The reasons for this are pretty standard: First, these are just simple integer values, so no pointer shenanigans. Second, tearing is unlikely on most architectures for 4-byte aligned integers, and even if it *does* happen, the worst case is a wrong poll result, which will be corrected in the next wakeup. Third, the logic itself is pretty robust against stale poll data; the real check is locked down in `read`.

Wait, the report states `value changed: 0x00000022 -> 0x00000024`. This strongly suggests that `packet_head` is the culprit.

Given this, I am going to lean towards "benign".

Just to be absolutely sure, though, I need to check if a race on `packet_head` or `tail` could *cause* a crash. Let's look at `evdev_poll`:

```c
 620:		if (client->packet_head != client->tail)
 621:			mask |= EPOLLIN | EPOLLRDNORM;
```

It's just a straight comparison. No way this could crash.

One more thing. Is it possible that the `client` itself is being freed under me? `evdev_poll` gets `client` from `file->private_data`. As long as the file is open, `client` should be alive, because `evdev_release` would handle the cleanup.

Okay, so the race is *definitely* on `packet_head`.

Now, is there any situation where `packet_head` is *used* as an index without the lock? In `evdev_poll`, it's just being compared to `tail`. In `evdev_fetch_next_event`, it's compared to `tail` *under* the lock. In `__evdev_flush_queue`, it is used, but that’s also under the lock. The same is true for `evdev_pass_values`.

So, the *only* unlocked access is the comparison in `evdev_poll`.

I am reasonably confident this is benign.

Hold on, I should double-check for more complex writes to `packet_head`. Going back to `__pass_event`:

```c
 224:			client->tail = (client->head - 2) & (client->bufsize - 1);
 ...
 234:			client->packet_head = client->tail;
```
And:

```c
 238:			client->packet_head = client->head;
```

These are all simple assignments of `unsigned int`.

I need to quickly see the `struct` definition to confirm my findings. Let me try `codesearch-definition-source` with `struct evdev_client` but as a `struct`. No, wait, I'll try searching for `evdev_client` in `include/linux/input.h`... Nope, that's likely internal to `evdev.c`.

Aha! `codesearch-definition-source` should handle queries like `Name: "struct evdev_client"`. I need to remember that!

unknown

map[IncludeLines:true Name:struct evdev_client SourceFile:drivers/input/evdev.c]

map[Missing:true SourceCode: SourceFile:]

unknown

**Analyzing a Potential Data Race**

Okay, let's break this down. My initial assumption is that we're dealing with a fairly standard data structure here. The data race report itself is providing the crucial clues. I see the write happening at address `0xffff88810456a808`, and it's a 4-byte write. The values being written are `0x22` and `0x24`.

My immediate thought is to check if this `packet_head` variable is involved in any offset calculations that could lead to out-of-bounds reads if the value is "torn" during the write. But, looking at the code, it's only compared to `tail` within the racy location in `evdev_poll`.

Now, let's consider a torn write, perhaps `0x00000022` to `0x00000122`. The comparison `0x122 != tail` could evaluate to either true or false. However, all this comparison is used for is setting the `EPOLLIN` bit in `mask`. The actual data reading occurs later in `evdev_read` which calls `evdev_fetch_next_event`, and *that* function takes a lock.

Hang on... `evdev_fetch_next_event` *also* compares `packet_head` and `tail`. Crucially, because it's under a lock, it will see a consistent state.

So, the racy read in `evdev_poll` only affects whether `poll()` returns `EPOLLIN` or not. If it returns `EPOLLIN` incorrectly (a false positive), the subsequent `read()` will simply block or return `EAGAIN`, after it acquires the lock and sees no data. If it returns 0 (false negative), it might miss a notification, but, as we discussed, the producer's `wake_up` call should eventually correct that situation.

This looks like a textbook "benign" race condition in the Linux kernel, though I can see why KCSAN might want this marked.

One more thing. I should double-check the type of `packet_head`. In `__evdev_flush_queue`, I see `unsigned int i, head, num;` and `client->packet_head = head;`. Okay, so it's an `unsigned int`.

Alright, I think I've got a handle on this. I'll summarize the results.

unknown

map[Benign:true Confident:true]

map[Benign:true Confident:true]

unknown

**Understanding the Evdev Data Race**

Okay, so I've pinned down the data race. It's definitely between `evdev_pass_values`, where `packet_head` gets written to, and `evdev_poll`, which reads it. I'm familiar with this kind of pattern; it’s a typical performance optimization you see in kernel `poll` implementations. They intentionally unlock the read access to keep things snappy.

The good news is, this race is actually benign. I’ve looked at it closely, and here’s why I'm not worried:

*   First, it only messes with the return value from `poll`. It's just a hint, so the consequences of it being stale are minimal.
*   Second, the producer side, the one updating `packet_head`, calls `wake_up_interruptible_poll` *after* it’s updated the value. That means any consumer that got a stale reading will be woken up and can try again. Classic synchronization.
*   Third, and this is key, the actual data consumption itself in `evdev_read` is protected by `client->buffer_lock`. This means even if `poll` gets an older value, the read will be properly serialized.
*   Finally, the variable itself, `packet_head`, is a simple `unsigned int`. The race can't lead to any memory corruption, or crashes. I’m comfortable with this. It's a trade-off for performance that's carefully considered.