- 13 Jul, 2016 1 commit
-
-
David Hildenbrand authored
__tlb_flush_asce() should never be used if multiple asce belong to a mm. As this function changes mm logic determining if local or global tlb flushes will be neded, we might end up flushing only the gmap asce on all CPUs and a follow up mm asce flushes will only flush on the local CPU, although that asce ran on multiple CPUs. The missing tlb flushes will provoke strange faults in user space and even low address protections in user space, crashing the kernel. Fixes: 1b948d6c ("s390/mm,tlb: optimize TLB flushing for zEC12") Cc: stable@vger.kernel.org # 3.15+ Reported-by:
Sascha Silbe <silbe@linux.vnet.ibm.com> Acked-by:
Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by:
David Hildenbrand <dahi@linux.vnet.ibm.com> Signed-off-by:
-
- 06 Jul, 2016 1 commit
-
-
Gerald Schaefer authored
This adds support for 2GB hugetlbfs pages on s390. Reviewed-by:
Gerald Schaefer <gerald.schaefer@de.ibm.com> Signed-off-by:
-
- 04 Jul, 2016 2 commits
-
-
Heiko Carstens authored
After linking there are several symbols for the same address that the __switch_to symbol points to. E.g.: 000000000089b9c0 T __kprobes_text_start 000000000089b9c0 T __lock_text_end 000000000089b9c0 T __lock_text_start 000000000089b9c0 T __sched_text_end 000000000089b9c0 T __switch_to When disassembling with "objdump -d" this results in a missing __switch_to function. It would be named __kprobes_text_start instead. To unconfuse objdump add a nop in front of the kprobes text section. That way __switch_to appears again. Obviously this solution is sort of a hack, since it also depends on link order if this works or not. However it is the best I can come up with for now. Signed-off-by:
Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by:
-
Heiko Carstens authored
Expose the maximum thread id with /proc/cpuinfo. With the new line the output looks like this: vendor_id : IBM/S390 bogomips per cpu: 20325.00 max thread id : 1 With this new interface it is possible to always tell the correct number of cpu threads potentially being used by the kernel. Signed-off-by:
-
- 28 Jun, 2016 19 commits
-
-
Martin Schwidefsky authored
The bits single_step and instruction_fetch lost their meaning with git commit 5e9a2692 "[S390] ptrace cleanup". Clarify the comment for these two bits. Signed-off-by:
-
Heiko Carstens authored
Avoid using the address of a process' thread_info structure as the kernel stack address. This will break as soon as the thread_info structure will be removed from the stack, and in addition it makes the code a bit more understandable. Signed-off-by:
-
Heiko Carstens authored
Remove a leftover from the code that transferred a couple of TIF bits from the previous task to the next task. Signed-off-by:
-
Heiko Carstens authored
Now that hopefully all inline assemblies have been converted to single basic blocks we can enable kcov on s390. Note that this patch does not disable as many files on s390 like the x86 variant does. Right now I didn't see a reason to do that, however additional files or directories can be excluded at any time. The runtime overhead seems to be quite high. Signed-off-by:
-
Heiko Carstens authored
Use only simple inline assemblies which consist of a single basic block if the register asm construct is being used. Otherwise gcc would generate broken code if the compiler option --sanitize-coverage=trace-pc would be used. Signed-off-by:
-
Heiko Carstens authored
Use only simple inline assemblies which consist of a single basic block if the register asm construct is being used. Otherwise gcc would generate broken code if the compiler option --sanitize-coverage=trace-pc would be used. Signed-off-by:
-
Heiko Carstens authored
Use only simple inline assemblies which consist of a single basic block if the register asm construct is being used. Otherwise gcc would generate broken code if the compiler option --sanitize-coverage=trace-pc would be used. Signed-off-by:
-
Heiko Carstens authored
Use only simple inline assemblies which consist of a single basic block if the register asm construct is being used. Otherwise gcc would generate broken code if the compiler option --sanitize-coverage=trace-pc would be used. Signed-off-by:
-
Heiko Carstens authored
Use only simple inline assemblies which consist of a single basic block if the register asm construct is being used. Otherwise gcc would generate broken code if the compiler option --sanitize-coverage=trace-pc would be used. Signed-off-by:
Sebastian Ott <sebott@linux.vnet.ibm.com> Signed-off-by:
-
Heiko Carstens authored
Use only simple inline assemblies which consist of a single basic block if the register asm construct is being used. Otherwise gcc would generate broken code if the compiler option --sanitize-coverage=trace-pc would be used. Signed-off-by:
-
Heiko Carstens authored
Use only simple inline assemblies which consist of a single basic block if the register asm construct is being used. Otherwise gcc would generate broken code if the compiler option --sanitize-coverage=trace-pc would be used. Signed-off-by:
-
Heiko Carstens authored
Use only simple inline assemblies which consist of a single basic block if the register asm construct is being used. Otherwise gcc would generate broken code if the compiler option --sanitize-coverage=trace-pc would be used. Signed-off-by:
-
Heiko Carstens authored
Use only simple inline assemblies which consist of a single basic block if the register asm construct is being used. Otherwise gcc would generate broken code if the compiler option --sanitize-coverage=trace-pc would be used. Signed-off-by:
-
Heiko Carstens authored
Use only simple inline assemblies which consist of a single basic block if the register asm construct is being used. Otherwise gcc would generate broken code if the compiler option --sanitize-coverage=trace-pc would be used. Signed-off-by:
-
Heiko Carstens authored
Use only simple inline assemblies which consist of a single basic block if the register asm construct is being used. Otherwise gcc would generate broken code if the compiler option --sanitize-coverage=trace-pc would be used. Signed-off-by:
-
Heiko Carstens authored
The __put_get_user_asm defines an inline assmembly which makes use of the asm register construct. The parameters passed to that define may also contain function calls. It is a gcc restriction that between register asm statements and the use of any such annotated variables function calls may clobber the register / variable contents. Or in other words: gcc would generate broken code. This can be achieved e.g. with the following code: get_user(x, func() ? a : b); where the call of func would clobber register zero which is used by the __put_get_user_asm define. To avoid this add two static inline functions which don't have these side effects. Signed-off-by: -
Heiko Carstens authored
The cpu field name within /proc/cpuinfo has a conflict with the powerpc and sparc output where it contains the cpu model name. So rename the field name to cpu number which shouldn't generate any conflicts. Signed-off-by:
-
Heiko Carstens authored
Now that the oprofile sampling code is gone there is only one user of the sampling facility left. Therefore the reserve and release functions can be removed. Signed-off-by:
Hendrik Brueckner <brueckner@linux.vnet.ibm.com> Signed-off-by:
-
Heiko Carstens authored
Remove hardware sampler support from oprofile module. The oprofile user space utilty has been switched to use the kernel perf interface, for which we also provide hardware sampling support. In addition the hardware sampling support is also slightly broken: it supports only 16 bits for the pid and therefore would generate wrong results on machines which have a pid >64k. Also the pt_regs structure which was passed to oprofile common code cannot necessarily be used to generate sane backtraces, since the task(s) in question may run while the samples are fed to oprofile. So the result would be more or less random. However given that the only user space tools switched to the perf interface already four years ago the hardware sampler code seems to be unused code, and therefore it should be reasonable to remove it. The timer based oprofile support continues to work. Signed-off-by:
Andreas Arnez <arnez@linux.vnet.ibm.com> Acked-by:
Andreas Krebbel <krebbel@linux.vnet.ibm.com> Acked-by:
Robert Richter <rric@kernel.org> Reviewed-by:
-
- 15 Jun, 2016 4 commits
-
-
Heiko Carstens authored
The last in-kernel user is gone so we can finally remove this code. Reviewed-by:
-
Heiko Carstens authored
Implement calculation of loops_per_jiffies with fp instructions which are available on all 64 bit machines. To save and restore floating point register context use the new vx support functions. Reviewed-by:
-
Hendrik Brueckner authored
Signed-off-by:
-
Hendrik Brueckner authored
Add a crypto API module to access the vector extension based CRC-32 implementations. Users can request the optimized implementation through the shash crypto API interface. Signed-off-by:
-
- 14 Jun, 2016 3 commits
-
-
Hendrik Brueckner authored
Use vector instructions to optimize the computation of CRC-32 checksums. An optimized version is provided for CRC-32 (IEEE 802.3 Ethernet) in normal and bitreflected domain, as well as, for bitreflected CRC-32C (Castagnoli). Signed-off-by:
-
Hendrik Brueckner authored
Introduce the kernel_fpu_begin() and kernel_fpu_end() function to enclose any in-kernel use of FPU instructions and registers. In enclosed sections, you can perform floating-point or vector (SIMD) computations. The functions take care of saving and restoring FPU register contents and controls. For usage details, see the guidelines in arch/s390/include/asm/fpu/api.h Signed-off-by:
-
Heiko Carstens authored
The usual problem for code that is ifdef'ed out is that it doesn't compile after a while. That's also the case for the storage key initialisation code, if it would be used (set PAGE_DEFAULT_KEY to something not zero): ./arch/s390/include/asm/page.h: In function 'storage_key_init_range': ./arch/s390/include/asm/page.h:36:2: error: implicit declaration of function '__storage_key_init_range' Since the code itself has been useful for debugging purposes several times, remove the ifdefs and make sure the code gets compiler coverage. The cost for this is eight bytes. Signed-off-by:
-
- 13 Jun, 2016 10 commits
-
-
Heiko Carstens authored
I don't have a z10 to test this anymore, so I have no idea if the code works at all or even crashes. I can try to emulate, but it is just guess work. Nor do we know if the z10 special handling is performance wise still better than the generic handling. There have been a lot of changes to the scheduler. Therefore let's play safe and remove the special handling. Signed-off-by:
-
Heiko Carstens authored
The z13 machine added a fourth level to the cpu topology information. The new top level is called drawer. A drawer contains two books, which used to be the top level. Adding this additional scheduling domain did show performance improvements for some workloads of up to 8%, while there don't seem to be any workloads impacted in a negative way. Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by:
-
Heiko Carstens authored
The s390 cpu topology gained another hierarchy level. The top level is now called drawer and contains several books. A book used to be the top level. In order to expose the cpu topology to user space allow to create new sysfs attributes dependent on CONFIG_SCHED_DRAWER which an architecture may define and select. These additional attributes will be available: /sys/devices/system/cpu/cpuX/topology/drawer_id /sys/devices/system/cpu/cpuX/topology/drawer_siblings /sys/devices/system/cpu/cpuX/topology/drawer_siblings_list Signed-off-by:
-
Heiko Carstens authored
Rename DIAG308_IPL and DIAG308_DUMP to DIAG308_LOAD_CLEAR and DIAG308_LOAD_NORMAL_DUMP to better reflect the associated IPL functions. Suggested-by:
Cornelia Huck <cornelia.huck@de.ibm.com> Suggested-by:
Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by:
Michael Holzheu <holzheu@linux.vnet.ibm.com> Reviewed-by:
Peter Oberparleiter <oberpar@linux.vnet.ibm.com> Signed-off-by:
-
Heiko Carstens authored
Avoid clearing memory for CCW-type re-ipl within a logical partition. This can save a significant amount of time if a logical partition contains a lot of memory. On the other hand we still clear memory if running within a second level hypervisor, since the hypervisor can simply free all memory that was used for the guest. Signed-off-by:
-
Heiko Carstens authored
We have some inline assemblies where the extable entry points to a label at the end of an inline assembly which is not followed by an instruction. On the other hand we have also inline assemblies where the extable entry points to the first instruction of an inline assembly. If a first type inline asm (extable point to empty label at the end) would be directly followed by a second type inline asm (extable points to first instruction) then we would have two different extable entries that point to the same instruction but would have a different target address. This can lead to quite random behaviour, depending on sorting order. I verified that we currently do not have such collisions within the kernel. However to avoid such subtle bugs add a couple of nop instructions to those inline assemblies which contain an extable that points to an empty label. Signed-off-by:
-
Heiko Carstens authored
We always expect that get_user and put_user return with zero. Give the compiler a hint so it can slightly optimize the code and avoid branches. This is the same what x86 got with commit a76cf66e ("x86/uaccess: Tell the compiler that uaccess is unlikely to fault"). Signed-off-by:
-
Heiko Carstens authored
Fix some whitespace damage that was introduced by me with a query-replace when removing 31 bit support. Signed-off-by:
-
Sebastian Ott authored
When we use the iommu_area_alloc helper to get dma addresses we specify the boundary_size parameter but not the offset (called shift in this context). As long as the offset (start_dma) is a multiple of the boundary we're ok (on current machines start_dma always seems to be 4GB). Don't leave this to chance and specify the offset for iommu_area_alloc. Signed-off-by:
-
Sebastian Ott authored
We don't have an architectural guarantee on the value of the dma offset but rely on it to be at least page aligned. Enforce page alignemt of start_dma. Signed-off-by:
-
