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.
