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]
Message-ID: <20081001084825.GA25009@elte.hu>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ