linux-kernel - Re: [PATCH 11/11] perf: Avoid uninitialized sample type reference in __perf_event__output_id

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: <20131004062427.GD11399@gmail.com>
Date:	Fri, 4 Oct 2013 08:24:27 +0200
From:	Ingo Molnar <mingo@...nel.org>
To:	Andi Kleen <ak@...ux.intel.com>
Cc:	Peter Zijlstra <peterz@...radead.org>,
	Andi Kleen <andi@...stfloor.org>, linux-kernel@...r.kernel.org,
	eranian@...gle.com
Subject: Re: [PATCH 11/11] perf: Avoid uninitialized sample type reference in
 __perf_event__output_id_sample

* Andi Kleen <ak@...ux.intel.com> wrote:

> > Forcing multiple, unnecessary rounds of emails instead of clearly 
> > volunteering all technical information that is related to the matter 
> > is something Andi is still doing routinely.
> 
> Sorry all the information was in the full email thread (including the 
> intro). And the patch description clearly described the problem in your 
> code.
> 
> As the patches spanned many subsystems you were only copied on the 
> patches that affect your subsystem, and not on the intro (as git 
> send-email doesn't seem to support that)
> 
> Here are possible alternatives. Please let me know which ones you prefer 
> and I'll try to adapt to your specific preferences in the future:
> 
> [ ] Always copy you guys on all patches of 
> subsystem spanning patch kits that are mostly of no relevance
> to you. 
> 
> [ ] Repeat the complete intro in every patch.
> 
> [ ] You think uninitialized are not a problem and you
> don't want to see any patches related to that.
> 
> [ ] You are not interested in fixing static checker problems in your
> subsystem and don't want to see any patches related to that.

  [x] Fix your changelog. Any commit log that is not self-describing to a
  maintainer like PeterZ is faulty by definition - regardless of any intro
  somewhere else. Changelogs ultimately detach from intros, they will be 
  read by others in the kernel repo, reviewing changes, looking for bugs,
  following development, etc., and if the relevant context is lost then
  that changelog is _BROKEN_. This is kernel development 101.

  [x] You should stop making idiotic excuses for broken changelogs. The
  fact that we had to complain about the quality of your patches and 
  changelogs for years should give you a big, huge hint that the problem 
  is still on your side. Writing snarky responses to maintainer questions 
  does not improve your changelogs, it only wastes PeterZ's, my and other 
  people's time.

Thanks,

	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/