1. 02 12月, 2014 8 次提交
    • J
      powerpc/oprofile: Disable pagefaults during user stack read · 0de3b56b
      Jiang Lu 提交于
      A page fault occurred during reading user stack in oprofile backtrace
      would lead following calltrace:
      
      WARNING: at linux/kernel/smp.c:210
      Modules linked in:
      CPU: 5 PID: 736 Comm: sh Tainted: G W 3.14.23-WR7.0.0.0_standard #1
      task: c0000000f6208bc0 ti: c00000007c72c000 task.ti: c00000007c72c000
      NIP: c0000000000ed6e4 LR: c0000000000ed5b8 CTR: 0000000000000000
      REGS: c00000007c72f050 TRAP: 0700 Tainted: G W (3.14.23-WR7.0.0
      tandard)
      MSR: 0000000080021000 <CE,ME> CR: 48222482 XER: 00000000
      SOFTE: 0
      GPR00: c0000000000ed5b8 c00000007c72f2d0 c0000000010aa048 0000000000000005
      GPR04: c000000000fdb820 c00000007c72f410 0000000000000001 0000000000000005
      GPR08: c0000000010b5768 c000000000f8a048 0000000000000001 0000000000000000
      GPR12: 0000000048222482 c00000000fffe580 0000000022222222 0000000010129664
      GPR16: 0000000010143cc0 0000000000000000 0000000044444444 0000000000000000
      GPR20: c00000007c7221d8 c0000000f638e3c8 000003f15a20120d 0000000000000001
      GPR24: 000000005a20120d c00000007c722000 c00000007cdedda8 00003fffef23b160
      GPR28: 0000000000000001 c00000007c72f410 c000000000fdb820 0000000000000006
      NIP [c0000000000ed6e4] .smp_call_function_single+0x18c/0x248
      LR [c0000000000ed5b8] .smp_call_function_single+0x60/0x248
      Call Trace:
      [c00000007c72f2d0] [c0000000000ed5b8] .smp_call_function_single+0x60/0x248 (unreliable)
      [c00000007c72f3a0] [c000000000030810] .__flush_tlb_page+0x164/0x1b0
      [c00000007c72f460] [c00000000002e054] .ptep_set_access_flags+0xb8/0x168
      [c00000007c72f500] [c0000000001ad3d8] .handle_mm_fault+0x4a8/0xbac
      [c00000007c72f5e0] [c000000000bb3238] .do_page_fault+0x3b8/0x868
      [c00000007c72f810] [c00000000001e1d0] storage_fault_common+0x20/0x44
       Exception: 301 at .__copy_tofrom_user_base+0x54/0x5b0
          LR = .op_powerpc_backtrace+0x190/0x20c
      [c00000007c72fb00] [c000000000a2ec34] .op_powerpc_backtrace+0x204/0x20c (unreliable)
      [c00000007c72fbc0] [c000000000a2b5fc] .oprofile_add_ext_sample+0xe8/0x118
      [c00000007c72fc70] [c000000000a2eee0] .fsl_emb_handle_interrupt+0x20c/0x27c
      [c00000007c72fd30] [c000000000a2e440] .op_handle_interrupt+0x44/0x58
      [c00000007c72fdb0] [c000000000016d68] .performance_monitor_exception+0x74/0x90
      [c00000007c72fe30] [c00000000001d8b4] exc_0x260_common+0xfc/0x100
      
      performance_monitor_exception() is executed in a context with interrupt
      disabled and preemption enabled. When there is a user space page fault
      happened, do_page_fault() invoke in_atomic() to decide whether kernel
      should handle such page fault. in_atomic() only check preempt_count.
      So need call pagefault_disable() to disable preemption before reading
      user stack.
      Signed-off-by: NJiang Lu <lu.jiang@windriver.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      0de3b56b
    • A
      powerpc/mm: Check for matching hpte without taking hpte lock · 0ec2698f
      Aneesh Kumar K.V 提交于
      With smaller hash page table config, we would end up in situation
      where we would be replacing hash page table slot frequently. In
      such config, we will find the hpte to be not matching, and we
      can do that check without holding the hpte lock. We need to
      recheck the hpte again after holding lock.
      Signed-off-by: NAneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      0ec2698f
    • G
      powerpc: Drop useless warning in eeh_init() · 221195fb
      Greg Kurz 提交于
      This is what we get in dmesg when booting a pseries guest and
      the hypervisor doesn't provide EEH support.
      
      [    0.166655] EEH functionality not supported
      [    0.166778] eeh_init: Failed to call platform init function (-22)
      
      Since both powernv_eeh_init() and pseries_eeh_init() already complain when
      hitting an error, it is not needed to print more (especially such an
      uninformative message).
      Signed-off-by: NGreg Kurz <gkurz@linux.vnet.ibm.com>
      Acked-by: NGavin Shan <gwshan@linux.vnet.ibm.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      221195fb
    • M
      powerpc/powernv: Cleanup unused MCE definitions/declarations. · 6d626c5e
      Mahesh Salgaonkar 提交于
      Cleanup OpalMCE_* definitions/declarations and other related code which
      is not used anymore.
      Signed-off-by: NMahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
      Acked-by: NBenjamin Herrrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      6d626c5e
    • G
      powerpc/eeh: Dump PHB diag-data early · a450e8f5
      Gavin Shan 提交于
      On PowerNV platform, PHB diag-data is dumped after stopping device
      drivers. In case of recursive EEH errors, the kernel is usually
      crashed before dumping PHB diag-data for the second EEH error. It's
      hard to locate the root cause of the second EEH error without PHB
      diag-data.
      
      The patch adds one more EEH option "eeh=early_log", which helps
      dumping PHB diag-data immediately once frozen PE is detected, in
      order to get the PHB diag-data for the second EEH error.
      Signed-off-by: NGavin Shan <gwshan@linux.vnet.ibm.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      a450e8f5
    • G
      powerpc/eeh: Recover EEH error on ownership change for BCM5719 · b1d76a7d
      Gavin Shan 提交于
      In PCI passthrou scenario, we need simulate EEH recovery for Emulex
      adapters when their ownership changes, as we did in commit 5cfb20b9
      ("powerpc/eeh: Emulate EEH recovery for VFIO devices"). Broadcom
      BCM5719 adpaters are facing same problem and needs same cure.
      Reported-by: NRajeshkumar Subramanian <rajeshkumars@in.ibm.com>
      Signed-off-by: NGavin Shan <gwshan@linux.vnet.ibm.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      b1d76a7d
    • G
      powerpc/eeh: Set EEH_PE_RESET on PE reset · 28bf36f9
      Gavin Shan 提交于
      The patch introduces additional flag EEH_PE_RESET to indicate the
      corresponding PE is under reset. In turn, the PE retrieval bakcend
      on PowerNV platform can return unfrozen state for the EEH core to
      moving forward. Flag EEH_PE_CFG_BLOCKED isn't the correct one for
      the purpose.
      
      In PCI passthrou case, the problem is more worse: Guest doesn't
      recover 6th EEH error. The PE is left in isolated (frozen) and
      config blocked state on Broadcom adapters. We can't retrieve the
      PE's state correctly any more, even from the host side via sysfs
      /sys/bus/pci/devices/xxx/eeh_pe_state.
      Reported-by: NRajeshkumar Subramanian <rajeshkumars@in.ibm.com>
      Signed-off-by: NGavin Shan <gwshan@linux.vnet.ibm.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      28bf36f9
    • G
      powerpc/eeh: Refactor eeh_reset_pe() · b85743ee
      Gavin Shan 提交于
      The patch refactors eeh_reset_pe() in order for:
      
         * Varied return values for different failure cases.
         * Replace pr_err() with pr_warn() and print function name.
         * Coding style cleanup.
      Signed-off-by: NGavin Shan <gwshan@linux.vnet.ibm.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      b85743ee
  2. 18 11月, 2014 1 次提交
  3. 17 11月, 2014 2 次提交
    • N
      rtc/tpo: Driver to support rtc and wakeup on PowerNV platform · 16b1d26e
      Neelesh Gupta 提交于
      The patch implements the OPAL rtc driver that binds with the rtc
      driver subsystem. The driver uses the platform device infrastructure
      to probe the rtc device and register it to rtc class framework. The
      'wakeup' is supported depending upon the property 'has-tpo' present
      in the OF node. It provides a way to load the generic rtc driver in
      in the absence of an OPAL driver.
      
      The patch also moves the existing OPAL rtc get/set time interfaces to the
      new driver and exposes the necessary OPAL calls using EXPORT_SYMBOL_GPL.
      
      Test results:
      -------------
      Host:
      [root@tul169p1 ~]# ls -l /sys/class/rtc/
      total 0
      lrwxrwxrwx 1 root root 0 Oct 14 03:07 rtc0 -> ../../devices/opal-rtc/rtc/rtc0
      [root@tul169p1 ~]# cat /sys/devices/opal-rtc/rtc/rtc0/time
      08:10:07
      [root@tul169p1 ~]# echo `date '+%s' -d '+ 2 minutes'` > /sys/class/rtc/rtc0/wakealarm
      [root@tul169p1 ~]# cat /sys/class/rtc/rtc0/wakealarm
      1413274345
      [root@tul169p1 ~]#
      
      FSP:
      $ smgr mfgState
      standby
      $ rtim timeofday
      
      System time is valid: 2014/10/14 08:12:04.225115
      
      $ smgr mfgState
      ipling
      $
      
      CC: devicetree@vger.kernel.org
      CC: tglx@linutronix.de
      CC: rtc-linux@googlegroups.com
      CC: a.zummo@towertech.it
      Signed-off-by: NNeelesh Gupta <neelegup@linux.vnet.ibm.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      16b1d26e
    • V
      powerpc: Use generic PIE randomization · 59994fb0
      Vineeth Vijayan 提交于
      Back in 2009 we merged 501cb16d "Randomise PIEs", which added support for
      randomizing PIE (Position Independent Executable) binaries.
      
      That commit added randomize_et_dyn(), which correctly randomized the addresses,
      but failed to honor PF_RANDOMIZE. That means it was not possible to disable PIE
      randomization via the personality flag, or /proc/sys/kernel/randomize_va_space.
      
      Since then there has been generic support for PIE randomization added to
      binfmt_elf.c, selectable via ARCH_BINFMT_ELF_RANDOMIZE_PIE.
      
      Enabling that allows us to drop randomize_et_dyn(), which means we start
      honoring PF_RANDOMIZE correctly.
      
      It also causes a fairly major change to how we layout PIE binaries.
      
      Currently we will place the binary at 512MB-520MB for 32 bit binaries, or
      512MB-1.5GB for 64 bit binaries, eg:
      
          $ cat /proc/$$/maps
          4e550000-4e580000 r-xp 00000000 08:02 129813       /bin/dash
          4e580000-4e590000 rw-p 00020000 08:02 129813       /bin/dash
          10014110000-10014140000 rw-p 00000000 00:00 0      [heap]
          3fffaa3f0000-3fffaa5a0000 r-xp 00000000 08:02 921  /lib/powerpc64le-linux-gnu/libc-2.19.so
          3fffaa5a0000-3fffaa5b0000 rw-p 001a0000 08:02 921  /lib/powerpc64le-linux-gnu/libc-2.19.so
          3fffaa5c0000-3fffaa5d0000 rw-p 00000000 00:00 0
          3fffaa5d0000-3fffaa5f0000 r-xp 00000000 00:00 0    [vdso]
          3fffaa5f0000-3fffaa620000 r-xp 00000000 08:02 1246 /lib/powerpc64le-linux-gnu/ld-2.19.so
          3fffaa620000-3fffaa630000 rw-p 00020000 08:02 1246 /lib/powerpc64le-linux-gnu/ld-2.19.so
          3ffffc340000-3ffffc370000 rw-p 00000000 00:00 0    [stack]
      
      With this commit applied we don't do any special randomisation for the binary,
      and instead rely on mmap randomisation. This means the binary ends up at high
      addresses, eg:
      
          $ cat /proc/$$/maps
          3fff99820000-3fff999d0000 r-xp 00000000 08:02 921    /lib/powerpc64le-linux-gnu/libc-2.19.so
          3fff999d0000-3fff999e0000 rw-p 001a0000 08:02 921    /lib/powerpc64le-linux-gnu/libc-2.19.so
          3fff999f0000-3fff99a00000 rw-p 00000000 00:00 0
          3fff99a00000-3fff99a20000 r-xp 00000000 00:00 0      [vdso]
          3fff99a20000-3fff99a50000 r-xp 00000000 08:02 1246   /lib/powerpc64le-linux-gnu/ld-2.19.so
          3fff99a50000-3fff99a60000 rw-p 00020000 08:02 1246   /lib/powerpc64le-linux-gnu/ld-2.19.so
          3fff99a60000-3fff99a90000 r-xp 00000000 08:02 129813 /bin/dash
          3fff99a90000-3fff99aa0000 rw-p 00020000 08:02 129813 /bin/dash
          3fffc3de0000-3fffc3e10000 rw-p 00000000 00:00 0      [stack]
          3fffc55e0000-3fffc5610000 rw-p 00000000 00:00 0      [heap]
      
      Although this should be OK, it's possible it might break badly written
      binaries that make assumptions about the address space layout.
      Signed-off-by: NVineeth Vijayan <vvijayan@mvista.com>
      [mpe: Rewrite changelog]
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      59994fb0
  4. 14 11月, 2014 12 次提交
  5. 13 11月, 2014 1 次提交
  6. 12 11月, 2014 7 次提交
  7. 10 11月, 2014 9 次提交
新手
引导
客服 返回
顶部