I agree with the gist of your analysis.
And it seems that Apache does try to use the deferred accept socket
option. So we may indeed have a hit on this IA64 bug.
The wording in the report about versions is a little confusing:
With kernel 2.6.26-rc5 and a git kernel just between rc4
and rc5, my kernel panic...
Does this mean that the problem appeared between rc4 and rc5? Or
that all 2.6.26-rcX releases have the problem? That's an important
fact because the change in question showed up in 2.6.26-rc1, as it
came in the inital networking merge for the 2.6.26 merge window.
Because of the requirements to trigger the new code, this case is
not likely to match the revert. SSH absolutely does not use the
deferred accept socket option.
Let's look at the change in question.
Every single code path touched in the data paths are guarded
with "tp->defer_tcp_accept.request" which will be NULL unless
1) defer-accept socket option enabled and 2) a new connection
got queued up there.
Nothing about the normal accept queue handling got modified by those
changes which were reverted.
And note that this means the behavior change only hits listening
sockets. So if we have a report that client outgoing SSH
connections hang with the current kernel, that report cannot
reasonably match this revert.
I also anticipate that if this change could trigger problems for
non-deferred-accept cases, we'd see a ton more reports than we have.
And we did some research and one of the only major servers that use
this obscure defer-accept feature is distcc and apache. It is this
element of Ingo's bug report (that he uses distcc heavily and it was a
distcc socket which hung) that helped us narrow things down.
The SSH report clearly states "With kernel 2.6.26-rc5, ssh connections
to _remote_ servers randomly hang". So this is a report about SSH
client connections under 2.6.26-rc5, not SSH server connections and
therefore not listening sockets.
So right now I'd say that the IA64 case could definitely be a match
but the SSH case very much is not.
--
