netdev - Re: [PATCH net v2] switchdev: don't abort hardware ipv4 fib offload on failure to program fib entry in hardware

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: <20150519194731.GK9559@gospo.home.greyhouse.net>
Date:	Tue, 19 May 2015 15:47:32 -0400
From:	Andy Gospodarek <gospo@...ulusnetworks.com>
To:	David Miller <davem@...emloft.net>
Cc:	roopa@...ulusnetworks.com, john.r.fastabend@...el.com,
	sfeldma@...il.com, john.fastabend@...il.com, jiri@...nulli.us,
	netdev@...r.kernel.org
Subject: Re: [PATCH net v2] switchdev: don't abort hardware ipv4 fib offload
 on failure to program fib entry in hardware

On Tue, May 19, 2015 at 12:34:18PM -0400, David Miller wrote:
> From: roopa <roopa@...ulusnetworks.com>
> Date: Mon, 18 May 2015 22:58:54 -0700
> 
> > from where I see, with the limitations on these boxes, this requires
> > every app, every `ip route` cmd running on the box to explicitly
> > specify offload when running on this hardware.
> 
> Users know what they are doing, and will ask for a policy change.
> 

Dave,

I'm only writing this as one of the things you said at netdev01 is that
we as a community need to be clear when collectively making decisions
about kernel functionality so there are reasonable 'breadcrumbs' when
someone asks why a decision was made.  So...

Are you actually saying that if users complain loudly enough about the
current behavior (not the change Roopa has proposed) that you would be
open to considering a change the current behavior?

-or-

Are you saying that users who are aware of offload hardware will
begin to make specifically crafted requests (as Roopa suggested with
option 'c') and those requests will force the kernel to behave in
differently that the current default behavior?

-or-

[Insert different conclusion here.]

Thanks,

-andy

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