Received: by 2002:ab2:6309:0:b0:1fb:d597:ff75 with SMTP id s9csp49215lqt; Wed, 5 Jun 2024 16:58:01 -0700 (PDT) X-Forwarded-Encrypted: i=3; AJvYcCXFguQhkCtn/rBd2QcHwE566QyR5eJOf5mK7KptjcuM9TtfoeQZyFc/ZlgdUUzBxAkgQo6unr2AOYYmDWG49S+qduJ845GW+FHOLIVUfA== X-Google-Smtp-Source: AGHT+IG6lPNjImhzP3AeDwHkIJUexD7RwjBTTISICMnU/V7CjfO28sWMgHIvo2NmCM3Xz7KHTX1O X-Received: by 2002:a05:6a00:2da1:b0:6ea:df65:ff7d with SMTP id d2e1a72fcca58-703e597a59amr4663088b3a.10.1717631881090; Wed, 05 Jun 2024 16:58:01 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1717631881; cv=pass; d=google.com; s=arc-20160816; b=ozy7eb5gVlVvUEgiseB6kvRcm6dwJuJ62nOVwljs1Lv6qbTeKgaZ2ln6vsFUc8SvTZ DCStBUXECaI33kZ55jB8xzWWWeTWbLuDo3Dpd2qPX7NgpSbo5JmULAAytzTOOS6wJDkF Pa8CW2JUTUmuPIEGvLU9L3sy+snuVcVenQ5r1dHvSAMsp4IPmmPKSsz0hgH0e/2hSgDz VaCKbuFxitL/QjVR7lttS0jecmvHQj3unklN0APCbOgMsBGUsOEWWyt4geaYu8DXIvQ/ pSSrOcrax6MxhgJCypmQSTpqwlxNnsjp+e/DDBxiSBIRKBCOCIfLvBtL314tafUx0wtk Al9A== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:in-reply-to:message-id :subject:cc:to:from:date; bh=EK7egJFU2xsAC1+WQ4ypjMFMpBAXua2chjU5SuZ7Ho0=; fh=Qxwcbfljj5Rl9KuH3i23D3aLHbMhPLPbNNcZhSwpBQk=; b=ObDM02CcejdIXHoJ/G6eykB1RGVUyxt5gxLLyf4Cy+0bJ1ZTq0ml6UrqcikO/14Yq9 4zijGcbIiue9y15I1xAF0Q5s9ck35od9EzVqIIqeAn6sNniJfOVFZQRQYnRqoy4zF+sp CypNEW4kYCnlA8oFwcsgWa333rF2G2bGQ3GhhxCzoJeTm3/BaKTvjY/+sOh/p3iRx9u+ oHZ4z/z1K863ulEyg7+fsszAoJEOFjHEKOfZ/bscFrKDsNybH5O2nHcEBGfwN1vUP1x4 qZO8oRytEp01xLBTZSO60AcJKPXa0kNgNcMsGHELOnXMFeG02/yk4f7DWhTrALZ5YKM3 dn3Q==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; arc=pass (i=1); spf=pass (google.com: domain of linux-kernel+bounces-203437-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-203437-linux.lists.archive=gmail.com@vger.kernel.org" Return-Path: Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [139.178.88.99]) by mx.google.com with ESMTPS id 41be03b00d2f7-6de28f34ea9si147497a12.603.2024.06.05.16.58.00 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 05 Jun 2024 16:58:01 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel+bounces-203437-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99; Authentication-Results: mx.google.com; arc=pass (i=1); spf=pass (google.com: domain of linux-kernel+bounces-203437-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-203437-linux.lists.archive=gmail.com@vger.kernel.org" Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id B55942882BE for ; Wed, 5 Jun 2024 23:58:00 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id AB2A8169386; Wed, 5 Jun 2024 23:57:51 +0000 (UTC) Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 28A0C1AAA5; Wed, 5 Jun 2024 23:57:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1717631871; cv=none; b=Wub+LatOf0YHSujXa/N/tJLFpDdqVMYhpfTeHhHCCgkzeR8sctu9hS80aTnlT4G2fkphiYidR7g/CLt5uRFtHJnhpM4dC0vOzOYiUSomWREt4TBTaieXUm8LPIVVI01Y/f3ho1V98dRp+ajVxd0ig0GiZw6PiVgDSUlR5m0oofI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1717631871; c=relaxed/simple; bh=5ApjUtK872vDWT9BiZ/Y5CWSDUL4VWEAnM4+OUhd+Zk=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=swM4D0LYZknRjEJeaV/zhOTNcKjNNN6DEXrd++mTLxliK8nBJLyyOWrCWf1iASivwiEjuytJWJx57GSKU5zmJEEwYHaTYEanYY7JYWZzC2mJBTYLddzldrsTcpvKU2PcM8Se7AAEIVIdXxsJ4bnlYV93iQlLtrJy4K5SUmv5JmE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id 445C9C2BD11; Wed, 5 Jun 2024 23:57:48 +0000 (UTC) Date: Wed, 5 Jun 2024 19:57:50 -0400 From: Steven Rostedt To: Yan Zhai Cc: netdev@vger.kernel.org, "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , David Ahern , Abhishek Chauhan , Mina Almasry , Florian Westphal , Alexander Lobakin , David Howells , Jiri Pirko , Daniel Borkmann , Sebastian Andrzej Siewior , Lorenzo Bianconi , Pavel Begunkov , linux-kernel@vger.kernel.org, kernel-team@cloudflare.com, Jesper Dangaard Brouer , Masami Hiramatsu , Mathieu Desnoyers , Neil Horman , linux-trace-kernel@vger.kernel.org, Dan Carpenter Subject: Re: [RFC v3 net-next 1/7] net: add rx_sk to trace_kfree_skb Message-ID: <20240605195750.1a225963@gandalf.local.home> In-Reply-To: <983c54f98746bd42d778b99840435d0a93963cb3.1717529533.git.yan@cloudflare.com> References: <983c54f98746bd42d778b99840435d0a93963cb3.1717529533.git.yan@cloudflare.com> X-Mailer: Claws Mail 3.20.0git84 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Tue, 4 Jun 2024 14:47:38 -0700 Yan Zhai wrote: > skb does not include enough information to find out receiving > sockets/services and netns/containers on packet drops. In theory > skb->dev tells about netns, but it can get cleared/reused, e.g. by TCP > stack for OOO packet lookup. Similarly, skb->sk often identifies a local > sender, and tells nothing about a receiver. > > Allow passing an extra receiving socket to the tracepoint to improve > the visibility on receiving drops. > > Signed-off-by: Yan Zhai > --- > v2->v3: fixed drop_monitor function prototype > --- > include/trace/events/skb.h | 11 +++++++---- > net/core/dev.c | 2 +- > net/core/drop_monitor.c | 9 ++++++--- > net/core/skbuff.c | 2 +- > 4 files changed, 15 insertions(+), 9 deletions(-) > > diff --git a/include/trace/events/skb.h b/include/trace/events/skb.h > index 07e0715628ec..aa6b46b6172c 100644 > --- a/include/trace/events/skb.h > +++ b/include/trace/events/skb.h > @@ -24,15 +24,16 @@ DEFINE_DROP_REASON(FN, FN) > TRACE_EVENT(kfree_skb, > > TP_PROTO(struct sk_buff *skb, void *location, > - enum skb_drop_reason reason), > + enum skb_drop_reason reason, struct sock *rx_sk), > > - TP_ARGS(skb, location, reason), > + TP_ARGS(skb, location, reason, rx_sk), > > TP_STRUCT__entry( > __field(void *, skbaddr) > __field(void *, location) > __field(unsigned short, protocol) > __field(enum skb_drop_reason, reason) > + __field(void *, rx_skaddr) Please add the pointer after the other pointers: __field(void *, skbaddr) __field(void *, location) + __field(void *, rx_skaddr) __field(unsigned short, protocol) __field(enum skb_drop_reason, reason) otherwise you are adding holes in the ring buffer event. The TP_STRUCT__entry() is a structure that is saved in the ring buffer. We want to avoid alignment holes. I also question having a short before the enum, if the emum is 4 bytes. The short should be at the end. In fact, looking at the format file, there is a 2 byte hole: # cat /sys/kernel/tracing/events/skb/kfree_skb/format name: kfree_skb ID: 1799 format: field:unsigned short common_type; offset:0; size:2; signed:0; field:unsigned char common_flags; offset:2; size:1; signed:0; field:unsigned char common_preempt_count; offset:3; size:1; signed:0; field:int common_pid; offset:4; size:4; signed:1; field:void * skbaddr; offset:8; size:8; signed:0; field:void * location; offset:16; size:8; signed:0; field:unsigned short protocol; offset:24; size:2; signed:0; field:enum skb_drop_reason reason; offset:28; size:4; signed:0; Notice that "protocol" is 2 bytes in size at offset 24, but "reason" starts at offset 28. This means at offset 26, there's a 2 byte hole. -- Steve > ), > > TP_fast_assign( > @@ -40,12 +41,14 @@ TRACE_EVENT(kfree_skb, > __entry->location = location; > __entry->protocol = ntohs(skb->protocol); > __entry->reason = reason; > + __entry->rx_skaddr = rx_sk; > ), >