linux-kernel - Re: [PATCH -tip] drivers/serial/8250.c: 'i' may be used uninitialized

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:	Wed, 1 Oct 2008 10:48:25 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Steven Noonan <steven@...inklabs.net>
Cc:	linux-kernel@...r.kernel.org, alan@...rguk.ukuu.org.uk
Subject: Re: [PATCH -tip] drivers/serial/8250.c: 'i' may be used
	uninitialized

* Steven Noonan <steven@...inklabs.net> wrote:

> I was kind of worried about being exceedingly verbose, but I 
> understand your point perfectly. I'm going to resend the patch with an 
> appropriately verbose comment.
> 
> As always, I appreciate the criticism. Thank you! :)

I have yet to meet a too verbose commit log, and i've seen many - so 
there's basically no way you can stretch. Our problem 99% of the time is 
that commit logs are either not verbose at all, or are structured in a 
way that makes it hard to interpret them.

If you think a change is too verbose, you could start using the 
'Impact:' line convention we recently started using in the x86 tree. 
Something like:

 serial, 8250.c: fix warning: 'i' may be used uninitialized

 Impact: cleanup, fix bogus gcc warning

 serial_unlink_irq_chain() does not initialize iterator 'i', and that is
 correct logically because it is always initialized due to XYZ. Gcc does
 not realize this connection and emits a false warning. Annotate it with
 uninitialized_var().

 Signed-off-by: Steven Noonan <steven@...inklabs.net>

Other good 'Impact:' tags are:

  Impact: fix boot crash
  Impact: style cleanup
  Impact: documentation fix

it's a "see impact at a glance" kind of thing. Maintainers will still 
read the rest and the code as well, but the thought process is much 
smoother: the maintainer can concentrate on "does what the patch does 
meet the expectation spelled out in the changelog", instead of spending 
time on "what does this patch do" thinking.

	Ingo
--
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/