kernel.git/arch/parisc/kernel, branch linux-5.18.y

parisc: io_pgetevents_time64() needs compat syscall in 32-bit compat mode

2022-08-17T12:40:09Z

commit 6431e92fc827bdd2d28f79150d90415ba9ce0d21 upstream. For all syscalls in 32-bit compat mode on 64-bit kernels the upper 32-bits of the 64-bit registers are zeroed out, so a negative 32-bit signed value will show up as positive 64-bit signed value. This behaviour breaks the io_pgetevents_time64() syscall which expects signed 64-bit values for the "min_nr" and "nr" parameters. Fix this by switching to the compat_sys_io_pgetevents_time64() syscall, which uses "compat_long_t" types for those parameters. Cc: # v5.1+ Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman

parisc: Drop pa_swapper_pg_lock spinlock

2022-08-17T12:40:09Z

commit 3fbc9a7de0564c55d8a9584c9cd2c9dfe6bd6d43 upstream. 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+ Signed-off-by: Greg Kroah-Hartman

parisc: Fix device names in /proc/iomem

2022-08-17T12:40:09Z

commit cab56b51ec0e69128909cef4650e1907248d821b upstream. Fix the output of /proc/iomem to show the real hardware device name including the pa_pathname, e.g. "Merlin 160 Core Centronics [8:16:0]". Up to now only the pa_pathname ("[8:16.0]") was shown. Signed-off-by: Helge Deller Cc: # v4.9+ Signed-off-by: Greg Kroah-Hartman

parisc/unaligned: Fix emulate_ldw() breakage

2022-07-07T15:54:46Z

commit 96b80fcd2705fc50ebe1f7f3ce204e861b3099ab upstream. The commit e8aa7b17fe41 broke the 32-bit load-word unalignment exception handler because it calculated the wrong amount of bits by which the value should be shifted. This patch fixes it. Signed-off-by: Helge Deller Fixes: e8aa7b17fe41 ("parisc/unaligned: Rewrite inline assembly of emulate_ldw()") Cc: stable@vger.kernel.org # v5.18 Signed-off-by: Greg Kroah-Hartman

parisc: Fix vDSO signal breakage on 32-bit kernel

2022-07-07T15:54:45Z

commit aa78fa905b4431c432071a878da99c2b37fc0e79 upstream. Addition of vDSO support for parisc in kernel v5.18 suddenly broke glibc signal testcases on a 32-bit kernel. The trampoline code (sigtramp.S) which is mapped into userspace includes an offset to the context data on the stack, which is used by gdb and glibc to get access to registers. In a 32-bit kernel we used by mistake the offset into the compat context (which is valid on a 64-bit kernel only) instead of the offset into the "native" 32-bit context. Reported-by: John David Anglin Tested-by: John David Anglin Fixes: df24e1783e6e ("parisc: Add vDSO support") CC: stable@vger.kernel.org # 5.18 Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman

parisc: Fix flush_anon_page on PA8800/PA8900

2022-06-29T07:04:41Z

commit e9ed22e6e5010997a2f922eef61ca797d0a2a246 upstream. 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+ Signed-off-by: Greg Kroah-Hartman

parisc: fix a crash with multicore scheduler

2022-06-09T08:29:26Z

commit 6ba688364856ad083be537f08e86ba97f433d405 upstream. With the kernel 5.18, the system will hang on boot if it is compiled with CONFIG_SCHED_MC. The last printed message is "Brought up 1 node, 1 CPU". The crash happens in sd_init tl->mask (which is cpu_coregroup_mask) returns an empty mask. This happens because cpu_topology[0].core_sibling is empty. Consequently, sd_span is set to an empty mask sd_id = cpumask_first(sd_span) sets sd_id == NR_CPUS (because the mask is empty) sd->shared = *per_cpu_ptr(sdd->sds, sd_id); sets sd->shared to NULL because sd_id is out of range atomic_inc(&sd->shared->ref); crashes without printing anything We can fix it by calling reset_cpu_topology() from init_cpu_topology() - this will initialize the sibling masks on CPUs, so that they're not empty. This patch also removes the variable "dualcores_found", it is useless, because during boot, init_cpu_topology is called before store_cpu_topology. Thus, set_sched_topology(parisc_mc_topology) is never called. We don't need to call it at all because default_topology in kernel/sched/topology.c contains the same items as parisc_mc_topology. Note that we should not call store_cpu_topology() from init_per_cpu() because it is called too early in the kernel initialization process and it results in the message "Failure to register CPU0 device". Before this patch, store_cpu_topology() would exit immediatelly because cpuid_topo->core id was uninitialized and it was 0. Signed-off-by: Mikulas Patocka Cc: stable@vger.kernel.org # v5.18 Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman

parisc: Fix patch code locking and flushing

2022-05-17T19:52:59Z

This change fixes the following: 1) The flags variable is not initialized. Always use raw_spin_lock_irqsave and raw_spin_unlock_irqrestore to serialize patching. 2) flush_kernel_vmap_range is primarily intended for DMA flushes. The whole cache flush in flush_kernel_vmap_range is only possible when interrupts are enabled on SMP machines. Since __patch_text_multiple calls flush_kernel_vmap_range with interrupts disabled, it is better to directly call flush_kernel_dcache_range_asm and flush_kernel_icache_range_asm. 3) The final call to flush_icache_range is unnecessary. Tested with `[PATCH, V3] parisc: Rewrite cache flush code for PA8800/PA8900' change on rp3440, c8000 and c3750 (32 and 64-bit). Note by Helge: This patch had been temporarily reverted shortly before v5.18-rc6 in order to fix boot issues. Now it can be re-applied. Signed-off-by: John David Anglin Signed-off-by: Helge Deller

parisc: Rewrite cache flush code for PA8800/PA8900

2022-05-17T19:52:47Z

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

Revert "parisc: Increase parisc_cache_flush_threshold setting"

2022-05-08T18:13:36Z

This reverts commit a58e9d0984e8dad53f17ec73ae3c1cc7f8d88151. Triggers segfaults with 32-bit kernels on PA8500 machines. Signed-off-by: Helge Deller