linux.git/arch/s390, branch vm-bind

mmu_gather: Remove per arch tlb_{start,end}_vma()

2022-07-21T17:50:13+00:00

Scattered across the archs are 3 basic forms of tlb_{start,end}_vma(). Provide two new MMU_GATHER_knobs to enumerate them and remove the per arch tlb_{start,end}_vma() implementations. - MMU_GATHER_NO_FLUSH_CACHE indicates the arch has flush_cache_range() but does *NOT* want to call it for each VMA. - MMU_GATHER_MERGE_VMAS indicates the arch wants to merge the invalidate across multiple VMAs if possible. With these it is possible to capture the three forms: 1) empty stubs; select MMU_GATHER_NO_FLUSH_CACHE and MMU_GATHER_MERGE_VMAS 2) start: flush_cache_range(), end: empty; select MMU_GATHER_MERGE_VMAS 3) start: flush_cache_range(), end: flush_tlb_range(); default Obviously, if the architecture does not have flush_cache_range() then it also doesn't need to select MMU_GATHER_NO_FLUSH_CACHE. Signed-off-by: Peter Zijlstra (Intel) Acked-by: Will Deacon Cc: David Miller Signed-off-by: Linus Torvalds

s390/nospec: remove unneeded header includes

2022-07-13T13:21:55+00:00

Commit 4efd417f298b ("s390: raise minimum supported machine generation to z10") removed the usage of alternatives and lowcore in expolines macros. Remove unneeded header includes as well. With that, expoline.S doesn't require asm-offsets.h and expoline_prepare target dependency could be removed. Tested-by: Joe Lawrence Link: https://lore.kernel.org/r/patch-2.thread-d13b6c.git-d13b6c96fb5f.your-ad-here.call-01656331067-ext-4899@work.hours Signed-off-by: Vasily Gorbik Signed-off-by: Alexander Gordeev

s390/nospec: build expoline.o for modules_prepare target

2022-07-13T13:21:55+00:00

When CONFIG_EXPOLINE_EXTERN is used expoline thunks are generated from arch/s390/lib/expoline.S and postlinked into every module. This is also true for external modules. Add expoline.o build to the modules_prepare target. Fixes: 1d2ad084800e ("s390/nospec: add an option to use thunk-extern") Reported-by: Joe Lawrence Tested-by: Sumanth Korikkar Acked-by: Sumanth Korikkar Tested-by: C. Erastus Toe Tested-by: Joe Lawrence Link: https://lore.kernel.org/r/patch-1.thread-d13b6c.git-a2387a74dc49.your-ad-here.call-01656331067-ext-4899@work.hours Signed-off-by: Vasily Gorbik Signed-off-by: Alexander Gordeev

s390/qdio: Fix spelling mistake

2022-06-30T17:40:36+00:00

Change 'defineable' to 'definable'. Change 'paramater' to 'parameter'. Signed-off-by: Zhang Jiaming Reviewed-by: Benjamin Block Link: https://lore.kernel.org/r/20220623060543.12870-1-jiaming@nfschina.com Signed-off-by: Alexander Gordeev

s390/archrandom: simplify back to earlier design and initialize earlier

2022-06-30T17:40:36+00:00

s390x appears to present two RNG interfaces: - a "TRNG" that gathers entropy using some hardware function; and - a "DRBG" that takes in a seed and expands it. Previously, the TRNG was wired up to arch_get_random_{long,int}(), but it was observed that this was being called really frequently, resulting in high overhead. So it was changed to be wired up to arch_get_random_ seed_{long,int}(), which was a reasonable decision. Later on, the DRBG was then wired up to arch_get_random_{long,int}(), with a complicated buffer filling thread, to control overhead and rate. Fortunately, none of the performance issues matter much now. The RNG always attempts to use arch_get_random_seed_{long,int}() first, which means a complicated implementation of arch_get_random_{long,int}() isn't really valuable or useful to have around. And it's only used when reseeding, which means it won't hit the high throughput complications that were faced before. So this commit returns to an earlier design of just calling the TRNG in arch_get_random_seed_{long,int}(), and returning false in arch_get_ random_{long,int}(). Part of what makes the simplification possible is that the RNG now seeds itself using the TRNG at bootup. But this only works if the TRNG is detected early in boot, before random_init() is called. So this commit also causes that check to happen in setup_arch(). Cc: stable@vger.kernel.org Cc: Harald Freudenberger Cc: Ingo Franzki Cc: Juergen Christ Cc: Heiko Carstens Signed-off-by: Jason A. Donenfeld Link: https://lore.kernel.org/r/20220610222023.378448-1-Jason@zx2c4.com Reviewed-by: Harald Freudenberger Acked-by: Heiko Carstens Signed-off-by: Alexander Gordeev

s390/purgatory: remove duplicated build rule of kexec-purgatory.o

2022-06-30T12:18:16+00:00

This is equivalent to the pattern rule in scripts/Makefile.build. Having the dependency on $(obj)/purgatory.ro is enough. Signed-off-by: Masahiro Yamada Link: https://lore.kernel.org/r/20220613170902.1775211-3-masahiroy@kernel.org Signed-off-by: Alexander Gordeev

s390/purgatory: hard-code obj-y in Makefile

2022-06-30T12:18:15+00:00

The purgatory/ directory is entirely guarded in arch/s390/Kbuild. CONFIG_ARCH_HAS_KEXEC_PURGATORY is bool type. $(CONFIG_ARCH_HAS_KEXEC_PURGATORY) is always 'y' when Kbuild visits this Makefile for building. Signed-off-by: Masahiro Yamada Link: https://lore.kernel.org/r/20220613170902.1775211-2-masahiroy@kernel.org Signed-off-by: Alexander Gordeev

s390: remove unneeded 'select BUILD_BIN2C'

2022-06-30T12:18:15+00:00

Since commit 4c0f032d4963 ("s390/purgatory: Omit use of bin2c"), s390 builds the purgatory without using bin2c. Remove 'select BUILD_BIN2C' to avoid the unneeded build of bin2c. Fixes: 4c0f032d4963 ("s390/purgatory: Omit use of bin2c") Signed-off-by: Masahiro Yamada Link: https://lore.kernel.org/r/20220613170902.1775211-1-masahiroy@kernel.org Signed-off-by: Alexander Gordeev

s390/pai: Fix multiple concurrent event installation

2022-06-23T15:24:00+00:00

Two different events such as pai_crypto/KM_AES_128/ and pai_crypto/KM_AES_192/ can be installed multiple times on the same CPU and the events are executed concurrently: # perf stat -e pai_crypto/KM_AES_128/ -C0 -a -- sleep 5 & # sleep 2 # perf stat -e pai_crypto/KM_AES_192/ -C0 -a -- true This results in the first event being installed two times with two seconds delay. The kernel does install the second event after the first event has been deleted and re-added, as can be seen in the traces: 13:48:47.600350 paicrypt_start event 0x1007 (event KM_AES_128) 13:48:49.599359 paicrypt_stop event 0x1007 (event KM_AES_128) 13:48:49.599198 paicrypt_start event 0x1007 13:48:49.599199 paicrypt_start event 0x1008 13:48:49.599921 paicrypt_event_destroy event 0x1008 13:48:52.601507 paicrypt_event_destroy event 0x1007 This is caused by functions event_sched_in() and event_sched_out() which call the PMU's add() and start() functions on schedule_in and the PMU's stop() and del() functions on schedule_out. This is correct for events attached to processes. The pai_crypto events are system-wide events and not attached to processes. Since the kernel common code can not be changed easily, fix this issue and do not reset the event count value to zero each time the event is added and started. Instead use a flag and zero the event count value only when called immediately after the event has been initialized. Therefore only the first invocation of the the event's add() function initializes the event count value to zero. The following invocations of the event's add() function leave the current event count value untouched. Fixes: 39d62336f5c1 ("s390/pai: add support for cryptography counters") Reported-by: Sumanth Korikkar Signed-off-by: Thomas Richter Acked-by: Sumanth Korikkar Signed-off-by: Alexander Gordeev

s390/pai: Prevent invalid event number for pai_crypto PMU

2022-06-23T15:23:59+00:00

The pai_crypto PMU has to check the event number. It has to be in the supported range. This is not the case, the lower limit is not checked. Fix this and obey the lower limit. Fixes: 39d62336f5c1 ("s390/pai: add support for cryptography counters") Signed-off-by: Thomas Richter Suggested-by: Sumanth Korikkar Reviewed-by: Sumanth Korikkar Signed-off-by: Alexander Gordeev