> This prevents an issue where an ACK is delayed, a retransmit is queued (either > at the RPC or TCP level) and the ACK arrives before the retransmission hits the > wire. If this happens to an NFS WRITE RPC then the write() system call > completes and the userspace process can continue, potentially modifying data > referenced by the retransmission before the retransmission occurs. The only problem I see is that the source address might get invalidated (assuming it is a user address mapped into kernel). Not sure what effect the fault would have... If it is an RPC retransmittion the NFS write won't be terminated by the RPC ACK (because it is a stale ACK) and the destination will see two copies of the NFS write. (This is quite common with NFS/UDP.) If it is a TCP retransmittion, then the receiving TCP stack will see it as duplicate data and discard the contents without passing them to RPC. Interrupting an NFS write with a signal is problematic anyway - I'm sure I've seen systems (SYSV?) when NFS writes were uninterruptable. NFI how Linux handles this. David -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
