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  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, 25 Feb 2015 16:16:41 -0800
From:	Alexander Duyck <>
To:	Julian Anastasov <>,
	Alexander Duyck <>
CC:, "David S. Miller" <>
Subject: Re: [net-next PATCH 4/4] fib_trie: Remove leaf_info

On 02/25/2015 04:06 PM, Julian Anastasov wrote:
> 	Hello,
> On Wed, 25 Feb 2015, Alexander Duyck wrote:
>>> 	If there is some fa in list with higher fa_slen
>>> fib_find_alias will always stop the loop and come with
>>> fa != NULL, so above 'if...break' is not needed, we are
>>> always going to add at tail when fa is NULL.
>> Actually fib_find_alias will return NULL in the case that there was a hole in
>> which the suffix length does not exist.
>> So for example if we have a suffix length of 8 and one of 10 and we are adding
>> a suffix length of 9 then fib_find_alias will return NULL and we need to walk
>> though the list and find the hole we are supposed to drop the suffix in.
> 	I missed the fact that we return NULL instead of fa.
> I thought, it would be more consistent with the old logic
> to return a stop position. And we avoid walking the list
> again. But in practice we should not see many entries here,
> right?

Most users should have a pretty shallow list here.  In the case of BGP
routes there might be more entries per slen but the odds of encountering
a NULL in that case should be pretty low.

>> Why are you showing me an example with a 32b int when I am using a long?  For
>> x86 a 32b shift on a 32b value is undefined so we need to compare the suffix
>> length to the KEYLENGTH.  For 64b a long value can be shifted up to 63 bits
>> and still be a defined value.  That is why I use "1ul" as the value being
>> shifted and then also perform the check for KEYLENGTH vs BITS_PER_LONG in
>> order to determine if I still need the check for fa_slen != KEYLENGTH.
> 	I see, so, on 64-bit platform we avoid the
> KEYLENGTH check... OK, that is better.
> Regards
> --
> Julian Anastasov <>

Yes, the BIT_PER_LONG check will be broken down to either 0 or 1 by the
complier so it will be stripped out in the resulting assembler.

- Alex
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists