Re: [PATCH net-next] unix: Guarantee sk_state relevance in case of it was assigned by a task on other cpu

[Jakub Kicinski <kuba@kernel.org>]

On Thu, 26 Jan 2023 00:09:08 +0300 Kirill Tkhai wrote:
> 1)There are a many combinations with third task involved:
> 
> [CPU0:Task0]  [CPU1:Task1]                           [CPU2:Task2]
> listen(sk)
>               kernel:
>                 sk_diag_fill(sk)
>                   rep->udiag_state = TCP_LISTEN
>                 return_from_syscall
>               userspace:
>                 mutex_lock()
>                 shared_mem_var = rep->udiag_state 
>                 mutex_unlock()
> 
>                                                      userspace: 
>                                                        mutex_lock()
>                                                        if (shared_mem_var == TCP_LISTEN)
>                                                          accept(sk); /* -> fail, since sk_state is not visible */
>                                                        mutex_unlock()
> 
> In this situation Task2 definitely knows Task0's listen() has succeed, but there is no a possibility
> to guarantee its accept() won't fail. Despite there are appropriate barriers in mutex_lock() and mutex_unlock(),
> there is no a possibility to add a barrier on CPU1 to make Task0's store visible on CPU2.

Me trying to prove that memory ordering is transitive would be 100%
speculation. Let's ask Paul instead - is the above valid? Or the fact
that CPU1 observes state from CPU0 and is strongly ordered with CPU2
implies that CPU2 will also observe CPU0's state?

> 2)My understanding is chronologically later accept() mustn't miss sk_state.
> Otherwise, kernel says that ordering between internal syscalls data
> is userspace duty, which is wrong. Userspace knows nothing about internal
> kernel data.

> 3)Such possible situations in log file also look strange:

Dunno those points are a bit subjective. Squeezing perf out of
distributed systems requires sacrifices 🤷️