linux-kernel - Re: [announce] new tree: "fix all build warnings, on all configs"

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]

Date:	Fri, 17 Oct 2008 20:05:23 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Roland Dreier <rdreier@...co.com>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"David S. Miller" <davem@...emloft.net>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	linux-kernel@...r.kernel.org,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>,
	David Howells <dhowells@...hat.com>
Subject: Re: [announce] new tree: "fix all build warnings, on all configs"


* Roland Dreier <rdreier@...co.com> wrote:

>  > diff --git a/drivers/net/mlx4/mcg.c b/drivers/net/mlx4/mcg.c
>  > index c83f88c..d1230a8 100644
>  > --- a/drivers/net/mlx4/mcg.c
>  > +++ b/drivers/net/mlx4/mcg.c
>  > @@ -215,7 +215,7 @@ int mlx4_multicast_attach(struct mlx4_dev *dev, struct mlx4_qp *qp, u8 gid[16],
>  >  
>  >  	if (block_mcast_loopback)
>  >  		mgm->qp[members_count++] = cpu_to_be32((qp->qpn & MGM_QPN_MASK) |
>  > -						       (1 << MGM_BLCK_LB_BIT));
>  > +						       (1U << MGM_BLCK_LB_BIT));
> 
> This is fixing a warning caused by a gcc bug 
> (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37261) which is fixed 
> upstream.  The change is rather inoffensive but on the other hand I'm 
> not sure what our policy for dealing with version-specific warning 
> bugs in gcc should be.

the full commit is below - i researched it when i created it and indeed 
it seemed like an incorrect warning.

OTOH, there should be a well-defined work flow to keep this all 
manageable: once we know why a warning triggers and it has been 
categorized by a human, we should get rid of the warning in some way. 

Applying this patch as-is would be one option. Annotating it with a 
specific gcc version would be overkill i think. Ignoring it would be 
bad, because there's real value in standardizing on a "no warnings" 
build output. Many new warnings get introduced because people do not 
notice new warnings amongst the very high baseline noise of the kernel 
build.

What do you think?

	Ingo

--------->
>From 367bb845bef83d64cfee452a18a84fd65f21d401 Mon Sep 17 00:00:00 2001
From: Ingo Molnar <mingo@...e.hu>
Date: Mon, 18 Aug 2008 16:18:34 +0200
Subject: [PATCH] fix warning in drivers/net/mlx4/mcg.c
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit

fix warning:

  drivers/net/mlx4/mcg.c: In function ‘mlx4_multicast_attach’:
  drivers/net/mlx4/mcg.c:217: warning: integer overflow in expression

there was no real danger of overflow here though.

md5:
   db8eb55620f886c03854a2abb2ce6c3f  mcg.o.before.asm
   db8eb55620f886c03854a2abb2ce6c3f  mcg.o.after.asm

Signed-off-by: Ingo Molnar <mingo@...e.hu>
---
 drivers/net/mlx4/mcg.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/net/mlx4/mcg.c b/drivers/net/mlx4/mcg.c
index c83f88c..d1230a8 100644
--- a/drivers/net/mlx4/mcg.c
+++ b/drivers/net/mlx4/mcg.c
@@ -215,7 +215,7 @@ int mlx4_multicast_attach(struct mlx4_dev *dev, struct mlx4_qp *qp, u8 gid[16],
 
 	if (block_mcast_loopback)
 		mgm->qp[members_count++] = cpu_to_be32((qp->qpn & MGM_QPN_MASK) |
-						       (1 << MGM_BLCK_LB_BIT));
+						       (1U << MGM_BLCK_LB_BIT));
 	else
 		mgm->qp[members_count++] = cpu_to_be32(qp->qpn & MGM_QPN_MASK);
 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/