netdev - Re: [PATCH net-next 2/7] neighbor: Fold ___neigh_lookup_noref into __neigh_lookup

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <7ebd3c00-c510-1bd4-34f3-3d6b5f6124ed@gmail.com>
Date:   Wed, 5 Dec 2018 17:46:37 -0700
From:   David Ahern <dsahern@...il.com>
To:     David Miller <davem@...emloft.net>, dsahern@...nel.org
Cc:     netdev@...r.kernel.org
Subject: Re: [PATCH net-next 2/7] neighbor: Fold ___neigh_lookup_noref into
 __neigh_lookup_noref

On 12/5/18 5:44 PM, David Miller wrote:
> From: David Ahern <dsahern@...nel.org>
> Date: Wed,  5 Dec 2018 15:34:09 -0800
> 
>> @@ -270,37 +270,25 @@ static inline bool neigh_key_eq128(const struct neighbour *n, const void *pkey)
>>  		(n32[2] ^ p32[2]) | (n32[3] ^ p32[3])) == 0;
>>  }
>>  
>> -static inline struct neighbour *___neigh_lookup_noref(
>> -	struct neigh_table *tbl,
>> -	bool (*key_eq)(const struct neighbour *n, const void *pkey),
>> -	__u32 (*hash)(const void *pkey,
>> -		      const struct net_device *dev,
>> -		      __u32 *hash_rnd),
>> -	const void *pkey,
>> -	struct net_device *dev)
>> +static inline struct neighbour *__neigh_lookup_noref(struct neigh_table *tbl,
>> +						     const void *pkey,
>> +						     struct net_device *dev)
>>  {
> 
> Sorry, we can't do this.
> 
> The whole point of how this is laid out is so that the entire hash traversal,
> including the hash function, is expanded inline.
> 
> This demux is extremely critical on the output side, it must be the
> smallest number of cycles possible.  It was the only way I could justify
> not caching neigh entries in the routes any more when I wrote this code.
> 
> Even before retpoline, putting an indirect call here is painful.  With
> retpoline it is deadly.
> 
> Please avoid removing the full inline expansion of the neigh lookup in the ipv6
> and ipv4 data paths.
> 

ok. patches 5-7 are not dependent on 1-4. Should I re-send outside of
this set?