On 2022-06-18 1:08 p.m., Rolf Eike Beer wrote:
Am Samstag, 18. Juni 2022, 17:14:34 CEST schrieb John David Anglin:
Anonymous pages are allocated with the shared mappings colouring,
SHM_COLOUR. Since the alias boundary on machines with PA8800 and
PA8900 processors is unknown, flush_user_cache_page() might not
flush all mappings of a shared anonymous page. Flushing the whole
data cache flushes all mappings.
This won't fix all coherency issues with shared mappings but it
seems to work well in practice. I haven't seen any random memory
faults in almost a month on a rp3440 running as a debian buildd
machine.
There is a small preformance hit.
Is there a limit we can limit this to the given CPU types? And given that this
It is limited to PA8800 and PA8900 CPUs by the parisc_requires_coherency() check.
There are already a bunch of similar checks in cache.c that have comments (e.g.,
range an mm flush routines).
seems to be a best effort workaround I would suggest adding a comment in the
code as explaining why this happens, otherwise someone looking at the code in
3 years may not get the point of it and a quick test will just show "oh, it
works without that".
The change is not a best effort workaround. Flushing the whole data cache always flushes
all aliases to a page. It could be used for all anonymous page flushes but it is slow.
Shared anonymous mappings only work when the mappings are equivalent or meet the
requirements for multi reader, single writer. The problem is we don't in general know what
mappings are equivalent on PA8800/PA8900 processors.
There is a comment about the alias boundary of machines with PA8800/PA8900
processors in arch/parisc/include/asm/fixmap.h. This is why we can't flush all aliases
of a shared page with single flush or use tmpalias flushes on these machines. Sometimes
they work and sometimes they don't.
Dave
--
John David Anglin dave.anglin@xxxxxxxx
