linux-kernel - Re: [Patch v2 4/4] x86/speculation: Add prctl to control indirect branch speculation per process

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: <20181003072528.GA98965@gmail.com>
Date:   Wed, 3 Oct 2018 09:25:28 +0200
From:   Ingo Molnar <mingo@...nel.org>
To:     Tim Chen <tim.c.chen@...ux.intel.com>
Cc:     Jiri Kosina <jikos@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Tom Lendacky <thomas.lendacky@....com>,
        Ingo Molnar <mingo@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        Andrea Arcangeli <aarcange@...hat.com>,
        David Woodhouse <dwmw@...zon.co.uk>,
        Andi Kleen <ak@...ux.intel.com>,
        Dave Hansen <dave.hansen@...el.com>,
        Casey Schaufler <casey.schaufler@...el.com>,
        Asit Mallick <asit.k.mallick@...el.com>,
        Arjan van de Ven <arjan@...ux.intel.com>,
        Jon Masters <jcm@...hat.com>, linux-kernel@...r.kernel.org,
        x86@...nel.org
Subject: Re: [Patch v2 4/4] x86/speculation: Add prctl to control indirect
 branch speculation per process

* Tim Chen <tim.c.chen@...ux.intel.com> wrote:

> Thanks for the corrections.  I'll update the patchset.

Please also go beyond the direct review feedback me and Thomas gave, and pro-actively look out 
for similar patterns of mistakes in these patches and in all future patches you send.

As Thomas's and my review made it abundantly clear, this patch series has a very high 
proportion of small, indefensible trivial quality problems.

If the root of the problem is that you are sending out patches too fast then please *read* your 
own code and changelogs more than once before sending it to lkml, fix trivial mistakes and 
coding style so that others don't have to waste time over trivialities.

If the root of the problem is that you don't have enough time to spend on these patches then 
you should perhaps delay your next series for another day or two, use more time to review the 
series, before sending it for an upstream merge.

I.e. please make a serious effort to improve patch and changelog quality in the future.

Thanks,

	Ingo