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

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

2022-08-17T12:40:09+00:00

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:09+00:00

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:09+00:00

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:46+00:00

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:45+00:00

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: Enable ARCH_HAS_STRICT_MODULE_RWX

2022-06-29T07:04:41+00:00

commit 0a1355db36718178becd2bfe728a023933d73123 upstream. Fix a boot crash on a c8000 machine as reported by Dave. Basically it changes patch_map() to return an alias mapping to the to-be-patched code in order to prevent writing to write-protected memory. Signed-off-by: Helge Deller Suggested-by: John David Anglin Cc: stable@vger.kernel.org # v5.2+ Link: https://lore.kernel.org/all/e8ec39e8-25f8-e6b4-b7ed-4cb23efc756e@bell.net/ Signed-off-by: Greg Kroah-Hartman

parisc: Fix flush_anon_page on PA8800/PA8900

2022-06-29T07:04:41+00:00

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/stifb: Fix fb_is_primary_device() only available with CONFIG_FB_STI

2022-06-29T07:04:40+00:00

commit 1d0811b03eb30b2f0793acaa96c6ce90b8b9c87a upstream. Fix this build error noticed by the kernel test robot: drivers/video/console/sticore.c:1132:5: error: redefinition of 'fb_is_primary_device' arch/parisc/include/asm/fb.h:18:19: note: previous definition of 'fb_is_primary_device' Signed-off-by: Helge Deller Reported-by: kernel test robot Cc: stable@vger.kernel.org # v5.10+ Signed-off-by: Greg Kroah-Hartman

parisc/stifb: Implement fb_is_primary_device()

2022-06-09T08:29:26+00:00

commit cf936af790a3ef5f41ff687ec91bfbffee141278 upstream. Implement fb_is_primary_device() function, so that fbcon detects if this framebuffer belongs to the default graphics card which was used to start the system. Signed-off-by: Helge Deller Cc: stable@vger.kernel.org # v5.10+ Signed-off-by: Greg Kroah-Hartman

parisc: fix a crash with multicore scheduler

2022-06-09T08:29:26+00:00

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