>> in case [1], user can't see the ENOMEM, ENOMEM is more like >> a internal err. >> > > Still not clear. Are you saying, say an old kernel like 3.11 would > not return the user ENOMEN for the use case[1] you fixed? I am not > talking post your fix. Sorry for confusing you. 3.11 would return the user ENOMEN for the use case[1]. but this behavior is incorrect, it's not consistent with tcp. > >> in case [2], user will got the ENOMEM, they should resend this msg, >> It's the the general case mentioned-above >> > > I am trying to see if we can avoid backporting this fix to 3.11. > In [1], is ENOMEM propagated to user space (dont talk about your > fix, I mean pre-your-fix). yes, in [1], pre-my-fix, ENOMEM is propagated to user space. > > >> here sctp's behavior is actually same with tcp's, in tcp, tcp_transmit_skb >> also may fail to alloc skb, but it doesn't return any err to user, just >> like >> sctp_packet_transmit. That's why I don't think we should change something >> in manpage, as here sctp is consistent with tcp now. >> >> make sense ? > > > No ;-> The manpage is bad. Go look at it. In the case of ENOBUFS or > EMSGSIZE it is clear what needs to be done. > If the answer is _on ENOMEM_ user must resend then thats what we need > to say. yes, on ENOMEM user must resend if he want send out this msg successfully. -- To unsubscribe from this list: send the line "unsubscribe linux-sctp" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
