linux-kernel - Re: [PATCH 2/4] SCHED: Remove BKL accounting from schedstats

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] [day] [month] [year] [list]

Message-ID: <20110507081602.GB25065@elte.hu>
Date:	Sat, 7 May 2011 10:16:02 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Andi Kleen <andi@...stfloor.org>
Cc:	linux-kernel@...r.kernel.org, peterz@...radead.org, arnd@...db.de,
	akpm@...ux-foundation.org, Andi Kleen <ak@...ux.intel.com>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH 2/4] SCHED: Remove BKL accounting from schedstats

* Andi Kleen <andi@...stfloor.org> wrote:

> From: Andi Kleen <ak@...ux.intel.com>
> 
> Remove the BKL accounting from schedstats.
> 
> I removed the field from the debug file too, in theory
> it could be kept as 0 for compatibility.
> 
> Signed-off-by: Andi Kleen <ak@...ux.intel.com>
> ---
>  include/linux/sched.h |    4 ----
>  kernel/sched.c        |    6 ------
>  kernel/sched_debug.c  |    3 ---
>  3 files changed, 0 insertions(+), 13 deletions(-)

The thing is, and this is rather amazing: not a *single* patch in your patch 
series gets the patch title right ...

Andi, how hard is it for you to type 'git log kernel/sched.c' (and 'git log 
kernel/mutex.c', etc.) and see what the commit title convention the affected 
kernel subsystem has, and follow that convention, so that the maintainer does 
not have to edit every single patch of your series?

You are not a kernel newbie, you've been a kernel developer for how many years? 

You are showing an amazing level of inattention, which makes me very reluctant 
to even look at your patches, all of which touch tricky pieces of code.

You badly need to improve the quality of your patches. You could start that by 
feeding patches to a third party who knows how to submit patches upstream and 
who can sign off to them and forward them to the right maintainers.

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/