netdev - Re: [PATCH net-next] net: change fib behavior based on interface link status

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: <20150603181628.GJ588@gospo.home.greyhouse.net>
Date:	Wed, 3 Jun 2015 14:16:29 -0400
From:	Andy Gospodarek <gospo@...ulusnetworks.com>
To:	Scott Feldman <sfeldma@...il.com>
Cc:	Netdev <netdev@...r.kernel.org>,
	"David S. Miller" <davem@...emloft.net>, ddutt@...ulusnetworks.com
Subject: Re: [PATCH net-next] net: change fib behavior based on interface
 link status

On Wed, Jun 03, 2015 at 11:12:11AM -0700, Scott Feldman wrote:
> On Wed, Jun 3, 2015 at 10:57 AM, Andy Gospodarek
> <gospo@...ulusnetworks.com> wrote:
> > On Wed, Jun 03, 2015 at 10:40:26AM -0700, Scott Feldman wrote:
> >> On Wed, Jun 3, 2015 at 8:12 AM, Andy Gospodarek
> >> <gospo@...ulusnetworks.com> wrote:
> >> > On Tue, Jun 02, 2015 at 10:03:23PM -0700, Scott Feldman wrote:
> >> >> On Tue, Jun 2, 2015 at 8:07 PM, Andy Gospodarek
> >> >> <gospo@...ulusnetworks.com> wrote:
> >> >> > This patch adds the ability to have the Linux kernel track whether or
> >> >> > not a particular route should be used based on the link-status of the
> >> >> > interface associated with the next-hop.
> >> >> >
> >> >> > Before this patch any link-failure on an interface that was serving as a
> >> >> > gateway for some systems could result in those systems being isolated
> >> >> > from the rest of the network as the stack would continue to attempt to
> >> >> > send frames out of an interface that is actually linked-down.  When the
> >> >> > kernel is responsible for all forwarding, it should also be responsible
> >> >> > for taking action when the traffic can no longer be forwarded -- there
> >> >> > is no real need to outsource link-monitoring to userspace anymore.
> >> >>
> >> >> Hi Andy, how does this work for the hardware offload case?  I'm not
> >> >> seeing how hardware gets updated when the software route is updated.
> >> >> Seems hardware isn't updated and would send frames out the downed nh
> >> >> interface.
> >> >
> >> > Scott, you are correct that this does not currently address the hardware
> >> > offload case.  If one wanted offloaded hardware to reflect this change,
> >> > then there needs to be either:
> >> >
> >> > - The ability to communicate the flag changes down to offload devices in
> >> >   the event that they want some action to take place
> >> >   switchdev_fib_ipv4_modify(), maybe? (Not to derail this convo too much
> >> >   but it will soon be time to consider what to do at the switchdev layer
> >> >   when route flags are modified like when the RTNH_F_OFFLOAD flag is
> >> >   removed by the user if they feel the route does not need to be
> >> >   offloaded for any reason.)
> >>
> >> Switchdev_fib_ipv4_add() can handle adds and mods, so you can use
> >> that.  Any place you're sending notification of route change, hook
> >> switchdev so the offload device is updated with the route change.
> > I should know better than to ask this, but does just the rocker
> > implementation presume this operation is an add and modify or was this
> > the implementation from the beginning.  (Forgive me for not remembering
> > earlier discussion on this.)
> 
> The intent was add/mod, but looks like I need to update some
> documentation; I'll do that.  See fib_trie.c:fib_table_insert case for
> NLM_F_REPLACE...that's a mod case.
The docs/comments in the code were my concern.  Thanks for doing that.

--
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