Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Thu, 10 Mar 2022 10:46:08 +0000 (GMT)
From:   "Maciej W. Rozycki" <macro@orcam.me.uk>
To:     Thomas Bogendoerfer <tsbogend@alpha.franken.de>
cc:     linux-mips@vger.kernel.org, linux-kernel@vger.kernel.org,
        arnd@kernel.org
Subject: Re: [PATCH] MIPS: Handle address errors for accesses above CPU max
 virtual user address
In-Reply-To: <20220222155345.138861-1-tsbogend@alpha.franken.de>
Message-ID: <alpine.DEB.2.21.2203101040530.47558@angie.orcam.me.uk>
References: <20220222155345.138861-1-tsbogend@alpha.franken.de>
User-Agent: Alpine 2.21 (DEB 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Precedence: bulk

On Tue, 22 Feb 2022, Thomas Bogendoerfer wrote:

> Address errors have always been treated as unaliged accesses and handled
> as such. But address errors are also issued for illegal accesses like
> user to kernel space or accesses outside of implemented spaces. This
> change implements Linux exception handling for accesses to the illegal
> space above the CPU implemented maximum virtual user address and the
> MIPS 64bit architecture maximum. With this we can now use a fixed value
> for the maximum task size on every MIPS CPU and get a more optimized
> access_ok().

 Decades ago I had a patch to handle this with CPU-specific limits, which 
in the end I have not submitted for one reason or another.  I guess we 
didn't have what is `cpu_vmbits' nowadays.  I'll see if I can dig it out 
and check if there's anything interesting there we might also require.

 Overall good work, and I'm rather embarassed we have gone so far without 
it.  Thanks!

  Maciej