lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <3a24afbf.8f12.19394d80ca6.Coremail.tianyu2@kernelsoft.com>
Date: Thu, 5 Dec 2024 11:23:27 +0800 (GMT+08:00)
From: tianyu2 <tianyu2@...nelsoft.com>
To: "Paolo Abeni" <pabeni@...hat.com>
Cc: eric.dumazet@...il.com, "Pablo Neira Ayuso" <pablo@...filter.org>, 
	netdev@...r.kernel.org
Subject: Re: [PATCH] ipv4: remove useless arg



> 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@...nelsoft.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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ