From: Jason Xing <kerneljasonxing@gmail.com>
To: Peilin He <peilinhe2020@163.com>
Cc: davem@davemloft.net, dsahern@kernel.org, edumazet@google.com,
he.peilin@zte.com.cn, jiang.xuexin@zte.com.cn, kuba@kernel.org,
linux-kernel@vger.kernel.org,
linux-trace-kernel@vger.kernel.org, liu.chun2@zte.com.cn,
mhiramat@kernel.org, netdev@vger.kernel.org,
rostedt@goodmis.org, xu.xin16@zte.com.cn,
yang.yang29@zte.com.cn, zhang.yunkai@zte.com.cn
Subject: Re: Re: [PATCH v3 resend] net/ipv4: add tracepoint for icmp_send
Date: Mon, 25 Mar 2024 13:34:33 +0800 [thread overview]
Message-ID: <CAL+tcoCOywxJ9VFs6PD4Wdsq1HvQ18YVhYX3DA5MfTSXA+Htug@mail.gmail.com> (raw)
In-Reply-To: <20240325040429.3776225-1-peilinhe2020@163.com>
On Mon, Mar 25, 2024 at 12:05 PM Peilin He <peilinhe2020@163.com> wrote:
>
> >> ---------
> >> v2->v3:
> >> Some fixes according to
> >> https://lore.kernel.org/all/20240319102549.7f7f6f53@gandalf.local.home/
> >> 1. Change the tracking directory to/sys/kernel/tracking.
> >> 2. Adjust the layout of the TP-STRUCT_entry parameter structure.
> >>
> >> v1->v2:
> >> Some fixes according to
> >> https://lore.kernel.org/all/CANn89iL-y9e_VFpdw=3DsZtRnKRu_tnUwqHuFQTJvJsv=
> >-nz1xPDw@mail.gmail.com/
> >> 1. adjust the trace_icmp_send() to more protocols than UDP.
> >> 2. move the calling of trace_icmp_send after sanity checks
> >> in __icmp_send().
> >>
> >> Signed-off-by: Peilin He<he.peilin@zte.com.cn>
> >> Reviewed-by: xu xin <xu.xin16@zte.com.cn>
> >> Reviewed-by: Yunkai Zhang <zhang.yunkai@zte.com.cn>
> >> Cc: Yang Yang <yang.yang29@zte.com.cn>
> >> Cc: Liu Chun <liu.chun2@zte.com.cn>
> >> Cc: Xuexin Jiang <jiang.xuexin@zte.com.cn>
> >
> >I think it would be better to target net-next tree since it's not a
> >fix or something else important.
> >
> OK. I would target it for net-next.
> >> ---
> >> include/trace/events/icmp.h | 64 +++++++++++++++++++++++++++++++++++++
> >> net/ipv4/icmp.c | 4 +++
> >> 2 files changed, 68 insertions(+)
> >> create mode 100644 include/trace/events/icmp.h
> >>
> >> diff --git a/include/trace/events/icmp.h b/include/trace/events/icmp.h
> >> new file mode 100644
> >> index 000000000000..2098d4b1b12e
> >> --- /dev/null
> >> +++ b/include/trace/events/icmp.h
> >> @@ -0,0 +1,64 @@
> >> +/* SPDX-License-Identifier: GPL-2.0 */
> >> +#undef TRACE_SYSTEM
> >> +#define TRACE_SYSTEM icmp
> >> +
> >> +#if !defined(_TRACE_ICMP_H) || defined(TRACE_HEADER_MULTI_READ)
> >> +#define _TRACE_ICMP_H
> >> +
> >> +#include <linux/icmp.h>
> >> +#include <linux/tracepoint.h>
> >> +
> >> +TRACE_EVENT(icmp_send,
> >> +
> >> + TP_PROTO(const struct sk_buff *skb, int type, int code),
> >> +
> >> + TP_ARGS(skb, type, code),
> >> +
> >> + TP_STRUCT__entry(
> >> + __field(const void *, skbaddr)
> >> + __field(int, type)
> >> + __field(int, code)
> >> + __array(__u8, saddr, 4)
> >> + __array(__u8, daddr, 4)
> >> + __field(__u16, sport)
> >> + __field(__u16, dport)
> >> + __field(unsigned short, ulen)
> >> + ),
> >> +
> >> + TP_fast_assign(
> >> + struct iphdr *iph =3D ip_hdr(skb);
> >> + int proto_4 =3D iph->protocol;
> >> + __be32 *p32;
> >> +
> >> + __entry->skbaddr =3D skb;
> >> + __entry->type =3D type;
> >> + __entry->code =3D code;
> >> +
> >> + if (proto_4 =3D=3D IPPROTO_UDP) {
> >> + struct udphdr *uh =3D udp_hdr(skb);
> >> + __entry->sport =3D ntohs(uh->source);
> >> + __entry->dport =3D ntohs(uh->dest);
> >> + __entry->ulen =3D ntohs(uh->len);
> >> + } else {
> >> + __entry->sport =3D 0;
> >> + __entry->dport =3D 0;
> >> + __entry->ulen =3D 0;
> >> + }
> >
> >What about using the TP_STORE_ADDR_PORTS_SKB macro to record the sport
> >and dport like the patch[1] did through extending the use of header
> >for TCP and UDP?
> >
> I believe patch[1] is a good idea as it moves the TCP protocol parsing
> previously done inside the TP_STORE_ADDR_PORTS_SKB macro to TP_fast_assign,
> and extracts the TP_STORE_ADDR_PORTS_SKB macro into a common file,
> enabling support for both UDP and TCP protocol parsing simultaneously.
>
> However, patch[1] only extracts the source and destination addresses of
> the packet, but does not extract the source port and destination port,
> which limits the significance of my submitted patch.
No, please take a look at TP_STORE_ADDR_PORTS_SKB() macro again. It
records 4-tuples of the flow.
Thanks,
Jason
>
> Perhaps the patch[1] could be referenced for integration after it is merged.
> >And, I wonder what the use of tracing ulen of that skb?
> >
> The tracking of ulen is primarily aimed at ensuring the legality of received
> UDP packets and providing developers with more detailed information
> on exceptions. See net/ipv4/udp.c:2494-2501.
> >[1]: https://lore.kernel.org/all/1c7156a3f164eb33ef3a25b8432e359f0bb60a8e.1=
> >710866188.git.balazs.scheidler@axoflow.com/
> >
> >Thanks,
> >Jason
> >
> >> +
> >> + p32 =3D (__be32 *) __entry->saddr;
> >> + *p32 =3D iph->saddr;
> >> +
> >> + p32 =3D (__be32 *) __entry->daddr;
> >> + *p32 =3D iph->daddr;
> >> + ),
> >> +
> >> + TP_printk("icmp_send: type=3D%d, code=3D%d. From %pI4:%u =
> >to %pI4:%u ulen=3D%d skbaddr=3D%p",
> >> + __entry->type, __entry->code,
> >> + __entry->saddr, __entry->sport, __entry->daddr,
> >> + __entry->dport, __entry->ulen, __entry->skbaddr)
> >> +);
> >> +
> >> +#endif /* _TRACE_ICMP_H */
> >> +
> >> +/* This part must be outside protection */
> >> +#include <trace/define_trace.h>
> >> \ No newline at end of file
> >> diff --git a/net/ipv4/icmp.c b/net/ipv4/icmp.c
> >> index e63a3bf99617..21fb41257fe9 100644
> >> --- a/net/ipv4/icmp.c
> >> +++ b/net/ipv4/icmp.c
> >> @@ -92,6 +92,8 @@
> >> #include <net/inet_common.h>
> >> #include <net/ip_fib.h>
> >> #include <net/l3mdev.h>
> >> +#define CREATE_TRACE_POINTS
> >> +#include <trace/events/icmp.h>
> >>
> >> /*
> >> * Build xmit assembly blocks
> >> @@ -672,6 +674,8 @@ void __icmp_send(struct sk_buff *skb_in, int type, in=
> >t code, __be32 info,
> >> }
> >> }
> >>
> >> + trace_icmp_send(skb_in, type, code);
> >> +
> >> /* Needed by both icmp_global_allow and icmp_xmit_lock */
> >> local_bh_disable();
> >>
> >> --
> >> 2.44.0
> >>
>
next prev parent reply other threads:[~2024-03-25 5:35 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-21 3:09 [PATCH v3 resend] net/ipv4: add tracepoint for icmp_send xu.xin16
2024-03-21 3:26 ` Jason Xing
2024-03-25 3:57 ` Peilin He
2024-03-25 4:04 ` Peilin He
2024-03-25 5:34 ` Jason Xing [this message]
2024-03-25 7:57 ` Peilin He
2024-03-21 3:44 ` Jakub Kicinski
2024-03-21 8:46 ` Eric Dumazet
2024-03-25 4:01 ` Peilin He
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAL+tcoCOywxJ9VFs6PD4Wdsq1HvQ18YVhYX3DA5MfTSXA+Htug@mail.gmail.com \
--to=kerneljasonxing@gmail.com \
--cc=davem@davemloft.net \
--cc=dsahern@kernel.org \
--cc=edumazet@google.com \
--cc=he.peilin@zte.com.cn \
--cc=jiang.xuexin@zte.com.cn \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=liu.chun2@zte.com.cn \
--cc=mhiramat@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=peilinhe2020@163.com \
--cc=rostedt@goodmis.org \
--cc=xu.xin16@zte.com.cn \
--cc=yang.yang29@zte.com.cn \
--cc=zhang.yunkai@zte.com.cn \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).