Re: [issue]: sockmap restrain send if receiver block

[John Fastabend <john.fastabend@gmail.com>]

zhengguoyong wrote:
> thanks for reply.
> 
> i mean the sk_msg with TCP protocol. in this case, sender use sk_stream_memory_free()
> to check if memory is free. and in __sk_stream_memory_free(), if
> sk->sk_wmem_queued is bigger then sk->sk_sndbuf or sk
> notsent_bytes(tp->write_seq - tp->snd_nxt) is too bigger then
> __sk_stream_memory_free() will return false and do sk_stream_wait_memory().
> 
> but in sk_msg mode, tcp_bpf_sendmsg() will not create skb structure and not use seq to
> recording sending info，so sk->sk_wmem_queued is not changed in tcp_bpf_sendmsg() path,
> and __sk_stream_memory_free() will always return true.
> 
> in bpf_tcp_ingress() will copy the sender msg and charge it, and in
> tcp_bpf_recvmsg(), it will uncharge the msg after sk_msg_recvmsg()
> receive it from psock ingress_msg queue, and if receiver is not to read again
> due to application bug, and sender continuous send, then the receiver
> psock ingress_msg queue will continuous increase and cannot be uncharged
> until tcp socket memory is not enough in the fllowing path.
> 
>     tcp_bpf_sendmsg
>         tcp_bpf_send_verdict
>             tcp_bpf_sendmsg_redir
>                 bpf_tcp_ingress
>                     sk_wmem_schedule

Shouldn't the sk_wmem_schedule push back through __sk_mem_schedule() and
cause us to return a ENOMEM here? The ENOMEM then will free the msg and
return ENOMEM all the way back through tcp_bpf_sendmsg and to the user
eventually. 

That sk_wmem_schedule() for ingress should be sk_rmem_schedule()?

I think the fix is to ensure that if we try to bpf_tcp_ingress onto a
receive socket that it pushes back if its memory limits are reached.

> 
> so if a sk_msg type sockmap receiver is block, then it may consume all the
> tcp socket memory and influence other tcp stream,
> can we limit per sockmap tcp stream link sk->sk_sndbuf ?
> 
> thanks.