1. 28 Aug, 2016 4 commits
    • Russell King's avatar
      net: smc91x: fix SMC accesses · 2fb04fdf
      Russell King authored
      Commit b70661c7 ("net: smc91x: use run-time configuration on all ARM
      machines") broke some ARM platforms through several mistakes.  Firstly,
      the access size must correspond to the following rule:
      
      (a) at least one of 16-bit or 8-bit access size must be supported
      (b) 32-bit accesses are optional, and may be enabled in addition to
          the above.
      
      Secondly, it provides no emulation of 16-bit accesses, instead blindly
      making 16-bit accesses even when the platform specifies that only 8-bit
      is supported.
      
      Reorganise smc91x.h so we can make use of the existing 16-bit access
      emulation already provided - if 16-bit accesses are supported, use
      16-bit accesses directly, otherwise if 8-bit accesses are supported,
      use the provided 16-bit access emulation.  If neither, BUG().  This
      exactly reflects the driver behaviour prior to the commit being fixed.
      
      Since the conversion incorrectly cut down the available access sizes on
      several platforms, we also need to go through every platform and fix up
      the overly-restrictive access size: Arnd assumed that if a platform can
      perform 32-bit, 16-bit and 8-bit accesses, then only a 32-bit access
      size needed to be specified - not so, all available access sizes must
      be specified.
      
      This likely fixes some performance regressions in doing this: if a
      platform does not support 8-bit accesses, 8-bit accesses have been
      emulated by performing a 16-bit read-modify-write access.
      
      Tested on the Intel Assabet/Neponset platform, which supports only 8-bit
      accesses, which was broken by the original commit.
      
      Fixes: b70661c7
      
       ("net: smc91x: use run-time configuration on all ARM machines")
      Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      Tested-by: default avatarRobert Jarzmik <robert.jarzmik@free.fr>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2fb04fdf
    • Cyril Bur's avatar
      powerpc: signals: Discard transaction state from signal frames · 78a3e888
      Cyril Bur authored
      
      
      Userspace can begin and suspend a transaction within the signal
      handler which means they might enter sys_rt_sigreturn() with the
      processor in suspended state.
      
      sys_rt_sigreturn() wants to restore process context (which may have
      been in a transaction before signal delivery). To do this it must
      restore TM SPRS. To achieve this, any transaction initiated within the
      signal frame must be discarded in order to be able to restore TM SPRs
      as TM SPRs can only be manipulated non-transactionally..
      >From the PowerPC ISA:
        TM Bad Thing Exception [Category: Transactional Memory]
         An attempt is made to execute a mtspr targeting a TM register in
         other than Non-transactional state.
      
      Not doing so results in a TM Bad Thing:
      [12045.221359] Kernel BUG at c000000000050a40 [verbose debug info unavailable]
      [12045.221470] Unexpected TM Bad Thing exception at c000000000050a40 (msr 0x201033)
      [12045.221540] Oops: Unrecoverable exception, sig: 6 [#1]
      [12045.221586] SMP NR_CPUS=2048 NUMA PowerNV
      [12045.221634] Modules linked in: xt_CHECKSUM iptable_mangle ipt_MASQUERADE
       nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4
       xt_conntrack nf_conntrack ipt_REJECT nf_reject_ipv4 xt_tcpudp bridge stp llc ebtable_filter
       ebtables ip6table_filter ip6_tables iptable_filter ip_tables x_tables kvm_hv kvm
       uio_pdrv_genirq ipmi_powernv uio powernv_rng ipmi_msghandler autofs4 ses enclosure
       scsi_transport_sas bnx2x ipr mdio libcrc32c
      [12045.222167] CPU: 68 PID: 6178 Comm: sigreturnpanic Not tainted 4.7.0 #34
      [12045.222224] task: c0000000fce38600 ti: c0000000fceb4000 task.ti: c0000000fceb4000
      [12045.222293] NIP: c000000000050a40 LR: c0000000000163bc CTR: 0000000000000000
      [12045.222361] REGS: c0000000fceb7ac0 TRAP: 0700   Not tainted (4.7.0)
      [12045.222418] MSR: 9000000300201033 <SF,HV,ME,IR,DR,RI,LE,TM[SE]> CR: 28444280  XER: 20000000
      [12045.222625] CFAR: c0000000000163b8 SOFTE: 0 PACATMSCRATCH: 900000014280f033
      GPR00: 01100000b8000001 c0000000fceb7d40 c00000000139c100 c0000000fce390d0
      GPR04: 900000034280f033 0000000000000000 0000000000000000 0000000000000000
      GPR08: 0000000000000000 b000000000001033 0000000000000001 0000000000000000
      GPR12: 0000000000000000 c000000002926400 0000000000000000 0000000000000000
      GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
      GPR20: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
      GPR24: 0000000000000000 00003ffff98cadd0 00003ffff98cb470 0000000000000000
      GPR28: 900000034280f033 c0000000fceb7ea0 0000000000000001 c0000000fce390d0
      [12045.223535] NIP [c000000000050a40] tm_restore_sprs+0xc/0x1c
      [12045.223584] LR [c0000000000163bc] tm_recheckpoint+0x5c/0xa0
      [12045.223630] Call Trace:
      [12045.223655] [c0000000fceb7d80] [c000000000026e74] sys_rt_sigreturn+0x494/0x6c0
      [12045.223738] [c0000000fceb7e30] [c0000000000092e0] system_call+0x38/0x108
      [12045.223806] Instruction dump:
      [12045.223841] 7c800164 4e800020 7c0022a6 f80304a8 7c0222a6 f80304b0 7c0122a6 f80304b8
      [12045.223955] 4e800020 e80304a8 7c0023a6 e80304b0 <7c0223a6> e80304b8 7c0123a6 4e800020
      [12045.224074] ---[ end trace cb8002ee240bae76 ]---
      
      It isn't clear exactly if there is really a use case for userspace
      returning with a suspended transaction, however, doing so doesn't (on
      its own) constitute a bad frame. As such, this patch simply discards
      the transactional state of the context calling the sigreturn and
      continues.
      Reported-by: default avatarLaurent Dufour <ldufour@linux.vnet.ibm.com>
      Signed-off-by: default avatarCyril Bur <cyrilbur@gmail.com>
      Tested-by: default avatarLaurent Dufour <ldufour@linux.vnet.ibm.com>
      Reviewed-by: default avatarLaurent Dufour <ldufour@linux.vnet.ibm.com>
      Acked-by: default avatarSimon Guo <wei.guo.simon@gmail.com>
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      78a3e888
    • Mukesh Ojha's avatar
      powerpc/powernv : Drop reference added by kset_find_obj() · a9cbf0b2
      Mukesh Ojha authored
      
      
      In a situation, where Linux kernel gets notified about duplicate error log
      from OPAL, it is been observed that kernel fails to remove sysfs entries
      (/sys/firmware/opal/elog/0xXXXXXXXX) of such error logs. This is because,
      we currently search the error log/dump kobject in the kset list via
      'kset_find_obj()' routine. Which eventually increment the reference count
      by one, once it founds the kobject.
      
      So, unless we decrement the reference count by one after it found the kobject,
      we would not be able to release the kobject properly later.
      
      This patch adds the 'kobject_put()' which was missing earlier.
      Signed-off-by: default avatarMukesh Ojha <mukesh02@linux.vnet.ibm.com>
      Cc: stable@vger.kernel.org
      Reviewed-by: default avatarVasant Hegde <hegdevasant@linux.vnet.ibm.com>
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      a9cbf0b2
    • Nicholas Piggin's avatar
      powerpc/tm: do not use r13 for tabort_syscall · cc7786d3
      Nicholas Piggin authored
      tabort_syscall runs with RI=1, so a nested recoverable machine
      check will load the paca into r13 and overwrite what we loaded
      it with, because exceptions returning to privileged mode do not
      restore r13.
      
      Fixes: b4b56f9e
      
       (powerpc/tm: Abort syscalls in active transactions)
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarNick Piggin <npiggin@gmail.com>
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      cc7786d3
  2. 26 Aug, 2016 1 commit
  3. 25 Aug, 2016 1 commit
  4. 24 Aug, 2016 2 commits
  5. 23 Aug, 2016 2 commits
  6. 21 Aug, 2016 12 commits
    • Paolo Bonzini's avatar
      powerpc: move hmi.c to arch/powerpc/kvm/ · 7c379526
      Paolo Bonzini authored
      
      
      hmi.c functions are unused unless sibling_subcore_state is nonzero, and
      that in turn happens only if KVM is in use.  So move the code to
      arch/powerpc/kvm/, putting it under CONFIG_KVM_BOOK3S_HV_POSSIBLE
      rather than CONFIG_PPC_BOOK3S_64.  The sibling_subcore_state is also
      included in struct paca_struct only if KVM is supported by the kernel.
      
      Cc: Daniel Axtens <dja@axtens.net>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: linuxppc-dev@lists.ozlabs.org
      Cc: kvm-ppc@vger.kernel.org
      Cc: kvm@vger.kernel.org
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      7c379526
    • Christophe Leroy's avatar
      powerpc: sysdev: cpm: fix gpio save_regs functions · 41017a75
      Christophe Leroy authored
      of_mm_gpiochip_add_data() calls mm_gc->save_regs() before
      setting the data. Therefore ->save_regs() cannot use
      gpiochip_get_data()
      
      [    0.275940] Unable to handle kernel paging request for data at address 0x00000130
      [    0.283120] Faulting instruction address: 0xc01b44cc
      [    0.288175] Oops: Kernel access of bad area, sig: 11 [#1]
      [    0.293343] PREEMPT CMPC885
      [    0.296141] CPU: 0 PID: 1 Comm: swapper Not tainted 4.7.0-g65124df-dirty #68
      [    0.304131] task: c6074000 ti: c6080000 task.ti: c6080000
      [    0.309459] NIP: c01b44cc LR: c0011720 CTR: c0011708
      [    0.314372] REGS: c6081d90 TRAP: 0300   Not tainted  (4.7.0-g65124df-dirty)
      [    0.322267] MSR: 00009032 <EE,ME,IR,DR,RI>  CR: 24000028  XER: 20000000
      [    0.328813] DAR: 00000130 DSISR: c0000000
      GPR00: c01b6d0c c6081e40 c6074000 c6017000 c9028000 c601d028 c6081dd8 00000000
      GPR08: c601d028 00000000 ffffffff 00000001 24000044 00000000 c0002790 00000000
      GPR16: 00000000 00000000 00000000 00000000 00000000 00000000 c05643b0 00000083
      GPR24: c04a1a6c c0560000 c04a8308 c04c6480 c0012498 c6017000 c7ffcc78 c6017000
      [    0.360806] NIP [c01b44cc] gpiochip_get_data+0x4/0xc
      [    0.365684] LR [c0011720] cpm1_gpio16_save_regs+0x18/0x44
      [    0.370972] Call Trace:
      [    0.373451] [c6081e50] [c01b6d0c] of_mm_gpiochip_add_data+0x70/0xdc
      [    0.379624] [c6081e70] [c00124c0] cpm_init_par_io+0x28/0x118
      [    0.385238] [c6081e80] [c04a8ac0] do_one_initcall+0xb0/0x17c
      [    0.390819] [c6081ef0] [c04a8cbc] kernel_init_freeable+0x130/0x1dc
      [    0.396924] [c6081f30] [c00027a4] kernel_init+0x14/0x110
      [    0.402177] [c6081f40] [c000b424] ret_from_kernel_thread+0x5c/0x64
      [    0.408233] Instruction dump:
      [    0.411168] 4182fafc 3f80c040 48234c6d 3bc0fff0 3b9c5ed0 4bfffaf4 81290020 712a0004
      [    0.418825] 4182fb34 48234c51 4bfffb2c 81230004 <80690130> 4e800020 7c0802a6 9421ffe0
      [    0.426763] ---[ end trace fe4113ee21d72ffa ]---
      
      fixes: e65078f1 ("powerpc: sysdev: cpm1: use gpiochip data pointer")
      fixes: a14a2d48
      
       ("powerpc: cpm_common: use gpiochip data pointer")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarChristophe Leroy <christophe.leroy@c-s.fr>
      Reviewed-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      41017a75
    • Nicholas Piggin's avatar
      powerpc/pseries: PACA save area fix for MCE vs MCE · a74599a5
      Nicholas Piggin authored
      
      
      MCE must not enable MSR_RI until PACA_EXMC is no longer being used.
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      a74599a5
    • Nicholas Piggin's avatar
      powerpc/pseries: PACA save area fix for general exception vs MCE · 3f3b5dc1
      Nicholas Piggin authored
      
      
      MCE must not use PACA_EXGEN. When a general exception enables MSR_RI,
      that means SPRN_SRR[01] and SPRN_SPRG are no longer used. However the
      PACA save area is still in use.
      Acked-by: default avatarMahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      3f3b5dc1
    • Michael Ellerman's avatar
      powerpc/prom: Fix sub-processor option passed to ibm, client-architecture-support · 66443efa
      Michael Ellerman authored
      When booting from an OpenFirmware which supports it, we use the
      "ibm,client-architecture-support" firmware call to communicate
      our capabilities to firmware.
      
      The format of the structure we pass to firmware is specified in
      PAPR (Power Architecture Platform Requirements), or the public version
      LoPAPR (Linux on Power Architecture Platform Reference).
      
      Referring to table 244 in LoPAPR v1.1, option vector 5 contains a 4 byte
      field at bytes 17-20 for the "Platform Facilities Enable". This is
      followed by a 1 byte field at byte 21 for "Sub-Processor Represenation
      Level".
      
      Comparing to the code, there we have the Platform Facilities
      options (OV5_PFO_*) at byte 17, but we fail to pad that field out to its
      full width of 4 bytes. This means the OV5_SUB_PROCESSORS option is
      incorrectly placed at byte 18.
      
      Fix it by adding zero bytes for bytes 18, 19, 20, and comment the bytes
      to hopefully make it clearer in future.
      
      As far as I'm aware nothing actually consumes this value at this time,
      so the effect of this bug is nil in practice.
      
      It does mean we've been incorrectly setting bit 15 of the "Platform
      Facilities Enable" option for the past ~3 1/2 years, so we should avoid
      allocating that bit to anything else in future.
      
      Fixes: df77c799
      
       ("powerpc/pseries: Update ibm,architecture.vec for PAPR 2.7/POWER8")
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      66443efa
    • Boqun Feng's avatar
      powerpc, hotplug: Avoid to touch non-existent cpumasks. · 19ab58d1
      Boqun Feng authored
      
      
      We observed a kernel oops when running a PPC guest with config NR_CPUS=4
      and qemu option "-smp cores=1,threads=8":
      
      [   30.634781] Unable to handle kernel paging request for data at
      address 0xc00000014192eb17
      [   30.636173] Faulting instruction address: 0xc00000000003e5cc
      [   30.637069] Oops: Kernel access of bad area, sig: 11 [#1]
      [   30.637877] SMP NR_CPUS=4 NUMA pSeries
      [   30.638471] Modules linked in:
      [   30.638949] CPU: 3 PID: 27 Comm: migration/3 Not tainted
      4.7.0-07963-g9714b26 #1
      [   30.640059] task: c00000001e29c600 task.stack: c00000001e2a8000
      [   30.640956] NIP: c00000000003e5cc LR: c00000000003e550 CTR:
      0000000000000000
      [   30.642001] REGS: c00000001e2ab8e0 TRAP: 0300   Not tainted
      (4.7.0-07963-g9714b26)
      [   30.643139] MSR: 8000000102803033 <SF,VEC,VSX,FP,ME,IR,DR,RI,LE,TM[E]>  CR: 22004084  XER: 00000000
      [   30.644583] CFAR: c000000000009e98 DAR: c00000014192eb17 DSISR: 40000000 SOFTE: 0
      GPR00: c00000000140a6b8 c00000001e2abb60 c0000000016dd300 0000000000000003
      GPR04: 0000000000000000 0000000000000004 c0000000016e5920 0000000000000008
      GPR08: 0000000000000004 c00000014192eb17 0000000000000000 0000000000000020
      GPR12: c00000000140a6c0 c00000000ffffc00 c0000000000d3ea8 c00000001e005680
      GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
      GPR20: 0000000000000000 c00000001e6b3a00 0000000000000000 0000000000000001
      GPR24: c00000001ff85138 c00000001ff85130 000000001eb6f000 0000000000000001
      GPR28: 0000000000000000 c0000000017014e0 0000000000000000 0000000000000018
      [   30.653882] NIP [c00000000003e5cc] __cpu_disable+0xcc/0x190
      [   30.654713] LR [c00000000003e550] __cpu_disable+0x50/0x190
      [   30.655528] Call Trace:
      [   30.655893] [c00000001e2abb60] [c00000000003e550] __cpu_disable+0x50/0x190 (unreliable)
      [   30.657280] [c00000001e2abbb0] [c0000000000aca0c] take_cpu_down+0x5c/0x100
      [   30.658365] [c00000001e2abc10] [c000000000163918] multi_cpu_stop+0x1a8/0x1e0
      [   30.659617] [c00000001e2abc60] [c000000000163cc0] cpu_stopper_thread+0xf0/0x1d0
      [   30.660737] [c00000001e2abd20] [c0000000000d8d70] smpboot_thread_fn+0x290/0x2a0
      [   30.661879] [c00000001e2abd80] [c0000000000d3fa8] kthread+0x108/0x130
      [   30.662876] [c00000001e2abe30] [c000000000009968] ret_from_kernel_thread+0x5c/0x74
      [   30.664017] Instruction dump:
      [   30.664477] 7bde1f24 38a00000 787f1f24 3b600001 39890008 7d204b78 7d05e214 7d0b07b4
      [   30.665642] 796b1f24 7d26582a 7d204a14 7d29f214 <7d4048a8> 7d4a3878 7d4049ad 40c2fff4
      [   30.666854] ---[ end trace 32643b7195717741 ]---
      
      The reason of this is that in __cpu_disable(), when we try to set the
      cpu_sibling_mask or cpu_core_mask of the sibling CPUs of the disabled
      one, we don't check whether the current configuration employs those
      sibling CPUs(hw threads). And if a CPU is not employed by a
      configuration, the percpu structures cpu_{sibling,core}_mask are not
      allocated, therefore accessing those cpumasks will result in problems as
      above.
      
      This patch fixes this problem by adding an addition check on whether the
      id is no less than nr_cpu_ids in the sibling CPU iteration code.
      Signed-off-by: default avatarBoqun Feng <boqun.feng@gmail.com>
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      19ab58d1
    • Paul Gortmaker's avatar
      powerpc: migrate exception table users off module.h and onto extable.h · 8a39b05f
      Paul Gortmaker authored
      
      
      These files were only including module.h for exception table
      related functions.  We've now separated that content out into its
      own file "extable.h" so now move over to that and avoid all the
      extra header content in module.h that we don't really need to compile
      these files.
      
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: linuxppc-dev@lists.ozlabs.org
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      8a39b05f
    • Andrzej Hajda's avatar
      powerpc/powernv/pci: fix iterator signedness · 60964816
      Andrzej Hajda authored
      
      
      Unsigned type is always non-negative, so the loop could not end in case
      condition is never true.
      
      The problem has been detected using semantic patch
      scripts/coccinelle/tests/unsigned_lesser_than_zero.cocci
      Signed-off-by: default avatarAndrzej Hajda <a.hajda@samsung.com>
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      60964816
    • Mauricio Faria de Oliveira's avatar
      powerpc/pseries: use pci_host_bridge.release_fn() to kfree(phb) · 2dd9c11b
      Mauricio Faria de Oliveira authored
      
      
      This patch leverages 'struct pci_host_bridge' from the PCI subsystem
      in order to free the pci_controller only after the last reference to
      its devices is dropped (avoiding an oops in pcibios_release_device()
      if the last reference is dropped after pcibios_free_controller()).
      
      The patch relies on pci_host_bridge.release_fn() (and .release_data),
      which is called automatically by the PCI subsystem when the root bus
      is released (i.e., the last reference is dropped).  Those fields are
      set via pci_set_host_bridge_release() (e.g. in the platform-specific
      implementation of pcibios_root_bridge_prepare()).
      
      It introduces the 'pcibios_free_controller_deferred()' .release_fn()
      and it expects .release_data to hold a pointer to the pci_controller.
      
      The function implictly calls 'pcibios_free_controller()', so an user
      must *NOT* explicitly call it if using the new _deferred() callback.
      
      The functionality is enabled for pseries (although it isn't platform
      specific, and may be used by cxl).
      
      Details on not-so-elegant design choices:
      
       - Use 'pci_host_bridge.release_data' field as pointer to associated
         'struct pci_controller' so *not* to 'pci_bus_to_host(bridge->bus)'
         in pcibios_free_controller_deferred().
      
         That's because pci_remove_root_bus() sets 'host_bridge->bus = NULL'
         (so, if the last reference is released after pci_remove_root_bus()
         runs, which eventually reaches pcibios_free_controller_deferred(),
         that would hit a null pointer dereference).
      
         The cxl/vphb.c code calls pci_remove_root_bus(), and the cxl folks
         are interested in this fix.
      
      Test-case #1 (hold references)
      
        # ls -ld /sys/block/sd* | grep -m1 0021:01:00.0
        <...> /sys/block/sdaa -> ../devices/pci0021:01/0021:01:00.0/<...>
      
        # ls -ld /sys/block/sd* | grep -m1 0021:01:00.1
        <...> /sys/block/sdab -> ../devices/pci0021:01/0021:01:00.1/<...>
      
        # cat >/dev/sdaa & pid1=$!
        # cat >/dev/sdab & pid2=$!
      
        # drmgr -w 5 -d 1 -c phb -s 'PHB 33' -r
        Validating PHB DLPAR capability...yes.
        [  594.306719] pci_hp_remove_devices: PCI: Removing devices on bus 0021:01
        [  594.306738] pci_hp_remove_devices:    Removing 0021:01:00.0...
        ...
        [  598.236381] pci_hp_remove_devices:    Removing 0021:01:00.1...
        ...
        [  611.972077] pci_bus 0021:01: busn_res: [bus 01-ff] is released
        [  611.972140] rpadlpar_io: slot PHB 33 removed
      
        # kill -9 $pid1
        # kill -9 $pid2
        [  632.918088] pcibios_free_controller_deferred: domain 33, dynamic 1
      
      Test-case #2 (don't hold references)
      
        # drmgr -w 5 -d 1 -c phb -s 'PHB 33' -r
        Validating PHB DLPAR capability...yes.
        [  916.357363] pci_hp_remove_devices: PCI: Removing devices on bus 0021:01
        [  916.357386] pci_hp_remove_devices:    Removing 0021:01:00.0...
        ...
        [  920.566527] pci_hp_remove_devices:    Removing 0021:01:00.1...
        ...
        [  933.955873] pci_bus 0021:01: busn_res: [bus 01-ff] is released
        [  933.955977] pcibios_free_controller_deferred: domain 33, dynamic 1
        [  933.955999] rpadlpar_io: slot PHB 33 removed
      Suggested-By: default avatarGavin Shan <gwshan@linux.vnet.ibm.com>
      Signed-off-by: default avatarMauricio Faria de Oliveira <mauricfo@linux.vnet.ibm.com>
      Reviewed-by: default avatarGavin Shan <gwshan@linux.vnet.ibm.com>
      Reviewed-by: default avatarAndrew Donnellan <andrew.donnellan@au1.ibm.com>
      Tested-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com> # cxl
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      2dd9c11b
    • Markus Elfring's avatar
      powerpc: mpc8349emitx: Delete unnecessary assignment for the field "owner" · f5ed841c
      Markus Elfring authored
      
      
      The field "owner" is set by the core.
      Thus delete an unneeded initialisation.
      
      Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci
      Signed-off-by: default avatarMarkus Elfring <elfring@users.sourceforge.net>
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      f5ed841c
    • Markus Elfring's avatar
      powerpc/512x: Delete unnecessary assignment for the field "owner" · e72e799c
      Markus Elfring authored
      
      
      The field "owner" is set by the core.
      Thus delete an unneeded initialisation.
      
      Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci
      Signed-off-by: default avatarMarkus Elfring <elfring@users.sourceforge.net>
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      e72e799c
    • Guenter Roeck's avatar
      powerpc: cputhreads: Add missing include file · e340eca9
      Guenter Roeck authored
      Powerpc builds may fail with the following build error.
      
      Error log:
      In file included from ./arch/powerpc/include/asm/mmu_context.h:11:0,
                       from ./include/linux/mmu_context.h:4,
      		 from mm/mmu_context.c:8:
      ./arch/powerpc/include/asm/cputhreads.h: In function 'get_tensr':
      ./arch/powerpc/include/asm/cputhreads.h:101:2: error:
      	implicit declaration of function 'cpu_has_feature'
      
      The problem can be triggered by configuring ppc64e_defconfig and selecting
      CONFIG_TICK_CPU_ACCOUNTING instead of CONFIG_VIRT_CPU_ACCOUNTING_NATIVE.
      
      Fixes: b92a226e
      
       ("powerpc: Move cpu_has_feature() to a separate file")
      Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      e340eca9
  7. 20 Aug, 2016 2 commits
    • Helge Deller's avatar
      parisc: Fix order of EREFUSED define in errno.h · 3eb53b20
      Helge Deller authored
      
      
      When building gccgo in userspace, errno.h gets parsed and the go include file
      sysinfo.go is generated.
      
      Since EREFUSED is defined to the same value as ECONNREFUSED, and ECONNREFUSED
      is defined later on in errno.h, this leads to go complaining that EREFUSED
      isn't defined yet.
      
      Fix this trivial problem by moving the define of EREFUSED down after
      ECONNREFUSED in errno.h (and clean up the indenting while touching this line).
      Signed-off-by: default avatarHelge Deller <deller@gmx.de>
      Cc: stable@vger.kernel.org
      3eb53b20
    • Helge Deller's avatar
      parisc: Fix automatic selection of cr16 clocksource · ae141830
      Helge Deller authored
      Commit 54b66800
      
       (parisc: Add native high-resolution sched_clock()
      implementation) added support to use the CPU-internal cr16 counters as reliable
      clocksource with the help of HAVE_UNSTABLE_SCHED_CLOCK.
      
      Sadly the commit missed to remove the hack which prevented cr16 to become the
      default clocksource even on SMP systems.
      Signed-off-by: default avatarHelge Deller <deller@gmx.de>
      Cc: stable@vger.kernel.org # 4.7+
      ae141830
  8. 19 Aug, 2016 6 commits
    • Vineet Gupta's avatar
      ARC: export __udivdi3 for modules · c57653dc
      Vineet Gupta authored
      
      
      Some module using div_u64() was failing to link because the libgcc 64-bit
      divide assist routine was not being exported for modules
      
      Reported-by: avinashp@quantenna.com
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarVineet Gupta <vgupta@synopsys.com>
      c57653dc
    • Vineet Gupta's avatar
      ARC: mm: fix build breakage with STRICT_MM_TYPECHECKS · 1c3c9093
      Vineet Gupta authored
      
      
      |  CC      mm/memory.o
      | In file included from ../mm/memory.c:53:0:
      | ../include/linux/pfn_t.h: In function ‘pfn_t_pte’:
      | ../include/linux/pfn_t.h:78:2: error: conversion to non-scalar type requested
      |  return pfn_pte(pfn_t_to_pfn(pfn), pgprot);
      
      With STRICT_MM_TYPECHECKS pte_t is a struct and the offending code
      forces a cast which ends up shifting a struct and hence the gcc warning.
      
      Note that in recent past some of the arches (aarch64, s390) made
      STRICT_MM_TYPECHECKS default, but we don't for ARC as this leads to slightly
      worse generated code, given ARC ABI definition of returning structs
      (which pte_t would become)
      
      Quoting from ARC ABI...
      
        "Results of type struct are returned in a caller-supplied temporary
        variable whose address is passed in r0.
        For such functions, the arguments are shifted so that they are
        passed in r1 and up."
      
      So
       - struct to be returned would be allocated on stack requiring extra
         code at call sites
       - callee updates stack memory to facilitate the return (vs. simple
         MOV into return reg r0)
      
      Hence STRICT_MM_TYPECHECKS is not enabled by default for ARC
      
      Cc: <stable@vger.kernel.org>   #4.4+
      Signed-off-by: default avatarVineet Gupta <vgupta@synopsys.com>
      1c3c9093
    • Vineet Gupta's avatar
      ARC: export kmap · d77976c4
      Vineet Gupta authored
      
      
      |  MODPOST 7 modules
      | ERROR: "kmap" [fs/ext2/ext2.ko] undefined!
      | ../scripts/Makefile.modpost:91: recipe for target '__modpost' failed
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarVineet Gupta <vgupta@synopsys.com>
      d77976c4
    • Vineet Gupta's avatar
      ARC: Support syscall ABI v4 · 840c054f
      Vineet Gupta authored
      
      
      The syscall ABI includes the gcc functional calling ABI since a syscall
      implies userland caller and kernel callee.
      
      The current gcc ABI (v3) for ARCv2 ISA required 64-bit data be passed in
      even-odd register pairs, (potentially punching reg holes when passing such
      values as args). This was partly driven by the fact that the double-word
      LDD/STD instructions in ARCv2 expect the register alignment and thus gcc
      forcing this avoids extra MOV at the cost of a few unused register (which we
      have plenty anyways).
      
      This however was rejected as part of upstreaming gcc port to HS. So the new
      ABI v4 doesn't enforce the even-odd reg restriction.
      
      Do note that for ARCompact ISA builds v3 and v4 are practically the same in
      terms of gcc code generation.
      
      In terms of change management, we infer the new ABI if gcc 6.x onwards
      is used for building the kernel.
      
      This also needs a stable backport to enable older kernels to work with
      new tools/user-space
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarVineet Gupta <vgupta@synopsys.com>
      840c054f
    • Liav Rehana's avatar
      ARC: use correct offset in pt_regs for saving/restoring user mode r25 · 86147e3c
      Liav Rehana authored
      
      
      User mode callee regs are explicitly collected before signal delivery or
      breakpoint trap. r25 is special for kernel as it serves as task pointer,
      so user mode value is clobbered very early. It is saved in pt_regs where
      generally only scratch (aka caller saved) regs are saved.
      
      The code to access the corresponding pt_regs location had a subtle bug as
      it was using load/store with scaling of offset, whereas the offset was already
      byte wise correct. So fix this by replacing LD.AS with a standard LD
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarLiav Rehana <liavr@mellanox.com>
      Reviewed-by: default avatarAlexey Brodkin <abrodkin@synopsys.com>
      [vgupta: rewrote title and commit log]
      Signed-off-by: default avatarVineet Gupta <vgupta@synopsys.com>
      86147e3c
    • James Hogan's avatar
      MIPS: KVM: Check for pfn noslot case · ba913e4f
      James Hogan authored
      When mapping a page into the guest we error check using is_error_pfn(),
      however this doesn't detect a value of KVM_PFN_NOSLOT, indicating an
      error HVA for the page. This can only happen on MIPS right now due to
      unusual memslot management (e.g. being moved / removed / resized), or
      with an Enhanced Virtual Memory (EVA) configuration where the default
      KVM_HVA_ERR_* and kvm_is_error_hva() definitions are unsuitable (fixed
      in a later patch). This case will be treated as a pfn of zero, mapping
      the first page of physical memory into the guest.
      
      It would appear the MIPS KVM port wasn't updated prior to being merged
      (in v3.10) to take commit 81c52c56 ("KVM: do not treat noslot pfn as
      a error pfn") into account (merged v3.8), which converted a bunch of
      is_error_pfn() calls to is_error_noslot_pfn(). Switch to using
      is_error_noslot_pfn() instead to catch this case properly.
      
      Fixes: 858dd5d4
      
       ("KVM/MIPS32: MMU/TLB operations for the Guest.")
      Signed-off-by: default avatarJames Hogan <james.hogan@imgtec.com>
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: Radim Krčmář <rkrcmar@redhat.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: linux-mips@linux-mips.org
      Cc: kvm@vger.kernel.org
      Cc: <stable@vger.kernel.org> # 3.10.y-
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      ba913e4f
  9. 18 Aug, 2016 6 commits
    • Catalin Marinas's avatar
      arm64: Fix shift warning in arch/arm64/mm/dump.c · a93a4d62
      Catalin Marinas authored
      
      
      When building with 48-bit VAs and 16K page configuration, it's possible
      to get the following warning when building the arm64 page table dumping
      code:
      
      arch/arm64/mm/dump.c: In function ‘walk_pud’:
      arch/arm64/mm/dump.c:274:102: warning: right shift count >= width of type [-Wshift-count-overflow]
      
      This is because pud_offset(pgd, 0) performs a shift to the right by 36
      while the value 0 has the type 'int' by default, therefore 32-bit.
      
      This patch modifies all the p*_offset() uses in arch/arm64/mm/dump.c to
      use 0UL for the address argument.
      Acked-by: default avatarMark Rutland <mark.rutland@arm.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      a93a4d62
    • Peter Feiner's avatar
      kvm: nVMX: fix nested tsc scaling · c95ba92a
      Peter Feiner authored
      
      
      When the host supported TSC scaling, L2 would use a TSC multiplier of
      0, which causes a VM entry failure. Now L2's TSC uses the same
      multiplier as L1.
      Signed-off-by: default avatarPeter Feiner <pfeiner@google.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      c95ba92a
    • Radim Krčmář's avatar
      KVM: nVMX: postpone VMCS changes on MSR_IA32_APICBASE write · dccbfcf5
      Radim Krčmář authored
      If vmcs12 does not intercept APIC_BASE writes, then KVM will handle the
      write with vmcs02 as the current VMCS.
      This will incorrectly apply modifications intended for vmcs01 to vmcs02
      and L2 can use it to gain access to L0's x2APIC registers by disabling
      virtualized x2APIC while using msr bitmap that assumes enabled.
      
      Postpone execution of vmx_set_virtual_x2apic_mode until vmcs01 is the
      current VMCS.  An alternative solution would temporarily make vmcs01 the
      current VMCS, but it requires more care.
      
      Fixes: 8d14695f
      
       ("x86, apicv: add virtual x2apic support")
      Reported-by: default avatarJim Mattson <jmattson@google.com>
      Reviewed-by: default avatarWanpeng Li <wanpeng.li@hotmail.com>
      Signed-off-by: default avatarRadim Krčmář <rkrcmar@redhat.com>
      dccbfcf5
    • Radim Krčmář's avatar
      KVM: nVMX: fix msr bitmaps to prevent L2 from accessing L0 x2APIC · d048c098
      Radim Krčmář authored
      msr bitmap can be used to avoid a VM exit (interception) on guest MSR
      accesses.  In some configurations of VMX controls, the guest can even
      directly access host's x2APIC MSRs.  See SDM 29.5 VIRTUALIZING MSR-BASED
      APIC ACCESSES.
      
      L2 could read all L0's x2APIC MSRs and write TPR, EOI, and SELF_IPI.
      To do so, L1 would first trick KVM to disable all possible interceptions
      by enabling APICv features and then would turn those features off;
      nested_vmx_merge_msr_bitmap() only disabled interceptions, so VMX would
      not intercept previously enabled MSRs even though they were not safe
      with the new configuration.
      
      Correctly re-enabling interceptions is not enough as a second bug would
      still allow L1+L2 to access host's MSRs: msr bitmap was shared for all
      VMCSs, so L1 could trigger a race to get the desired combination of msr
      bitmap and VMX controls.
      
      This fix allocates a msr bitmap for every L1 VCPU, allows only safe
      x2APIC MSRs from L1's msr bitmap, and disables msr bitmaps if they would
      have to intercept everything anyway.
      
      Fixes: 3af18d9c
      
       ("KVM: nVMX: Prepare for using hardware MSR bitmap")
      Reported-by: default avatarJim Mattson <jmattson@google.com>
      Suggested-by: default avatarWincy Van <fanwenyi0529@gmail.com>
      Reviewed-by: default avatarWanpeng Li <wanpeng.li@hotmail.com>
      Signed-off-by: default avatarRadim Krčmář <rkrcmar@redhat.com>
      d048c098
    • Jiri Olsa's avatar
      x86/smp: Fix __max_logical_packages value setup · 7b0501b1
      Jiri Olsa authored
      
      
      Frank reported kernel panic when he disabled several cores in BIOS
      via following option:
      
        Core Disable Bitmap(Hex)   [0]
      
      with number 0xFFE, which leaves 16 CPUs in system (out of 48).
      
      The kernel panic below goes along with following messages:
      
       smpboot: Max logical packages: 2^M
       smpboot: APIC(0) Converting physical 0 to logical package 0^M
       smpboot: APIC(20) Converting physical 1 to logical package 1^M
       smpboot: APIC(40) Package 2 exceeds logical package map^M
       smpboot: CPU 8 APICId 40 disabled^M
       smpboot: APIC(60) Package 3 exceeds logical package map^M
       smpboot: CPU 12 APICId 60 disabled^M
       ...
       general protection fault: 0000 [#1] SMP^M
       Modules linked in:^M
       CPU: 15 PID: 1 Comm: swapper/0 Not tainted 4.7.0-rc5+ #1^M
       Hardware name: SGI UV300/UV300, BIOS SGI UV 300 series BIOS 05/25/2016^M
       task: ffff8801673e0000 ti: ffff8801673ac000 task.ti: ffff8801673ac000^M
       RIP: 0010:[<ffffffff81014d54>]  [<ffffffff81014d54>] uncore_change_context+0xd4/0x180^M
       ...
        [<ffffffff810158ac>] uncore_event_init_cpu+0x6c/0x70^M
        [<ffffffff81d8c91c>] intel_uncore_init+0x1c2/0x2dd^M
        [<ffffffff81d8c75a>] ? uncore_cpu_setup+0x17/0x17^M
        [<ffffffff81002190>] do_one_initcall+0x50/0x190^M
        [<ffffffff810ab193>] ? parse_args+0x293/0x480^M
        [<ffffffff81d87365>] kernel_init_freeable+0x1a5/0x249^M
        [<ffffffff81d86a35>] ? set_debug_rodata+0x12/0x12^M
        [<ffffffff816dc19e>] kernel_init+0xe/0x110^M
        [<ffffffff816e93bf>] ret_from_fork+0x1f/0x40^M
        [<ffffffff816dc190>] ? rest_init+0x80/0x80^M
      
      The reason for the panic is wrong value of __max_logical_packages,
      which lets logical_package_map uninitialized and the uncore code
      relying on this map being properly initialized (maybe we should
      add some safety checks there as well).
      
      The __max_logical_packages is computed as:
      
        DIV_ROUND_UP(total_cpus, ncpus);
        - ncpus being number of cores
      
      With above BIOS setup we get total_cpus == 16 which set
      __max_logical_packages to 2 (ncpus is 12).
      
      Once topology_update_package_map processes CPU with logical
      pkg over 2 we display above messages and fail to initialize
      the physical_to_logical_pkg map, which makes the uncore code
      crash.
      
      The fix is to remove logical_package_map bitmap completely
      and keep and update the logical_packages number instead.
      
      After we enumerate all the present CPUs, we check if the
      enumerated logical packages count is within its computed
      maximum from BIOS data.
      
      If it's not the case, we set this maximum to the new enumerated
      value and freeze any new addition of logical packages.
      
      The freeze is because lot of init code like uncore/rapl/cqm
      depends on having maximum logical package value set to allocate
      their data, so we can't change it later on.
      
      Prarit Bhargava tested the patch and confirms that it solves
      the problem:
      
        From dmidecode:
                Core Count: 24
                Core Enabled: 24
                Thread Count: 48
      
      Orig kernel boot log:
      
       [    0.464981] smpboot: Max logical packages: 19
       [    0.469861] smpboot: APIC(0) Converting physical 0 to logical package 0
       [    0.477261] smpboot: APIC(40) Converting physical 1 to logical package 1
       [    0.484760] smpboot: APIC(80) Converting physical 2 to logical package 2
       [    0.492258] smpboot: APIC(c0) Converting physical 3 to logical package 3
      
      1.  nr_cpus=8, should stop enumerating in package 0:
      
       [    0.533664] smpboot: APIC(0) Converting physical 0 to logical package 0
       [    0.539596] smpboot: Max logical packages: 19
      
      2.  max_cpus=8, should still enumerate all packages:
      
       [    0.526494] smpboot: APIC(0) Converting physical 0 to logical package 0
       [    0.532428] smpboot: APIC(40) Converting physical 1 to logical package 1
       [    0.538456] smpboot: APIC(80) Converting physical 2 to logical package 2
       [    0.544486] smpboot: APIC(c0) Converting physical 3 to logical package 3
       [    0.550524] smpboot: Max logical packages: 19
      
      3.  nr_cpus=49 ( 2 socket + 1 core on 3rd socket), should stop enumerating in
          package 2:
      
       [    0.521378] smpboot: APIC(0) Converting physical 0 to logical package 0
       [    0.527314] smpboot: APIC(40) Converting physical 1 to logical package 1
       [    0.533345] smpboot: APIC(80) Converting physical 2 to logical package 2
       [    0.539368] smpboot: Max logical packages: 19
      
      4.  maxcpus=49, should still enumerate all packages:
      
       [    0.525591] smpboot: APIC(0) Converting physical 0 to logical package 0
       [    0.531525] smpboot: APIC(40) Converting physical 1 to logical package 1
       [    0.537547] smpboot: APIC(80) Converting physical 2 to logical package 2
       [    0.543579] smpboot: APIC(c0) Converting physical 3 to logical package 3
       [    0.549624] smpboot: Max logical packages: 19
      
      5.  kdump (nr_cpus=1) works as well.
      Reported-by: default avatarFrank Ramsay <framsay@redhat.com>
      Tested-by: default avatarPrarit Bhargava <prarit@redhat.com>
      Signed-off-by: default avatarJiri Olsa <jolsa@kernel.org>
      Reviewed-by: default avatarPrarit Bhargava <prarit@redhat.com>
      Acked-by: default avatarPeter Zijlstra <peterz@infradead.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/20160815101700.GA30090@krava
      
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      7b0501b1
    • Borislav Petkov's avatar
      x86/microcode/AMD: Fix initrd loading with CONFIG_RANDOMIZE_MEMORY=y · 88b2f634
      Borislav Petkov authored
      Similar to:
      
        efaad554
      
       ("x86/microcode/intel: Fix initrd loading with CONFIG_RANDOMIZE_MEMORY=y")
      
      ... fix microcode loading from the initrd on AMD by adding the
      randomization offset to the microcode patch container within the initrd.
      Reported-and-tested-by: default avatarBrian Gerst <brgerst@gmail.com>
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-tip-commits@vger.kernel.org
      Link: http://lkml.kernel.org/r/20160817113314.GA19221@nazgul.tnic
      
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      88b2f634
  10. 17 Aug, 2016 4 commits