From nobody Sun May 19 05:51:08 2024 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9E451136E2D for ; Tue, 23 Apr 2024 13:47:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1713880062; cv=none; b=MbBH2BaI9tJ3sdSiCQMRPWZJ5eyEXGagjY4tl5HzXQTVCckoQd7iT3ls21haUvQkeD0V6AuXK2E3gwUogoWr+wPGDQAhgirneQ7BE30hlPKUr4iSuFxNndhRXIeAnYTVGkdZywtf6y7j5dKhfvBtc6GPvjrZ28cIfdGJtM0VuBE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1713880062; c=relaxed/simple; bh=SLVehTKF+44M8nOQRcYo9sNLtTeGWb/0pP2ZXk9JzXU=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=gRopgMmIUw37r2sjVgkOjFXEbBh66wZJMA2F0f4ghanslyCJzo8T7AcrLc+qIlMQU0wF2zyNFN6RisZ2/HSo/sVr3xtVzlwwmMat4feDMCSaKIrrlzk0jNBRxN3i/XaYqroPmJVgbPik/LJEnnxHSujy9+ju+qCCzXF/XXz9oso= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=g6uODNW+; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="g6uODNW+" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1713880059; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=hMZp7vYlgNuZhS/jUXjj83MHWi0SFemcDgb6WZEyykI=; b=g6uODNW+QBBIzKc2afziISnG2yyzqp6PfDKHBrTjKgrKKUu1QPgAOFnTDCAKpy9ywL+CfH PTdtAtbAp3nuJNukBy2lBMr7A6hkWa+Z5+ke1Oujz0m98OFj0RwrRpVBn9f353/4a+mvSU SIk8zG5aA6KyERf3S8CZGPB0wD2f2po= Received: from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-473-Rxv05-80N6mL9QIoHLVtCw-1; Tue, 23 Apr 2024 09:47:34 -0400 X-MC-Unique: Rxv05-80N6mL9QIoHLVtCw-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 4BAC13C3D0C5; Tue, 23 Apr 2024 13:47:33 +0000 (UTC) Received: from calimero.vinschen.de (unknown [10.39.194.197]) by smtp.corp.redhat.com (Postfix) with ESMTPS id DF92D200A5C5; Tue, 23 Apr 2024 13:47:32 +0000 (UTC) Received: by calimero.vinschen.de (Postfix, from userid 500) id 88233A80CED; Tue, 23 Apr 2024 15:47:31 +0200 (CEST) From: Corinna Vinschen To: netdev@vger.kernel.org, linux-kernel@vger.kernel.org, intel-wired-lan@lists.osuosl.org Cc: Nikolay Aleksandrov , Jason Xing , Paolo Abeni , Jakub Kicinski , Eric Dumazet , "David S . Miller" , Tony Nguyen , Jesse Brandeburg Subject: [PATCH net v2] igb: cope with large MAX_SKB_FRAGS Date: Tue, 23 Apr 2024 15:47:31 +0200 Message-ID: <20240423134731.918157-1-vinschen@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.4 Content-Type: text/plain; charset="utf-8" From: Paolo Abeni Sabrina reports that the igb driver does not cope well with large MAX_SKB_FRAG values: setting MAX_SKB_FRAG to 45 causes payload corruption on TX. An easy reproducer is to run ssh to connect to the machine. With MAX_SKB_FRAGS=3D17 it works, with MAX_SKB_FRAGS=3D45 it fails. The root cause of the issue is that the driver does not take into account properly the (possibly large) shared info size when selecting the ring layout, and will try to fit two packets inside the same 4K page even when the 1st fraglist will trump over the 2nd head. Address the issue forcing the driver to fit a single packet per page, leaving there enough room to store the (currently) largest possible skb_shared_info. Fixes: 3948b05950fd ("net: introduce a config option to tweak MAX_SKB_FRAG") Reported-by: Jan Tluka Reported-by: Jirka Hladky Reported-by: Sabrina Dubroca Tested-by: Sabrina Dubroca Tested-by: Corinna Vinschen Signed-off-by: Paolo Abeni --- v2: fix subject, add a simple reproducer drivers/net/ethernet/intel/igb/igb_main.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/ethernet/intel/igb/igb_main.c b/drivers/net/ethern= et/intel/igb/igb_main.c index a3f100769e39..22fb2c322bca 100644 --- a/drivers/net/ethernet/intel/igb/igb_main.c +++ b/drivers/net/ethernet/intel/igb/igb_main.c @@ -4833,6 +4833,7 @@ static void igb_set_rx_buffer_len(struct igb_adapter = *adapter, =20 #if (PAGE_SIZE < 8192) if (adapter->max_frame_size > IGB_MAX_FRAME_BUILD_SKB || + SKB_HEAD_ALIGN(adapter->max_frame_size) > (PAGE_SIZE / 2) || rd32(E1000_RCTL) & E1000_RCTL_SBP) set_ring_uses_large_buffer(rx_ring); #endif --=20 2.44.0