linux-kernel - Re: [PATCH 07/32] mm: Bring back vmalloc

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: <dcf8648b-c367-47a5-a2b6-94fb07a68904@app.fastmail.com>
Date:   Tue, 20 Jun 2023 11:15:25 -0700
From:   "Andy Lutomirski" <luto@...nel.org>
To:     "Kent Overstreet" <kent.overstreet@...ux.dev>
Cc:     "Mark Rutland" <mark.rutland@....com>,
        "Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>,
        linux-fsdevel@...r.kernel.org,
        "linux-bcachefs@...r.kernel.org" <linux-bcachefs@...r.kernel.org>,
        "Kent Overstreet" <kent.overstreet@...il.com>,
        "Andrew Morton" <akpm@...ux-foundation.org>,
        "Uladzislau Rezki" <urezki@...il.com>,
        "hch@...radead.org" <hch@...radead.org>, linux-mm@...ck.org,
        "Kees Cook" <keescook@...omium.org>,
        "the arch/x86 maintainers" <x86@...nel.org>
Subject: Re: [PATCH 07/32] mm: Bring back vmalloc_exec

On Tue, Jun 20, 2023, at 11:08 AM, Kent Overstreet wrote:
> On Tue, Jun 20, 2023 at 10:42:02AM -0700, Andy Lutomirski wrote:
>> Code is either correct, and comes with an explanation as to how it is
>> correct, or it doesn't go in.  Saying that something is like BPF is
>> not an explanation as to how it's correct.  Saying that someone has
>> not come up with the chain of events that causes a mere violation of
>> architecture rules to actual incorrect execution is not an explanation
>> as to how something is correct.
>
> No, I'm saying your concerns are baseless and too vague to address.

If you don't address them, the NAK will stand forever, or at least until a different group of people take over x86 maintainership.  That's fine with me.

I'm generally pretty happy about working with people to get their Linux code right.  But no one is obligated to listen to me.

>
>> text_poke() by itself is *not* the proper API, as discussed.  It
>> doesn't serialize adequately, even on x86.  We have text_poke_sync()
>> for that.
>
> Andy, I replied explaining the difference between text_poke() and
> text_poke_sync(). It's clear you have no idea what you're talking about,
> so I'm not going to be wasting my time on further communications with
> you.

No problem.  Then your x86 code will not be merged upstream.

Best of luck with the actual filesystem parts!

--Andy