linux.git/arch/parisc/kernel/cache.c, branch v6.5

parisc: Add cacheflush() syscall

2023-06-30T15:14:13+00:00

Signed-off-by: Helge Deller

parisc: add pte_unmap() to balance get_ptep()

2023-06-19T23:19:07+00:00

To keep balance in future, remember to pte_unmap() after a successful
get_ptep().  And act as if flush_cache_pages() really needs a map there,
to read the pfn before "unmapping", to be sure page table is not removed.

Link: https://lkml.kernel.org/r/653369-95ef-acd2-d6ea-e95f5a997493@google.com
Signed-off-by: Hugh Dickins 
Cc: Alexander Gordeev 
Cc: Alexandre Ghiti 
Cc: Aneesh Kumar K.V 
Cc: Catalin Marinas 
Cc: Christian Borntraeger 
Cc: Chris Zankel 
Cc: Claudio Imbrenda 
Cc: David Hildenbrand 
Cc: "David S. Miller" 
Cc: Geert Uytterhoeven 
Cc: Greg Ungerer 
Cc: Heiko Carstens 
Cc: Helge Deller 
Cc: "H. Peter Anvin" 
Cc: Ingo Molnar 
Cc: John David Anglin 
Cc: John Paul Adrian Glaubitz 
Cc: Kirill A. Shutemov 
Cc: Matthew Wilcox (Oracle) 
Cc: Max Filippov 
Cc: Michael Ellerman 
Cc: Michal Simek 
Cc: Mike Kravetz 
Cc: Mike Rapoport (IBM) 
Cc: Palmer Dabbelt 
Cc: Peter Zijlstra 
Cc: Qi Zheng 
Cc: Russell King 
Cc: Suren Baghdasaryan 
Cc: Thomas Bogendoerfer 
Cc: Thomas Gleixner 
Cc: Will Deacon 
Signed-off-by: Andrew Morton

parisc: Fix flush_dcache_page() for usage from irq context

2023-05-24T17:03:49+00:00

Since at least kernel 6.1, flush_dcache_page() is called with IRQs
disabled, e.g. from aio_complete().

But the current implementation for flush_dcache_page() on parisc
unintentionally re-enables IRQs, which may lead to deadlocks.

Fix it by using xa_lock_irqsave() and xa_unlock_irqrestore()
for the flush_dcache_mmap_*lock() macros instead.

Cc: linux-parisc@vger.kernel.org
Cc: stable@kernel.org # 5.18+
Signed-off-by: Helge Deller

parisc: remove mmap linked list from cache handling

2022-09-27T02:46:19+00:00

Use the VMA iterator instead.

Link: https://lkml.kernel.org/r/20220906194824.2110408-33-Liam.Howlett@oracle.com
Signed-off-by: Matthew Wilcox (Oracle) 
Signed-off-by: Liam R. Howlett 
Acked-by: Vlastimil Babka 
Reviewed-by: Davidlohr Bueso 
Tested-by: Yu Zhao 
Cc: Catalin Marinas 
Cc: David Hildenbrand 
Cc: David Howells 
Cc: SeongJae Park 
Cc: Sven Schnelle 
Cc: Will Deacon 
Signed-off-by: Andrew Morton

Merge tag 'for-5.20/parisc-1' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux

2022-08-05T16:58:58+00:00

Pull parisc updates from Helge Deller:
 "One real bugfix to change the io_pgetevents_time64() syscall to use
  the compat implementation when running in compat mode, otherwise the
  signed int32 parameters min_nr and nr will be incorrectly handled as
  unsigned int64 values.

  Other than that just small cleanups:

   - hardware database housekeeping and proper /proc/iomem output

   - add proper function exit code if probe functions fail

   - drop stale variables (pa_swapper_pg_lock)

   - drop unneccessary zero-initializations

   - typo fixes in comments"

* tag 'for-5.20/parisc-1' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux:
  Input: gscps2 - check return value of ioremap() in gscps2_probe()
  parisc: io_pgetevents_time64() needs compat syscall in 32-bit compat mode
  parisc: Drop zero variable initialisations in mm/init.c
  parisc: Do not initialise statics to 0
  parisc: Check the return value of ioremap() in lba_driver_probe()
  parisc: Drop pa_swapper_pg_lock spinlock
  parisc: Fix comment typo in fault.c
  parisc: Fix device names in /proc/iomem
  parisc: Clean up names in hardware database

parisc: Drop pa_swapper_pg_lock spinlock

2022-08-01T16:43:23+00:00

This spinlock was dropped with commit b7795074a046 ("parisc: Optimize
per-pagetable spinlocks") in kernel v5.12.

Remove it to silence a sparse warning.

Signed-off-by: Helge Deller 
Reported-by: kernel test robot 
Cc:  # v5.12+

highmem: Make __kunmap_{local,atomic}() take const void pointer

2022-07-25T15:45:40+00:00

__kunmap_ {local,atomic}() currently take pointers to void. However, this
is semantically incorrect, since these functions do not change the memory
their arguments point to.

Therefore, make this semantics explicit by modifying the
__kunmap_{local,atomic}() prototypes to take pointers to const void.

As a side effect, compilers may produce more efficient code.

Acked-by: Andrew Morton 
Acked-by: Helge Deller   # parisc
Suggested-by: David Sterba 
Suggested-by: Ira Weiny 
Reviewed-by: Ira Weiny 
Signed-off-by: Fabio M. De Francesco 
Reviewed-by: David Sterba 
Signed-off-by: David Sterba

parisc: Fix flush_anon_page on PA8800/PA8900

2022-06-26T10:23:15+00:00

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.

Signed-off-by: John David Anglin 
Signed-off-by: Helge Deller 
Cc: stable@vger.kernel.org   # v5.18+

parisc: Don't enforce DMA completion order in cache flushes

2022-05-23T11:44:24+00:00

The only place we need to ensure all outstanding cache coherence
operations are complete is in invalidate_kernel_vmap_range. All
parisc drivers synchronize DMA operations internally and do not
call invalidate_kernel_vmap_range. We only need this for non-coherent
I/O operations.

Signed-off-by: John David Anglin 
Signed-off-by: Helge Deller

parisc: Rewrite cache flush code for PA8800/PA8900

2022-05-17T19:52:47+00:00

Originally, I was convinced that we needed to use tmpalias flushes
everwhere, for both user and kernel flushes. However, when I modified
flush_kernel_dcache_page_addr, to use a tmpalias flush, my c8000
would crash quite early when booting.

The PDC returns alias values of 0 for the icache and dcache. This
indicates that either the alias boundary is greater than 16MB or
equivalent aliasing doesn't work. I modified the tmpalias code to
make it easy to try alternate boundaries. I tried boundaries up to
128MB but still kernel tmpalias flushes didn't work on c8000.

This led me to conclude that tmpalias flushes don't work on PA8800
and PA8900 machines, and that we needed to flush directly using the
virtual address of user and kernel pages. This is likely the major
cause of instability on the c8000 and rp34xx machines.

Flushing user pages requires doing a temporary context switch as we
have to flush pages that don't belong to the current context. Further,
we have to deal with pages that aren't present. If a page isn't
present, the flush instructions fault on every line.

Other code has been rearranged and simplified based on testing. For
example, I introduced a flush_cache_dup_mm routine. flush_cache_mm
and flush_cache_dup_mm differ in that flush_cache_mm calls
purge_cache_pages and flush_cache_dup_mm calls flush_cache_pages.
In some implementations, pdc is more efficient than fdc. Based on
my testing, I don't believe there's any performance benefit on the
c8000.

Signed-off-by: John David Anglin 
Signed-off-by: Helge Deller