Re: [PATCH v4] fs/pipe: unify the page pools into a single per-pipe pool

[Oleg Nesterov <oleg@redhat.com>]

On 07/20, Breno Leitao wrote:
>
> On Fri, Jul 17, 2026 at 06:19:45PM +0200, Oleg Nesterov wrote:
> >
> > And READ_ONCE() is enough correctness wise.
> >
> > But AFAIK it is not enough to make KCSAN happy. anon_pipe_prealloc_pop/push
> > which modify ->count under pipe->mutex need WRITE_ONCE() to please KCSAN.
> >
> > Or anon_pipe_prefill_and_lock() can use data_race(READ_ONCE()).
>
> I am not sure that is correct. I got the impression if the reading side
> has READ_ONCE or data_race(), that is enough to please KCSAN.

And quite possibly I am wrong! I was never able to convince myself I
understand the should_watch() logic. See below.

> I will respin with, an additional "__data_racy" attribute in `count`
>
>   struct anon_pipe_prealloc {
>     struct page *pages[PIPE_PREALLOC_MAX];
>     unsigned int __data_racy count;

Ah! I didn't even know we have __data_racy. Much better than what I suggested.
I see you have already sent V5 and it looks good to me.

----------------------------------------------------------------------------
But just for my education, let me abuse this thread and ask KCSAN maintainers
to shed a light...

Marco, Dmitry. to simplify, suppose we have something like

	int DATA;
	struct mutex LOCK;

	void set(void)
	{
		mutex_lock(&LOCK);
		DATA++;
		mutex_unlock(&LOCK);
	}

	int get(void)
	{
		return READ_ONCE(DATA);
	}

My understanding is that KCSAN can complain if get() races with set(),
READ_ONCE() in get() is not enough.

Is it correct?

Oleg.