1. 02 Feb, 2012 3 commits
    • Dave Martin's avatar
      ARM: 7307/1: vfp: fix ptrace regset modification race · 247f4993
      Dave Martin authored
      In a preemptible kernel, vfp_set() can be preempted, causing the
      hardware VFP context to be switched while the thread vfp state is
      being read and modified.  This leads to a race condition which can
      cause the thread vfp state to become corrupted if lazy VFP context
      save occurs due to preemption in between the time thread->vfpstate
      is read and the time the modified state is written back.
      
      This may occur if preemption occurs during the execution of a
      ptrace() call which modifies the VFP register state of a thread.
      Such instances should be very rare in most realistic scenarios --
      none has been reported, so far as I am aware.  Only uniprocessor
      systems should be affected, since VFP context save is not currently
      lazy in SMP kernels.
      
      The problem was introduced by my earlier patch migrating to use
      regsets to implement ptrace.
      
      This patch does a vfp_sync_hwstate() before reading
      thread->vfpstate, to make sure that the thread's VFP state is not
      live in the hardware registers while the registers are modified.
      
      Thanks to Will Deacon for spotting this.
      
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarDave Martin <dave.martin@linaro.org>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      247f4993
    • Will Deacon's avatar
      ARM: 7306/1: vfp: flush thread hwstate before restoring context from sigframe · 2af276df
      Will Deacon authored
      Following execution of a signal handler, we currently restore the VFP
      context from the ucontext in the signal frame. This involves copying
      from the user stack into the current thread's vfp_hard_struct and then
      flushing the new data out to the hardware registers.
      
      This is problematic when using a preemptible kernel because we could be
      context switched whilst updating the vfp_hard_struct. If the current
      thread has made use of VFP since the last context switch, the VFP
      notifier will copy from the hardware registers into the vfp_hard_struct,
      overwriting any data that had been partially copied by the signal code.
      
      Disabling preemption across copy_from_user calls is a terrible idea, so
      instead we move the VFP thread flush *before* we update the
      vfp_hard_struct. Since the flushing is performed lazily, this has the
      effect of disabling VFP and clearing the CPU's VFP state pointer,
      therefore preventing the thread from being updated with stale data on
      the next context switch.
      
      Cc: stable <stable@vger.kernel.org>
      Tested-by: default avatarPeter Maydell <peter.maydell@linaro.org>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      2af276df
    • Russell King's avatar
      Revert "ARM: 7304/1: ioremap: fix boundary check when reusing static mapping" · 97f10409
      Russell King authored
      This reverts commit 3c424f35.
      
      Joachim Eastwood reports:
      | "ARM: 7304/1: ioremap: fix boundary check when reusing static mapping"
      | Commit: 3c424f35 in Linus master
      |
      | Breaks booting on my custom AT91RM9200 board.
      | There isn't any error messages or anything that indicates what goes
      | wrong it just stops after; Uncompressing Linux... done, booting the
      | kernel.
      |
      | Reverting it makes my board boot again.
      
      and further debugging reveals:
      
      ioremap: pfn=fffff phys=fffff000 offset=400 size=1000
      ioremap: area c3ffdfc0: phys_addr=200000 pfn=200 size=4000
      ioremap: found: addr fef74000 => fed73000 => fed73400
      
      Clearly, an area for pfn 0x200, 16K can't ever satisfy a request for pfn
      0xfffff.  This happens because the changed if statement becomes:
      
                      if (0x00200 > 0xfffff ||
                          0xfffff000 + 0x400 + 0x1000-1 > 0x00200000 + 0x4000-1)
      and therefore:
                      if (0x00200 > 0xfffff ||
                          0x000003ff > 0x00203fff)
      
      The if condition fails, and so we _believe_ that the SRAM mapping fits
      our request.  Clearly that's totally bogus.
      
      Moreover, the original premise of the 'fix' patch was wrong:
      |    The condition checking boundaries of the requested and existing
      |    mappings didn't take in-page offset into consideration though,
      |    which lead to obscure and hard to debug problems when requested
      |    mapping crossed end of the static one.
      
      as the code immediately above this loop does:
      
              size = PAGE_ALIGN(offset + size);
      
      so 'size' already contains the requested offset into the page.
      
      So, revert the broken 'fix'.
      Acked-by: default avatarNicolas Pitre <nico@linaro.org>
      97f10409
  2. 27 Jan, 2012 1 commit
  3. 26 Jan, 2012 1 commit
  4. 25 Jan, 2012 3 commits
  5. 24 Jan, 2012 1 commit
    • Russell King's avatar
      PCMCIA: fix sa1111 oops on remove · 171cf94c
      Russell King authored
      The sa1111 socket driver oopses when removed:
      
      Unable to handle kernel NULL pointer dereference at virtual address 000003b0
      pgd = c1b40000
      [000003b0] *pgd=00000000
      Internal error: Oops: 41b43005 [#1]
      Modules linked in:
      CPU: 0    Not tainted  (3.3.0-rc1+ #744)
      PC is at pcmcia_remove+0x3c/0x60
      LR is at pcmcia_remove+0x34/0x60
      
      This is because we try to dereference a NULL 's' to obtain the next
      pointer.  Fix this.
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      171cf94c
  6. 23 Jan, 2012 8 commits
  7. 22 Jan, 2012 1 commit
    • Russell King's avatar
      MFD: ucb1x00-ts: fix resume failure · 0af5e4c3
      Russell King authored
      If the ucb1x00 touchscreen is resumed while the touchscreen is being
      touched, the main thread stops responding.  This occurs because two
      things happen:
      
      1. When we suspended, we were woken up, and executed the loop.
         Finding that the touchscreen was not pressed, we prepare to
         schedule for a maximum timeout, before being stopped in
         try_to_freeze().
      
      2. an irq occurs, we disable the irq, and mark it as disabled,
         and wake the thread.  This wake occurs while the thread is
         still within __refrigerator()
      
      3. The thread is unfrozen, and __refrigerator() sets the threads
         state back to INTERRUPTIBLE.
      
      We then drop into schedule_timeout() with an infinite timeout and the
      IRQ disabled.  This prevents any further screen touches activating
      the thread.
      
      Fix this by using kthread_freezable_should_stop() which handles the
      freezing issues for us outside of the hotspot where the task state
      matters.  Include a flag to ignore the touchscreen until it is
      released to avoid sending unintended data to the application.
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      0af5e4c3
  8. 21 Jan, 2012 3 commits
  9. 20 Jan, 2012 3 commits
    • Russell King's avatar
      MFD: mcp-core: fix complaints from the genirq layer · 98250221
      Russell King authored
      The genirq layer complains if an interrupt handler returns with
      interrupts enabled.  The UCB1x00 handler does just this, because
      ucb1x00_enable() calls mcp_enable(), which uses spin_lock_irq()
      rather than spin_lock_irqsave().  Convert this, and the divisor
      setting functions to use spin_lock_irqsave().
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      98250221
    • Russell King's avatar
      Revert "ARM: sa11x0: Implement autoloading of codec and codec pdata for mcp bus." · 65f2e753
      Russell King authored
      This reverts commit 5dd7bf59.
      
      Conflicts:
      
      	scripts/mod/file2alias.c
      
      This change is wrong on many levels.  First and foremost, it causes a
      regression.  On boot on Assabet, which this patch gives a codec id of
      'ucb1x00', it gives:
      
      	ucb1x00 ID not found: 1005
      
      0x1005 is a valid ID for the UCB1300 device.
      
      Secondly, this patch is way over the top in terms of complexity.  The
      only device which has been seen to be connected with this MCP code is
      the UCB1x00 (UCB1200, UCB1300 etc) devices, and they all use the same
      driver.  Adding a match table, requiring the codec string to match the
      hardware ID read out of the ID register, etc is completely over the top
      when we can just read the hardware ID register.
      65f2e753
    • Russell King's avatar
      Revert "ARM: sa1100: Refactor mcp-sa11x0 to use platform resources." · 216f63c4
      Russell King authored
      This reverts commit af9081ae.
      
      This revert is necessary to revert 5dd7bf59.
      216f63c4
  10. 19 Jan, 2012 16 commits