1. 16 5月, 2017 1 次提交
  2. 11 5月, 2017 1 次提交
  3. 10 5月, 2017 1 次提交
    • N
      uapi: export all headers under uapi directories · fcc8487d
      Nicolas Dichtel 提交于
      Regularly, when a new header is created in include/uapi/, the developer
      forgets to add it in the corresponding Kbuild file. This error is usually
      detected after the release is out.
      
      In fact, all headers under uapi directories should be exported, thus it's
      useless to have an exhaustive list.
      
      After this patch, the following files, which were not exported, are now
      exported (with make headers_install_all):
      asm-arc/kvm_para.h
      asm-arc/ucontext.h
      asm-blackfin/shmparam.h
      asm-blackfin/ucontext.h
      asm-c6x/shmparam.h
      asm-c6x/ucontext.h
      asm-cris/kvm_para.h
      asm-h8300/shmparam.h
      asm-h8300/ucontext.h
      asm-hexagon/shmparam.h
      asm-m32r/kvm_para.h
      asm-m68k/kvm_para.h
      asm-m68k/shmparam.h
      asm-metag/kvm_para.h
      asm-metag/shmparam.h
      asm-metag/ucontext.h
      asm-mips/hwcap.h
      asm-mips/reg.h
      asm-mips/ucontext.h
      asm-nios2/kvm_para.h
      asm-nios2/ucontext.h
      asm-openrisc/shmparam.h
      asm-parisc/kvm_para.h
      asm-powerpc/perf_regs.h
      asm-sh/kvm_para.h
      asm-sh/ucontext.h
      asm-tile/shmparam.h
      asm-unicore32/shmparam.h
      asm-unicore32/ucontext.h
      asm-x86/hwcap2.h
      asm-xtensa/kvm_para.h
      drm/armada_drm.h
      drm/etnaviv_drm.h
      drm/vgem_drm.h
      linux/aspeed-lpc-ctrl.h
      linux/auto_dev-ioctl.h
      linux/bcache.h
      linux/btrfs_tree.h
      linux/can/vxcan.h
      linux/cifs/cifs_mount.h
      linux/coresight-stm.h
      linux/cryptouser.h
      linux/fsmap.h
      linux/genwqe/genwqe_card.h
      linux/hash_info.h
      linux/kcm.h
      linux/kcov.h
      linux/kfd_ioctl.h
      linux/lightnvm.h
      linux/module.h
      linux/nbd-netlink.h
      linux/nilfs2_api.h
      linux/nilfs2_ondisk.h
      linux/nsfs.h
      linux/pr.h
      linux/qrtr.h
      linux/rpmsg.h
      linux/sched/types.h
      linux/sed-opal.h
      linux/smc.h
      linux/smc_diag.h
      linux/stm.h
      linux/switchtec_ioctl.h
      linux/vfio_ccw.h
      linux/wil6210_uapi.h
      rdma/bnxt_re-abi.h
      
      Note that I have removed from this list the files which are generated in every
      exported directories (like .install or .install.cmd).
      
      Thanks to Julien Floret <julien.floret@6wind.com> for the tip to get all
      subdirs with a pure makefile command.
      
      For the record, note that exported files for asm directories are a mix of
      files listed by:
       - include/uapi/asm-generic/Kbuild.asm;
       - arch/<arch>/include/uapi/asm/Kbuild;
       - arch/<arch>/include/asm/Kbuild.
      Signed-off-by: NNicolas Dichtel <nicolas.dichtel@6wind.com>
      Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Acked-by: NRussell King <rmk+kernel@armlinux.org.uk>
      Acked-by: NMark Salter <msalter@redhat.com>
      Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc)
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      fcc8487d
  4. 09 5月, 2017 5 次提交
  5. 08 5月, 2017 3 次提交
  6. 04 5月, 2017 1 次提交
    • C
      KVM: arm/arm64: Move shared files to virt/kvm/arm · 35d2d5d4
      Christoffer Dall 提交于
      For some time now we have been having a lot of shared functionality
      between the arm and arm64 KVM support in arch/arm, which not only
      required a horrible inter-arch reference from the Makefile in
      arch/arm64/kvm, but also created confusion for newcomers to the code
      base, as was recently seen on the mailing list.
      
      Further, it causes confusion for things like cscope, which needs special
      attention to index specific shared files for arm64 from the arm tree.
      
      Move the shared files into virt/kvm/arm and move the trace points along
      with it.  When moving the tracepoints we have to modify the way the vgic
      creates definitions of the trace points, so we take the chance to
      include the VGIC tracepoints in its very own special vgic trace.h file.
      Signed-off-by: NChristoffer Dall <cdall@linaro.org>
      35d2d5d4
  7. 02 5月, 2017 3 次提交
    • J
      xen: Implement EFI reset_system callback · e371fd76
      Julien Grall 提交于
      When rebooting DOM0 with ACPI on ARM64, the kernel is crashing with the stack
      trace [1].
      
      This is happening because when EFI runtimes are enabled, the reset code
      (see machine_restart) will first try to use EFI restart method.
      
      However, the EFI restart code is expecting the reset_system callback to
      be always set. This is not the case for Xen and will lead to crash.
      
      The EFI restart helper is used in multiple places and some of them don't
      not have fallback (see machine_power_off). So implement reset_system
      callback as a call to xen_reboot when using EFI Xen.
      
      [   36.999270] reboot: Restarting system
      [   37.002921] Internal error: Attempting to execute userspace memory: 86000004 [#1] PREEMPT SMP
      [   37.011460] Modules linked in:
      [   37.014598] CPU: 0 PID: 1 Comm: systemd-shutdow Not tainted 4.11.0-rc1-00003-g1e248b60a39b-dirty #506
      [   37.023903] Hardware name: (null) (DT)
      [   37.027734] task: ffff800902068000 task.stack: ffff800902064000
      [   37.033739] PC is at 0x0
      [   37.036359] LR is at efi_reboot+0x94/0xd0
      [   37.040438] pc : [<0000000000000000>] lr : [<ffff00000880f2c4>] pstate: 404001c5
      [   37.047920] sp : ffff800902067cf0
      [   37.051314] x29: ffff800902067cf0 x28: ffff800902068000
      [   37.056709] x27: ffff000008992000 x26: 000000000000008e
      [   37.062104] x25: 0000000000000123 x24: 0000000000000015
      [   37.067499] x23: 0000000000000000 x22: ffff000008e6e250
      [   37.072894] x21: ffff000008e6e000 x20: 0000000000000000
      [   37.078289] x19: ffff000008e5d4c8 x18: 0000000000000010
      [   37.083684] x17: 0000ffffa7c27470 x16: 00000000deadbeef
      [   37.089079] x15: 0000000000000006 x14: ffff000088f42bef
      [   37.094474] x13: ffff000008f42bfd x12: ffff000008e706c0
      [   37.099870] x11: ffff000008e70000 x10: 0000000005f5e0ff
      [   37.105265] x9 : ffff800902067a50 x8 : 6974726174736552
      [   37.110660] x7 : ffff000008cc6fb8 x6 : ffff000008cc6fb0
      [   37.116055] x5 : ffff000008c97dd8 x4 : 0000000000000000
      [   37.121453] x3 : 0000000000000000 x2 : 0000000000000000
      [   37.126845] x1 : 0000000000000000 x0 : 0000000000000000
      [   37.132239]
      [   37.133808] Process systemd-shutdow (pid: 1, stack limit = 0xffff800902064000)
      [   37.141118] Stack: (0xffff800902067cf0 to 0xffff800902068000)
      [   37.146949] 7ce0:                                   ffff800902067d40 ffff000008085334
      [   37.154869] 7d00: 0000000000000000 ffff000008f3b000 ffff800902067d40 ffff0000080852e0
      [   37.162787] 7d20: ffff000008cc6fb0 ffff000008cc6fb8 ffff000008c7f580 ffff000008c97dd8
      [   37.170706] 7d40: ffff800902067d60 ffff0000080e2c2c 0000000000000000 0000000001234567
      [   37.178624] 7d60: ffff800902067d80 ffff0000080e2ee8 0000000000000000 ffff0000080e2df4
      [   37.186544] 7d80: 0000000000000000 ffff0000080830f0 0000000000000000 00008008ff1c1000
      [   37.194462] 7da0: ffffffffffffffff 0000ffffa7c4b1cc 0000000000000000 0000000000000024
      [   37.202380] 7dc0: ffff800902067dd0 0000000000000005 0000fffff24743c8 0000000000000004
      [   37.210299] 7de0: 0000fffff2475f03 0000000000000010 0000fffff2474418 0000000000000005
      [   37.218218] 7e00: 0000fffff2474578 000000000000000a 0000aaaad6b722c0 0000000000000001
      [   37.226136] 7e20: 0000000000000123 0000000000000038 ffff800902067e50 ffff0000081e7294
      [   37.234055] 7e40: ffff800902067e60 ffff0000081e935c ffff800902067e60 ffff0000081e9388
      [   37.241973] 7e60: ffff800902067eb0 ffff0000081ea388 0000000000000000 00008008ff1c1000
      [   37.249892] 7e80: ffffffffffffffff 0000ffffa7c4a79c 0000000000000000 ffff000000020000
      [   37.257810] 7ea0: 0000010000000004 0000000000000000 0000000000000000 ffff0000080830f0
      [   37.265729] 7ec0: fffffffffee1dead 0000000028121969 0000000001234567 0000000000000000
      [   37.273651] 7ee0: ffffffffffffffff 8080000000800000 0000800000008080 feffa9a9d4ff2d66
      [   37.281567] 7f00: 000000000000008e feffa9a9d5b60e0f 7f7fffffffff7f7f 0101010101010101
      [   37.289485] 7f20: 0000000000000010 0000000000000008 000000000000003a 0000ffffa7ccf588
      [   37.297404] 7f40: 0000aaaad6b87d00 0000ffffa7c4b1b0 0000fffff2474be0 0000aaaad6b88000
      [   37.305326] 7f60: 0000fffff2474fb0 0000000001234567 0000000000000000 0000000000000000
      [   37.313240] 7f80: 0000000000000000 0000000000000001 0000aaaad6b70d4d 0000000000000000
      [   37.321159] 7fa0: 0000000000000001 0000fffff2474ea0 0000aaaad6b5e2e0 0000fffff2474e80
      [   37.329078] 7fc0: 0000ffffa7c4b1cc 0000000000000000 fffffffffee1dead 000000000000008e
      [   37.336997] 7fe0: 0000000000000000 0000000000000000 9ce839cffee77eab fafdbf9f7ed57f2f
      [   37.344911] Call trace:
      [   37.347437] Exception stack(0xffff800902067b20 to 0xffff800902067c50)
      [   37.353970] 7b20: ffff000008e5d4c8 0001000000000000 0000000080f82000 0000000000000000
      [   37.361883] 7b40: ffff800902067b60 ffff000008e17000 ffff000008f44c68 00000001081081b4
      [   37.369802] 7b60: ffff800902067bf0 ffff000008108478 0000000000000000 ffff000008c235b0
      [   37.377721] 7b80: ffff800902067ce0 0000000000000000 0000000000000000 0000000000000015
      [   37.385643] 7ba0: 0000000000000123 000000000000008e ffff000008992000 ffff800902068000
      [   37.393557] 7bc0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
      [   37.401477] 7be0: 0000000000000000 ffff000008c97dd8 ffff000008cc6fb0 ffff000008cc6fb8
      [   37.409396] 7c00: 6974726174736552 ffff800902067a50 0000000005f5e0ff ffff000008e70000
      [   37.417318] 7c20: ffff000008e706c0 ffff000008f42bfd ffff000088f42bef 0000000000000006
      [   37.425234] 7c40: 00000000deadbeef 0000ffffa7c27470
      [   37.430190] [<          (null)>]           (null)
      [   37.434982] [<ffff000008085334>] machine_restart+0x6c/0x70
      [   37.440550] [<ffff0000080e2c2c>] kernel_restart+0x6c/0x78
      [   37.446030] [<ffff0000080e2ee8>] SyS_reboot+0x130/0x228
      [   37.451337] [<ffff0000080830f0>] el0_svc_naked+0x24/0x28
      [   37.456737] Code: bad PC value
      [   37.459891] ---[ end trace 76e2fc17e050aecd ]---
      Signed-off-by: NJulien Grall <julien.grall@arm.com>
      
      --
      
      Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
      Cc: Juergen Gross <jgross@suse.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: x86@kernel.org
      
      The x86 code has theoritically a similar issue, altought EFI does not
      seem to be the preferred method. I have only built test it on x86.
      
      This should also probably be fixed in stable tree.
      
          Changes in v2:
              - Implement xen_efi_reset_system using xen_reboot
              - Move xen_efi_reset_system in drivers/xen/efi.c
      Signed-off-by: NJuergen Gross <jgross@suse.com>
      e371fd76
    • J
    • S
      xen/arm,arm64: fix xen_dma_ops after 815dd187 "Consolidate get_dma_ops..." · e0586326
      Stefano Stabellini 提交于
      The following commit:
      
        commit 815dd187
        Author: Bart Van Assche <bart.vanassche@sandisk.com>
        Date:   Fri Jan 20 13:04:04 2017 -0800
      
            treewide: Consolidate get_dma_ops() implementations
      
      rearranges get_dma_ops in a way that xen_dma_ops are not returned when
      running on Xen anymore, dev->dma_ops is returned instead (see
      arch/arm/include/asm/dma-mapping.h:get_arch_dma_ops and
      include/linux/dma-mapping.h:get_dma_ops).
      
      Fix the problem by storing dev->dma_ops in dev_archdata, and setting
      dev->dma_ops to xen_dma_ops. This way, xen_dma_ops is returned naturally
      by get_dma_ops. The Xen code can retrieve the original dev->dma_ops from
      dev_archdata when needed. It also allows us to remove __generic_dma_ops
      from common headers.
      Signed-off-by: NStefano Stabellini <sstabellini@kernel.org>
      Tested-by: NJulien Grall <julien.grall@arm.com>
      Suggested-by: NCatalin Marinas <catalin.marinas@arm.com>
      Reviewed-by: NCatalin Marinas <catalin.marinas@arm.com>
      Cc: <stable@vger.kernel.org>        [4.11+]
      CC: linux@armlinux.org.uk
      CC: catalin.marinas@arm.com
      CC: will.deacon@arm.com
      CC: boris.ostrovsky@oracle.com
      CC: jgross@suse.com
      CC: Julien Grall <julien.grall@arm.com>
      e0586326
  8. 29 4月, 2017 1 次提交
  9. 28 4月, 2017 1 次提交
  10. 27 4月, 2017 4 次提交
  11. 26 4月, 2017 3 次提交
    • G
      ARM: 8672/1: mm: remove tasklist locking from update_sections_early() · 11ce4b33
      Grygorii Strashko 提交于
      The below backtrace can be observed on -rt kernel with
      CONFIG_DEBUG_MODULE_RONX (4.9 kernel CONFIG_DEBUG_RODATA) option enabled:
      
       BUG: sleeping function called from invalid context at kernel/locking/rtmutex.c:993
       in_atomic(): 1, irqs_disabled(): 128, pid: 14, name: migration/0
       1 lock held by migration/0/14:
        #0:  (tasklist_lock){+.+...}, at: [<c01183e8>] update_sections_early+0x24/0xdc
       irq event stamp: 38
       hardirqs last  enabled at (37): [<c08f6f7c>] _raw_spin_unlock_irq+0x24/0x68
       hardirqs last disabled at (38): [<c01fdfe8>] multi_cpu_stop+0xd8/0x138
       softirqs last  enabled at (0): [<c01303ec>] copy_process.part.5+0x238/0x1b64
       softirqs last disabled at (0): [<  (null)>]   (null)
       Preemption disabled at: [<c01fe244>] cpu_stopper_thread+0x80/0x10c
       CPU: 0 PID: 14 Comm: migration/0 Not tainted 4.9.21-rt16-02220-g49e319c #15
       Hardware name: Generic DRA74X (Flattened Device Tree)
       [<c0112014>] (unwind_backtrace) from [<c010d370>] (show_stack+0x10/0x14)
       [<c010d370>] (show_stack) from [<c049beb8>] (dump_stack+0xa8/0xd4)
       [<c049beb8>] (dump_stack) from [<c01631a0>] (___might_sleep+0x1bc/0x2ac)
       [<c01631a0>] (___might_sleep) from [<c08f7244>] (__rt_spin_lock+0x1c/0x30)
       [<c08f7244>] (__rt_spin_lock) from [<c08f77a4>] (rt_read_lock+0x54/0x68)
       [<c08f77a4>] (rt_read_lock) from [<c01183e8>] (update_sections_early+0x24/0xdc)
       [<c01183e8>] (update_sections_early) from [<c01184b0>] (__fix_kernmem_perms+0x10/0x1c)
       [<c01184b0>] (__fix_kernmem_perms) from [<c01fe010>] (multi_cpu_stop+0x100/0x138)
       [<c01fe010>] (multi_cpu_stop) from [<c01fe24c>] (cpu_stopper_thread+0x88/0x10c)
       [<c01fe24c>] (cpu_stopper_thread) from [<c015edc4>] (smpboot_thread_fn+0x174/0x31c)
       [<c015edc4>] (smpboot_thread_fn) from [<c015a988>] (kthread+0xf0/0x108)
       [<c015a988>] (kthread) from [<c0108818>] (ret_from_fork+0x14/0x3c)
       Freeing unused kernel memory: 1024K (c0d00000 - c0e00000)
      
      The stop_machine() is called with cpus = NULL from fix_kernmem_perms() and
      mark_rodata_ro() which means only one CPU will execute
      update_sections_early() while all other CPUs will spin and wait. Hence,
      it's safe to remove tasklist locking from update_sections_early(). As part
      of this change also mark functions which are local to this module as
      static.
      Signed-off-by: NGrygorii Strashko <grygorii.strashko@ti.com>
      Acked-by: NLaura Abbott <labbott@redhat.com>
      Acked-by: NKees Cook <keescook@chromium.org>
      Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>
      11ce4b33
    • V
      ARM: 8671/1: V7M: Preserve registers across switch from Thread to Handler mode · b70cd406
      Vladimir Murzin 提交于
      According to ARMv7 ARM, when exception is taken content of r0-r3, r12
      is unknown (see ExceptionTaken() pseudocode). Even though existent
      implementations keep these register unchanged, preserve them to be in
      line with architecture.
      Reported-by: NDobromir Stefanov <dobromir.stefanov@arm.com>
      Signed-off-by: NVladimir Murzin <vladimir.murzin@arm.com>
      Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>
      b70cd406
    • V
      ARM: 8670/1: V7M: Do not corrupt vector table around v7m_invalidate_l1 call · 6d805949
      Vladimir Murzin 提交于
      We save/restore registers around v7m_invalidate_l1 to address pointed
      by r12, which is vector table, so the first eight entries are
      overwritten with a garbage. We already have stack setup at that stage,
      so use it to save/restore register.
      
      Fixes: 6a8146f4 ("ARM: 8609/1: V7M: Add support for the Cortex-M7 processor")
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NVladimir Murzin <vladimir.murzin@arm.com>
      Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>
      6d805949
  12. 25 4月, 2017 2 次提交
    • R
      regulator: arizona-ldo1: Move pdata into a separate structure · aaa84e6a
      Richard Fitzgerald 提交于
      In preparation for sharing this driver with Madera, move the pdata
      for the LDO1 regulator out of struct arizona_pdata into a dedicated
      pdata struct for this driver. As a result the code in
      arizona_ldo1_of_get_pdata() can be made independent of struct arizona.
      
      This patch also updates the definition of struct arizona_pdata and
      the use of this pdata in mach-crag6410-module.c
      Signed-off-by: NRichard Fitzgerald <rf@opensource.wolfsonmicro.com>
      Acked-by: NKrzysztof Kozlowski <krzk@kernel.org>
      Acked-by: NLee Jones <lee.jones@linaro.org>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      aaa84e6a
    • L
      ARM: Implement pci_remap_cfgspace() interface · b9cdbe6e
      Lorenzo Pieralisi 提交于
      The PCI bus specification (rev 3.0, 3.2.5 "Transaction Ordering and
      Posting") defines rules for PCI configuration space transactions ordering
      and posting, that state that configuration writes have to be non-posted
      transactions.
      
      Current ioremap interface on ARM provides mapping functions that provide
      "bufferable" writes transactions (ie ioremap uses MT_DEVICE memory type)
      aka posted writes, so PCI host controller drivers have no arch interface to
      remap PCI configuration space with memory attributes that comply with the
      PCI specifications for configuration space.
      
      Implement an ARM specific pci_remap_cfgspace() interface that allows to map
      PCI config memory regions with MT_UNCACHED memory type (ie strongly ordered
      - non-posted writes), providing a remap function that complies with PCI
      specifications for config space transactions.
      Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Russell King <linux@armlinux.org.uk>
      b9cdbe6e
  13. 23 4月, 2017 1 次提交
    • I
      Revert "x86/mm/gup: Switch GUP to the generic get_user_page_fast() implementation" · 6dd29b3d
      Ingo Molnar 提交于
      This reverts commit 2947ba05.
      
      Dan Williams reported dax-pmem kernel warnings with the following signature:
      
         WARNING: CPU: 8 PID: 245 at lib/percpu-refcount.c:155 percpu_ref_switch_to_atomic_rcu+0x1f5/0x200
         percpu ref (dax_pmem_percpu_release [dax_pmem]) <= 0 (0) after switching to atomic
      
      ... and bisected it to this commit, which suggests possible memory corruption
      caused by the x86 fast-GUP conversion.
      
      He also pointed out:
      
       "
        This is similar to the backtrace when we were not properly handling
        pud faults and was fixed with this commit: 220ced16 "mm: fix
        get_user_pages() vs device-dax pud mappings"
      
        I've found some missing _devmap checks in the generic
        get_user_pages_fast() path, but this does not fix the regression
        [...]
       "
      
      So given that there are known bugs, and a pretty robust looking bisection
      points to this commit suggesting that are unknown bugs in the conversion
      as well, revert it for the time being - we'll re-try in v4.13.
      Reported-by: NDan Williams <dan.j.williams@intel.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Michal Hocko <mhocko@suse.cz>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Rik van Riel <riel@redhat.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: aneesh.kumar@linux.vnet.ibm.com
      Cc: dann.frazier@canonical.com
      Cc: dave.hansen@intel.com
      Cc: steve.capper@linaro.org
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      6dd29b3d
  14. 21 4月, 2017 2 次提交
  15. 20 4月, 2017 5 次提交
  16. 19 4月, 2017 6 次提交