Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932842Ab3GDM5e (ORCPT ); Thu, 4 Jul 2013 08:57:34 -0400 Received: from mail.avalus.com ([89.16.176.221]:45561 "EHLO mail.avalus.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752186Ab3GDM5c (ORCPT ); Thu, 4 Jul 2013 08:57:32 -0400 Date: Thu, 04 Jul 2013 13:57:16 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Eric Dumazet , Ian Campbell cc: Joe Jin , Frank Blaschka , "David S. Miller" , linux-kernel@vger.kernel.org, netdev@vger.kernel.org, zheng.x.li@oracle.com, Xen Devel , Jan Beulich , Stefano Stabellini , Konrad Rzeszutek Wilk , Alex Bligh Subject: Re: kernel panic in skb_copy_bits Message-ID: <06F8DA5DD1D9E277F2AF6F1E@Ximines.local> In-Reply-To: <1372932730.4979.96.camel@edumazet-glaptop> References: <51CBAA48.3080802@oracle.com> <1372311118.3301.214.camel@edumazet-glaptop> <51CD0E67.4000008@oracle.com> <6BFD5AF235F72F13CE646A0D@nimrod.local> <51D0F514.3070309@oracle.com> <1372666283.14691.8.camel@zakaz.uk.xensource.com> <51D53896.1060405@oracle.com> <1372928382.7184.16.camel@kazak.uk.xensource.com> <1372930465.4979.82.camel@edumazet-glaptop> <1372931565.7184.32.camel@kazak.uk.xensource.com> <1372932730.4979.96.camel@edumazet-glaptop> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1763 Lines: 45 --On 4 July 2013 03:12:10 -0700 Eric Dumazet wrote: > It looks like a typical COW issue to me. > > If the page content is written while there is still a reference on this > page, we should allocate a new page and copy the previous content. > > And this has little to do with networking. I suspect this would get more attention if we could make Ian's case below trigger (a) outside Xen, (b) outside networking. > memset(buf, 0xaa, 4096); > write(fd, buf, 4096) > memset(buf, 0x55, 4096); > (where fd is O_DIRECT on NFS) Can result in 0x55 being seen on the wire > in the TCP retransmit. We know this should fail using O_DIRECT+NFS. We've had reports suggesting it fails in O_DIRECT+iSCSI. However, that's been with a kernel panic (under Xen) rather than data corruption as per the above. Historical trawling suggests this is an issue with DRDB (see Ian's original thread from the mists of time). I don't quite understand why we aren't seeing corruption with standard ATA devices + O_DIRECT and no Xen involved at all. My memory is a bit misty on this but I had thought the reason why this would NOT be solved simply by O_DIRECT taking a reference to the page was that the O_DIRECT I/O completed (and thus the reference would be freed up) before the networking stack had actually finished with the page. If the O_DIRECT I/O did not complete until the page was actually finished with, we wouldn't see the problem in the first place. I may be completely off base here. -- Alex Bligh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/