Bug 539560

Description of problem:

rpc xprt re-connections over tcp can have trash in the initial fsinfo
if the new connection has not negotiated tcp options, e.g. timestamp,
but the previous connection had negotiated tcp option. What it takes
to have this happen is a clustered server failover where the original
server negotiates timestamps and the new one does not. If the original
connection is nuked from an RST [e.g. from the new server], the logic
in tcp_disconnect() [via xprt connect to AF_UNSPEC before re-connecting
the same socket], the bits in tp->rx_opt are not reset (as they would
be if the original socket were tossed and a new one is created).

This manifests as checksum problems in the first FSINFO packet
because while th_off is 5 [from syn-ack negotiation] the bits
that control the tcp build options can still be set overwriting
the bytes in the beginning of the fsinfo packet and botching
the already computed checksums. What happens is that the packets
are dropped on the other side due to checksum failures. tcp resends
the same packet, but each time it is slightly different due to
timestamp option values. Eventually the connection times out
since the peer never acks the bogus packets.

There is a fix in 2.6.22 upstream that fixes this case.

See the commit for [TCP]: zero out rx_opt in tcp_disconnect().
The commit is b40b4f79ce789e9e28d382c85006f62be2725282.


Version-Release number of selected component (if applicable):


How reproducible:

Not trivial, but the corruption in the outbound fsinfo packet is
very predictable when it happens. This would also affect a user
program if it were emulating the re-use same privileged source
port options and when the connection breaks due to the RST, it
then connects to AF_UNSPEC and then re-connects to the same
destination address. It is not nfs/rpc specific, but impacts
the kernel nfs client badly when it hits.

Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info: