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] [thread-next>] [day] [month] [year] [list]
Date: Tue, 14 Nov 2023 12:02:00 +0100
From: Paolo Abeni <>
To: Hangbin Liu <>,
Cc: "David S. Miller" <>, Jakub Kicinski
 <>,  Eric Dumazet <>, Shuah Khan
 <>, David Ahern <>,, Po-Hsu Lin <>, 
 Guillaume Nault <>
Subject: Re: [Discuss] Seeking advice on net selftests netns naming method

On Tue, 2023-11-14 at 17:55 +0800, Hangbin Liu wrote:
> Good day! Following Guillaume's suggestion, I've been working on updating all
> net self-tests to run in their respective netns. This modification allows us
> to execute all tests in parallel, potentially saving a significant amount of
> test time.
> However, I've encountered a challenge while making these modifications. The
> net selftest folder contains around 80 tests (excluding the forwarding test),
> with some tests using common netns names and others using self-defined names.
> I've considered two methods to address this issue:
> One approach is to retain the original names but append a unique suffix using
> $(mktemp -u XXXXXX). While this is a straightforward solution, it may not
> prevent future tests from using common names.
> Another option is to establish a general netns lib. Similar to the NUM_NETIFS
> variable in the forwarding test, we could introduce a variable like NUM_NS.
> This variable would define the number of netns instances, and all tests would
> use the netns lib to set up and clean up netns accordingly. However, this
> approach might complicate test debugging, especially for tests like
>, which relies on clear and visually netns names
> (e.g., me/peer/remote).

I personally would like sort of both :) e.g. lib function(s) to
automatically create and dispose netns, and retain a script-
specific/related name prefix. 

The library function could optionally set  the newly created namespaces
name in global variables provided by the caller, e.g.:

# create 3 namespaces:
netns_init 3 

# create 3 namespaces and set the global variables:
# $remote, $local $me 
# to their respective names
netns_init 3 remote local me

The trick to do such assignment would be using the 'eval' statement,
something alike

	# create the netns

	while [ -n "$1" ]; do
		eval $1=$NETNS_NAMES[0]

While at that, it would be useful to package some common helper e.g. to
wait for a (tcp) listener to be created (available) on a given port.




Powered by blists - more mailing lists