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>] [day] [month] [year] [list]
Message-ID: <197a3669-c72f-45ee-8aa7-47bf4816fbdd@t-8ch.de>
Date: Mon, 1 Jul 2024 08:33:30 +0200
From: Thomas Weißschuh <thomas@...ch.de>
To: lin jia <chinasjtu@....com>
Cc: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, 
	Luis Chamberlain <mcgrof@...nel.org>, Kees Cook <keescook@...omium.org>, 
	Joel Granados <j.granados@...sung.com>, "linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>
Subject: Re: 回复: can anyone explain the meaning of improvement of try_attach function in sysctl.c?


On 2024-07-01 01:06:32+0000, lin jia wrote:
> dear sir :
> thanks for reply,  Mr Thomas,  I read the commit log of "sysctl: Stop
> requiring explicit management of sysctl directories" , found  the
> following section of benchmark in sysctl: Stop requiring explicit
> management of sysctl directories - kernel/git/sysctl/sysctl.git -
> joel.granados's fork of
> linux.git<https://git.kernel.org/pub/scm/linux/kernel/git/sysctl/sysctl.git/commit/?id=7ec66d06362da7684a4948c4c2bf1f8546425df4>

Please don't top-post, use inline quotes.

> 
>       Benchmark before:
>     make-dummies 0 999 -> 0.7s
>     rmmod dummy        -> 0.07s
>     make-dummies 0 9999 -> 1m10s
>     rmmod dummy         -> 0.4s
> 
> Benchmark after:
>     make-dummies 0 999 -> 0.44s
>     rmmod dummy        -> 0.065s
>     make-dummies 0 9999 -> 1m36s
>     rmmod dummy         -> 0.4s
> 
> does it means the difference on the performance between new implement
> and old of sysctl?  If that's the case, it seems the difference is not
> significant

In your original mail you reported that it helps to exit earlier from
the loop.
This commit completely removes the loop, so I would guess that should be
even better.
The benchmark probably also depends on the actual usage, did you test yours?

Personally I don't know much about the sysctl internals, especially that
old ones. So can't give any other advice.

> ________________________________
> 发件人: Thomas Weißschuh <thomas@...ch.de>
> 发送时间: 2024年6月29日 19:19
> 收件人: lin jia <chinasjtu@....com>
> 抄送: linux-kernel@...r.kernel.org <linux-kernel@...r.kernel.org>; Luis Chamberlain <mcgrof@...nel.org>; Kees Cook <keescook@...omium.org>; Joel Granados <j.granados@...sung.com>; linux-fsdevel@...r.kernel.org <linux-fsdevel@...r.kernel.org>
> 主题: Re: can anyone explain the meaning of improvement of try_attach function in sysctl.c?
> 
> Hi lin jia,
> 
> thanks for posting to the list.
> I'll also add Joel, Kees, Luis and the fsdevel lists to Cc, as per
> "PROC SYSCTL" from the MAINTAINERS file.
> 
> On 2024-06-29 10:54:15+0000, lin jia wrote:
> > Hi all:
> >    I've been reading the sysctl part of the Linux kernel source code( 3.3.8) recently and encountered some issues. I'm not sure who I can ask for help.
> >    In sysctl.c ,  the function of __register_sysctl_paths is to register a sysctl hierarchy,  I am confused by the function " try_attach",
> 
> This is a very old kernel.
> 
> The function you mention was removed over ten years ago and the way
> sysctls are registered today is completely different.
> 
> > /* see if attaching q to p would be an improvement */
> > static void try_attach(struct ctl_table_header *p, struct ctl_table_header *q)
> >
> > what is the meaning of "improvement",  I don’t know the matching standard for the entry in the list
> >
> > another question is , why not break when variable is_better and
> > not_in_parent is true, so as to save time,  when I config about 2k~4k
> > net device objects in system,  "register_net_sysctl_table" cost
> > considerable time.
> 
> try_attach() was removed in
> commit 7ec66d06362d ("sysctl: Stop requiring explicit management of sysctl directories")
> citing performance reasons.
> This may be same performance issue you are encountering and maybe you
> can take inspiration from that commit to avoid it.
> 
> Or even better, upgrade to a newer kernel.
> 
> > <snip>
> 
> 
> Thomas

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ