linux-kernel - Re: [PATCH 0/7] Silence even more W=2 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:	Tue, 23 Sep 2014 10:22:09 +0200
From:	Borislav Petkov <bp@...en8.de>
To:	"Rustad, Mark D" <mark.d.rustad@...el.com>
Cc:	"Kirsher, Jeffrey T" <jeffrey.t.kirsher@...el.com>,
	"sparse@...isli.org" <sparse@...isli.org>,
	"linux-sparse@...r.kernel.org" <linux-sparse@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 0/7] Silence even more W=2 warnings

On Mon, Sep 22, 2014 at 09:50:54PM +0000, Rustad, Mark D wrote:
> On Sep 22, 2014, at 1:33 PM, Borislav Petkov <bp@...en8.de> wrote:
> 
> > Btw, out of curiosity, what is your use case for staring at those W=2
> > warnings?
> 
> I know no one cares about out-of-tree drivers, but I have a hack that

Yah :-)

> allows building out-of-tree drivers without getting warnings from the
> kernel includes. We do an automated compile of every patch with W=12
> and expect clean compiles.
> 
> It would be nice to compile drivers in-tree and have a similar expectation.
> I guess a similar hack could be developed, but since we are contributing
> upstream, I would rather uncover any potential issues that may exist, even
> if they aren't in the driver. The hack would tend to cover up such issues.
> This is definitely NOT about covering up things that could be problems!

Yeah, as I said in the other mail to Jeff, I think there are a couple of
things to be pointed out:

* Fixing those is a good idea if the fixes are clean - I think we all
agree by now that adding code just to shut up gcc is not nice.

* Then, even if all those warnings were fixed one fine day, the people
who fix them would be fighting windmills because every new patch which
adds new places causing those warnings would simply go in because the
warnings are not visible in default builds.

So the question IMO turns into: are there some warnings which we should
promote to default builds so that they get taken care of eventually...

> Well, I have W=1 in my environment, so I don't even have to ask for it, I
> just get it.

I think this was the initial use case we had in mind for W= - use it
during development in order to have the compiler do extra checks to your
code. And it has caught a couple of issues, FWIW.

> W=12 is just insane, or I would use that all the time. I think it
> would be nice for new code, or at least new drivers, to compile clean
> with W=12, but that isn't possible when the kernel includes throw so
> many warnings.

Right, see above.

> Nested-externs, for example, can catch people gratuitously providing a
> function prototype that could become a hazard, but some use of that may
> be justified. The macros provide a way to specifically allow certain
> instances while generally discouraging it. Of course if you never use
> W=2 you may never catch those gratuitous declarations.

Sure, but the cost for fixing that is what bothers me. For that
particular case, it probably would even be cleaner to add a
nested-extern check to checkpatch instead of cluttering the code with
those macros.

> Hopefully the discussion is somewhat useful.

Well, it has become already, as you can see. :-D

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
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/