- 13 Jun, 2017 1 commit
-
-
Martin Schwidefsky authored
The system control vm.alloc_pgste is used to control the size of the page tables, either 2K or 4K. The idea is that a KVM host sets the vm.alloc_pgste control to 1 which causes *all* new processes to run with 4K page tables. For a non-kvm system the control should stay off to save on memory used for page tables. Trouble is that distributions choose to set the control globally to be able to run KVM guests. This wastes memory on non-KVM systems. Introduce the PT_S390_PGSTE ELF segment type to "mark" the qemu executable with it. All executables with this (empty) segment in its ELF phdr array will be started with 4K page tables. Any executable without PT_S390_PGSTE will run with the default 2K page tables. This removes the need to set vm.alloc_pgste=1 for a KVM host and minimizes the waste of memory for page tables. Signed-off-by:Martin Schwidefsky <schwidefsky@de.ibm.com>
-
- 12 Jun, 2017 38 commits
-
-
Heiko Carstens authored
Rename a couple of the struct psw_bits members so it is more obvious for what they are good. Initially I thought using the single character names from the PoP would be sufficient and obvious, but admittedly that is not true. The current implementation is not easy to use, if one has to look into the source file to figure out which member represents the 'per' bit (which is the 'r' member). Therefore rename the members to sane names that are identical to the uapi psw mask defines: r -> per i -> io e -> ext t -> dat m -> mcheck w -> wait p -> pstate Signed-off-by:
Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by:
-
Heiko Carstens authored
The address space enums that must be used when modifying the address space part of a psw with the psw_bits() macro can easily be confused with the psw defines that are used to mask and compare directly the mask part of a psw. We have e.g. PSW_AS_PRIMARY vs PSW_ASC_PRIMARY. To avoid confusion rename the PSW_AS_* enums to PSW_BITS_AS_*. In addition also rename the PSW_AMODE_* enums, so they also follow the same naming scheme: PSW_BITS_AMODE_*. Signed-off-by:
-
Heiko Carstens authored
Right now the kernel uses the primary address space until finally the switch to the correct home address space will be done when the idle PSW will be loaded within psw_idle(). Correct this and simply use the home address space when DAT is enabled for the first time. This doesn't really fix a bug, but fixes odd behavior. Reviewed-by:
Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by:
-
Sebastian Ott authored
The sysfs attributes implemented by the vfio_ccw driver are also implemented by the io_subchannel driver. Move these into a device_type which is set by the css bus. Signed-off-by:
Sebastian Ott <sebott@linux.vnet.ibm.com> Reviewed-by:
Dong Jia Shi <bjsdjshi@linux.vnet.ibm.com> Reviewed-by:
Cornelia Huck <cornelia.huck@de.ibm.com> Signed-off-by:
-
Heiko Carstens authored
This reverts the two commits 7afbeb6d ("s390/ipl: always use load normal for CCW-type re-IPL") 0f7451ff ("s390/ipl: use load normal for LPAR re-ipl") The two commits did not take into account that behavior of standby memory changes fundamentally if the re-IPL method is changed from Load Clear to Load Normal. In case of the old re-IPL clear method all memory that was initially in standby state will be put into standby state again within the re-IPL process. Or in other words: memory that was brought online before a re-IPL will be offline again after a reboot. Given that we use different re-IPL methods depending on the hypervisor and CCW-type vs SCSI re-IPL it is not easy to tell in advance when and why memory will stay online or will be offline after a re-IPL. This does also have other side effects, since memory that is online from the beginning will be in ZONE_NORMAL by default vs ZONE_MOVABLE for memory that is offline. Therefore, before the change, a user could online and offline memory easily since standby memory was always in ZONE_NORMAL. After the change, and a re-IPL, this depended on which memory parts were online before the re-IPL. From a usability point of view the current behavior is more than suboptimal. Therefore revert these changes until we have a better solution and get back to a consistent behavior. The bad thing about this is that the time required for a re-IPL will be significantly increased for configurations with several 100GB or 1TB of memory. Signed-off-by:
-
Heiko Carstens authored
Remove raw stack dumps that are printed before call traces in case of a warning, or the 'l' sysrq trigger (show a stack backtrace for all active CPUs). Besides that a raw stack dump should not be shown for the 'l' sysrq trigger the value of the dump is close to zero. That's also why we don't print it in case of a panic since ages anymore. That this is still printed on warnings is just a leftover. So get rid of this completely. The following won't be printed anymore with this change: Stack: 00000000bbc4fbc8 00000000bbc4fc58 0000000000000003 0000000000000000 00000000bbc4fcf8 00000000bbc4fc70 00000000bbc4fc70 0000000000000020 000000007fe00098 00000000bfe8be00 00000000bbc4fe94 000000000000000a 000000000000000c 00000000bbc4fcc0 0000000000000000 0000000000000000 000000000095b930 0000000000113366 00000000bbc4fc58 00000000bbc4fca0 Signed-off-by: -
Stefan Haberland authored
The safe offline processing may hang forever because it waits for I/O which can not be started because of the offline flag that prevents new I/O from being started. Allow I/O to be started during safe offline processing because in this special case we take care that the queues are empty before throwing away the device. Signed-off-by:
Stefan Haberland <sth@linux.vnet.ibm.com> Signed-off-by:
-
Stefan Haberland authored
The safe offline processing needs, as well as the normal offline processing, to be locked against multiple parallel executions. But it should be able to be overtaken by a normal offline processing to make sure that the device does not wait forever for outstanding I/O if the user wants to. Unfortunately the parallel processing of safe offline and normal offline might lead to a race situation where both threads report successful execution to the CIO layer which in turn tries to deregister the kobject of the device twice. This leads to a refcount_t: underflow; use-after-free. error and the device is not able to be set online again afterwards without a reboot. Correct the locking of the safe offline processing by doing the following: - Use the cdev lock to secure all set and test operations to the device flags. - Two safe offline processes are locked against each other using the DASD_FLAG_SAFE_OFFLINE and DASD_FLAG_SAFE_OFFLINE_RUNNING device flags. The differentiation between offline triggered and offline running is needed since the normal offline attribute is owned by CIO and we have to pass over control in between. - The dasd_generic_set_offline process handles the offline processing. It is locked against parallel execution using the DASD_FLAG_OFFLINE. - Only a running safe offline should be able to be overtaken by a single normal offline. This is ensured by clearing the DASD_FLAG_SAFE_OFFLINE_RUNNING flag when a normal offline overtakes. So this can only happen ones. - The safe offline just aborts in this case doing nothing and the normal offline processing finishes as usual. Signed-off-by:
-
Jan Höppner authored
We have two flags, DASD_FLAG_DEVICE_RO and DASD_FEATURE_READONLY, that tell us whether a device is read-only. DASD_FLAG_DEVICE_RO is set when a device is attached as read-only to z/VM and DASD_FEATURE_READONLY is set when either the corresponding kernel parameter is configured, or the read-only state is changed via sysfs. This is valuable information in any case. However, only the feature flag is being checked at the moment when we display the current state. Fix this by checking both flags. Reviewed-by:
Jan Höppner <hoeppner@linux.vnet.ibm.com> Signed-off-by:
-
Logan Gunthorpe authored
Move the CONFIG_PCI device so that ioremap and iounmap are always available. This looks safe as there's nothing PCI specific in the implementation of these functions. I have designs to use these functions in scatterlist.c where they'd likely never be called without CONFIG_PCI set, but this is needed to compile such changes. Signed-off-by:
Logan Gunthorpe <logang@deltatee.com> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> Cc: Heiko Carstens <heiko.carstens@de.ibm.com> Cc: Sebastian Ott <sebott@linux.vnet.ibm.com> Cc: Al Viro <viro@ZenIV.linux.org.uk> Signed-off-by:
-
Thomas Richter authored
Command 'perf list pmu' displays events which contain an invalid string "(null)=xxx", where xxx is the pmu event name, for example: cpum_cf/AES_BLOCKED_CYCLES,(null)=AES_BLOCKED_CYCLES/ This is not correct, the invalid string should not be displayed at all. It is caused by an obsolete term in the sysfs attribute file for each s390 CPUMF counter event. Reading from the sysfs file also displays the event name. Fix this by omitting the event name. This patch makes s390 CPUMF sysfs files consistent with other plattforms. This is an interface change between user and kernel but does not break anything. Reading from a counter event sysfs file should only list terms mentioned in the /sys/bus/event_source/devices/<cpumf>/format directory. Name is not listed. Reported-by:
Zvonko Kosic <zvonko.kosic@de.ibm.com> Signed-off-by:
Thomas Richter <tmricht@linux.vnet.ibm.com> Reviewed-by:
Hendrik Brueckner <brueckner@linux.vnet.ibm.com> Signed-off-by:
-
Heiko Carstens authored
Introduce and use p?d_folded() functions to clarify the page table code a bit more. Signed-off-by:
-
Heiko Carstens authored
_REGION3_ENTRY_ORIGIN defines a wrong mask which can be used to extract a segment table origin from a region 3 table entry. It removes only the lower 11 instead of 12 bits from a region 3 table entry. Luckily this bit is currently always zero, so nothing bad happened yet. In order to avoid future bugs just remove the region 3 specific mask and use the correct generic _REGION_ENTRY_ORIGIN mask. Signed-off-by:
-
Martin Schwidefsky authored
The regset functions for guarded storage are supposed to work on the current task as well. For task == current add the required load and store instructions for the guarded storage control block. Signed-off-by: -
Heiko Carstens authored
All call sites of "stfle" check if the instruction is available before executing it. Therefore there is no reason to have the corresponding facility bit set within the architecture level set. This removes the last more or less odd bit from the list. Signed-off-by:
-
Thomas Huth authored
The code in arch/s390/crypto checks for the availability of the 'message security assist' facility on its own, either by using module_cpu_feature_match(MSA, ...) or by checking the facility bit during cpacf_query(). Thus setting the MSA facility bit in gen_facilities.c as hard requirement is not necessary. We can remove it here, so that the kernel can also run on systems that do not provide the MSA facility yet (like the emulated environment of QEMU, for example). Signed-off-by:
Thomas Huth <thuth@redhat.com> Signed-off-by:
-
Heiko Carstens authored
When masking an ASCE to get its origin use the corresponding define instead of the unrelated PAGE_MASK. This doesn't fix a bug since both masks are identical. Signed-off-by:
-
Harald Freudenberger authored
Added some dbf debug messages on failure of the most important ioctl calls. These messages are only enabled with dbf level 6 (debug) and so do not affect the normal operating mode which uses level 3 (errors and higher). Signed-off-by:
Harald Freudenberger <freude@linux.vnet.ibm.com> Signed-off-by:
-
Heiko Carstens authored
Use proper define instead of open-coding the condition code value. Signed-off-by:
-
Christian Borntraeger authored
I get number of CPUs - 1 kmemleak hits like unreferenced object 0x37ec6f000 (size 1024): comm "swapper/0", pid 1, jiffies 4294937330 (age 889.690s) hex dump (first 32 bytes): 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk backtrace: [<000000000034a848>] kmem_cache_alloc+0x2b8/0x3d0 [<00000000001164de>] __cpu_up+0x456/0x488 [<000000000016f60c>] bringup_cpu+0x4c/0xd0 [<000000000016d5d2>] cpuhp_invoke_callback+0xe2/0x9e8 [<000000000016f3c6>] cpuhp_up_callbacks+0x5e/0x110 [<000000000016f988>] _cpu_up+0xe0/0x158 [<000000000016faf0>] do_cpu_up+0xf0/0x110 [<0000000000dae1ee>] smp_init+0x126/0x130 [<0000000000d9bd04>] kernel_init_freeable+0x174/0x2e0 [<000000000089fc62>] kernel_init+0x2a/0x148 [<00000000008adce2>] kernel_thread_starter+0x6/0xc [<00000000008adcdc>] kernel_thread_starter+0x0/0xc [<ffffffffffffffff>] 0xffffffffffffffff The pointer of this data structure is stored in the prefix page of that CPU together with some extra bits ORed into the the low bits. Mark the data structure as non-leak. Signed-off-by: -
Harald Freudenberger authored
When a out of range domain parameter was given, the init function returned with -EINVAL and the driver was not operational. As the driver is statically build into the kernel and is able to work with multiple domains anyway the init function should continue. Now the user has a chance to write a new default domain value via sysfs attribute file. Also added two new dbf debug messages related to the domain value handling. Signed-off-by:
-
Heiko Carstens authored
Select statements in Kconfig do not necessarily enable all required dependencies and can lead to broken configs. This is also the case for the "select IUCV" statement within HVC_IUCV: warning: (HVC_IUCV) selects IUCV which has unmet direct dependencies (NET && S390) Just add the missing "depends on NET" to avoid broken configs. Signed-off-by: -
Harald Freudenberger authored
The s390_paes and the s390_aes kernel module used just one config symbol CONFIG_CRYPTO_AES. As paes has a dependency to PKEY and this requires ZCRYPT the aes module also had a dependency to the zcrypt device driver which is not true. Fixed by introducing a new config symbol CONFIG_CRYPTO_PAES which has dependencies to PKEY and ZCRYPT. Removed the dependency for the aes module to ZCRYPT. Signed-off-by:
-
Harald Freudenberger authored
Signed-off-by:
-
Heiko Carstens authored
The zcrypt code contains a couple of functions which receive a "big_endian" argument. All callers naturally pass "1" for big endian, since s390 is big endian. Therefore get rid of this argument and also get rid of the cpu_to_le()/cpu_to_be() calls. This way we get rid of a couple of sparse warnings: drivers/s390/crypto/zcrypt_cca_key.h:255:34: warning: incorrect type in assignment (different base types) expected unsigned short [unsigned] ulen got restricted __be16 [usertype] <noident> Cc: Harald Freudenberger <freude@linux.vnet.ibm.com> Signed-off-by: -
Martin Schwidefsky authored
Switch to the improved _install_special_mapping function to install the vdso mapping. This has two advantages, the arch_vma_name function is not needed anymore and the vdso vma still has its name after its memory location has been changed with mremap. Tested-by:
Michael Holzheu <holzheu@linux.vnet.ibm.com> Signed-off-by:
-
Martin Schwidefsky authored
The account_system_index_scaled gets two cputime values, a raw value derived from CPU timer deltas and a scaled value. The scaled value is always calculated from the raw value, the code can be simplified by moving the scale_vtime call into account_system_index_scaled. Signed-off-by: -
Heiko Carstens authored
I missed at least these two header files where we can make use of the generic ones. vga.h is another one, however that is already addressed by a patch from Jiri Slaby. Signed-off-by:
-
Heiko Carstens authored
Add missing __user annotations to get rid of a couple of sparse warnings. All callers actually pass kernel pointers instead of user space pointers, however the pointers are being used within KERNEL_DS. So everything is fine. Corresponding sparse warnings: drivers/s390/crypto/pkey_api.c:181:41: warning: incorrect type in assignment (different address spaces) expected char [noderef] <asn:1>*request_control_blk_addr got void *<noident> Cc: Harald Freudenberger <freude@linux.vnet.ibm.com> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by: -
Jan Höppner authored
Dynamic stack allocations are considered bad. Get rid of this one occurrence and use kstrdup() instead. Also, set the return codes so that we have only one exit where we can call kfree(). Signed-off-by:
-
Sebastian Ott authored
Exploit multiple hardware contexts (queues) that can process requests in parallel. Signed-off-by:
-
Sebastian Ott authored
Drop the tasklet that was used to complete requests in favor of block layer helpers that finish the IO on the CPU that initiated it. Signed-off-by:
-
Sebastian Ott authored
Convert scm_blk to use the blk-mq API. This is just a simple conversion since we still use a single queue. Signed-off-by:
-
Sebastian Ott authored
Remove CONFIG_SCM_BLOCK_CLUSTER_WRITE and related code. This quirk is no longer needed on current hardware. Signed-off-by:
-
Heiko Carstens authored
Add __rcu annotations so sparse correctly warns only if "slot" gets derefenced without using rcu_dereference(). Right now we get warnings because of the missing annotation: arch/s390/mm/gmap.c:135:17: warning: incorrect type in assignment (different address spaces) arch/s390/mm/gmap.c:135:17: expected void **slot arch/s390/mm/gmap.c:135:17: got void [noderef] <asn:4>** Signed-off-by:
-
Heiko Carstens authored
drivers/s390/crypto/pkey_api.c:1197:12: warning: symbol 'pkey_init' was not declared. Should it be static? Signed-off-by:
-
Heiko Carstens authored
Add missing include statements to make sure that prototypes match implementation. As reported by sparse: arch/s390/crypto/arch_random.c:18:1: warning: symbol 's390_arch_random_available' was not declared. Should it be static? arch/s390/kernel/traps.c:279:13: warning: symbol 'trap_init' was not declared. Should it be static? Signed-off-by:
-
Martin Schwidefsky authored
Add the logic to upgrade the page table for a 64-bit process to five levels. This increases the TASK_SIZE from 8PB to 16EB-4K. Signed-off-by:
-
- 08 Jun, 2017 1 commit
-
-
Martin Schwidefsky authored
Signed-off-by:
-
