linux-kernel - Re: [PATCH v2 0/1] arm/arm64: add support for folded p4d page tables

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:   Fri, 24 Jan 2020 14:02:37 +0000
From:   Quentin Perret <qperret@...gle.com>
To:     Marc Zyngier <maz@...nel.org>
Cc:     Will Deacon <will@...nel.org>, Mike Rapoport <rppt@...nel.org>,
        Anshuman Khandual <anshuman.khandual@....com>,
        Catalin Marinas <catalin.marinas@....com>,
        Russell King <linux@...linux.org.uk>,
        linux-kernel@...r.kernel.org, linux-mm@...ck.org,
        linux-arm-kernel@...ts.infradead.org,
        Mike Rapoport <rppt@...ux.ibm.com>,
        kvmarm@...ts.cs.columbia.edu, kernel-team@...roid.com
Subject: Re: [PATCH v2 0/1] arm/arm64: add support for folded p4d page tables

On Friday 24 Jan 2020 at 13:34:35 (+0000), Marc Zyngier wrote:
> I don't disagree at all. To be honest, I've been on the cusp of getting
> rid of it for a while, for multiple reasons:
> 
> - It has no users (as you noticed)
> - It is hardly tested (a consequence of the above)
> - It isn't feature complete (no debug, no PMU)
> - It doesn't follow any of the evolution of the architecture (a more
>   generic feature of the 32bit port, probably because people run their
>   64bit-capable cores in 64bit mode)
> - It is becoming a mess of empty stubs
> 
> The maintenance aspect hasn't been a real problem so far. Even the NV
> support is only about 200 lines of stubs. But what you have in mind is
> going to be much more invasive, and I wouldn't want an unused feature to
> get in the way.
> 
> What I may end-up doing is to send a RFC series to remove the 32bit host
> support from the tree during in the 5.6 cycle, targeting 5.7. If someone
> shouts loudly during that time frame, we keep it and you'll have to work
> around it. If nobody cares, then dropping it is the right thing to do.
> 
> Would that be OK with you?

Absolutely. And yes, if there are users of the 32 bits port, it'll be on
us to work around in a clean way, but I think this is perfectly fair.
I'll be happy to try and test your RFC series when it goes on the list
if that can help.

Thanks!
Quentin