aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2015-10-01dax: fix NULL pointer in __dax_pmd_fault()Ross Zwisler1-1/+12
Commit 46c043ede471 ("mm: take i_mmap_lock in unmap_mapping_range() for DAX") moved some code in __dax_pmd_fault() that was responsible for zeroing newly allocated PMD pages. The new location didn't properly set up 'kaddr', so when run this code resulted in a NULL pointer BUG. Fix this by getting the correct 'kaddr' via bdev_direct_access(). Signed-off-by: Ross Zwisler <[email protected]> Reported-by: Dan Williams <[email protected]> Reviewed-by: Dan Williams <[email protected]> Cc: Alexander Viro <[email protected]> Cc: Matthew Wilcox <[email protected]> Cc: "Kirill A. Shutemov" <[email protected]> Cc: Dave Chinner <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2015-10-01mm: hugetlbfs: skip shared VMAs when unmapping private pages to satisfy a faultMel Gorman1-0/+8
SunDong reported the following on https://bugzilla.kernel.org/show_bug.cgi?id=103841 I think I find a linux bug, I have the test cases is constructed. I can stable recurring problems in fedora22(4.0.4) kernel version, arch for x86_64. I construct transparent huge page, when the parent and child process with MAP_SHARE, MAP_PRIVATE way to access the same huge page area, it has the opportunity to lead to huge page copy on write failure, and then it will munmap the child corresponding mmap area, but then the child mmap area with VM_MAYSHARE attributes, child process munmap this area can trigger VM_BUG_ON in set_vma_resv_flags functions (vma - > vm_flags & VM_MAYSHARE). There were a number of problems with the report (e.g. it's hugetlbfs that triggers this, not transparent huge pages) but it was fundamentally correct in that a VM_BUG_ON in set_vma_resv_flags() can be triggered that looks like this vma ffff8804651fd0d0 start 00007fc474e00000 end 00007fc475e00000 next ffff8804651fd018 prev ffff8804651fd188 mm ffff88046b1b1800 prot 8000000000000027 anon_vma (null) vm_ops ffffffff8182a7a0 pgoff 0 file ffff88106bdb9800 private_data (null) flags: 0x84400fb(read|write|shared|mayread|maywrite|mayexec|mayshare|dontexpand|hugetlb) ------------ kernel BUG at mm/hugetlb.c:462! SMP Modules linked in: xt_pkttype xt_LOG xt_limit [..] CPU: 38 PID: 26839 Comm: map Not tainted 4.0.4-default #1 Hardware name: Dell Inc. PowerEdge R810/0TT6JF, BIOS 2.7.4 04/26/2012 set_vma_resv_flags+0x2d/0x30 The VM_BUG_ON is correct because private and shared mappings have different reservation accounting but the warning clearly shows that the VMA is shared. When a private COW fails to allocate a new page then only the process that created the VMA gets the page -- all the children unmap the page. If the children access that data in the future then they get killed. The problem is that the same file is mapped shared and private. During the COW, the allocation fails, the VMAs are traversed to unmap the other private pages but a shared VMA is found and the bug is triggered. This patch identifies such VMAs and skips them. Signed-off-by: Mel Gorman <[email protected]> Reported-by: SunDong <[email protected]> Reviewed-by: Michal Hocko <[email protected]> Cc: Andrea Arcangeli <[email protected]> Cc: Hugh Dickins <[email protected]> Cc: Naoya Horiguchi <[email protected]> Cc: David Rientjes <[email protected]> Reviewed-by: Naoya Horiguchi <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2015-10-01mm/slab: fix unexpected index mapping result of kmalloc_size(INDEX_NODE+1)Joonsoo Kim1-3/+10
Commit description is copied from the original post of this bug: http://comments.gmane.org/gmane.linux.kernel.mm/135349 Kernels after v3.9 use kmalloc_size(INDEX_NODE + 1) to get the next larger cache size than the size index INDEX_NODE mapping. In kernels 3.9 and earlier we used malloc_sizes[INDEX_L3 + 1].cs_size. However, sometimes we can't get the right output we expected via kmalloc_size(INDEX_NODE + 1), causing a BUG(). The mapping table in the latest kernel is like: index = {0, 1, 2 , 3, 4, 5, 6, n} size = {0, 96, 192, 8, 16, 32, 64, 2^n} The mapping table before 3.10 is like this: index = {0 , 1 , 2, 3, 4 , 5 , 6, n} size = {32, 64, 96, 128, 192, 256, 512, 2^(n+3)} The problem on my mips64 machine is as follows: (1) When configured DEBUG_SLAB && DEBUG_PAGEALLOC && DEBUG_LOCK_ALLOC && DEBUG_SPINLOCK, the sizeof(struct kmem_cache_node) will be "150", and the macro INDEX_NODE turns out to be "2": #define INDEX_NODE kmalloc_index(sizeof(struct kmem_cache_node)) (2) Then the result of kmalloc_size(INDEX_NODE + 1) is 8. (3) Then "if(size >= kmalloc_size(INDEX_NODE + 1)" will lead to "size = PAGE_SIZE". (4) Then "if ((size >= (PAGE_SIZE >> 3))" test will be satisfied and "flags |= CFLGS_OFF_SLAB" will be covered. (5) if (flags & CFLGS_OFF_SLAB)" test will be satisfied and will go to "cachep->slabp_cache = kmalloc_slab(slab_size, 0u)", and the result here may be NULL while kernel bootup. (6) Finally,"BUG_ON(ZERO_OR_NULL_PTR(cachep->slabp_cache));" causes the BUG info as the following shows (may be only mips64 has this problem): This patch fixes the problem of kmalloc_size(INDEX_NODE + 1) and removes the BUG by adding 'size >= 256' check to guarantee that all necessary small sized slabs are initialized regardless sequence of slab size in mapping table. Fixes: e33660165c90 ("slab: Use common kmalloc_index/kmalloc_size...") Signed-off-by: Joonsoo Kim <[email protected]> Reported-by: Liuhailong <[email protected]> Acked-by: Christoph Lameter <[email protected]> Cc: Pekka Enberg <[email protected]> Cc: David Rientjes <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2015-10-01userfaultfd: remove kernel header include from uapi headerAndre Przywara1-2/+0
As include/uapi/linux/userfaultfd.h is a user visible header file, it should not include kernel-exclusive header files. So trying to build the userfaultfd test program from the selftests directory fails, since it contains a reference to linux/compiler.h. As it turns out, that header is not really needed there, so we can simply remove it to fix that issue. Signed-off-by: Andre Przywara <[email protected]> Cc: Andrea Arcangeli <[email protected]> Cc: Shuah Khan <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2015-10-01arch/x86/include/asm/efi.h: fix build failureAndrey Ryabinin1-0/+2
With KMEMCHECK=y, KASAN=n: arch/x86/platform/efi/efi.c:673:3: error: implicit declaration of function `memcpy' [-Werror=implicit-function-declaration] arch/x86/platform/efi/efi_64.c:139:2: error: implicit declaration of function `memcpy' [-Werror=implicit-function-declaration] arch/x86/include/asm/desc.h:121:2: error: implicit declaration of function `memcpy' [-Werror=implicit-function-declaration] Don't #undef memcpy if KASAN=n. Fixes: 769a8089c1fd ("x86, efi, kasan: #undef memset/memcpy/memmove per arch") Signed-off-by: Andrey Ryabinin <[email protected]> Reported-by: Ingo Molnar <[email protected]> Reported-by: Sedat Dilek <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2015-10-02Merge tag 'drm-intel-fixes-2015-10-01' of ↵Dave Airlie6-12/+54
git://anongit.freedesktop.org/drm-intel into drm-fixes a few i915 fixes for v4.3. * tag 'drm-intel-fixes-2015-10-01' of git://anongit.freedesktop.org/drm-intel: drm/i915: Call non-locking version of drm_kms_helper_poll_enable(), v2 drm: Add a non-locking version of drm_kms_helper_poll_enable(), v2 drm/i915: Consider HW CSB write pointer before resetting the sw read pointer drm/i915/skl: Don't call intel_prepare_ddi when encoder list isn't yet initialized.
2015-10-02Merge tag 'vmwgfx-fixes-4.3-151001' of ↵Dave Airlie1-0/+8
git://people.freedesktop.org/~thomash/linux into drm-fixes A single commit to fix a command submission hang regression. Pull request of 2015-10-01 * tag 'vmwgfx-fixes-4.3-151001' of git://people.freedesktop.org/~thomash/linux: drm/vmwgfx: Fix a command submission hang regression
2015-10-02Merge branch 'exynos-drm-fixes' of ↵Dave Airlie12-152/+65
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-fixes This pull request includes regression fixups, build warnings, and trivial cleanups which mostly remove some codes not used anymore. * 'exynos-drm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos: drm/exynos: Staticize local function in exynos_drm_gem.c drm/exynos: fimd: actually disable dp clock drm/exynos: dp: remove suspend/resume functions drm/exynos: remove unused mode_fixup() code drm/exynos: remove decon_mode_fixup() drm/exynos: remove fimd_mode_fixup() drm/exynos: rotator: Clock control is unused if !PM drm/exynos: fimc: Clock control is unused if !PM drm/exynos: Suspend/resume is unused if !PM drm/exynos: create a fake mmap offset with gem creation drm/exynos: remove call to drm_gem_free_mmap_offset() drm/exynos: Remove useless EXPORT_SYMBOL_GPLs drm/exynos: cleanup line feed in exynos_drm_gem_get_ioctl drm/exynos: cleanup function calling written twice drm/exynos: staticize exynos_drm_gem_init() drm/exynos: remove unnecessary NULL assignment drm/exynos: fix missed calling of drm_prime_gem_destroy() drm/exynos: fix layering violation of address
2015-10-02Merge branch 'drm-fixes-4.3' of git://people.freedesktop.org/~agd5f/linux ↵Dave Airlie7-67/+19
into drm-fixes radeon and amdgpu fixes for 4.3. - backlight s/r fixes - typo fix from Dan - vm debugging fix - remove import_gpu_mem after discussion with Daniel * 'drm-fixes-4.3' of git://people.freedesktop.org/~agd5f/linux: drm/amdgpu: only print meaningful VM faults drm/amdgpu/cgs: remove import_gpu_mem drm/amdgpu: Restore LCD backlight level on resume drm/radeon: Restore LCD backlight level on resume (>= R5xx) drm/amdgpu: signedness bug in amdgpu_cs_parser_init()
2015-10-01Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvmLinus Torvalds5-121/+24
Pull KVM fixes from Paolo Bonzini: "(Relatively) a lot of reverts, mostly. Bugs have trickled in for a new feature in 4.2 (MTRR support in guests) so I'm reverting it all; let's not make this -rc period busier for KVM than it's been so far. This covers the four reverts from me. The fifth patch is being reverted because Radim found a bug in the implementation of stable scheduler clock, *but* also managed to implement the feature entirely without hypervisor support. So instead of fixing the hypervisor side we can remove it completely; 4.4 will get the new implementation" * tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm: Use WARN_ON_ONCE for missing X86_FEATURE_NRIPS Update KVM homepage Url Revert "KVM: SVM: use NPT page attributes" Revert "KVM: svm: handle KVM_X86_QUIRK_CD_NW_CLEARED in svm_get_mt_mask" Revert "KVM: SVM: Sync g_pat with guest-written PAT value" Revert "KVM: x86: apply guest MTRR virtualization on host reserved pages" Revert "KVM: x86: zero kvmclock_offset when vcpu0 initializes kvmclock system MSR"
2015-10-01Merge tag 'for-linus' of ↵Linus Torvalds18-167/+70
git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma Pull rdma fixes from Doug Ledford: - Fixes for mlx5 related issues - Fixes for ipoib multicast handling * tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma: IB/ipoib: increase the max mcast backlog queue IB/ipoib: Make sendonly multicast joins create the mcast group IB/ipoib: Expire sendonly multicast joins IB/mlx5: Remove pa_lkey usages IB/mlx5: Remove support for IB_DEVICE_LOCAL_DMA_LKEY IB/iser: Add module parameter for always register memory xprtrdma: Replace global lkey with lkey local to PD
2015-10-01Merge branches 'pm-cpuidle', 'pm-opp' and 'pm-tools'Rafael J. Wysocki3-12/+56
* pm-cpuidle: intel_idle: Skylake Client Support - updated * pm-opp: PM / OPP: Fix typo modifcation -> modification PM / OPP: of_property_count_u32_elems() can return errors * pm-tools: tools/power turbosat: update version number tools/power turbostat: SKL: Adjust for TSC difference from base frequency tools/power turbostat: KNL workaround for %Busy and Avg_MHz tools/power turbostat: IVB Xeon: fix --debug regression
2015-10-01Merge branch 'acpi-ec'Rafael J. Wysocki1-0/+2
* acpi-ec: ACPI / EC: Fix a memory leak issue in acpi_ec_query()
2015-10-01Merge branches 'pm-pci' and 'acpi-pci'Rafael J. Wysocki5-18/+58
* pm-pci: PCI / PM: Update runtime PM documentation for PCI devices * acpi-pci: ACPI / PCI: Remove duplicated penalty on SCI IRQ ACPI, PCI, irq: Do not share PCI IRQ with ISA IRQ
2015-10-01scsi_dh: Use the correct module name when loading device handlerPaul Mackerras1-1/+1
This fixes a bug in recent kernels which results in failure to boot on systems that have multipath SCSI disks. I observed this failure on a POWER8 server where all the disks are multipath SCSI disks. The symptoms are several messages like this on the console: [ 3.018700] device-mapper: table: 253:0: multipath: error attaching hardware handler [ 3.018828] device-mapper: ioctl: error adding target to table and the system does not find its disks, and therefore fails to boot. Bisection revealed that the bug was introduced in commit 566079c849cf, "dm-mpath, scsi_dh: request scsi_dh modules in scsi_dh, not dm-mpath". The specific reason for the failure is that where we previously loaded the "scsi_dh_alua" module, we are now trying to load the "alua" module, which doesn't exist. To fix this, we change the request_module call in scsi_dh_lookup() to prepend "scsi_dh_" to the name, just like the old code in drivers/md/dm-mpath.c:parse_hw_handler() used to do. [jejb: also fixes issue spotted by Sasha Levin that formatting characters could be passed in via sysfs and cause issues with request_module()] Fixes: 566079c849cf Signed-off-by: Paul Mackerras <[email protected]> Cc: Sasha Levin <[email protected]> Reviewed-by: Hannes Reinecke <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: James Bottomley <[email protected]>
2015-10-01arm64: Fix THP protection change logicSteve Capper1-2/+2
6910fa1 ("arm64: enable PTE type bit in the mask for pte_modify") fixes a problem whereby a large block of PROT_NONE mapped memory is incorrectly mapped as block descriptors when mprotect is called. Unfortunately, a subtle bug was introduced by this fix to the THP logic. If one mmaps a large block of memory, then faults it such that it is collapsed into THPs; resulting calls to mprotect on this area of memory will lead to incorrect table descriptors being written instead of block descriptors. This is because pmd_modify calls pte_modify which is now allowed to modify the type of the page table entry. This patch reverts commit 6910fa16dbe142f6a0fd0fd7c249f9883ff7fc8a, and fixes the problem it was trying to address by adjusting PAGE_NONE to represent a table entry. Thus no change in pte type is required when moving from PROT_NONE to a different protection. Fixes: 6910fa16dbe1 ("arm64: enable PTE type bit in the mask for pte_modify") Cc: <[email protected]> # 4.0+ Cc: Feng Kan <[email protected]> Reported-by: Ganapatrao Kulkarni <[email protected]> Tested-by: Ganapatrao Kulkarni <[email protected]> Reviewed-by: Catalin Marinas <[email protected]> Signed-off-by: Steve Capper <[email protected]> Signed-off-by: Catalin Marinas <[email protected]>
2015-10-01mfd: max77843: Fix max77843_chg_init() return on errorJavier Martinez Canillas1-1/+1
If i2c_new_dummy() fails in max77843_chg_init(), an PTR_ERR(NULL) is returned which is 0. So the function was wrongly returning a success value instead of an error code. Cc: [email protected] # 4.1 Fixes: c7f585fe46d8 ("mfd: max77843: Add max77843 MFD driver core driver") Signed-off-by: Javier Martinez Canillas <[email protected]> Reviewed-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Lee Jones <[email protected]>
2015-10-01mfd: intel-lpss: Fix build error when !CONFIG_PM_SLEEPAndy Shevchenko1-0/+2
Jim Davis reported the compilation error with a random configuration which apparently has CONFIG_PM=y and CONFIG_PM_SLEEP=n. With that conditions we have missed definition of INTEL_LPSS_SLEEP_PM_OPS macro. Add it here. Reported-by: Jim Davis <[email protected]> Signed-off-by: Andy Shevchenko <[email protected]> Signed-off-by: Lee Jones <[email protected]>
2015-10-01dm: fix AB-BA deadlock in __dm_destroy()Junichi Nomura1-4/+2
__dm_destroy() takes io_barrier SRCU lock (dm_get_live_table) and suspend_lock in reverse order. Doing so can cause AB-BA deadlock: __dm_destroy dm_swap_table --------------------------------------------------- mutex_lock(suspend_lock) dm_get_live_table() srcu_read_lock(io_barrier) dm_sync_table() synchronize_srcu(io_barrier) .. waiting for dm_put_live_table() mutex_lock(suspend_lock) .. waiting for suspend_lock Fix this by taking the locks in proper order. Signed-off-by: Jun'ichi Nomura <[email protected]> Fixes: ab7c7bb6f4ab ("dm: hold suspend_lock while suspending device during device deletion") Acked-by: Mikulas Patocka <[email protected]> Signed-off-by: Mike Snitzer <[email protected]> Cc: [email protected]
2015-10-01MIPS: BPF: Do all exports of symbols with FEXPORT().Ralf Baechle1-6/+3
FEXPORT also marks the symbol as code using .type symbol, @function. Without objdump -d will output only a hexdump for code following the affected symbols. Signed-off-by: Ralf Baechle <[email protected]>
2015-10-01Use WARN_ON_ONCE for missing X86_FEATURE_NRIPSDirk Müller1-1/+1
The cpu feature flags are not ever going to change, so warning everytime can cause a lot of kernel log spam (in our case more than 10GB/hour). The warning seems to only occur when nested virtualization is enabled, so it's probably triggered by a KVM bug. This is a sensible and safe change anyway, and the KVM bug fix might not be suitable for stable releases anyway. Cc: [email protected] Signed-off-by: Dirk Mueller <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]>
2015-10-01Update KVM homepage UrlDirk Müller1-2/+2
The old one appears to be a generic catch all page, which is unhelpful. Signed-off-by: Dirk Mueller <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]>
2015-10-01Merge tag 'upstream-4.3-rc4' of git://git.infradead.org/linux-ubifsLinus Torvalds4-3/+7
Pull UBI/UBIFS fixes from Richard Weinberger: "This contains three bug fixes for both UBI and UBIFS" * tag 'upstream-4.3-rc4' of git://git.infradead.org/linux-ubifs: UBI: return ENOSPC if no enough space available UBI: Validate data_size UBIFS: Kill unneeded locking in ubifs_init_security
2015-10-01Merge branch 'for-linus' of ↵Linus Torvalds5-30/+82
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security Pull key signing fixes from James Morris: "Keyrings and modsign fixes from David Howells" * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security: MODSIGN: Change from CMS to PKCS#7 signing if the openssl is too old X.509: Don't strip leading 00's from key ID when constructing key description KEYS: Remove unnecessary header #inclusions from extract-cert.c KEYS: Fix race between key destruction and finding a keyring by name
2015-10-01Revert "KVM: SVM: use NPT page attributes"Paolo Bonzini1-96/+5
This reverts commit 3c2e7f7de3240216042b61073803b61b9b3cfb22. Initializing the mapping from MTRR to PAT values was reported to fail nondeterministically, and it also caused extremely slow boot (due to caching getting disabled---bug 103321) with assigned devices. Reported-by: Markus Trippelsdorf <[email protected]> Reported-by: Sebastian Schuette <[email protected]> Cc: [email protected] # 4.2+ Signed-off-by: Paolo Bonzini <[email protected]>
2015-10-01Revert "KVM: svm: handle KVM_X86_QUIRK_CD_NW_CLEARED in svm_get_mt_mask"Paolo Bonzini1-8/+7
This reverts commit 5492830370171b6a4ede8a3bfba687a8d0f25fa5. It builds on the commit that is being reverted next. Cc: [email protected] # 4.2+ Signed-off-by: Paolo Bonzini <[email protected]>
2015-10-01Revert "KVM: SVM: Sync g_pat with guest-written PAT value"Paolo Bonzini1-10/+0
This reverts commit e098223b789b4a618dacd79e5e0dad4a9d5018d1, which has a dependency on other commits being reverted. Cc: [email protected] # 4.2+ Signed-off-by: Paolo Bonzini <[email protected]>
2015-10-01Revert "KVM: x86: apply guest MTRR virtualization on host reserved pages"Paolo Bonzini2-5/+13
This reverts commit fd717f11015f673487ffc826e59b2bad69d20fe5. It was reported to cause Machine Check Exceptions (bug 104091). Reported-by: [email protected] Cc: [email protected] # 4.2+ Signed-off-by: Paolo Bonzini <[email protected]>
2015-10-01arm64/efi: Fix boot crash by not padding between EFI_MEMORY_RUNTIME regionsArd Biesheuvel2-16/+75
The new Properties Table feature introduced in UEFIv2.5 may split memory regions that cover PE/COFF memory images into separate code and data regions. Since these regions only differ in the type (runtime code vs runtime data) and the permission bits, but not in the memory type attributes (UC/WC/WT/WB), the spec does not require them to be aligned to 64 KB. Since the relative offset of PE/COFF .text and .data segments cannot be changed on the fly, this means that we can no longer pad out those regions to be mappable using 64 KB pages. Unfortunately, there is no annotation in the UEFI memory map that identifies data regions that were split off from a code region, so we must apply this logic to all adjacent runtime regions whose attributes only differ in the permission bits. So instead of rounding each memory region to 64 KB alignment at both ends, only round down regions that are not directly preceded by another runtime region with the same type attributes. Since the UEFI spec does not mandate that the memory map be sorted, this means we also need to sort it first. Note that this change will result in all EFI_MEMORY_RUNTIME regions whose start addresses are not aligned to the OS page size to be mapped with executable permissions (i.e., on kernels compiled with 64 KB pages). However, since these mappings are only active during the time that UEFI Runtime Services are being invoked, the window for abuse is rather small. Tested-by: Mark Salter <[email protected]> Tested-by: Mark Rutland <[email protected]> [UEFI 2.4 only] Signed-off-by: Ard Biesheuvel <[email protected]> Signed-off-by: Matt Fleming <[email protected]> Reviewed-by: Mark Salter <[email protected]> Reviewed-by: Mark Rutland <[email protected]> Cc: <[email protected]> # v4.0+ Cc: Catalin Marinas <[email protected]> Cc: Leif Lindholm <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Mike Galbraith <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Will Deacon <[email protected]> Cc: [email protected] Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2015-10-01x86/efi: Fix boot crash by mapping EFI memmap entries bottom-up at runtime, ↵Matt Fleming1-1/+66
instead of top-down Beginning with UEFI v2.5 EFI_PROPERTIES_TABLE was introduced that signals that the firmware PE/COFF loader supports splitting code and data sections of PE/COFF images into separate EFI memory map entries. This allows the kernel to map those regions with strict memory protections, e.g. EFI_MEMORY_RO for code, EFI_MEMORY_XP for data, etc. Unfortunately, an unwritten requirement of this new feature is that the regions need to be mapped with the same offsets relative to each other as observed in the EFI memory map. If this is not done crashes like this may occur, BUG: unable to handle kernel paging request at fffffffefe6086dd IP: [<fffffffefe6086dd>] 0xfffffffefe6086dd Call Trace: [<ffffffff8104c90e>] efi_call+0x7e/0x100 [<ffffffff81602091>] ? virt_efi_set_variable+0x61/0x90 [<ffffffff8104c583>] efi_delete_dummy_variable+0x63/0x70 [<ffffffff81f4e4aa>] efi_enter_virtual_mode+0x383/0x392 [<ffffffff81f37e1b>] start_kernel+0x38a/0x417 [<ffffffff81f37495>] x86_64_start_reservations+0x2a/0x2c [<ffffffff81f37582>] x86_64_start_kernel+0xeb/0xef Here 0xfffffffefe6086dd refers to an address the firmware expects to be mapped but which the OS never claimed was mapped. The issue is that included in these regions are relative addresses to other regions which were emitted by the firmware toolchain before the "splitting" of sections occurred at runtime. Needless to say, we don't satisfy this unwritten requirement on x86_64 and instead map the EFI memory map entries in reverse order. The above crash is almost certainly triggerable with any kernel newer than v3.13 because that's when we rewrote the EFI runtime region mapping code, in commit d2f7cbe7b26a ("x86/efi: Runtime services virtual mapping"). For kernel versions before v3.13 things may work by pure luck depending on the fragmentation of the kernel virtual address space at the time we map the EFI regions. Instead of mapping the EFI memory map entries in reverse order, where entry N has a higher virtual address than entry N+1, map them in the same order as they appear in the EFI memory map to preserve this relative offset between regions. This patch has been kept as small as possible with the intention that it should be applied aggressively to stable and distribution kernels. It is very much a bugfix rather than support for a new feature, since when EFI_PROPERTIES_TABLE is enabled we must map things as outlined above to even boot - we have no way of asking the firmware not to split the code/data regions. In fact, this patch doesn't even make use of the more strict memory protections available in UEFI v2.5. That will come later. Suggested-by: Ard Biesheuvel <[email protected]> Reported-by: Ard Biesheuvel <[email protected]> Signed-off-by: Matt Fleming <[email protected]> Cc: <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Chun-Yi <[email protected]> Cc: Dave Young <[email protected]> Cc: H. Peter Anvin <[email protected]> Cc: James Bottomley <[email protected]> Cc: Lee, Chun-Yi <[email protected]> Cc: Leif Lindholm <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Matthew Garrett <[email protected]> Cc: Mike Galbraith <[email protected]> Cc: Peter Jones <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: [email protected] Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2015-10-01genirq: Fix race in register_irq_proc()Ben Hutchings1-2/+17
Per-IRQ directories in procfs are created only when a handler is first added to the irqdesc, not when the irqdesc is created. In the case of a shared IRQ, multiple tasks can race to create a directory. This race condition seems to have been present forever, but is easier to hit with async probing. Signed-off-by: Ben Hutchings <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Thomas Gleixner <[email protected]> Cc: [email protected]
2015-10-01ASoC: tlv320aic3x: Prevent writing reserved registers on tlv320aic3104 CODECsRick Mann1-8/+11
The current code writes a set of registers that are reserved on the tlc320aic3104. The change skips those registers for that IC. Signed-off-by: Rick Mann <[email protected]> Signed-off-by: Mark Brown <[email protected]>
2015-10-01ASoC: rt5645: Correct the naming and setting of ADC Boost Volume ControlOder Chiou2-10/+12
Signed-off-by: Oder Chiou <[email protected]> Signed-off-by: Mark Brown <[email protected]>
2015-10-01regulator: core: Handle probe deferral from DT when resolving suppliesMark Brown1-0/+4
When resolving regulator-regulator supplies we ignore probe deferral returns from regulator_dev_lookup() (such as are generated for DT when we can see a supply is registered) and just fall back to the dummy regulator if there are full constraints (as is the case for DT). This means that probe deferral is broken for DT systems, fix that by paying attention to -EPROBE_DEFER return codes like we do -ENODEV. A further patch will simplify this further, this is a minimal fix for the specific issue. Fixes: 9f7e25edb1575a6d2 (regulator: core: Handle full constraints systems when resolving supplies) Reported-by: Sascha Hauer <[email protected]> Tested-by: Sascha Hauer <[email protected]> Signed-off-by: Mark Brown <[email protected]> Cc: [email protected]
2015-10-01s390/defconfig: set SCSI_DH=ySebastian Ott3-3/+3
Fix this warning: arch/s390/configs/performance_defconfig:380:warning: symbol value 'm' invalid for SCSI_DH Introduced via 086b91d052ebe4ead5d28021afe3bdfd70af15bf (scsi_dh: integrate into the core SCSI code) Signed-off-by: Sebastian Ott <[email protected]> Signed-off-by: Martin Schwidefsky <[email protected]>
2015-10-01blk-mq: factor out a helper to iterate all tags for a request_queueChristoph Hellwig4-20/+25
And replace the blk_mq_tag_busy_iter with it - the driver use has been replaced with a new helper a while ago, and internal to the block we only need the new version. Signed-off-by: Christoph Hellwig <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2015-10-01blk-mq: fix racy updates of rq->errorsChristoph Hellwig8-34/+32
blk_mq_complete_request may be a no-op if the request has already been completed by others means (e.g. a timeout or cancellation), but currently drivers have to set rq->errors before calling blk_mq_complete_request, which might leave us with the wrong error value. Add an error parameter to blk_mq_complete_request so that we can defer setting rq->errors until we known we won the race to complete the request. Signed-off-by: Christoph Hellwig <[email protected]> Reviewed-by: Sagi Grimberg <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2015-10-01MIPS: Fix the build on jz4740 after removing the custom gpio.hAlban Bedel2-0/+2
Somehow the wrong version of the patch to remove the use of custom gpio.h on mips has been merged. This patch add the missing fixes for a build error on jz4740 because linux/gpio.h doesn't provide any machine specfics definitions anymore. Signed-off-by: Alban Bedel <[email protected]> Cc: Paul Burton <[email protected]> Cc: Lars-Peter Clausen <[email protected]> Cc: Brian Norris <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Linus Walleij <[email protected]> Cc: [email protected] Cc: [email protected] Patchwork: https://patchwork.linux-mips.org/patch/11089/ Signed-off-by: Ralf Baechle <[email protected]>
2015-10-01Merge remote-tracking branch 'tglx/x86/urgent' into x86/urgentIngo Molnar3-52/+55
Pick up the WCHAN fixes from Thomas. Signed-off-by: Ingo Molnar <[email protected]>
2015-10-01drm/exynos: Staticize local function in exynos_drm_gem.cKrzysztof Kozlowski1-1/+1
The exynos_drm_gem_mmap_buffer() is not used outside so make it static. Signed-off-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Inki Dae <[email protected]>
2015-10-01drm/exynos: fimd: actually disable dp clockGustavo Padovan1-1/+1
fimd_dp_clock_enable() was setting the always to enabled, this patch fix this to actually use the value that is set to 'val'. Reported-by: Emilio López <[email protected]> Signed-off-by: Gustavo Padovan <[email protected]> Signed-off-by: Inki Dae <[email protected]>
2015-10-01drm/exynos: dp: remove suspend/resume functionsInki Dae1-23/+0
This patch removes unnecessary pm suspend/resume functions. All kms sub drivers will be controlled by top of Exynos drm driver and connector dpms so these sub drivers shouldn't have their own pm interfaces. Signed-off-by: Inki Dae <[email protected]> Reviewed-by: Gustavo Padovan <[email protected]>
2015-10-01drm/qxl: recreate the primary surface when the bo is not primaryFabiano Fidêncio1-1/+1
When disabling/enabling a crtc the primary area must be updated independently of which crtc has been disabled/enabled. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1264735 Signed-off-by: Fabiano Fidêncio <[email protected]> Cc: [email protected] Signed-off-by: Dave Airlie <[email protected]>
2015-10-01dmaengine: pxa_dma: fix residue corner caseRobert Jarzmik1-0/+10
A very tiny temporal window exists in the residue calculation where : - upon entering residue calculation, the transfer is ongoing - when reading the current transfer pointer, it just changed to the "finisher/linker" descriptor In this case, the residue returned is the whole transfer length instead of 0. Fix it. This appears almost in one extreme case, where the driver is used by older clients which inquire for residue in interrupt context, such as the smsc91x ethernet driver, in a tight loop : interrupt_handler() dmaengine_submit() do { dmaengine_tx_status() } while (residue > 0 || status != DMA_ERROR) Signed-off-by: Robert Jarzmik <[email protected]> Signed-off-by: Vinod Koul <[email protected]>
2015-10-01dmaengine: pxa_dma: fix the no-requestor caseRobert Jarzmik1-6/+14
A very small number of devices don't use the flow control offered by requestor lines. In these specific cases, the pxa dma driver should be aware of that and not try to use a requestor line. Signed-off-by: Robert Jarzmik <[email protected]> Signed-off-by: Vinod Koul <[email protected]>
2015-10-01dmaengine: zxdma: Fix off-by-one for testing valid pchan requestAxel Lin1-1/+1
The valid pchan range is 0 ~ d->dma_requests - 1. Signed-off-by: Axel Lin <[email protected]> Reviewed-by: Jun Nie <[email protected]> Signed-off-by: Vinod Koul <[email protected]>
2015-10-01dmaengine: at_xdmac: clean used descriptorLudovic Desroches1-1/+10
When putting back a descriptor to the free descs list, some fields are not set to 0, it can cause bugs if someone uses it without having this in mind. Descriptor are not put back one by one so it is easier to clean descriptors when we request them. Signed-off-by: Ludovic Desroches <[email protected]> Cc: [email protected] #4.2 Signed-off-by: Vinod Koul <[email protected]>
2015-10-01dmaengine: at_xdmac: change block increment addressing modeMaxime Ripard1-2/+2
The addressing mode we were using was not only incrementing the address at each microblock, but also at each data boundary, which was severely slowing the transfer, without any benefit since we were not using the data stride. Switch to the micro block increment only in order to get back to an acceptable performance level. Signed-off-by: Maxime Ripard <[email protected]> Signed-off-by: Ludovic Desroches <[email protected]> Fixes: 6007ccb57744 ("dmaengine: xdmac: Add interleaved transfer support") Cc: [email protected] #4.2 Signed-off-by: Vinod Koul <[email protected]>
2015-10-01cxl: fix leak of ctx->mapping when releasing kernel API contextsAndrew Donnellan1-3/+10
When a context is created via the kernel API, ctx->mapping is allocated within the kernel and thus needs to be freed when the context is freed. reclaim_ctx() attempts to do this for contexts with the ctx->kernelapi flag set, but afu_release() (which can be called from the kernel API through cxl_fd_release()) sets ctx->mapping to NULL before calling cxl_context_free() to free the context. Add a check to afu_release() so that the mappings in contexts created via the kernel API are left alone so reclaim_ctx() can free them. Reported-by: Matthew R. Ochs <[email protected]> Fixes: 6f7f0b3df6d4 ("cxl: Add AFU virtual PHB and kernel API") Signed-off-by: Andrew Donnellan <[email protected]> Acked-by: Ian Munsie <[email protected]> Reviewed-by: Matthew R. Ochs <[email protected]> Signed-off-by: Michael Ellerman <[email protected]>
2015-10-01cxl: fix leak of ctx->irq_bitmap when releasing context via kernel APIAndrew Donnellan2-2/+3
At present, ctx->irq_bitmap is freed in afu_release_irqs(), which is called from afu_release() via cxl_context_detach(). Move the freeing of ctx->irq_bitmap from afu_release_irqs() to reclaim_ctx() (called through cxl_context_free()) so it's freed when releasing a context via the kernel API (cxl_release_context()) or the userspace API (afu_release()). Reported-by: Matthew R. Ochs <[email protected]> Fixes: 6f7f0b3df6d4 ("cxl: Add AFU virtual PHB and kernel API") Signed-off-by: Andrew Donnellan <[email protected]> Acked-by: Ian Munsie <[email protected]> Reviewed-by: Matthew R. Ochs <[email protected]> Signed-off-by: Michael Ellerman <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.