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

Powered by blists - more mailing lists