syzbot

unknown

map[Benign:true Explanation:The KCSAN data race report is consistent and points to a race between `pipe_poll` (reader) and `pipe_release` (writer) on the `pipe->readers` field.

**Analysis:**
1.  **Code Locations:**
    *   `pipe_poll` at `fs/pipe.c:702`: Reads `pipe->readers` in `if (!pipe->readers)` to determine if `EPOLLERR` should be set. This access is performed without holding `pipe->mutex`.
    *   `pipe_release` at `fs/pipe.c:731` (approx): Decrements `pipe->readers` (read-modify-write) while holding `pipe->mutex`. The stack trace confirms `pipe_release` is executing the file release path (`__fput`).

2.  **Shared Variable:**
    *   Both functions access the same memory address (`0xffff8881609948a4`) with a size of 4 bytes.
    *   `pipe->readers` is an `unsigned int` field in `struct pipe_inode_info`.
    *   The "value changed" (1 -> 0) matches the decrement logic in `pipe_release` when the last reader closes the pipe.

3.  **Benign vs. Harmful:**
    *   **Intentional Race:** The comment in `pipe_poll` explicitly states: *"Reading pipe state only -- no need for acquiring the semaphore."* and *"But because this is racy, the code has to add the entry to the poll table _first_ ... and only then can you do the racy tests."*
    *   **Correctness Logic:** The `pipe_poll` function adds the calling process to the wait queue *before* reading `pipe->readers`.
        *   If `pipe_poll` sees the old value (1) while `pipe_release` is changing it to 0, `pipe_poll` might momentarily miss the `EPOLLERR` condition.
        *   However, `pipe_release` subsequently calls `wake_up_interruptible_all`, which wakes up the poller.
        *   Upon waking, `pipe_poll` runs again and will see the new value (0), correctly setting `EPOLLERR`.
    *   **No Corruption/Crash:** The race is on a simple integer counter. Accesses to aligned integers are atomic on x86 (and most architectures supported by Linux). There is no risk of memory corruption or pointer invalidation.
    *   **Prompt Definition:** The race fits the prompt's definition of "benign": it is on a simple integer field, and the reader access is intentionally not protected by mutual exclusion. It does not lead to corruption or a crash.

While the access in `pipe_poll` should technically be annotated with `READ_ONCE(pipe->readers)` to document the data race and prevent theoretical compiler optimizations (and silence KCSAN), the underlying logic is robust. Therefore, the race is classified as benign in the context of stability and correctness.

**Result:**
The report is consistent, but the data race is **benign**.]

unknown

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

unknown

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

unknown

map[Index:codesearch-index]

unknown

map[Benign:true]

You are an experienced Linux kernel developer tasked with determining if the given kernel bug
report is actionable or not. Actionable means that it contains enough info to root cause
the underlying bug, and that the report is self-consistent and makes sense, rather than
a one-off nonsensical crash induced by a previous memory corruption.

Use the provided tools to confirm any assumptions, what 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.

The bug report is a data race report from KCSAN tool.
It contains 2 stack traces of the memory accesses that constitute a data race.
The report would be inconsistent, if the stacks point to different subsystems,
or if they access different fields.
The report would be non-actionable, if the underlysing data race is "benign".
That is, the race is on a simple int/bool 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.
An actionable race is "harmful", that is 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 report is consistent and the data race is harmful.


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 bug report is:

==================================================================
BUG: KCSAN: data-race in pipe_poll / pipe_release

read-write to 0xffff8881609948a4 of 4 bytes by task 10024 on cpu 1:
 pipe_release+0x6e/0x1d0 fs/pipe.c:731
 __fput+0x29b/0x650 fs/file_table.c:468
 ____fput+0x1c/0x30 fs/file_table.c:496
 task_work_run+0x131/0x1a0 kernel/task_work.c:227
 resume_user_mode_work include/linux/resume_user_mode.h:50 [inline]
 exit_to_user_mode_loop+0xed/0x110 kernel/entry/common.c:43
 exit_to_user_mode_prepare include/linux/irq-entry-common.h:225 [inline]
 syscall_exit_to_user_mode_work include/linux/entry-common.h:175 [inline]
 syscall_exit_to_user_mode include/linux/entry-common.h:210 [inline]
 do_syscall_64+0x1d6/0x200 arch/x86/entry/syscall_64.c:100
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

read to 0xffff8881609948a4 of 4 bytes by task 18582 on cpu 0:
 pipe_poll+0x215/0x250 fs/pipe.c:702
 vfs_poll include/linux/poll.h:82 [inline]
 aio_poll_complete_work+0xd4/0x350 fs/aio.c:1733
 process_one_work kernel/workqueue.c:3263 [inline]
 process_scheduled_works+0x4ce/0x9d0 kernel/workqueue.c:3346
 worker_thread+0x582/0x770 kernel/workqueue.c:3427
 kthread+0x489/0x510 kernel/kthread.c:463
 ret_from_fork+0x122/0x1b0 arch/x86/kernel/process.c:158
 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245

value changed: 0x00000001 -> 0x00000000

Reported by Kernel Concurrency Sanitizer on:
CPU: 0 UID: 0 PID: 18582 Comm: kworker/0:1 Tainted: G        W           syzkaller #0 PREEMPT(voluntary) 
Tainted: [W]=WARN
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/02/2025
Workqueue: events aio_poll_complete_work
==================================================================

The KCSAN data race report is consistent and points to a race between `pipe_poll` (reader) and `pipe_release` (writer) on the `pipe->readers` field.

**Analysis:**
1.  **Code Locations:**
    *   `pipe_poll` at `fs/pipe.c:702`: Reads `pipe->readers` in `if (!pipe->readers)` to determine if `EPOLLERR` should be set. This access is performed without holding `pipe->mutex`.
    *   `pipe_release` at `fs/pipe.c:731` (approx): Decrements `pipe->readers` (read-modify-write) while holding `pipe->mutex`. The stack trace confirms `pipe_release` is executing the file release path (`__fput`).

2.  **Shared Variable:**
    *   Both functions access the same memory address (`0xffff8881609948a4`) with a size of 4 bytes.
    *   `pipe->readers` is an `unsigned int` field in `struct pipe_inode_info`.
    *   The "value changed" (1 -> 0) matches the decrement logic in `pipe_release` when the last reader closes the pipe.

3.  **Benign vs. Harmful:**
    *   **Intentional Race:** The comment in `pipe_poll` explicitly states: *"Reading pipe state only -- no need for acquiring the semaphore."* and *"But because this is racy, the code has to add the entry to the poll table _first_ ... and only then can you do the racy tests."*
    *   **Correctness Logic:** The `pipe_poll` function adds the calling process to the wait queue *before* reading `pipe->readers`.
        *   If `pipe_poll` sees the old value (1) while `pipe_release` is changing it to 0, `pipe_poll` might momentarily miss the `EPOLLERR` condition.
        *   However, `pipe_release` subsequently calls `wake_up_interruptible_all`, which wakes up the poller.
        *   Upon waking, `pipe_poll` runs again and will see the new value (0), correctly setting `EPOLLERR`.
    *   **No Corruption/Crash:** The race is on a simple integer counter. Accesses to aligned integers are atomic on x86 (and most architectures supported by Linux). There is no risk of memory corruption or pointer invalidation.
    *   **Prompt Definition:** The race fits the prompt's definition of "benign": it is on a simple integer field, and the reader access is intentionally not protected by mutual exclusion. It does not lead to corruption or a crash.

While the access in `pipe_poll` should technically be annotated with `READ_ONCE(pipe->readers)` to document the data race and prevent theoretical compiler optimizations (and silence KCSAN), the underlying logic is robust. Therefore, the race is classified as benign in the context of stability and correctness.

**Result:**
The report is consistent, but the data race is **benign**.

unknown

unknown

map[IncludeLines:true Name:pipe_release SourceFile:fs/pipe.c]

map[Missing:false SourceCode: 723:	static int
 724:	pipe_release(struct inode *inode, struct file *file)
 725:	{
 726:		struct pipe_inode_info *pipe = file->private_data;
 727:	
 728:		mutex_lock(&pipe->mutex);
 729:		if (file->f_mode & FMODE_READ)
 730:			pipe->readers--;
 731:		if (file->f_mode & FMODE_WRITE)
 732:			pipe->writers--;
 733:	
 734:		/* Was that the last reader or writer, but not the other side? */
 735:		if (!pipe->readers != !pipe->writers) {
 736:			wake_up_interruptible_all(&pipe->rd_wait);
 737:			wake_up_interruptible_all(&pipe->wr_wait);
 738:			kill_fasync(&pipe->fasync_readers, SIGIO, POLL_IN);
 739:			kill_fasync(&pipe->fasync_writers, SIGIO, POLL_OUT);
 740:		}
 741:		mutex_unlock(&pipe->mutex);
 742:	
 743:		put_pipe_info(inode, pipe);
 744:		return 0;
 745:	}
 SourceFile:fs/pipe.c]

unknown

map[IncludeLines:true Name:pipe_poll SourceFile:fs/pipe.c]

map[Missing:false SourceCode: 657:	/* No kernel lock held - fine */
 658:	static __poll_t
 659:	pipe_poll(struct file *filp, poll_table *wait)
 660:	{
 661:		__poll_t mask;
 662:		struct pipe_inode_info *pipe = filp->private_data;
 663:		union pipe_index idx;
 664:	
 665:		/* Epoll has some historical nasty semantics, this enables them */
 666:		WRITE_ONCE(pipe->poll_usage, true);
 667:	
 668:		/*
 669:		 * Reading pipe state only -- no need for acquiring the semaphore.
 670:		 *
 671:		 * But because this is racy, the code has to add the
 672:		 * entry to the poll table _first_ ..
 673:		 */
 674:		if (filp->f_mode & FMODE_READ)
 675:			poll_wait(filp, &pipe->rd_wait, wait);
 676:		if (filp->f_mode & FMODE_WRITE)
 677:			poll_wait(filp, &pipe->wr_wait, wait);
 678:	
 679:		/*
 680:		 * .. and only then can you do the racy tests. That way,
 681:		 * if something changes and you got it wrong, the poll
 682:		 * table entry will wake you up and fix it.
 683:		 */
 684:		idx.head_tail = READ_ONCE(pipe->head_tail);
 685:	
 686:		mask = 0;
 687:		if (filp->f_mode & FMODE_READ) {
 688:			if (!pipe_empty(idx.head, idx.tail))
 689:				mask |= EPOLLIN | EPOLLRDNORM;
 690:			if (!pipe->writers && filp->f_pipe != pipe->w_counter)
 691:				mask |= EPOLLHUP;
 692:		}
 693:	
 694:		if (filp->f_mode & FMODE_WRITE) {
 695:			if (!pipe_full(idx.head, idx.tail, pipe->max_usage))
 696:				mask |= EPOLLOUT | EPOLLWRNORM;
 697:			/*
 698:			 * Most Unices do not set EPOLLERR for FIFOs but on Linux they
 699:			 * behave exactly like pipes for poll().
 700:			 */
 701:			if (!pipe->readers)
 702:				mask |= EPOLLERR;
 703:		}
 704:	
 705:		return mask;
 706:	}
 SourceFile:fs/pipe.c]

unknown

unknown

map[IncludeLines:false Name:struct pipe_inode_info SourceFile:include/linux/pipe_fs_i.h]

map[Missing:true SourceCode: SourceFile:]

unknown

unknown

map[SourceFile:fs/pipe.c]

map[Entities:[map[Kind:function Name:__do_pipe_flags] map[Kind:function Name:__do_sys_pipe] map[Kind:function Name:__do_sys_pipe] map[Kind:function Name:__do_sys_pipe2] map[Kind:function Name:__do_sys_pipe2] map[Kind:function Name:__ia32_sys_pipe] map[Kind:function Name:__ia32_sys_pipe2] map[Kind:function Name:__se_sys_pipe] map[Kind:function Name:__se_sys_pipe2] map[Kind:function Name:__x64_sys_pipe] map[Kind:function Name:__x64_sys_pipe2] map[Kind:function Name:account_pipe_buffers] map[Kind:function Name:alloc_pipe_info] map[Kind:function Name:anon_pipe_buf_release] map[Kind:function Name:anon_pipe_buf_try_steal] map[Kind:function Name:anon_pipe_get_page] map[Kind:function Name:anon_pipe_put_page] map[Kind:function Name:anon_pipe_read] map[Kind:function Name:anon_pipe_write] map[Kind:function Name:create_pipe_files] map[Kind:function Name:do_pipe2] map[Kind:function Name:do_pipe_flags] map[Kind:function Name:do_proc_dopipe_max_size_conv] map[Kind:function Name:fifo_open] map[Kind:function Name:fifo_pipe_read] map[Kind:function Name:fifo_pipe_write] map[Kind:function Name:free_pipe_info] map[Kind:function Name:generic_pipe_buf_get] map[Kind:function Name:generic_pipe_buf_get] map[Kind:function Name:generic_pipe_buf_release] map[Kind:function Name:generic_pipe_buf_release] map[Kind:function Name:generic_pipe_buf_try_steal] map[Kind:function Name:generic_pipe_buf_try_steal] map[Kind:function Name:get_pipe_info] map[Kind:function Name:get_pipe_inode] map[Kind:function Name:init_pipe_fs] map[Kind:function Name:is_packetized] map[Kind:function Name:pipe_double_lock] map[Kind:function Name:pipe_fasync] map[Kind:function Name:pipe_fcntl] map[Kind:function Name:pipe_ioctl] map[Kind:function Name:pipe_is_unprivileged_user] map[Kind:function Name:pipe_lock] map[Kind:function Name:pipe_lock] map[Kind:function Name:pipe_poll] map[Kind:function Name:pipe_readable] map[Kind:function Name:pipe_release] map[Kind:function Name:pipe_resize_ring] map[Kind:function Name:pipe_set_size] map[Kind:function Name:pipe_unlock] map[Kind:function Name:pipe_unlock] map[Kind:function Name:pipe_update_tail] map[Kind:function Name:pipe_wait_readable] map[Kind:function Name:pipe_wait_writable] map[Kind:function Name:pipe_writable] map[Kind:function Name:pipefs_dname] map[Kind:function Name:pipefs_init_fs_context] map[Kind:function Name:proc_dopipe_max_size] map[Kind:function Name:put_pipe_info] map[Kind:function Name:round_pipe_size] map[Kind:function Name:too_many_pipe_buffers_hard] map[Kind:function Name:too_many_pipe_buffers_soft] map[Kind:function Name:wait_for_partner] map[Kind:function Name:wake_up_partner]] Missing:false]

unknown

unknown

map[IncludeLines:false Name:pipe_poll SourceFile:fs/pipe.c]

map[Missing:false SourceCode:/* No kernel lock held - fine */
static __poll_t
pipe_poll(struct file *filp, poll_table *wait)
{
	__poll_t mask;
	struct pipe_inode_info *pipe = filp->private_data;
	union pipe_index idx;

	/* Epoll has some historical nasty semantics, this enables them */
	WRITE_ONCE(pipe->poll_usage, true);

	/*
	 * Reading pipe state only -- no need for acquiring the semaphore.
	 *
	 * But because this is racy, the code has to add the
	 * entry to the poll table _first_ ..
	 */
	if (filp->f_mode & FMODE_READ)
		poll_wait(filp, &pipe->rd_wait, wait);
	if (filp->f_mode & FMODE_WRITE)
		poll_wait(filp, &pipe->wr_wait, wait);

	/*
	 * .. and only then can you do the racy tests. That way,
	 * if something changes and you got it wrong, the poll
	 * table entry will wake you up and fix it.
	 */
	idx.head_tail = READ_ONCE(pipe->head_tail);

	mask = 0;
	if (filp->f_mode & FMODE_READ) {
		if (!pipe_empty(idx.head, idx.tail))
			mask |= EPOLLIN | EPOLLRDNORM;
		if (!pipe->writers && filp->f_pipe != pipe->w_counter)
			mask |= EPOLLHUP;
	}

	if (filp->f_mode & FMODE_WRITE) {
		if (!pipe_full(idx.head, idx.tail, pipe->max_usage))
			mask |= EPOLLOUT | EPOLLWRNORM;
		/*
		 * Most Unices do not set EPOLLERR for FIFOs but on Linux they
		 * behave exactly like pipes for poll().
		 */
		if (!pipe->readers)
			mask |= EPOLLERR;
	}

	return mask;
}
 SourceFile:fs/pipe.c]

unknown

unknown

map[SourceFile:include/linux/pipe_fs_i.h]

map[Entities:[map[Kind:function Name:account_pipe_buffers] map[Kind:function Name:alloc_pipe_info] map[Kind:function Name:create_pipe_files] map[Kind:function Name:free_pipe_info] map[Kind:function Name:generic_pipe_buf_get] map[Kind:function Name:generic_pipe_buf_release] map[Kind:function Name:generic_pipe_buf_try_steal] map[Kind:function Name:get_pipe_info] map[Kind:function Name:pipe_buf] map[Kind:function Name:pipe_buf_confirm] map[Kind:function Name:pipe_buf_get] map[Kind:function Name:pipe_buf_release] map[Kind:function Name:pipe_buf_try_steal] map[Kind:function Name:pipe_buf_usage] map[Kind:function Name:pipe_double_lock] map[Kind:function Name:pipe_empty] map[Kind:function Name:pipe_fcntl] map[Kind:function Name:pipe_full] map[Kind:function Name:pipe_has_watch_queue] map[Kind:function Name:pipe_head_buf] map[Kind:function Name:pipe_is_empty] map[Kind:function Name:pipe_is_full] map[Kind:function Name:pipe_is_unprivileged_user] map[Kind:function Name:pipe_lock] map[Kind:function Name:pipe_occupancy] map[Kind:function Name:pipe_resize_ring] map[Kind:function Name:pipe_unlock] map[Kind:function Name:pipe_wait_readable] map[Kind:function Name:pipe_wait_writable] map[Kind:function Name:round_pipe_size] map[Kind:function Name:too_many_pipe_buffers_hard] map[Kind:function Name:too_many_pipe_buffers_soft]] Missing:false]

unknown

unknown

map[IncludeLines:true Name:pipe_empty SourceFile:include/linux/pipe_fs_i.h]

map[Missing:false SourceCode: 188:	/**
 189:	 * pipe_empty - Return true if the pipe is empty
 190:	 * @head: The pipe ring head pointer
 191:	 * @tail: The pipe ring tail pointer
 192:	 */
 193:	static inline bool pipe_empty(unsigned int head, unsigned int tail)
 194:	{
 195:		return !pipe_occupancy(head, tail);
 196:	}
 SourceFile:include/linux/pipe_fs_i.h]

unknown

unknown

map[IncludeLines:true Name:pipe_lock SourceFile:include/linux/pipe_fs_i.h]

map[Missing:false SourceCode: 314:	/* Pipe lock and unlock operations */
 315:	void pipe_lock(struct pipe_inode_info *);
 SourceFile:include/linux/pipe_fs_i.h]

unknown

unknown

map[IncludeLines:true Name:pipe_inode_info SourceFile:include/linux/pipe_fs_i.h]

map[Missing:true SourceCode: SourceFile:]

unknown

unknown

map[Benign:true]

map[Benign:true]

unknown