On Wed, Jul 11, 2018 at 07:20:02PM +0200, Petr Malat wrote: > Hi! > > > $ ./a.out | ts "%H:%M:%S" # Empty lines added for readability > > > 10:45:46 Testing IPPROTO_SCTP on a blocking socket > > > 10:45:49 1st connect - rtn: -1 errno: 114 (Operation already in progress) > > > 10:45:49 2nd connect - rtn: -1 errno: 114 (Operation already in progress) > > > 10:45:49 Testing IPPROTO_TCP on a blocking socket > > > 10:46:52 1st connect - rtn: -1 errno: 110 (Connection timed out) > > > 10:47:55 2nd connect - rtn: -1 errno: 110 (Connection timed out) > > > > > This is the origional case, and I agree that it seems like SCTP is acting as a > > non-blocking socket here (I presume it returns EINPROGRESS immediately, rather > > than after some timeout value)? > It returns after a signal is handled - in my test the signal is > generated by alarm, but it doesn't matter what is the source of > the signal. > The blocking socket can be easilly identified by the return value > from sock_intr_errno, which is ERESTARTSYS for a blocking operation > and EINTR for a non-blocking one. > I can change my patch to free the association only if ERESTARTSYS > is returned. What do you think about it? > Petr > No, I don't think we should be freeing the association without taking direction from user space here, as I noted before. Neil -- 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
