> I think the specific use case this patch addresses > seems to have bitten us in an older kernel sctp (3.11?). > A send() on a loaded network box caused the skb to > alloc in what appears to be this code path and fail (problem > is intermittent, so not 100% sure). errno seen was ENOMEM. > Unfortunately the manpage for sendxxx sucks. > It says "no memory available". > [We'll fix the manpage if there is an appropriate answer]. > > Two questions: > a) Seems like we can safely ignore ENOMEM in user space > at least for this use case. i.e the kernel will retry and > eventually send this message. Is there any other scenario > where we have to worry about ENOMEM showing up in user space? > > b) What is the general view of what sendXXX reaction oughta > be from user space in presence of ENOMEM? > This patch doesn't ignore all the ENOMEN cases, only after msg is enqueued in out queue/send queue, in the lower layer, when alloc new skb and copy data from old skb, if it fails to alloc new skb, sctp will ignore this ENOMEM, as this msg will be taken care by retransmit mechanism, it's reasonable and also safe, user can't feel that. But for the cases before enqueue, like in sctp_sendmsg, sctp_datamsg_from_user may return ENOMEM, this err will return back to user, and can't be ignored. So I don't really think we should change something in manpage, what do you think ? maybe a little explanation there is also nice, :) -- 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
