1. 14 5月, 2013 7 次提交
    • L
      powerpc: Fix MAX_STACK_TRACE_ENTRIES too low warning again · af945cf4
      Li Zhong 提交于
      Saw this warning again, and this time from the ret_from_fork path.
      
      It seems we could clear the back chain earlier in copy_thread(), which
      could cover both path, and also fix potential lockdep usage in
      schedule_tail(), or exception occurred before we clear the back chain.
      Signed-off-by: NLi Zhong <zhong@linux.vnet.ibm.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      af945cf4
    • M
      powerpc: Make CONFIG_RTAS_PROC depend on CONFIG_PROC_FS · b80ec3dc
      Michael Ellerman 提交于
      We are getting build errors with CONFIG_PROC_FS=n:
      
      arch/powerpc/kernel/rtas_flash.c
         In function 'rtas_flash_init':
        745:33: error: unused variable 'f' [-Werror=unused-variable]
      
      But rtas_flash.c should not be built when CONFIG_PROC_FS=n, beacause all
      it does is provide a /proc interface to the RTAS flash routines.
      
      CONFIG_RTAS_FLASH already depends on CONFIG_RTAS_PROC, to indicate that
      it depends on the RTAS proc support, but CONFIG_RTAS_PROC does not
      depend on CONFIG_PROC_FS. So fix that.
      Signed-off-by: NMichael Ellerman <michael@ellerman.id.au>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      b80ec3dc
    • R
      powerpc: Bring all threads online prior to migration/hibernation · 120496ac
      Robert Jennings 提交于
      This patch brings online all threads which are present but not online
      prior to migration/hibernation.  After migration/hibernation those
      threads are taken back offline.
      
      During migration/hibernation all online CPUs must call H_JOIN, this is
      required by the hypervisor.  Without this patch, threads that are offline
      (H_CEDE'd) will not be woken to make the H_JOIN call and the OS will be
      deadlocked (all threads either JOIN'd or CEDE'd).
      
      Cc: <stable@kernel.org>
      Signed-off-by: NRobert Jennings <rcj@linux.vnet.ibm.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      120496ac
    • V
      powerpc/rtas_flash: Fix validate_flash buffer overflow issue · a94a1472
      Vasant Hegde 提交于
      ibm,validate-flash-image RTAS call output buffer contains 150 - 200
      bytes of data on latest system. Presently we have output
      buffer size as 64 bytes and we use sprintf to copy data from
      RTAS buffer to local buffer. This causes kernel oops (see below
      call trace).
      
      This patch increases local buffer size to 256 and also uses
      snprintf instead of sprintf to copy data from RTAS buffer.
      
      Kernel call trace :
      -------------------
      Oops: Kernel access of bad area, sig: 11 [#1]
      SMP NR_CPUS=1024 NUMA pSeries
      Modules linked in: nfs fscache lockd auth_rpcgss nfs_acl sunrpc fuse loop dm_mod ipv6 ipv6_lib usb_storage ehea(X) sr_mod qlge ses cdrom enclosure st be2net sg ext3 jbd mbcache usbhid hid ohci_hcd ehci_hcd usbcore qla2xxx usb_common sd_mod crc_t10dif scsi_dh_hp_sw scsi_dh_rdac scsi_dh_alua scsi_dh_emc scsi_dh lpfc scsi_transport_fc scsi_tgt ipr(X) libata scsi_mod
      Supported: Yes
      NIP: 4520323031333130 LR: 4520323031333130 CTR: 0000000000000000
      REGS: c0000001b91779b0 TRAP: 0400   Tainted: G            X  (3.0.13-0.27-ppc64)
      MSR: 8000000040009032 <EE,ME,IR,DR>  CR: 44022488  XER: 20000018
      TASK = c0000001bca1aba0[4736] 'cat' THREAD: c0000001b9174000 CPU: 36
      GPR00: 4520323031333130 c0000001b9177c30 c000000000f87c98 000000000000009b
      GPR04: c0000001b9177c4a 000000000000000b 3520323031333130 2032303133313031
      GPR08: 3133313031350a4d 000000000000009b 0000000000000000 c0000000003664a4
      GPR12: 0000000022022448 c000000003ee6c00 0000000000000002 00000000100e8a90
      GPR16: 00000000100cb9d8 0000000010093370 000000001001d310 0000000000000000
      GPR20: 0000000000008000 00000000100fae60 000000000000005e 0000000000000000
      GPR24: 0000000010129350 46573738302e3030 2046573738302e30 300a4d4720323031
      GPR28: 333130313520554e 4b4e4f574e0a4d47 2032303133313031 3520323031333130
      NIP [4520323031333130] 0x4520323031333130
      LR [4520323031333130] 0x4520323031333130
      Call Trace:
      [c0000001b9177c30] [4520323031333130] 0x4520323031333130 (unreliable)
      Instruction dump:
      XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
      XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
      Signed-off-by: NVasant Hegde <hegdevasant@linux.vnet.ibm.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      a94a1472
    • A
      powerpc/kexec: Fix kexec when using VMX optimised memcpy · 79c66ce8
      Anton Blanchard 提交于
      commit b3f271e8 (powerpc: POWER7 optimised memcpy using VMX and
      enhanced prefetch) uses VMX when it is safe to do so (ie not in
      interrupt). It also looks at the task struct to decide if we have to
      save the current tasks' VMX state.
      
      kexec calls memcpy() at a point where the task struct may have been
      overwritten by the new kexec segments. If it has been overwritten
      then when memcpy -> enable_altivec looks up current->thread.regs->msr
      we get a cryptic oops or lockup.
      
      I also notice we aren't initialising thread_info->cpu, which means
      smp_processor_id is broken. Fix that too.
      Signed-off-by: NAnton Blanchard <anton@samba.org>
      Cc: <stable@vger.kernel.org> # 3.6+
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      79c66ce8
    • A
    • A
      powerpc/mm: Use the correct mask value when looking at pgtable address · 613e60a6
      Aneesh Kumar K.V 提交于
      Our pgtable are 2*sizeof(pte_t)*PTRS_PER_PTE which is PTE_FRAG_SIZE.
      Instead of depending on frag size, mask with PMD_MASKED_BITS.
      Signed-off-by: NAneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      613e60a6
  2. 10 5月, 2013 2 次提交
  3. 08 5月, 2013 2 次提交
  4. 07 5月, 2013 1 次提交
  5. 06 5月, 2013 17 次提交
  6. 05 5月, 2013 11 次提交