linux-kernel - Re: [PATCH v3 5/6] x86/ftrace: Use text

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: <20200130141733.krfdmirathscgkkp@treble>
Date:   Thu, 30 Jan 2020 08:17:33 -0600
From:   Josh Poimboeuf <jpoimboe@...hat.com>
To:     Petr Mladek <pmladek@...e.com>
Cc:     Miroslav Benes <mbenes@...e.cz>,
        Peter Zijlstra <peterz@...radead.org>,
        Steven Rostedt <rostedt@...dmis.org>,
        Joe Lawrence <joe.lawrence@...hat.com>,
        Jessica Yu <jeyu@...nel.org>, x86@...nel.org,
        linux-kernel@...r.kernel.org, mhiramat@...nel.org,
        bristot@...hat.com, jbaron@...mai.com,
        torvalds@...ux-foundation.org, tglx@...utronix.de,
        mingo@...nel.org, namit@...are.com, hpa@...or.com, luto@...nel.org,
        ard.biesheuvel@...aro.org, live-patching@...r.kernel.org,
        Randy Dunlap <rdunlap@...radead.org>, nstange@...e.de
Subject: Re: [PATCH v3 5/6] x86/ftrace: Use text_poke()

On Thu, Jan 30, 2020 at 10:53:46AM +0100, Petr Mladek wrote:
> On Wed 2020-01-29 09:59:51, Josh Poimboeuf wrote:
> > In retrospect, the prerequisites for merging it should have been:
> 
> OK, let me do one more move in this game.
> 
> 
> > 1) Document how source-based patches can be safely generated;
> 
> I agree that the information are really scattered over many files
> in Documentation/livepatch/.

Once again you're blithely ignoring my point and pretending I'm saying
something else.  And you did that again further down in the email, but
what's the point of arguing if you're not going to listen.

This has nothing to do with the organization of the existing
documentation.  When did I say that?

Adding the -flive-patching flag doesn't remove *all*
function-ABI-breaking optimizations.  It's only a partial solution.  The
rest of the solution involves tooling and processes which need to be
documented.  But you already know that.

If we weren't co-maintainers I would have reverted the patch days ago.
I've tried to give you all the benefit of the doubt.  But you seem to be
playing company politics.

I would ask that you please put on your upstream hats and stop playing
politics.  If the patch creation process is a secret, then by all means,
keep it secret.  But then keep your GCC flag to yourself.

-- 
Josh