On Fri, Nov 11, 2011 at 01:20:27PM +0000, Ian Campbell wrote: > On Fri, 2011-11-11 at 12:38 +0000, Michael S. Tsirkin wrote: > > On Wed, Nov 09, 2011 at 03:02:07PM +0000, Ian Campbell wrote: > > > 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. > > > > > > Signed-off-by: Ian Campbell <ian.campbell@xxxxxxxxxx> > > > Acked-by: Trond Myklebust <Trond.Myklebust@xxxxxxxxxx> > > > Cc: "David S. Miller" <davem@xxxxxxxxxxxxx> > > > Cc: Neil Brown <neilb@xxxxxxx> > > > Cc: "J. Bruce Fields" <bfields@xxxxxxxxxxxx> > > > Cc: linux-nfs@xxxxxxxxxxxxxxx > > > Cc: netdev@xxxxxxxxxxxxxxx > > > > So this blocks the system call until all page references > > are gone, right? > > Right. The alternative is to return to userspace while the network stack > still has a reference to the buffer which was passed in -- that's the > exact class of problem this patch is supposed to fix. > > > But, there's no upper limit on how long the > > page is referenced, correct? > > Correct. > > > consider a bridged setup > > with an skb queued at a tap device - this cause one process > > to block another one by virtue of not consuming a cloned skb? > > Hmm, yes. > > One approach might be to introduce the concept of an skb timeout to the > stack as a whole and cancel (or deep copy) after that timeout occurs. > That's going to be tricky though I suspect... > > A simpler option would be to have an end points such as a tap device > which can swallow skbs for arbitrary times implement a policy in this > regard, either to deep copy or drop after a timeout? Stupid question: Is it a requirement that you be safe against DOS by a rogue process with a tap device? (And if so, does current code satisfy that requirement?) --b. -- 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
