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: <55B78EFD.1030306@brocade.com>
Date:	Tue, 28 Jul 2015 15:17:33 +0100
From:	Robert Shearman <rshearma@...cade.com>
To:	Roopa Prabhu <roopa@...ulusnetworks.com>, <davem@...emloft.net>,
	<tgraf@...g.ch>
CC:	<netdev@...r.kernel.org>
Subject: Re: [PATCH net-next v4] af_mpls: fix undefined reference to ip6_route_output

On 28/07/15 07:40, Roopa Prabhu wrote:
> From: Roopa Prabhu <roopa@...ulusnetworks.com>
>
> Undefined reference to ip6_route_output and ip_route_output
> was reported with CONFIG_INET=n and CONFIG_IPV6=n.
>
> This patch adds new CONFIG_MPLS_NEXTHOP_DEVLOOKUP
> to lookup nexthop device if user has not specified it
> in RTA_OIF attribute. Make CONFIG_MPLS_NEXTHOP_DEVLOOKUP
> depend on INET and (IPV6 || IPV6=n) because it
> uses ip6_route_output and ip_route_output.
>
> Reported-by: kbuild test robot <fengguang.wu@...el.com>
> Reported-by: Thomas Graf <tgraf@...g.ch>
> Signed-off-by: Roopa Prabhu <roopa@...ulusnetworks.com>

Is there a compelling reason to allow the user/applications to not 
specify the output interface and to derive it from the nexthop? If the 
user/application intends to treat this as a recursive route then it has 
to make sure to trigger route updates to the kernel anyway, and an 
application should have the output interface and real nexthop close to 
hand in that case.

If there isn't a compelling reason, then perhaps the best course of 
action is to revert the commit, instead of introducing a level of config 
complexity that means that users/applications may not be able to rely on 
this capability anyway?

Thanks,
Rob
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ