- 20 May, 2014 29 commits
-
-
Martin Schwidefsky authored
The out of line _raw_read_lock_wait_flags/_raw_write_lock_wait_flags functions for the arch_read_lock_flags/arch_write_lock_flags calls fail to re-enable the interrupts after another unsuccessful try to get the lock with compare-and-swap. The following wait would be done with interrupts disabled which is suboptimal. Signed-off-by:Martin Schwidefsky <schwidefsky@de.ibm.com>
-
Martin Schwidefsky authored
In case a lock is contended it is better to do a load-and-test first before trying to get the lock with compare-and-swap. This helps to avoid unnecessary cache invalidations of the cacheline for the lock if the CPU has to wait for the lock. For an uncontended lock doing the compare-and-swap directly is a bit better, if the CPU does not have the cacheline in its cache yet the compare-and-swap will get it read-write immediately while a load-and-test would get it read-only first. Always to the load-and-test first to avoid the cacheline invalidations for the contended case outweight the potential read-only to read-write cacheline upgrade for the uncontended case. Signed-off-by: -
Sebastian Ott authored
Fix multiple definitions of struct channel_path_desc by moving it to asm/chpid.h . Also change ccw_device_get_chp_desc to use proper types. Reviewed-by:
Peter Oberparleiter <oberpar@linux.vnet.ibm.com> Signed-off-by:
Sebastian Ott <sebott@linux.vnet.ibm.com> Signed-off-by:
-
Gerald Schaefer authored
On LPAR, when spin_retry is set to <= 0, arch_spin_lock_wait() and arch_spin_lock_wait_flags() may end up in a while(1) loop w/o doing any compare and swap operation. To fix this, use do/while instead of for loop. Signed-off-by:
Gerald Schaefer <gerald.schaefer@de.ibm.com> Signed-off-by:
-
Jeff Mahoney authored
This fixes: arch/s390/appldata/appldata_mem.c:135:2: error: implicit declaration of function 'kzalloc' [-Werror=implicit-function-declaration] arch/s390/appldata/appldata_mem.c:141:3: error: implicit declaration of function 'kfree' [-Werror=implicit-function-declaration] Signed-off-by:
Jeff Mahoney <jeffm@suse.com> Signed-off-by:
Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by:
-
Heiko Carstens authored
This shortens the code by ~17k (performace_defconfig, march=z196). The number of exception table entries however increases from 164 entries to 2500 entries (+~18k). However the executed code is shorter and also faster since we save the branches to the out-of-line copy_to/from_user implementations. Signed-off-by:
-
Sebastian Ott authored
Add a bunch of s390 specific pci attributes to help identifying pci functions. Reviewed-by:
-
Sebastian Ott authored
Let the driver core handle attribute creation by putting all s390 specific pci attributes in an attribute group which is referenced by pdev->dev.groups in pcibios_add_device. Link: https://lkml.kernel.org/r/alpine.LFD.2.11.1404141101500.1529@denkbrettReviewed-by:
-
Sebastian Ott authored
Introduce the zpci_attr macro to create read only sysfs attributes to avoid duplicate code. Reviewed-by:
-
Sebastian Ott authored
Processing pci hotplug events can fail when a pci function is in an unexpected state. This can happen when we already processed the change associated with the hotplug event (especially when receiving hotplug events during early boot). Just ignore the event in this case. Reviewed-by:
-
Martin Schwidefsky authored
The oi and ni instructions used in entry[64].S to set and clear bits in the thread-flags are not guaranteed to be atomic in regard to other CPUs. Split the TIF bits into CPU, pt_regs and thread-info specific bits. Updates on the TIF bits are done with atomic instructions, updates on CPU and pt_regs bits are done with non-atomic instructions. Signed-off-by: -
Martin Schwidefsky authored
Always switch to the kernel ASCE in switch_mm. Load the secondary space ASCE in finish_arch_post_lock_switch after checking that any pending page table operations have completed. The primary ASCE is loaded in entry[64].S. With this the update_primary_asce call can be removed from the switch_to macro and from the start of switch_mm function. Remove the load_primary argument from update_user_asce/clear_user_asce, rename update_user_asce to set_user_asce and rename update_primary_asce to load_kernel_asce. Signed-off-by: -
Michael Holzheu authored
Currently the smp_stop_cpu() function for SMP kernels enters a busy loop when "begin" is entered on the z/VM console after Linux is halted. To avoid this behavior, use the non-SMP variant of smp_stop_cpu() which stops the CPU again after "begin" is entered. As a side effect we now have consistent behavior for SMP and non-SMP Linux. Signed-off-by:
Michael Holzheu <holzheu@linux.vnet.ibm.com> Signed-off-by:
-
Randy Dunlap authored
Fix new s390 kernel-doc warning: Warning(arch/s390/include/asm/ccwgroup.h:27): No description found for parameter 'ungroup_work' Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Cc: Sebastian Ott <sebott@linux.vnet.ibm.com> Cc: Peter Oberparleiter <oberpar@linux.vnet.ibm.com> Cc: linux-s390@vger.kernel.org Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> Cc: Heiko Carstens <heiko.carstens@de.ibm.com> Cc: linux390@de.ibm.com Signed-off-by:
-
Michael Holzheu authored
Do the following changes: - Document new /proc/vmcore interface - Document partition dump external initramfs with s390-tools-1.24.0 - Remove initramfs config file because initramfs is now built automatically in s390-tools - Replace description of kernel config options with "make zfcpdump_defconfig" - Some editorial changes Signed-off-by:
-
Michael Holzheu authored
Currently there are two s390 kernel dump config options "CONFIG_ZFCPDUMP" and "CONFIG_CRASH_DUMP". In order to keep things simple and because the "CONFIG_ZFCPDUMP" option already has a dependency to "CONFIG_CRASH_DUMP" remove the CONFIG_ZFCPDUMP option. Signed-off-by:
Eric Farman <farman@linux.vnet.ibm.com> Signed-off-by:
-
Heiko Carstens authored
This is not necessary anymore, since the offending code is gone with the conversion to the memblock code. Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>- Signed-off-by: -
Philipp Hachtmann authored
Use lowcore constant to improve the code generated for spinlocks. [ Martin Schwidefsky: patch breakdown and code beautification ] Signed-off-by:
Philipp Hachtmann <phacht@linux.vnet.ibm.com> Signed-off-by:
-
Philipp Hachtmann authored
Improve the spinlock code in several aspects: - Have _raw_compare_and_swap return true if the operation has been successful instead of returning the old value. - Remove the "volatile" from arch_spinlock_t and arch_rwlock_t - Rename 'owner_cpu' to 'lock' - Add helper functions arch_spin_trylock_once / arch_spin_tryrelease_once [ Martin Schwidefsky: patch breakdown and code beautification ] Signed-off-by:
-
Philipp Hachtmann authored
The original bootmem allocator is getting replaced by memblock. To cover the needs of the s390 kdump implementation the physical memory list is used. With this patch the bootmem allocator and its bitmaps are completely removed from s390. Signed-off-by:
-
Philipp Hachtmann authored
Add the physmem list to the memblock structure. This list only exists if HAVE_MEMBLOCK_PHYS_MAP is selected and contains the unmodified list of physically available memory. It differs from the memblock memory list as it always contains all memory ranges even if the memory has been restricted, e.g. by use of the mem= kernel parameter. Signed-off-by:
-
Philipp Hachtmann authored
Refactor the memblock code and extend the memblock API to make it more flexible. With the extended API it is simple to define and work with additional memory lists. The static functions memblock_add_region and __memblock_remove are renamed to memblock_add_range and meblock_remove_range and added to the memblock API. The __next_free_mem_range and __next_free_mem_range_rev functions are replaced with calls to the more generic list walkers __next_mem_range and __next_mem_range_rev. To walk an arbitrary memory list two new macros for_each_mem_range and for_each_mem_range_rev are added. These new macros are used to define for_each_free_mem_range and for_each_free_mem_range_reverse. Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linuxLinus Torvalds authored
Pull parisc fixes from Helge Deller: "There are two patches in here: The first patch greatly improves latency and corrects the memory ordering in our light-weight atomic locking syscall. The second patch ratelimits printing of userspace segfaults in the same way as it's done on other platforms. This fixes a possible DOS on parisc since it prevents the syslog to grow too fast. For example, when the debian acl2 package was built on our debian buildd servers, this package produced lots of gigabytes in syslog in very short time and thus filled our harddisks, which then turned the server nearly completely unaccessible and unresponsive" * 'parisc-3.15-4' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux: parisc: Improve LWS-CAS performance parisc: ratelimit userspace segfault printing
-
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linuxLinus Torvalds authored
Pull two arm64 fixes from Catalin Marinas: - arm64 migrate_irqs() fix following commit ffde1de6 (irqchip: Gic: Support forced affinity setting) - fix arm64 pud_huge() to return 0 when only 2 levels page tables are used (__PAGETABLE_PMD_FOLDED defined and pmd_huge already covers block entries at the first level), otherwise KVM gets confused * tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: arm64: fix pud_huge() for 2-level pagetables arm64: use cpu_online_mask when using forced irq_set_affinity
-
git://git.kernel.org/pub/scm/linux/kernel/git/jhogan/metagLinus Torvalds authored
Pull Metag architecture and related fixes from James Hogan: "Mostly fixes for metag and parisc relating to upgrowing stacks. - Fix missing compiler barriers in metag memory barriers. - Fix BUG_ON on metag when RLIMIT_STACK hard limit is increased beyond safe value. - Make maximum stack size configurable. This reduces the default user stack size back to 80MB (especially on parisc after their removal of _STK_LIM_MAX override). This only affects metag and parisc. - Remove metag _STK_LIM_MAX override to match other arches and follow parisc, now that it is safe to do so (due to the BUG_ON fix mentioned above). - Finally now that both metag and parisc _STK_LIM_MAX overrides have been removed, it makes sense to remove _STK_LIM_MAX altogether" * tag 'metag-for-v3.15-2' of git://git.kernel.org/pub/scm/linux/kernel/git/jhogan/metag: asm-generic: remove _STK_LIM_MAX metag: Remove _STK_LIM_MAX override parisc,metag: Do not hardcode maximum userspace stack size metag: Reduce maximum stack size to 256MB metag: fix memory barriers -
git://people.freedesktop.org/~airlied/linuxLinus Torvalds authored
Pull drm/intel fixes from Dave Airlie: "Just some intel fixes. I have some radeon ones but I need to get some patches dropped from the pull req" * 'drm-fixes' of git://people.freedesktop.org/~airlied/linux: drm/i915: Increase WM memory latency values on SNB drm/i915: restore backlight precision when converting from ACPI drm/i915: Use the first mode if there is no preferred mode in the EDID drm/i915/dp: force eDP lane count to max available lanes on BDW drm/i915/vlv: reset VLV media force wake request register drm/i915/SDVO: For sysfs link put directory and target in correct order drm/i915: use lane count and link rate from VBT as minimums for eDP drm/i915: clean up VBT eDP link param decoding drm/i915: consider the source max DP lane count too
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull x86 fixes from Peter Anvin. * 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86-64, modify_ldt: Make support for 16-bit segments a runtime option x86, mm, hugetlb: Add missing TLB page invalidation for hugetlb_cow() x86, rdrand: When nordrand is specified, disable RDSEED as well
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull timer fix from Thomas Gleixner: "A single bug fix for a long standing issue: - Updating the expiry value of a relative timer _after_ letting the idle logic select a target cpu for the timer based on its stale expiry value is outright stupid. Thanks to Viresh for spotting the brainfart" * 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: hrtimer: Set expiry time before switch_hrtimer_base() -
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull irq fixes from Thomas Gleixner: "Two small updates from the irq departement: - Provide missing inline stub for a SMP only function - Add sub-maintainer for the drivers/irqchip/ part of the irq subsystem. YAY!" * 'irq-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: MAINTAINERS: Add co-maintainer for drivers/irqchip genirq: Provide irq_force_affinity fallback for non-SMP
-
- 19 May, 2014 1 commit
-
-
git://anongit.freedesktop.org/drm-intelDave Airlie authored
Intel fixes for regressions, black screens and hangs, for 3.15. * tag 'drm-intel-fixes-2014-05-16' of git://anongit.freedesktop.org/drm-intel: drm/i915: Increase WM memory latency values on SNB drm/i915: restore backlight precision when converting from ACPI drm/i915: Use the first mode if there is no preferred mode in the EDID drm/i915/dp: force eDP lane count to max available lanes on BDW drm/i915/vlv: reset VLV media force wake request register drm/i915/SDVO: For sysfs link put directory and target in correct order drm/i915: use lane count and link rate from VBT as minimums for eDP drm/i915: clean up VBT eDP link param decoding drm/i915: consider the source max DP lane count too
-
- 16 May, 2014 1 commit
-
-
Mark Salter authored
The following happens when trying to run a kvm guest on a kernel configured for 64k pages. This doesn't happen with 4k pages: BUG: failure at include/linux/mm.h:297/put_page_testzero()! Kernel panic - not syncing: BUG! CPU: 2 PID: 4228 Comm: qemu-system-aar Tainted: GF 3.13.0-0.rc7.31.sa2.k32v1.aarch64.debug #1 Call trace: [<fffffe0000096034>] dump_backtrace+0x0/0x16c [<fffffe00000961b4>] show_stack+0x14/0x1c [<fffffe000066e648>] dump_stack+0x84/0xb0 [<fffffe0000668678>] panic+0xf4/0x220 [<fffffe000018ec78>] free_reserved_area+0x0/0x110 [<fffffe000018edd8>] free_pages+0x50/0x88 [<fffffe00000a759c>] kvm_free_stage2_pgd+0x30/0x40 [<fffffe00000a5354>] kvm_arch_destroy_vm+0x18/0x44 [<fffffe00000a1854>] kvm_put_kvm+0xf0/0x184 [<fffffe00000a1938>] kvm_vm_release+0x10/0x1c [<fffffe00001edc1c>] __fput+0xb0/0x288 [<fffffe00001ede4c>] ____fput+0xc/0x14 [<fffffe00000d5a2c>] task_work_run+0xa8/0x11c [<fffffe0000095c14>] do_notify_resume+0x54/0x58 In arch/arm/kvm/mmu.c:unmap_range(), we end up doing an extra put_page() on the stage2 pgd which leads to the BUG in put_page_testzero(). This happens because a pud_huge() test in unmap_range() returns true when it should always be false with 2-level pages tables used by 64k pages. This patch removes support for huge puds if 2-level pagetables are being used. Signed-off-by:
Mark Salter <msalter@redhat.com> [catalin.marinas@arm.com: removed #ifndef around PUD_SIZE check] Signed-off-by:
Catalin Marinas <catalin.marinas@arm.com> Cc: <stable@vger.kernel.org> # v3.11+
-
- 15 May, 2014 6 commits
-
-
John David Anglin authored
The attached change significantly improves the performance of the LWS-CAS code in syscall.S. This allows a number of packages to build (e.g., zeromq3, gtest and libxs) that previously failed because slow LWS-CAS performance under contention. In particular, interrupts taken while the lock was taken degraded performance significantly. The change does the following: 1) Disables interrupts around the CAS operation, and 2) Changes the loads and stores to use the ordered completer, "o", on PA 2.0. "o" and "ma" with a zero offset are equivalent. The latter is accepted on both PA 1.X and 2.0. The use of ordered loads and stores probably makes no difference on all existing hardware, but it seemed pedantically correct. In particular, the CAS operation must complete before LDCW lock is released. As written before, a processor could reorder the operations. I don't believe the period interrupts are disabled is long enough to significantly increase interrupt latency. For example, the TLB insert code is longer. Worst case is a memory fault in the CAS operation. Signed-off-by:
John David Anglin <dave.anglin@bell.net> Cc: stable@vger.kernel.org # 3.13+ Signed-off-by:
Helge Deller <deller@gmx.de>
-
Helge Deller authored
Ratelimit printing of userspace segfaults and make it runtime configurable via the /proc/sys/debug/exception-trace variable. This should resolve syslog from growing way too fast and thus prevents possible system service attacks. Signed-off-by: -
Ville Syrjälä authored
On SNB the BIOS provided WM memory latency values seem insufficient to handle high resolution displays. In this particular case the display mode was a 2560x1440@60Hz, which makes the pixel clock 241.5 MHz. It was empirically found that a memory latency value if 1.2 usec is enough to avoid underruns, whereas the BIOS provided value of 0.7 usec was clearly too low. Incidentally 1.2 usec is what the typical BIOS provided values are on IVB systems. Increase the WM memory latency values to at least 1.2 usec on SNB. Hopefully this won't have a significant effect on power consumption. v2: Increase the latency values regardless of the pixel clock Cc: Robert N <crshman@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70254Tested-by:
Robert Navarro <crshman@gmail.com> Tested-by:
Vitaly Minko <vitaly.minko@gmail.com> Cc: stable@vger.kernel.org Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com>
-
Aaron Lu authored
When we set backlight on behalf of ACPI opregion, we will convert the backlight value in the 0-255 range defined in opregion to the actual hardware level. Commit 22505b82 (drm/i915: avoid brightness overflow when doing scale) is meant to fix the overflow problem when doing the conversion, but it also caused a problem that the converted hardware level doesn't quite represent the intended value: say user wants maximum backlight level(255 in opregion's range), then we will calculate the actual hardware level to be: level = freq / max * level, where freq is the hardware's max backlight level(937 on an user's box), and max and level are all 255. The converted value should be 937 but the above calculation will yield 765. To fix this issue, just use 64 bits to do the calculation to keep the precision and avoid overflow at the same time. Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=72491Reported-by:
Nico Schottelius <nico-bugzilla.kernel.org@schottelius.org> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: stable@vger.kernel.org Signed-off-by:
Aaron Lu <aaron.lu@intel.com> Signed-off-by:
-
Chris Wilson authored
This matches the algorithm used by earlier kernels when selecting the mode for the fbcon. And only if there is no modes at all, do we fall back to using the BIOS configuration. Seamless transition is still preserved (from the BIOS configuration to ours) so long as the BIOS has also chosen what we hope is the native configuration. Reported-by:
Knut Petersen <Knut_Petersen@t-online.de> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78655Reviewed-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Tested-by:
-
Jani Nikula authored
There are certain BDW high res eDP machines that regressed due to commit 38aecea0 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Mon Mar 3 11:18:10 2014 +0100 drm/i915: reverse dp link param selection, prefer fast over wide again The commit lead to 2 lanes at 5.4 Gbps being used instead of 4 lanes at 2.7 Gbps on the affected machines. Link training succeeded for both, but the screen remained blank with the former config. Further investigation showed that 4 lanes at 5.4 Gbps worked also. The root cause for the blank screen using 2 lanes remains unknown, but apparently the driver for a certain other operating system by default uses the max available lanes. Follow suit on Broadwell eDP, for at least until we figure out what is going on. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76711Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@gmail.com> Tested-by:
-
- 14 May, 2014 3 commits
-
-
Linus Torvalds authored
Checkin: b3b42ac2 x86-64, modify_ldt: Ban 16-bit segments on 64-bit kernels disabled 16-bit segments on 64-bit kernels due to an information leak. However, it does seem that people are genuinely using Wine to run old 16-bit Windows programs on Linux. A proper fix for this ("espfix64") is coming in the upcoming merge window, but as a temporary fix, create a sysctl to allow the administrator to re-enable support for 16-bit segments. It adds a "/proc/sys/abi/ldt16" sysctl that defaults to zero (off). If you hit this issue and care about your old Windows program more than you care about a kernel stack address information leak, you can do echo 1 > /proc/sys/abi/ldt16 as root (add it to your startup scripts), and you should be ok. The sysctl table is only added if you have COMPAT support enabled on x86-64, but I assume anybody who runs old windows binaries very much does that ;) Signed-off-by:
H. Peter Anvin <hpa@linux.intel.com> Link: http://lkml.kernel.org/r/CA%2B55aFw9BPoD10U1LfHbOMpHWZkvJTkMcfCs9s3urPr1YyWBxw@mail.gmail.com Cc: <stable@vger.kernel.org>
-
James Hogan authored
_STK_LIM_MAX could be used to override the RLIMIT_STACK hard limit from an arch's include/uapi/asm-generic/resource.h file, but is no longer used since both parisc and metag removed the override. Therefore remove it entirely, setting the hard RLIMIT_STACK limit to RLIM_INFINITY directly in include/asm-generic/resource.h. Signed-off-by:James Hogan <james.hogan@imgtec.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: linux-arch@vger.kernel.org Cc: Helge Deller <deller@gmx.de> Cc: John David Anglin <dave.anglin@bell.net>
-
James Hogan authored
Meta overrode _STK_LIM_MAX (the default RLIMIT_STACK hard limit) to 256MB, apparently in an attempt to prevent setup_arg_pages's STACK_GROWSUP code from choosing the maximum stack size of 1GB, which is far too large for Meta's limited virtual address space and hits a BUG_ON (stack_top is usually 0x3ffff000). However the commit "metag: Reduce maximum stack size to 256MB" reduces the absolute stack size limit to a safe value for metag. This allows the default _STK_LIM_MAX override to be removed, bringing the default behaviour in line with all other architectures. Parisc in particular recently removed their override of _STK_LIMT_MAX in commit e0d8898d (parisc: remove _STK_LIM_MAX override) since it subtly affects stack allocation semantics in userland. Meta's uapi/asm/resource.h can now be removed and switch to using generic-y. Suggested-by:
-
