Received: by 2002:a05:6a10:6744:0:0:0:0 with SMTP id w4csp1128608pxu; Fri, 16 Oct 2020 04:47:55 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz+bzyYTnnkecp23PWU1vOxjaRSIzJJjG61FHD1Gdlh1cTpIybrOn/sPpG13tyNkymHDyYH X-Received: by 2002:a05:6402:396:: with SMTP id o22mr3337499edv.361.1602848875259; Fri, 16 Oct 2020 04:47:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1602848875; cv=none; d=google.com; s=arc-20160816; b=uOqN17+xzq2Cz7KthZ04lqd3ML3qvkzIZGT3fHZSAHQdsLhAcBW2tqtifvmhFlVsyS O1ksze9Emi6NFKvQFxies1WGP8eCDHr7BF7di4mK1J05J0/ICqxB6ln/4w0YjVq2KgqQ A0kSXa/0oOYt1+ZJp7aYJyOMPQSsEhgUGGJP7nWAHiFg4J8/Ho+I/+kw80cNXheT68yu JoyPRWRXsA4l2KjBP5M+6oGwR4n6u8KRlfI9/4bt4DTCWpoXfels5t7CgbIPfT7dikTC c3DTbipT2DcxaI2uTFhtuvo7MrrAq0pRoaaQW0v/5pabcK53RmIXoWYwztVHUmHVMtZV Qa6Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:organization:message-id:date:subject:cc:to :from; bh=P+JOIRCDciF8TKYQ1UwBS4bm2GVDjKyDFqi6t2FhX7w=; b=X5utjx0cKHxwgAbg099nJGS5euqxM2DHJg46TsNW0xoQgboTi8lk1pX88LnJ4sOwcT O8kmg6TfuNjbHbxOsceO9oETHQCoLVRUGCBOtqhKx3ybq1r7Mmrqm4H7z/H2ZbgzuYxC 0xVsV9Y2NTQEKf/rmm3Y1iRIVaOOCeh0OW9zcvXqFxcV3XrjHsSzmocjnwvc9wq6SW0D oBmO99TSpIk8Ca77pw3oPMNcSANJ2lzegjkXEHRuKG6B4kQm244coEk+L6Ayxz6OAuJj cN6tVslMALVVw/SZ5VtkXOZGuv+sj+se+fZL48EL8lSjT8oIka7o974iYvOESmv4mdof sBxA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id pw16si1510494ejb.430.2020.10.16.04.47.32; Fri, 16 Oct 2020 04:47:55 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2394863AbgJPJBS (ORCPT + 99 others); Fri, 16 Oct 2020 05:01:18 -0400 Received: from mailout08.rmx.de ([94.199.90.85]:37589 "EHLO mailout08.rmx.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2394365AbgJPJBR (ORCPT ); Fri, 16 Oct 2020 05:01:17 -0400 Received: from kdin02.retarus.com (kdin02.dmz1.retloc [172.19.17.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout08.rmx.de (Postfix) with ESMTPS id 4CCKrT4CTvzMyvB; Fri, 16 Oct 2020 11:01:13 +0200 (CEST) Received: from mta.arri.de (unknown [217.111.95.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by kdin02.retarus.com (Postfix) with ESMTPS id 4CCKrG6TMrz2TTNX; Fri, 16 Oct 2020 11:01:02 +0200 (CEST) Received: from n95hx1g2.localnet (192.168.54.19) by mta.arri.de (192.168.100.104) with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 16 Oct 2020 11:00:21 +0200 From: Christian Eggers To: Kurt Kanzenbach CC: Vladimir Oltean , Woojung Huh , Andrew Lunn , Vivien Didelot , Florian Fainelli , Microchip Linux Driver Support , "David S . Miller" , Jakub Kicinski , , Subject: Re: [PATCH net] net: dsa: ksz: fix padding size of skb Date: Fri, 16 Oct 2020 11:00:20 +0200 Message-ID: <4467366.g9nP7YU7d8@n95hx1g2> Organization: Arnold & Richter Cine Technik GmbH & Co. Betriebs KG In-Reply-To: <875z7asjfd.fsf@kurt> References: <20201014161719.30289-1-ceggers@arri.de> <1647199.FWNDY5eN7L@n95hx1g2> <875z7asjfd.fsf@kurt> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Originating-IP: [192.168.54.19] X-RMX-ID: 20201016-110110-4CCKrG6TMrz2TTNX-0@kdin02 X-RMX-SOURCE: 217.111.95.66 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Friday, 16 October 2020, 09:45:42 CEST, Kurt Kanzenbach wrote: > On Thu Oct 15 2020, Christian Eggers wrote: > > On Wednesday, 14 October 2020, 19:31:03 CEST, Vladimir Oltean wrote: > >> What problem are you actually trying to solve? > > > > After (hopefully) understanding the important bits, I would like to solve > > the problem that after calling __skb_put_padto() there may be no tailroom > > for the tail tag. > > > > The conditions where this can happen are quite special. You need a > > skb->len < ETH_ZLEN and the skb must be marked as cloned. One condition > > where this happens in practice is when the skb has been selected for TX > > time stamping in dsa_skb_tx_timestamp() [cloned] and L2 is used as > > transport for PTP [size < ETH_ZLEN]. But maybe cloned sk_buffs can also > > happen for other reasons. > Hmm. I've never observed any problems using DSA with L2 PTP time > stamping with this tail tag code. What's the impact exactly? Memory > corruption? It looks like skb_put_padto() is only used by the tag_ksz driver. So it's unlikely that other drivers are affected by the same problem. If I remember correctly, I got a skb_panic in skb_put() when adding the tail tag. But with the current kernel I didn't manage to create packets where the skb allocated by __skb_put_padto has not enough spare room for the tag tag. Either I am trying with wrong packets, or something else has been changed in between. I just sent a new patch which should solve the problem correctly here: https://patchwork.ozlabs.org/project/netdev/list/?series=208269 Best regards Christian