Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753523Ab3GDKMP (ORCPT ); Thu, 4 Jul 2013 06:12:15 -0400 Received: from mail-pd0-f173.google.com ([209.85.192.173]:44414 "EHLO mail-pd0-f173.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750769Ab3GDKMN (ORCPT ); Thu, 4 Jul 2013 06:12:13 -0400 Message-ID: <1372932730.4979.96.camel@edumazet-glaptop> Subject: Re: kernel panic in skb_copy_bits From: Eric Dumazet To: Ian Campbell Cc: Joe Jin , Alex Bligh , 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 Date: Thu, 04 Jul 2013 03:12:10 -0700 In-Reply-To: <1372931565.7184.32.camel@kazak.uk.xensource.com> 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> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1531 Lines: 39 On Thu, 2013-07-04 at 10:52 +0100, Ian Campbell wrote: > Might just be that no one has observed it with vmsplice()+splice()? Most > of the time this happens silently and you'll probably never notice, it's > just the behaviour of Xen which escalates the issue into one you can > see. The point I wanted to make is that nobody can seriously use vmsplice(), unless the memory is never reused by the application, or the application doesn't care of security implications. Because an application has no way to know when it's safe to reuse the area for another usage. [ Unless it uses the obscure and complex pagemap stuff (Documentation/vm/pagemap.txt), but its not asynchronous signaling and not pluggable into epoll()/poll()/select()) ] > Xen's out of tree netback used to fix this by a destructor call back on > page free, but that was a core mm patch in the hot memory free path > which wasn't popular, and it doesn't solve anything for the non-Xen > instances of this issue. It _is_ a mm core patch which is needed, if we ever want to fix this problem. 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. -- 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/