1. 20 9月, 2012 18 次提交
  2. 11 9月, 2012 3 次提交
    • F
      ARM: clk-imx35: Fix SSI clock registration · 48540058
      Fabio Estevam 提交于
      SSI block has two types of clock:
      
      ipg: bus clock, the clock needed for accessing registers.
      per: peripheral clock, the clock needed for generating the bit rate.
      
      Currently SSI driver only supports slave mode and only need to handle
      the ipg clock, because the peripheral clock comes from the master codec.
      
      Only register the ipg clock and do not register the peripheral clock for ssi.
      Signed-off-by: NFabio Estevam <fabio.estevam@freescale.com>
      Tested-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>
      Cc: stable@vger.kernel.org
      48540058
    • F
      ARM: clk-imx25: Fix SSI clock registration · 912bfe76
      Fabio Estevam 提交于
      SSI block has two types of clock:
      
      ipg: bus clock, the clock needed for accessing registers.
      per: peripheral clock, the clock needed for generating the bit rate.
      
      Currently SSI driver only supports slave mode and only need to handle
      the ipg clock, because the peripheral clock comes from the master codec.
      
      Only register the ipg clock and do not register the peripheral clock for ssi.
      Signed-off-by: NFabio Estevam <fabio.estevam@freescale.com>
      Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>
      Cc: stable@vger.kernel.org
      912bfe76
    • J
      kbuild: add symbol prefix arg to kallsyms · 6895f97e
      James Hogan 提交于
      Commit 1f2bfbd0 ("kbuild: link of
      vmlinux moved to a script") introduced in v3.5-rc1 broke kallsyms on
      architectures which have symbol prefixes.
      
      The --symbol-prefix argument used to be added to the KALLSYMS command
      line from the architecture Makefile, however this isn't picked up by the
      new scripts/link-vmlinux.sh. This resulted in symbols like
      kallsyms_addresses being added which weren't correctly overriding the
      weak symbols such as _kallsyms_addresses. These could then trigger
      BUG_ONs in kallsyms code.
      
      This is fixed by removing the KALLSYMS addition from the architecture
      Makefile, and using CONFIG_SYMBOL_PREFIX in the link-vmlinux.sh script
      to determine whether to add the --symbol-prefix argument.
      Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
      Signed-off-by: NBob Liu <lliubbo@gmail.com>
      6895f97e
  3. 10 9月, 2012 5 次提交
    • T
      arm: mm: fix DMA pool affiliation check · f3d87524
      Thomas Petazzoni 提交于
      The __free_from_pool() function was changed in
      e9da6e99. Unfortunately, the test that
      checks whether the provided (start,size) is within the DMA pool has
      been improperly modified. It used to be:
      
        if (start < coherent_head.vm_start || end > coherent_head.vm_end)
      
      Where coherent_head.vm_end was non-inclusive (i.e, it did not include
      the first byte after the pool). The test has been changed to:
      
        if (start < pool->vaddr || start > pool->vaddr + pool->size)
      
      So now pool->vaddr + pool->size is inclusive (i.e, it includes the
      first byte after the pool), so the test should be >= instead of >.
      
      This bug causes the following message when freeing the *first* DMA
      coherent buffer that has been allocated, because its virtual address
      is exactly equal to pool->vaddr + pool->size :
      
      WARNING: at /home/thomas/projets/linux-2.6/arch/arm/mm/dma-mapping.c:463 __free_from_pool+0xa4/0xc0()
      freeing wrong coherent size from pool
      Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Cc: Marek Szyprowski <m.szyprowski@samsung.com>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Lior Amsalem <alior@marvell.com>
      Cc: Maen Suleiman <maen@marvell.com>
      Cc: Tawfik Bayouk <tawfik@marvell.com>
      Cc: Shadi Ammouri <shadi@marvell.com>
      Cc: Eran Ben-Avi <benavi@marvell.com>
      Cc: Yehuda Yitschak <yehuday@marvell.com>
      Cc: Nadav Haklai <nadavh@marvell.com>
      [m.szyprowski: rebased onto v3.6-rc5 and resolved conflict]
      Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com>
      f3d87524
    • X
      KVM: fix error paths for failed gfn_to_page() calls · 4484141a
      Xiao Guangrong 提交于
      This bug was triggered:
      [ 4220.198458] BUG: unable to handle kernel paging request at fffffffffffffffe
      [ 4220.203907] IP: [<ffffffff81104d85>] put_page+0xf/0x34
      ......
      [ 4220.237326] Call Trace:
      [ 4220.237361]  [<ffffffffa03830d0>] kvm_arch_destroy_vm+0xf9/0x101 [kvm]
      [ 4220.237382]  [<ffffffffa036fe53>] kvm_put_kvm+0xcc/0x127 [kvm]
      [ 4220.237401]  [<ffffffffa03702bc>] kvm_vcpu_release+0x18/0x1c [kvm]
      [ 4220.237407]  [<ffffffff81145425>] __fput+0x111/0x1ed
      [ 4220.237411]  [<ffffffff8114550f>] ____fput+0xe/0x10
      [ 4220.237418]  [<ffffffff81063511>] task_work_run+0x5d/0x88
      [ 4220.237424]  [<ffffffff8104c3f7>] do_exit+0x2bf/0x7ca
      
      The test case:
      
      	printf(fmt, ##args);		\
      	exit(-1);} while (0)
      
      static int create_vm(void)
      {
      	int sys_fd, vm_fd;
      
      	sys_fd = open("/dev/kvm", O_RDWR);
      	if (sys_fd < 0)
      		die("open /dev/kvm fail.\n");
      
      	vm_fd = ioctl(sys_fd, KVM_CREATE_VM, 0);
      	if (vm_fd < 0)
      		die("KVM_CREATE_VM fail.\n");
      
      	return vm_fd;
      }
      
      static int create_vcpu(int vm_fd)
      {
      	int vcpu_fd;
      
      	vcpu_fd = ioctl(vm_fd, KVM_CREATE_VCPU, 0);
      	if (vcpu_fd < 0)
      		die("KVM_CREATE_VCPU ioctl.\n");
      	printf("Create vcpu.\n");
      	return vcpu_fd;
      }
      
      static void *vcpu_thread(void *arg)
      {
      	int vm_fd = (int)(long)arg;
      
      	create_vcpu(vm_fd);
      	return NULL;
      }
      
      int main(int argc, char *argv[])
      {
      	pthread_t thread;
      	int vm_fd;
      
      	(void)argc;
      	(void)argv;
      
      	vm_fd = create_vm();
      	pthread_create(&thread, NULL, vcpu_thread, (void *)(long)vm_fd);
      	printf("Exit.\n");
      	return 0;
      }
      
      It caused by release kvm->arch.ept_identity_map_addr which is the
      error page.
      
      The parent thread can send KILL signal to the vcpu thread when it was
      exiting which stops faulting pages and potentially allocating memory.
      So gfn_to_pfn/gfn_to_page may fail at this time
      
      Fixed by checking the page before it is used
      Signed-off-by: NXiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>
      Signed-off-by: NAvi Kivity <avi@redhat.com>
      4484141a
    • W
      ARM: 7529/1: delay: set loops_per_jiffy when moving to timer-based loop · beafa0de
      Will Deacon 提交于
      The delay functions may be called by some platforms between switching to
      the timer-based delay loop but before calibration. In this case, the
      initial loops_per_jiffy may not be suitable for the timer (although a
      compromise may be achievable) and delay times may be considered too
      inaccurate.
      
      This patch updates loops_per_jiffy when switching to the timer-based
      delay loop so that delays are consistent prior to calibration.
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      beafa0de
    • W
      ARM: 7528/1: uaccess: annotate [__]{get,put}_user functions with might_fault() · ad72907a
      Will Deacon 提交于
      The user access functions may generate a fault, resulting in invocation
      of a handler that may sleep.
      
      This patch annotates the accessors with might_fault() so that we print a
      warning if they are invoked from atomic context and help lockdep keep
      track of mmap_sem.
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      ad72907a
    • R
      ARM: 7527/1: uaccess: explicitly check __user pointer when !CPU_USE_DOMAINS · 8404663f
      Russell King 提交于
      The {get,put}_user macros don't perform range checking on the provided
      __user address when !CPU_HAS_DOMAINS.
      
      This patch reworks the out-of-line assembly accessors to check the user
      address against a specified limit, returning -EFAULT if is is out of
      range.
      
      [will: changed get_user register allocation to match put_user]
      [rmk: fixed building on older ARM architectures]
      Reported-by: NCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      8404663f
  4. 09 9月, 2012 1 次提交
  5. 08 9月, 2012 4 次提交
  6. 07 9月, 2012 1 次提交
  7. 06 9月, 2012 1 次提交
  8. 05 9月, 2012 7 次提交
    • A
      xen: fix logical error in tlb flushing · ce7184bd
      Alex Shi 提交于
      While TLB_FLUSH_ALL gets passed as 'end' argument to
      flush_tlb_others(), the Xen code was made to check its 'start'
      parameter. That may give a incorrect op.cmd to MMUEXT_INVLPG_MULTI
      instead of MMUEXT_TLB_FLUSH_MULTI. Then it causes some page can not
      be flushed from TLB.
      
      This patch fixed this issue.
      Reported-by: NJan Beulich <jbeulich@suse.com>
      Signed-off-by: NAlex Shi <alex.shi@intel.com>
      Acked-by: NJan Beulich <jbeulich@suse.com>
      Tested-by: NYongjie Ren <yongjie.ren@intel.com>
      Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      ce7184bd
    • K
      xen/p2m: Fix one-off error in checking the P2M tree directory. · 50e90041
      Konrad Rzeszutek Wilk 提交于
      We would traverse the full P2M top directory (from 0->MAX_DOMAIN_PAGES
      inclusive) when trying to figure out whether we can re-use some of the
      P2M middle leafs.
      
      Which meant that if the kernel was compiled with MAX_DOMAIN_PAGES=512
      we would try to use the 512th entry. Fortunately for us the p2m_top_index
      has a check for this:
      
       BUG_ON(pfn >= MAX_P2M_PFN);
      
      which we hit and saw this:
      
      (XEN) domain_crash_sync called from entry.S
      (XEN) Domain 0 (vcpu#0) crashed on cpu#0:
      (XEN) ----[ Xen-4.1.2-OVM  x86_64  debug=n  Tainted:    C ]----
      (XEN) CPU:    0
      (XEN) RIP:    e033:[<ffffffff819cadeb>]
      (XEN) RFLAGS: 0000000000000212   EM: 1   CONTEXT: pv guest
      (XEN) rax: ffffffff81db5000   rbx: ffffffff81db4000   rcx: 0000000000000000
      (XEN) rdx: 0000000000480211   rsi: 0000000000000000   rdi: ffffffff81db4000
      (XEN) rbp: ffffffff81793db8   rsp: ffffffff81793d38   r8:  0000000008000000
      (XEN) r9:  4000000000000000   r10: 0000000000000000   r11: ffffffff81db7000
      (XEN) r12: 0000000000000ff8   r13: ffffffff81df1ff8   r14: ffffffff81db6000
      (XEN) r15: 0000000000000ff8   cr0: 000000008005003b   cr4: 00000000000026f0
      (XEN) cr3: 0000000661795000   cr2: 0000000000000000
      
      Fixes-Oracle-Bug: 14570662
      CC: stable@vger.kernel.org # only for v3.5
      Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      50e90041
    • B
      powerpc: Don't use __put_user() in patch_instruction · 636802ef
      Benjamin Herrenschmidt 提交于
      patch_instruction() can be called very early on ppc32, when the kernel
      isn't yet running at it's linked address. That can cause the !
      is_kernel_addr() test in __put_user() to trip and call might_sleep()
      which is very bad at that point during boot.
      
      Use a lower level function instead for now, at least until we get to
      rework ppc32 boot process to do the code patching later, like ppc64
      does.
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      636802ef
    • P
      powerpc: Make sure IPI handlers see data written by IPI senders · 9fb1b36c
      Paul Mackerras 提交于
      We have been observing hangs, both of KVM guest vcpu tasks and more
      generally, where a process that is woken doesn't properly wake up and
      continue to run, but instead sticks in TASK_WAKING state.  This
      happens because the update of rq->wake_list in ttwu_queue_remote()
      is not ordered with the update of ipi_message in
      smp_muxed_ipi_message_pass(), and the reading of rq->wake_list in
      scheduler_ipi() is not ordered with the reading of ipi_message in
      smp_ipi_demux().  Thus it is possible for the IPI receiver not to see
      the updated rq->wake_list and therefore conclude that there is nothing
      for it to do.
      
      In order to make sure that anything done before smp_send_reschedule()
      is ordered before anything done in the resulting call to scheduler_ipi(),
      this adds barriers in smp_muxed_message_pass() and smp_ipi_demux().
      The barrier in smp_muxed_message_pass() is a full barrier to ensure that
      there is a full ordering between the smp_send_reschedule() caller and
      scheduler_ipi().  In smp_ipi_demux(), we use xchg() rather than
      xchg_local() because xchg() includes release and acquire barriers.
      Using xchg() rather than xchg_local() makes sense given that
      ipi_message is not just accessed locally.
      
      This moves the barrier between setting the message and calling the
      cause_ipi() function into the individual cause_ipi implementations.
      Most of them -- those that used outb, out_8 or similar -- already had
      a full barrier because out_8 etc. include a sync before the MMIO
      store.  This adds an explicit barrier in the two remaining cases.
      
      These changes made no measurable difference to the speed of IPIs as
      measured using a simple ping-pong latency test across two CPUs on
      different cores of a POWER7 machine.
      
      The analysis of the reason why processes were not waking up properly
      is due to Milton Miller.
      
      Cc: stable@vger.kernel.org # v3.0+
      Reported-by: NMilton Miller <miltonm@bga.com>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      9fb1b36c
    • A
      powerpc: Restore correct DSCR in context switch · 71433285
      Anton Blanchard 提交于
      During a context switch we always restore the per thread DSCR value.
      If we aren't doing explicit DSCR management
      (ie thread.dscr_inherit == 0) and the default DSCR changed while
      the process has been sleeping we end up with the wrong value.
      
      Check thread.dscr_inherit and select the default DSCR or per thread
      DSCR as required.
      
      This was found with the following test case, when running with
      more threads than CPUs (ie forcing context switching):
      
      http://ozlabs.org/~anton/junkcode/dscr_default_test.c
      
      With the four patches applied I can run a combination of all
      test cases successfully at the same time:
      
      http://ozlabs.org/~anton/junkcode/dscr_default_test.c
      http://ozlabs.org/~anton/junkcode/dscr_explicit_test.c
      http://ozlabs.org/~anton/junkcode/dscr_inherit_test.cSigned-off-by: NAnton Blanchard <anton@samba.org>
      Cc: <stable@kernel.org> # 3.0+
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      71433285
    • A
      powerpc: Fix DSCR inheritance in copy_thread() · 1021cb26
      Anton Blanchard 提交于
      If the default DSCR is non zero we set thread.dscr_inherit in
      copy_thread() meaning the new thread and all its children will ignore
      future updates to the default DSCR. This is not intended and is
      a change in behaviour that a number of our users have hit.
      
      We just need to inherit thread.dscr and thread.dscr_inherit from
      the parent which ends up being much simpler.
      
      This was found with the following test case:
      
      http://ozlabs.org/~anton/junkcode/dscr_default_test.cSigned-off-by: NAnton Blanchard <anton@samba.org>
      Cc: <stable@kernel.org> # 3.0+
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      1021cb26
    • A
      powerpc: Keep thread.dscr and thread.dscr_inherit in sync · 00ca0de0
      Anton Blanchard 提交于
      When we update the DSCR either via emulation of mtspr(DSCR) or via
      a change to dscr_default in sysfs we don't update thread.dscr.
      We will eventually update it at context switch time but there is
      a period where thread.dscr is incorrect.
      
      If we fork at this point we will copy the old value of thread.dscr
      into the child. To avoid this, always keep thread.dscr in sync with
      reality.
      
      This issue was found with the following testcase:
      
      http://ozlabs.org/~anton/junkcode/dscr_inherit_test.cSigned-off-by: NAnton Blanchard <anton@samba.org>
      Cc: <stable@kernel.org> # 3.0+
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      00ca0de0