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: <20150304163053.GC1551@gospo>
Date:	Wed, 4 Mar 2015 11:30:53 -0500
From:	Andy Gospodarek <gospo@...ulusnetworks.com>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
Cc:	David Miller <davem@...emloft.net>, netdev@...r.kernel.org
Subject: Re: [PATCH net-next 1/2] neigh: Factor out ___neigh_lookup_noref

On Wed, Mar 04, 2015 at 09:58:28AM -0600, Eric W. Biederman wrote:
> Andy Gospodarek <gospo@...ulusnetworks.com> writes:
> 
> > On Tue, Mar 03, 2015 at 05:10:44PM -0600, Eric W. Biederman wrote:
> >> 
> >> While looking at the mpls code I found myself writing yet another
> >> version of neigh_lookup_noref.  We currently have __ipv4_lookup_noref
> >> and __ipv6_lookup_noref.
> >> 
> >> So to make my work a little easier and to make it a smidge easier to
> >> verify/maintain the mpls code in the future I stopped and wrote
> >> ___neigh_lookup_noref.  Then I rewote __ipv4_lookup_noref and
> >> __ipv6_lookup_noref in terms of this new function.  I tested my new
> >> version by verifying that the same code is generated in
> >> ip_finish_output2 and ip6_finish_output2 where these functions are
> >> inlined.
> >> 
> >> To get to ___neigh_lookup_noref I added a new neighbour cache table
> >> function key_eq.  So that the static size of the key would be
> >> available.
> >> 
> >> I also added __neigh_lookup_noref for people who want to to lookup
> >> a neighbour table entry quickly but don't know which neibhgour table
> >> they are going to look up.
> >
> > While I understand your intent here, you do really need to know which
> > neighbour table being used in order to do the look-up with your new
> > function, so this changelog isn't quite accurate.  I know Dave has
> > already accepted this patch, but it did not appear in the tree I just
> > updated, so hopefully there is time to fix this if you agree with me.
> 
> Currently __ipv4_lookup_noref and __ipv6_lookup_noref hard code the
> table.  __neigh_lookup_noref works without needing to hard code the
> neighbour table.  The neighbour table being a variable in the code and
> not a hard coded value is what I was referring to above when I said you
> don't need to know your neighbour table.  That is you still need a
> neighbour table it just doesn't need to be hard coded.

Thanks for the clarification.


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

Powered by Openwall GNU/*/Linux Powered by OpenVZ