netdev - Re: [PATCH iproute2-next v4] ip-link: add support for nolocalbypass in vxlan

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <ZGc9MHUkZ7nS7q+o@renaissance-vector>
Date: Fri, 19 May 2023 11:11:12 +0200
From: Andrea Claudi <aclaudi@...hat.com>
To: Vladimir Nikishkin <vladimir@...ishkin.pw>
Cc: Stephen Hemminger <stephen@...workplumber.org>, netdev@...r.kernel.org,
	davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org,
	pabeni@...hat.com, eng.alaamohamedsoliman.am@...il.com,
	gnault@...hat.com, razor@...ckwall.org, idosch@...dia.com,
	liuhangbin@...il.com, eyal.birger@...il.com, jtoppins@...hat.com
Subject: Re: [PATCH iproute2-next v4] ip-link: add support for nolocalbypass
 in vxlan

On Fri, May 19, 2023 at 11:50:03AM +0800, Vladimir Nikishkin wrote:
> 
> Stephen Hemminger <stephen@...workplumber.org> writes:
> 
> > On Thu, 18 May 2023 21:46:01 +0800
> > Vladimir Nikishkin <vladimir@...ishkin.pw> wrote:
> >
> >> +	if (tb[IFLA_VXLAN_LOCALBYPASS]) {
> >> +		__u8 localbypass = rta_getattr_u8(tb[IFLA_VXLAN_LOCALBYPASS]);
> >> +
> >> +		print_bool(PRINT_JSON, "localbypass", NULL, localbypass);
> >> +		if (localbypass) {
> >> +			print_string(PRINT_FP, NULL, "localbypass ", NULL);
> >> +		} else {
> >> +			print_string(PRINT_FP, NULL, "nolocalbypass ", NULL);
> >> +		}
> >> +	}
> >
> > You don't have to print anything if nolocalbypass.  Use presence as
> > a boolean in JSON.
> >
> > I.e.
> > 	if (tb[IFLA_VXLAN_LOCALBYPASS] &&
> > 	   rta_getattr_u8(tb[IFLA_VXLAN_LOCALBYPASS])) {
> > 		print_bool(PRINT_ANY, "localbypass", "localbypass", true);
> > 	}
> >
> > That is what other options do.
> > Follows the best practices for changes to existing programs: your
> > new feature should look like all the others.
> 
> Sorry, I do not understand. I intended to do exactly that, and I copied
> and adjusted for the option name the code currently used for the
> "udpcsum" option. Which is exactly
> 
> 		if (is_json_context()) {
> 			print_bool(PRINT_ANY, "udp_csum", NULL, udp_csum);
> 		} else {
> 			if (!udp_csum)
> 				fputs("no", f);
> 			fputs("udpcsum ", f);
> 		}
> I just replaced that option name with [no]localbypass. Fairly
> straightforward, prints noudpcsum or udpcsum. Later Andrea C
> 
> Then Andrea Claudi suggested that print_bool knows about the json
> context itself, so the outer check is not needed, so I removed that.
> But the "model option" I used (really the simplest one), does have
> output both when set to true, and when set to false. I have neither an
> opinion on this nor an understanding what is better for scripting. But I
> do not understand the suggestion "do like the other options do", when
> seemingly, other options do what I suggest in the first place.
>

If I get Stephen corretly, he is simply suggesting that printing
"nolocalbypass" is unnecessary. If you find don't find "localbypass" in
the output, you know it's not enabled.

Unfortunately iplink_vxlan does not work according to this logic, as you
are pointing out, but there are several places where this happens, like
link_gre6.c:543. So you can do that for "localbypass" here.

Fixing old options, on the other hand, is not easy, as we may end up
breaking user scripts relying on "no<whatever>" option. I can work on a
patch for that, but we probably need some kind of deprecation warning to
users.

Stephen, what do you think?