Re: Recurring INEQUIVALENT ALIASES issues and userland corruption/crashes

[John David Anglin <dave.anglin@bell.net>]

On 2022-04-19 5:52 p.m., James Bottomley wrote:
> On Tue, 2022-04-19 at 17:29 -0400, John David Anglin wrote:
>>   We know that the PDC call to determine cache
>> characteristics indicates that the alias boundary on PA8800/PA8900 is
>> larger than 16 MB.
> Sorry, late to the party.  What the PDC tells you is unreliable.
Are you sure?  The PDC reference that I have is version 1.1E dated July 22, 2004.
That's after the c8000 and rp34xx were released.

It seems likely that the PDC firmware would have returned the value for 4 MB
if that were the case for these machines.
>   
> However, the Architecture guide Appendix F says "These rules provide
> offset aliasing on 16 Mbyte boundaries, with optional support for
> offset aliasing on smaller power of two sized boundaries, and either
> restricted or unlimited space aliasing."
Correct.  The Architecture that I have has an errata note changing the value
from 1 MB to 16 MB.  However, if you search on equivalent aliases you will
find inconsistencies in the number of offset bits (requirement 2).
>
> So unless someone has an update to the architecture guide, 16MB as a
> cache stride is architecturally required to work.  The tmpalias code in
> pacache.S is predicated on an assurance by the old HP chip designers
> that no chip was released with a cache stride greater than 4MB, meaning
> we could safely relax the 16MB architectural rules down to 4MB.
The patches that I sent change to hard coded bit definitions in pacache.S and
entry.S.  This makes it easy to test any alias boundary.  I went with 64 MB for
CONFIG_64BIT since a 128 MB region is only a small part of the address space.
It seemed to me unlikely that the alias boundary would be larger than the size
of the L2 cache.

I still don't know why the tmpalias code doesn't work for kernel virtual addresses.
Yet, even 4 MB seems to work fine for user virtual addresses.

As far as I can tell, space register hashing is off.

While it easy to make the tmpalias region larger, it not easy to increase SHM_COLOUR
which is currently 0x00400000.

It appears the gentoo folks are still having problems with random segmentation faults.
Yet, I'm not seeing them at anywhere near the same rate as other debian buildds.

Withe the patch, it's relatively easy to swithch between tmpalias flushing and flushing
through the user mappings.  Performance is about the same.

Dave

-- 
John David Anglin  dave.anglin@bell.net