[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AE90C24D6B3A694183C094C60CF0A2F6D8AEC1@saturn3.aculab.com>
Date: Mon, 14 Nov 2011 13:25:01 -0000
From: "David Laight" <David.Laight@...LAB.COM>
To: "Ian Campbell" <Ian.Campbell@...rix.com>,
"Michael S. Tsirkin" <mst@...hat.com>
Cc: <netdev@...r.kernel.org>, "David S. Miller" <davem@...emloft.net>,
"Neil Brown" <neilb@...e.de>,
"J. Bruce Fields" <bfields@...ldses.org>,
<linux-nfs@...r.kernel.org>
Subject: RE: [PATCH 4/4] sunrpc: use SKB fragment destructors to delay completion until page is released by network stack.
> 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 netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists