kern: soclose: don't sleep on SO_LINGER w/ timeout=0

[kevans]

Summary

This is a valid scenario that's handled in the various protocol layers where it makes sense (e.g., tcp_disconnect and sctp_disconnect).

This lead to panics with INVARIANTS, and on non-INVARIANTS would result in the thread hanging until a signal interrupts it.

Reported by: [e-mail]

[markj]

It might be worthwhile to update the setsockopt(2) man page clarifying the behaviour of so_linger == 0.

[kevans]

In D27407#612263, @markj wrote:

It might be worthwhile to update the setsockopt(2) man page clarifying the behaviour of so_linger == 0.

Sure- I'll follow up with a manpage update... I'm looking at how we're handling the non-0 case, and I think it also needs a little re-working to handle some corner case. Right now we'll wait up until the linger interval has elapsed unless we see a wakeup on so->so_timeo, at which point we'll again wait until the entirety of the linger interval has elapsed again -- but any scenario that leaves me blocked for any significant amount over the linger interval would be surprising to me as an application developer.

My gut reaction is that we should probably be tracking how long we've slept thus far in case we've been woken up by some path other than soisdisconnected(), or we should make it clear why we would expect to get woken up early enough that the discrepancy is not a concern.

[markj]

In D27407#612458, @kevans wrote:

In D27407#612263, @markj wrote:

It might be worthwhile to update the setsockopt(2) man page clarifying the behaviour of so_linger == 0.

Sure- I'll follow up with a manpage update... I'm looking at how we're handling the non-0 case, and I think it also needs a little re-working to handle some corner case. Right now we'll wait up until the linger interval has elapsed unless we see a wakeup on so->so_timeo, at which point we'll again wait until the entirety of the linger interval has elapsed again -- but any scenario that leaves me blocked for any significant amount over the linger interval would be surprising to me as an application developer.

How do we get a spurious wakeup? It looks like we're specifically waiting for the transition to SS_ISDISCONNECTED. At the point where we're sleeping, a disconnect has already been initiated. I don't see anything in the TCP or SCTP code that would wake us up for any other reason.

My gut reaction is that we should probably be tracking how long we've slept thus far in case we've been woken up by some path other than soisdisconnected(), or we should make it clear why we would expect to get woken up early enough that the discrepancy is not a concern.

[kevans]

In D27407#612683, @markj wrote:

In D27407#612458, @kevans wrote:

In D27407#612263, @markj wrote:

It might be worthwhile to update the setsockopt(2) man page clarifying the behaviour of so_linger == 0.

Sure- I'll follow up with a manpage update... I'm looking at how we're handling the non-0 case, and I think it also needs a little re-working to handle some corner case. Right now we'll wait up until the linger interval has elapsed unless we see a wakeup on so->so_timeo, at which point we'll again wait until the entirety of the linger interval has elapsed again -- but any scenario that leaves me blocked for any significant amount over the linger interval would be surprising to me as an application developer.

How do we get a spurious wakeup? It looks like we're specifically waiting for the transition to SS_ISDISCONNECTED. At the point where we're sleeping, a disconnect has already been initiated. I don't see anything in the TCP or SCTP code that would wake us up for any other reason.

This is part of my question as well... it's written as if it's possible, given the loop. Userland cannot call any of these so*() that might wake it up because the fd's already been removed, but I haven't dug into what else might call them in-kernel to determine if the state change is something that can safely be asserted on error == 0.

[markj]

In D27407#612688, @kevans wrote:

In D27407#612683, @markj wrote:

In D27407#612458, @kevans wrote:

In D27407#612263, @markj wrote:

It might be worthwhile to update the setsockopt(2) man page clarifying the behaviour of so_linger == 0.

Sure- I'll follow up with a manpage update... I'm looking at how we're handling the non-0 case, and I think it also needs a little re-working to handle some corner case. Right now we'll wait up until the linger interval has elapsed unless we see a wakeup on so->so_timeo, at which point we'll again wait until the entirety of the linger interval has elapsed again -- but any scenario that leaves me blocked for any significant amount over the linger interval would be surprising to me as an application developer.

How do we get a spurious wakeup? It looks like we're specifically waiting for the transition to SS_ISDISCONNECTED. At the point where we're sleeping, a disconnect has already been initiated. I don't see anything in the TCP or SCTP code that would wake us up for any other reason.

This is part of my question as well... it's written as if it's possible, given the loop. Userland cannot call any of these so*() that might wake it up because the fd's already been removed, but I haven't dug into what else might call them in-kernel to determine if the state change is something that can safely be asserted on error == 0.

My guess is that it was written that way defensively: if (<cond>) sleep-on-cond(); is a common programming mistake when the condition isn't sticky.

[kevans]

I've pushed the manpage change into D27472- thanks!