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]

Date:	Wed, 3 Jun 2015 10:40:26 -0700
From:	Scott Feldman <sfeldma@...il.com>
To:	Andy Gospodarek <gospo@...ulusnetworks.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 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.

Please include updates for switchdev for this patch v2.  I'm assuming
you're already shipping this feature on offloaded switches, so you
want it to work with switchdev, right?


> - Register a register_netdevice_notifier and take action at the
>   switchdev layer to make sure that routes can be removed or marked as
>   inactive when link goes down.

The core code is already handling the events, so it seems better to
call into switchdev from core code rather than having two listeners
potentially handling the event differently.

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