linux-kernel - Re: [RESEND PATCH] fs/pipe: Introduce a check to skip sleeping processes during pipe read/write

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ee120531-5857-4bfc-908c-8a6f1f3e7385@colorfullife.com>
Date: Sun, 29 Dec 2024 13:41:17 +0100
From: Manfred Spraul <manfred@...orfullife.com>
To: Oleg Nesterov <oleg@...hat.com>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
 WangYuli <wangyuli@...ontech.com>,
 linux-fsdevel <linux-fsdevel@...r.kernel.org>,
 Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
 Christian Brauner <brauner@...nel.org>
Subject: Re: [RESEND PATCH] fs/pipe: Introduce a check to skip sleeping
 processes during pipe read/write

Hi Oleg,

On 12/29/24 12:57 PM, Oleg Nesterov wrote:
> On 12/28, Manfred Spraul wrote:
>> On 12/28/24 4:22 PM, Oleg Nesterov wrote:
>>> Now suppose that another CPU executes wake() between LOAD(CONDITION)
>>> and list_add(entry, head). With your patch wait() will miss the event.
>>> The same for __pollwait(), I think...
> ...
>
>> It could still work for prepare_to_wait and thus fs/pipe, since then the
>> smb_mb() in set_current_state prevents earlier execution.

 From now, I'll try to follow standard patterns:

every memory barrier must be paired. And adding barriers to common 
functions for potentially rare situations is now allowed.

(unless it is a bugfix).

And then enumerate all codepaths:

For the wait_event users: We have a smp_mb() in prepare_to_wait(), it 
could pair with the barrier in wq_has_sleepers().

> Not sure, please see the note about __pollwait() above.
>
> I think that your patch (and the original patch from WangYuli) has the same
> proble with pipe_poll()->poll_wait()->__pollwait().

What is the memory barrier for pipe_poll()?

There is poll_wait()->__pollwait()->add_wait_queue()->spin_unlock(). 
thus only store_release.

And then READ_ONCE(), i.e. no memory barrier.

Thus the CPU would be free to load pipe->head and pipe->tail before 
adding the entry to the poll table.

Correct?

--

     Manfred