On Fri, 2016-09-30 at 01:28 +0200, Christian Lamparter wrote: > On Wednesday, September 28, 2016 7:20:39 PM CEST Jay Smith wrote: > > Actually, on a little more searching of this list's archives, I think > > that this discussion: https://patchwork.kernel.org/patch/9260733/ is > > about exactly the same issue I've found, except from the TCP side. I'm > > cc'ing a few of the participants from that discussion. > > > > So is the patch proposed there (copying and restoring the entire > > iov_iter in skb_copy_and_csum_datagram_msg()) being considered as a > > fix? > > From Alan's post: > > "My ugly patch fixes this in the most obvious way: make a local copy of > msg->msg_iter before the call to skb_copy_and_csum_datagram(), and copy > it back if the checksum is bad, just before goto csum_error;" > > IMHO this meant that the patch is a proof of concept for his problem. > > > If not, would an alternate one that concealed the save-and-restore logic > > inside iov_iter.c be more acceptable? I'd be happy to produce whatever's > > needed, or yield to someone with stronger feelings about where it should > > go... > Al Viro identified more inconsistencies within the error-paths that deal > with EFAULT in the whole area (in and around skb_copy_and_csum_datagram()). > > As far as I can tell the original discussion about the data corruption > issue went off on a tangent and it is stuck in figuring out "How to handle > the errors in tcp_copy_to_iovec()". > > As for fixing the issue: I'm happy to test and review patches. > The trouble is that nobody seem to be able to produce them... >
This is doable with a bit of fault injection I believe. And "ethtool -K eth0 rx off gro off lro off" to let the TCP receiver compute the checksum itself.
