linux-kernel - Re: [PATCH -mm] drivers/md/: Shut up uninitialized variable warnings

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:	Mon, 3 Sep 2007 02:27:48 +0530 (IST)
From:	Satyam Sharma <satyam@...radead.org>
To:	Jeff Garzik <jeff@...zik.org>
cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Alasdair G Kergon <agk@...hat.com>, dm-devel@...hat.com,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH -mm] drivers/md/: Shut up uninitialized variable
 warnings



On Sun, 2 Sep 2007, Jeff Garzik wrote:

> Satyam Sharma wrote:
> > drivers/md/dm-exception-store.c: In function ‘persistent_read_metadata’:
> > drivers/md/dm-exception-store.c:452: warning: ‘new_snapshot’ may be used
> > uninitialized in this function
> > 
> > drivers/md/dm-ioctl.c: In function ‘ctl_ioctl’:
> > drivers/md/dm-ioctl.c:1407: warning: ‘param’ may be used uninitialized in
> > this function
> > 
> > [ For these, I'd like to especially add -- shame on you, gcc! ]
> > 
> > drivers/md/dm-table.c: In function ‘dm_get_device’:
> > drivers/md/dm-table.c:472: warning: ‘dev’ may be used uninitialized in this
> > function
> > 
> > are all verified to be bogus warnings. Let's shut them up.
> > 
> > ---
> > 
> >  drivers/md/dm-exception-store.c |    3 ++-
> >  drivers/md/dm-ioctl.c |    2 +-
> >  drivers/md/dm-table.c |    2 +-
> >  3 file changed, 4 insertions(+), 3 deletion(-)
> 
> same comment as with the last uninit'd var patch:  these markers should be
> used sparingly.  Try it on multiple compiler versions, see if it's a new
> behavior.
> 
> Quite realistically, you might actually be finding gcc bugs,

Definitely -- a lot of these patches are purely a result of gcc's shoddy
inadequacies. I do intend filing reports with gcc, however ...

> implying the
> proper path is to file a gcc bug report (and they are _very_ diligent about
> handling these, its impressive) rather than to patch the Linux kernel.

My experience (regarding gcc's diligence in dealing with bug reports) has
been otherwise :-)

Anyway, I once had a _very_ similar discussion with Andrew (regarding some
other gcc bug) previously, and the (completely correct) point he made was
that: firstly, there's no guarantee they'll get this sorted out asap, and
even if they did, we'll still not be dropping support for older gcc
versions anyway ...