From: tianyu2 <tianyu2@kernelsoft.com>
To: "Paolo Abeni" <pabeni@redhat.com>
Cc: eric.dumazet@gmail.com, "Pablo Neira Ayuso" <pablo@netfilter.org>,
netdev@vger.kernel.org
Subject: Re: [PATCH] ipv4: remove useless arg
Date: Thu, 5 Dec 2024 11:23:27 +0800 (GMT+08:00) [thread overview]
Message-ID: <3a24afbf.8f12.19394d80ca6.Coremail.tianyu2@kernelsoft.com> (raw)
In-Reply-To: <cbd3f835-0d01-46fa-9125-a0fbd5f50919@redhat.com>
> On 12/4/24 04:16, tianyu2 wrote:
> >> On 12/2/24 04:32, tianyu2 wrote:
> >>> The "struct sock *sk" parameter in ip_rcv_finish_core is unused, which
> >>> leads the compiler to optimize it out. As a result, the
> >>> "struct sk_buff *skb" parameter is passed using x1. And this make kprobe
> >>> hard to use.
> >>>
> >>> Signed-off-by: tianyu2 <tianyu2@kernelsoft.com>
> >>
> >> The patch code good, but the above does not look like a real name?!?
> >>
> >> If so, please re-submit, using your real full name and including the
> >> target tree (net-next in this case) in the subj prefix.
> >>
> >> See:
> >> https://elixir.bootlin.com/linux/v6.12.1/source/Documentation/process/submitting-patches.rst#L440
> >> https://elixir.bootlin.com/linux/v6.12.1/source/Documentation/process/maintainer-netdev.rst#L12
> >>
> >> @Pablo: after this change will be merged, I *think* that a possible
> >> follow-up could drop the 'sk' arg from NF_HOOK_LIST and ip_rcv_finish() too.
> >>
> >> Thanks!
> >>
> >> Paolo
> >
> > Thank you for the reminder. I’ll adjust the patch format in the next version.
> >
> > If ip_rcv_finish is modified, NF_HOOK/NF_HOOK_LIST also needs to be adjusted. I noticed that many places use NF_HOOK. These modifications should be fine, right?
>
> Ouch, I missed the NF_HOOK implication. Touching all NF_HOOK()
> call-sites looks IMHO way to invasive to justify this change.
>
> > However, I found that the ip_rcv_finish function doesn’t seem to be optimized by the compiler.
> > (ARM64)( gcc version 8.5.0 20210514 (Red Hat 8.5.0-4) (GCC) )
>
> FTR, that is quite an old one :) You should try with gcc 13.
I applied my patch to the v6.13-rc1 version.And I compiled it on x86 using GCC 13.
It seems that ip_rcv_finish was not optimized.
(gcc version 13.1.0 (Ubuntu 13.1.0-8ubuntu1~22.04))
ffffffff81cc6e40 <ip_rcv_finish>:
ffffffff81cc6e40: f3 0f 1e fa endbr64
ffffffff81cc6e44: 48 85 d2 test %rdx,%rdx
ffffffff81cc6e47: 74 3a je ffffffff81cc6e83 <ip_rcv_finish+0x43>
ffffffff81cc6e49: 53 push %rbx
ffffffff81cc6e4a: 48 89 d3 mov %rdx,%rbx
ffffffff81cc6e4d: 48 8b 52 10 mov 0x10(%rdx),%rdx
ffffffff81cc6e51: 31 c9 xor %ecx,%ecx
ffffffff81cc6e53: 48 89 de mov %rbx,%rsi
ffffffff81cc6e56: e8 05 f0 ff ff call ffffffff81cc5e60 <ip_rcv_finish_core>
>
> Thanks,
>
> Paolo
prev parent reply other threads:[~2024-12-05 3:26 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-02 3:32 [PATCH] ipv4: remove useless arg tianyu2
2024-12-03 10:51 ` Paolo Abeni
2024-12-04 3:16 ` tianyu2
2024-12-04 9:16 ` Paolo Abeni
2024-12-05 3:23 ` tianyu2 [this message]
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=3a24afbf.8f12.19394d80ca6.Coremail.tianyu2@kernelsoft.com \
--to=tianyu2@kernelsoft.com \
--cc=eric.dumazet@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=pablo@netfilter.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.