[PATCH 1/3] netfilter: nf_tables: avoid uninitialized variable warning

[PATCH 1/3] netfilter: nf_tables: avoid uninitialized variable warning

[Arnd Bergmann]

The newly added nft_range_eval() function handles the two possible
nft range operations, but as the compiler warning points out,
any unexpected value would lead to the 'mismatch' variable being
used without being initialized:

net/netfilter/nft_range.c: In function 'nft_range_eval':
net/netfilter/nft_range.c:45:5: error: 'mismatch' may be used uninitialized in this function [-Werror=maybe-uninitialized]

This can be trivially avoided by added a 'default:' clause.

Fixes: 0f3cd9b36977 ("netfilter: nf_tables: add range expression")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 net/netfilter/nft_range.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/net/netfilter/nft_range.c b/net/netfilter/nft_range.c
index c6d5358482d1..72dff5bffca8 100644
--- a/net/netfilter/nft_range.c
+++ b/net/netfilter/nft_range.c
@@ -40,6 +40,8 @@ static void nft_range_eval(const struct nft_expr *expr,
 	case NFT_RANGE_NEQ:
 		mismatch = (d1 >= 0 && d2 <= 0);
 		break;
+	default:
+		mismatch = 0;
 	}
 
 	if (mismatch)
-- 
2.9.0

[PATCH 2/3] netfilter: hide reference to nf_hooks_ingress

[Arnd Bergmann]

A recent cleanup added an unconditional reference to the nf_hooks_ingress pointer,
but that fails when CONFIG_NETFILTER_INGRESS is disabled and that member is
not present in net_device:

net/netfilter/core.c: In function 'nf_set_hooks_head':
net/netfilter/core.c:96:30: error: 'struct net_device' has no member named 'nf_hooks_ingress'

This avoids the build error by simply enclosing the assignment in an #ifdef,
which may or may not be the correct fix.

Fixes: e3b37f11e6e4 ("netfilter: replace list_head with single linked list")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 net/netfilter/core.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/net/netfilter/core.c b/net/netfilter/core.c
index 576a9c0406a9..5ccff1d9f209 100644
--- a/net/netfilter/core.c
+++ b/net/netfilter/core.c
@@ -90,10 +90,12 @@ static void nf_set_hooks_head(struct net *net, const struct nf_hook_ops *reg,
 {
 	switch (reg->pf) {
 	case NFPROTO_NETDEV:
+#ifdef CONFIG_NETFILTER_INGRESS
 		/* We already checked in nf_register_net_hook() that this is
 		 * used from ingress.
 		 */
 		rcu_assign_pointer(reg->dev->nf_hooks_ingress, entry);
+#endif
 		break;
 	default:
 		rcu_assign_pointer(net->nf.hooks[reg->pf][reg->hooknum],
-- 
2.9.0

[PATCH 3/3] netfilter: xt_hashlimit: uses div_u64 for division

[Arnd Bergmann]

The newly added support for high-resolution pps rates introduced multiple 64-bit
division operations in one function, which fails on all 32-bit architectures:

net/netfilter/xt_hashlimit.o: In function `user2credits':
xt_hashlimit.c:(.text.user2credits+0x3c): undefined reference to `__aeabi_uldivmod'
xt_hashlimit.c:(.text.user2credits+0x68): undefined reference to `__aeabi_uldivmod'
xt_hashlimit.c:(.text.user2credits+0x88): undefined reference to `__aeabi_uldivmod'

This replaces the division with an explicit call to div_u64 for version 2
to documents that this is a slow operation, and reverts back to 32-bit arguments
for the version 1 data to restore the original faster 32-bit division.

With both changes combined, we no longer get a link error.

Fixes: 11d5f15723c9 ("netfilter: xt_hashlimit: Create revision 2 to support higher pps rates")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
Vishwanath Pai already sent a patch for this, and I did my version independently.
The difference is that his version also the more expensive division for the
version 1 variant that doesn't need it.

See also http://patchwork.ozlabs.org/patch/676713/
---
 net/netfilter/xt_hashlimit.c | 17 ++++++++++-------
 1 file changed, 10 insertions(+), 7 deletions(-)

diff --git a/net/netfilter/xt_hashlimit.c b/net/netfilter/xt_hashlimit.c
index 44a095ecc7b7..3d5525df6eb3 100644
--- a/net/netfilter/xt_hashlimit.c
+++ b/net/netfilter/xt_hashlimit.c
@@ -464,20 +464,23 @@ static u32 xt_hashlimit_len_to_chunks(u32 len)
 static u64 user2credits(u64 user, int revision)
 {
 	if (revision == 1) {
+		u32 user32 = user; /* use 32-bit division */
+
 		/* If multiplying would overflow... */
-		if (user > 0xFFFFFFFF / (HZ*CREDITS_PER_JIFFY_v1))
+		if (user32 > 0xFFFFFFFF / (HZ*CREDITS_PER_JIFFY_v1))
 			/* Divide first. */
-			return (user / XT_HASHLIMIT_SCALE) *\
+			return (user32 / XT_HASHLIMIT_SCALE) *
 						HZ * CREDITS_PER_JIFFY_v1;
 
-		return (user * HZ * CREDITS_PER_JIFFY_v1) \
-						/ XT_HASHLIMIT_SCALE;
+		return (user32 * HZ * CREDITS_PER_JIFFY_v1) /
+						XT_HASHLIMIT_SCALE;
 	} else {
 		if (user > 0xFFFFFFFFFFFFFFFF / (HZ*CREDITS_PER_JIFFY))
-			return (user / XT_HASHLIMIT_SCALE_v2) *\
-						HZ * CREDITS_PER_JIFFY;
+			return div_u64_u64(user, XT_HASHLIMIT_SCALE_v2) *
+					   HZ * CREDITS_PER_JIFFY;
 
-		return (user * HZ * CREDITS_PER_JIFFY) / XT_HASHLIMIT_SCALE_v2;
+		return div_u64_u64(user * HZ * CREDITS_PER_JIFFY,
+				   XT_HASHLIMIT_SCALE_v2);
 	}
 }
 
-- 
2.9.0

Re: [PATCH 3/3] netfilter: xt_hashlimit: uses div_u64 for division

[Eric Dumazet]

On Fri, 2016-09-30 at 18:05 +0200, Arnd Bergmann wrote:
> The newly added support for high-resolution pps rates introduced multiple 64-bit
> division operations in one function, which fails on all 32-bit architectures:
> 
> net/netfilter/xt_hashlimit.o: In function `user2credits':
> xt_hashlimit.c:(.text.user2credits+0x3c): undefined reference to `__aeabi_uldivmod'
> xt_hashlimit.c:(.text.user2credits+0x68): undefined reference to `__aeabi_uldivmod'
> xt_hashlimit.c:(.text.user2credits+0x88): undefined reference to `__aeabi_uldivmod'
> 
> This replaces the division with an explicit call to div_u64 for version 2
> to documents that this is a slow operation, and reverts back to 32-bit arguments
> for the version 1 data to restore the original faster 32-bit division.
> 
> With both changes combined, we no longer get a link error.
> 
> Fixes: 11d5f15723c9 ("netfilter: xt_hashlimit: Create revision 2 to support higher pps rates")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> Vishwanath Pai already sent a patch for this, and I did my version independently.
> The difference is that his version also the more expensive division for the
> version 1 variant that doesn't need it.
> 
> See also http://patchwork.ozlabs.org/patch/676713/
> ---
>  net/netfilter/xt_hashlimit.c | 17 ++++++++++-------
>  1 file changed, 10 insertions(+), 7 deletions(-)
> 
> diff --git a/net/netfilter/xt_hashlimit.c b/net/netfilter/xt_hashlimit.c
> index 44a095ecc7b7..3d5525df6eb3 100644
> --- a/net/netfilter/xt_hashlimit.c
> +++ b/net/netfilter/xt_hashlimit.c
> @@ -464,20 +464,23 @@ static u32 xt_hashlimit_len_to_chunks(u32 len)
>  static u64 user2credits(u64 user, int revision)
>  {
>  	if (revision == 1) {
> +		u32 user32 = user; /* use 32-bit division */
> +

This looks dangerous to me. Have you really tried all possible cases ?

Caller (even if using revision == 1) does
user2credits(cfg->avg * cfg->burst, revision);

Since this is not a fast path, I would prefer to keep the 64bit divide.

Vishwanath version looks safer.

Re: [PATCH 2/3] netfilter: hide reference to nf_hooks_ingress

[Aaron Conole]

Arnd Bergmann <arnd@arndb.de> writes:

> A recent cleanup added an unconditional reference to the nf_hooks_ingress pointer,
> but that fails when CONFIG_NETFILTER_INGRESS is disabled and that member is
> not present in net_device:
>
> net/netfilter/core.c: In function 'nf_set_hooks_head':
> net/netfilter/core.c:96:30: error: 'struct net_device' has no member named 'nf_hooks_ingress'
>
> This avoids the build error by simply enclosing the assignment in an #ifdef,
> which may or may not be the correct fix.

NAK, it's not the right fix.  The entry being set may be leaked with only this
hunk.  I've posted a complete fix for this.

Sorry that it was broken.

Re: [PATCH 3/3] netfilter: xt_hashlimit: uses div_u64 for division

[Vishwanath Pai]

On 09/30/2016 12:38 PM, Eric Dumazet wrote:
> On Fri, 2016-09-30 at 18:05 +0200, Arnd Bergmann wrote:
>> The newly added support for high-resolution pps rates introduced multiple 64-bit
>> division operations in one function, which fails on all 32-bit architectures:
>>
>> net/netfilter/xt_hashlimit.o: In function `user2credits':
>> xt_hashlimit.c:(.text.user2credits+0x3c): undefined reference to `__aeabi_uldivmod'
>> xt_hashlimit.c:(.text.user2credits+0x68): undefined reference to `__aeabi_uldivmod'
>> xt_hashlimit.c:(.text.user2credits+0x88): undefined reference to `__aeabi_uldivmod'
>>
>> This replaces the division with an explicit call to div_u64 for version 2
>> to documents that this is a slow operation, and reverts back to 32-bit arguments
>> for the version 1 data to restore the original faster 32-bit division.
>>
>> With both changes combined, we no longer get a link error.
>>
>> Fixes: 11d5f15723c9 ("netfilter: xt_hashlimit: Create revision 2 to support higher pps rates")
>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>> ---
>> Vishwanath Pai already sent a patch for this, and I did my version independently.
>> The difference is that his version also the more expensive division for the
>> version 1 variant that doesn't need it.
>>
>> See also http://patchwork.ozlabs.org/patch/676713/
>> ---
>>  net/netfilter/xt_hashlimit.c | 17 ++++++++++-------
>>  1 file changed, 10 insertions(+), 7 deletions(-)
>>
>> diff --git a/net/netfilter/xt_hashlimit.c b/net/netfilter/xt_hashlimit.c
>> index 44a095ecc7b7..3d5525df6eb3 100644
>> --- a/net/netfilter/xt_hashlimit.c
>> +++ b/net/netfilter/xt_hashlimit.c
>> @@ -464,20 +464,23 @@ static u32 xt_hashlimit_len_to_chunks(u32 len)
>>  static u64 user2credits(u64 user, int revision)
>>  {
>>  	if (revision == 1) {
>> +		u32 user32 = user; /* use 32-bit division */
>> +
> 
> This looks dangerous to me. Have you really tried all possible cases ?
> 
> Caller (even if using revision == 1) does
> user2credits(cfg->avg * cfg->burst, revision);
> 

It does look like we might lose precision here because of 64bit to 32bit
conversion, but I am not sure how much it matters here. Iirc this is how
it used to be before rev2 code.

> Since this is not a fast path, I would prefer to keep the 64bit divide.
> 

Agreed, this code does not get executed too often for us to worry about
div_u64 being slow. And it reverts back to regular division on 64 bit
arch anyways.

> Vishwanath version looks safer.
> 
> 

-Vishwanath

Re: [PATCH 3/3] netfilter: xt_hashlimit: uses div_u64 for division

[Arnd Bergmann]

On Friday 30 September 2016, Eric Dumazet wrote:
> On Fri, 2016-09-30 at 18:05 +0200, Arnd Bergmann wrote:
> >  net/netfilter/xt_hashlimit.c | 17 ++++++++++-------
> >  1 file changed, 10 insertions(+), 7 deletions(-)
> > 
> > diff --git a/net/netfilter/xt_hashlimit.c b/net/netfilter/xt_hashlimit.c
> > index 44a095ecc7b7..3d5525df6eb3 100644
> > --- a/net/netfilter/xt_hashlimit.c
> > +++ b/net/netfilter/xt_hashlimit.c
> > @@ -464,20 +464,23 @@ static u32 xt_hashlimit_len_to_chunks(u32 len)
> >  static u64 user2credits(u64 user, int revision)
> >  {
> >  	if (revision == 1) {
> > +		u32 user32 = user; /* use 32-bit division */
> > +
> 
> This looks dangerous to me. Have you really tried all possible cases ?

Yes, I'm pretty certain about that: The 11d5f15723c9 patch that introduced this
kept the existing implementation for the revision==1 case, except for changing
the types.

> Caller (even if using revision == 1) does
> user2credits(cfg->avg * cfg->burst, revision);
> 
> Since this is not a fast path, I would prefer to keep the 64bit divide.
>
> Vishwanath version looks safer.

Ok, fair enough. I couldn't tell how much of a fast path this
was, and it's more a general issue that I see with other developers
blindly using div_u64() whenever getting this link error.

Since I already had the patch by the time I saw the other one
(which is also at v3 and got comments), I just sent it out along
with the other two patches I had for netfilter.

I also ended up introducing a typo in a last-minute change, so I'll let
Vishwanath and you work out the best implementation and withdraw my
version.

	Arnd

Re: [PATCH 1/3] netfilter: nf_tables: avoid uninitialized variable warning

[Pablo Neira Ayuso]

On Fri, Sep 30, 2016 at 06:05:34PM +0200, Arnd Bergmann wrote:
> The newly added nft_range_eval() function handles the two possible
> nft range operations, but as the compiler warning points out,
> any unexpected value would lead to the 'mismatch' variable being
> used without being initialized:
> 
> net/netfilter/nft_range.c: In function 'nft_range_eval':
> net/netfilter/nft_range.c:45:5: error: 'mismatch' may be used uninitialized in this function [-Werror=maybe-uninitialized]
> 
> This can be trivially avoided by added a 'default:' clause.

Applied this patch, I took Aaron's and Pai's patches instead.

Thanks anyway for following up on this issue Arnd.

Re: [PATCH 1/3] netfilter: nf_tables: avoid uninitialized variable warning

[Pablo Neira Ayuso]

On Fri, Sep 30, 2016 at 07:47:49PM +0200, Pablo Neira Ayuso wrote:
> On Fri, Sep 30, 2016 at 06:05:34PM +0200, Arnd Bergmann wrote:
> > The newly added nft_range_eval() function handles the two possible
> > nft range operations, but as the compiler warning points out,
> > any unexpected value would lead to the 'mismatch' variable being
> > used without being initialized:
> > 
> > net/netfilter/nft_range.c: In function 'nft_range_eval':
> > net/netfilter/nft_range.c:45:5: error: 'mismatch' may be used uninitialized in this function [-Werror=maybe-uninitialized]
> > 
> > This can be trivially avoided by added a 'default:' clause.
> 
> Applied this patch, I took Aaron's and Pai's patches instead.

Looking at this again, I know uninitialized_var() has been discussed
as not nice since it can hide bugs behind. But if I fix the existing
code to validate priv->op from _init() (this is currently broken), we
can probably use this so save extra code in the packet path for a case
that is not going to happen.

Let me know, thanks!