netdev - Re: [PATCH net-next] rocker: check for BRIDGE_FLAGS

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: <CAE4R7bB2GC3_vMvKAcYie1SP0xB9hm-himzP_BGHX5B2gZKisw@mail.gmail.com>
Date:	Wed, 18 Mar 2015 22:49:23 -0700
From:	Scott Feldman <sfeldma@...il.com>
To:	John Fastabend <john.fastabend@...il.com>
Cc:	roopa <roopa@...ulusnetworks.com>,
	John Fastabend <john.r.fastabend@...el.com>,
	Jiri Pirko <jiri@...nulli.us>,
	"Arad, Ronen" <ronen.arad@...el.com>,
	Netdev <netdev@...r.kernel.org>,
	"David S. Miller" <davem@...emloft.net>
Subject: Re: [PATCH net-next] rocker: check for BRIDGE_FLAGS_SELF in bridge
 setlink handler

On Wed, Mar 18, 2015 at 8:24 AM, John Fastabend
<john.fastabend@...il.com> wrote:
> [...]

>> I am not sure how this would be and what other issues you will hit if
>> you are planning to bypass the kernel and directly go to the switch
>> driver for all l2 and l3 in the stacked netdevice case. For l3, its
>> better to use the in-kernel route fib offload mechanism which was
>> recently submitted by scott feldman.
>>
>
> Why? I saw the patched and liked it but noted that the existing policy
> wont actually work for real networks. Its a good start. My proposal
> is to add a flag to l3 to similarly fail to load a rule if it can't
> be pushed at hardware same as l2.

RIght, what we have is a start to get the basic plumbing in place.
Agreed, the current would be inadequate for a real switch that can't
handle a software fallback.

Maybe the next step is to not flush hw of all routes on failure to add
the Nth one, but rather just fail the Nth completely (don't install in
hw or sw and return err to user).  This would keep the switch alive,
but now moves a decision to the user.  The user must decide what to do
with the failed Nth route.

We also added the netlink flag RTNH_F_EXTERNAL to mark routes
offloaded to hardware, but the marking is only done internally now, by
the kernel.  What I'm hoping is we can use that same flag in the
user's netlink msg to work like you describe: if user requests
RTNH_F_EXTERNAL, and it can't be loaded into hw, don't load into sw.
Or something like that.  Again, punting the decision on what to do
next to the user.

This part of the discussion should probably move to a new thread;
maybe someone brave can propose a patch to move us to the next level?

-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