linux-kernel - Re: [PATCH v3 00/23] Use asm-generic for mmu

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]

Date:   Mon, 19 Oct 2020 11:00:16 +1000
From:   Nicholas Piggin <npiggin@...il.com>
To:     Arnd Bergmann <arnd@...db.de>,
        Stephen Rothwell <sfr@...b.auug.org.au>
Cc:     linux-arch <linux-arch@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Linux-MM <linux-mm@...ck.org>
Subject: Re: [PATCH v3 00/23] Use asm-generic for mmu_context no-op functions

Excerpts from Arnd Bergmann's message of October 10, 2020 6:25 pm:
> On Sat, Oct 10, 2020 at 4:02 AM Stephen Rothwell <sfr@...b.auug.org.au> wrote:
>> On Fri, 9 Oct 2020 16:01:22 +0200 Arnd Bergmann <arnd@...db.de> wrote:
>>
>> > Are there other changes that depend on this? If not, I would
>> > just wait until -rc1 and then either push the branch correctly or
>> > rebase the patches on that first, to avoid pushing something that
>> > did not see the necessary testing.
>>
>> If it is useful enough (or important enough), then put in in your
>> linux-next included branch, but don't ask Linus to merge it until the
>> second week of the merge window ... no worse than some other stuff I
>> see :-(
> 
> By itself, it's a nice cleanup, but it doesn't provide any immediate
> benefit over the previous state, while potentially introducing a
> regression in one of the less tested architectures.
> 
> The question to me is really whether Nick has any pending work
> that he would like to submit after this branch is merged into
> mainline.

Not for this merge window but I was hoping to submit something for
improving lazy tlb handling in the next one.

Thanks,
Nick