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]
Date: Sat, 29 Jun 2024 13:19:24 +0200
From: Thomas Weißschuh <thomas@...ch.de>
To: lin jia <chinasjtu@....com>
Cc: 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
Subject: 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