Re: [PATCH net] sctp: fix a success return may hide an error
From: Xin Long <lucien.xin@gmail.com>
Date: 2016-08-17 11:43:18
Also in:
linux-sctp
quoted
quoted
If letting the application see ENOMEM errors, and sctp has to drop this chunk, instead of retransmiting the ENOMEM chunk, but the ENOMEM chunk may not be the chunk from current msg, as it flush all the queue. even if users get an ENOMEM error, they may re-send a chunk that is same with the one that is still in retransmit queue.Yep, one more reason to handle those internally when safe.
I just checked tcp_sendmsg, it doesn't return any transmit error to user,
*NOT ONLY* ENOMEM. you can check __tcp_push_pending_frames
and tcp_push, their return type is even void. although it may get
err from sk->sk_err:
err = sk_stream_error(sk, flags, err);
But I didn't see it put any err into sk->sk_err in the main transmit
path.
yes, tcp_write_xmit has return value, as well as tcp_transmit_skb and
err = icsk->icsk_af_ops->queue_xmit(sk, skb, &inet->cork.fl). but
all of them are just used for internal, never return to userspace
In tcp_write_xmit, it even uses "unlikely':
if (unlikely(tcp_transmit_skb(sk, skb, 1, gfp)))
break;
Xin, maybe you can squash this patch and this ENOMEM handling? I'm thinking that handling ENOMEM may result in similar situations in other places, so we have a common reasoning on them.
So this reason does really matter, and not only for ENOMEM in transmit path.