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
