From patchwork Mon Jan 24 17:47:52 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Michal Schmidt X-Patchwork-Id: 80221 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 96FC3B7127 for ; Tue, 25 Jan 2011 04:48:10 +1100 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752867Ab1AXRsF (ORCPT ); Mon, 24 Jan 2011 12:48:05 -0500 Received: from mx1.redhat.com ([209.132.183.28]:63117 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751882Ab1AXRsE (ORCPT ); Mon, 24 Jan 2011 12:48:04 -0500 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id p0OHlujr019291 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 24 Jan 2011 12:47:57 -0500 Received: from delilah (dhcp-27-113.brq.redhat.com [10.34.27.113]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id p0OHlsIV016059; Mon, 24 Jan 2011 12:47:54 -0500 Date: Mon, 24 Jan 2011 18:47:52 +0100 From: Michal Schmidt To: David Miller Cc: netdev@vger.kernel.org, Herbert Xu , Ben Hutchings Subject: [PATCH] GRO: fix merging a paged skb after non-paged skbs Message-ID: <20110124184752.1d0947dd@delilah> Organization: Red Hat Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Suppose that several linear skbs of the same flow were received by GRO. They were thus merged into one skb with a frag_list. Then a new skb of the same flow arrives, but it is a paged skb with data starting in its frags[]. Before adding the skb to the frag_list skb_gro_receive() will of course adjust the skb to throw away the headers. It correctly modifies the page_offset and size of the frag, but it leaves incorrect information in the skb: ->data_len is not decreased at all. ->len is decreased only by headlen, as if no change were done to the frag. Later in a receiving process this causes skb_copy_datagram_iovec() to return -EFAULT and this is seen in userspace as the result of the recv() syscall. In practice the bug can be reproduced with the sfc driver. By default the driver uses an adaptive scheme when it switches between using napi_gro_receive() (with skbs) and napi_gro_frags() (with pages). The bug is reproduced when under rx load with enough successful GRO merging the driver decides to switch from the former to the latter. Manual control is also possible, so reproducing this is easy with netcat: - on machine1 (with sfc): nc -l 12345 > /dev/null - on machine2: nc machine1 12345 < /dev/zero - on machine1: echo 1 > /sys/module/sfc/parameters/rx_alloc_method # use skbs echo 2 > /sys/module/sfc/parameters/rx_alloc_method # use pages - See that nc has quit suddenly. Signed-off-by: Michal Schmidt --- net/core/skbuff.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/net/core/skbuff.c b/net/core/skbuff.c index d31bb36..c231f5b 100644 --- a/net/core/skbuff.c +++ b/net/core/skbuff.c @@ -2746,7 +2746,7 @@ merge: if (offset > headlen) { skbinfo->frags[0].page_offset += offset - headlen; skbinfo->frags[0].size -= offset - headlen; - offset = headlen; + skb->data_len -= offset - headlen; } __skb_pull(skb, offset);