1. 06 Dec, 2012 12 commits
    • Dan Williams's avatar
      USB: option: add Novatel E362 and Dell Wireless 5800 USB IDs · 6bed143f
      Dan Williams authored
      commit fcb21645 upstream.
      
      The Dell 5800 appears to be a simple rebrand of the Novatel E362.
      Signed-off-by: default avatarDan Williams <dcbw@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      6bed143f
    • Heiko Carstens's avatar
      s390/gup: add missing TASK_SIZE check to get_user_pages_fast() · 63d0412f
      Heiko Carstens authored
      commit d55c4c61 upstream.
      
      When walking page tables we need to make sure that everything
      is within bounds of the ASCE limit of the task's address space.
      Otherwise we might calculate e.g. a pud pointer which is not
      within a pud and dereference it.
      So check against TASK_SIZE (which is the ASCE limit) before
      walking page tables.
      Reviewed-by: default avatarGerald Schaefer <gerald.schaefer@de.ibm.com>
      Signed-off-by: default avatarHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      63d0412f
    • Jani Nikula's avatar
      drm/i915/sdvo: clean up connectors on intel_sdvo_init() failures · 8a3a3f4a
      Jani Nikula authored
      commit d0ddfbd3 upstream.
      
      Any failures in intel_sdvo_init() after the intel_sdvo_setup_output() call
      left behind ghost connectors, attached (with a dangling pointer) to the
      sdvo that has been cleaned up and freed. Properly destroy any connectors
      attached to the encoder.
      
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=46381
      CC: Chris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      Tested-by: bjo@nord-west.org
      [danvet: added a comment to explain why we need to clean up connectors
      even when sdvo_output_setup fails.]
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      [bwh: Backported to 3.2: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      8a3a3f4a
    • Johannes Berg's avatar
      wireless: allow 40 MHz on world roaming channels 12/13 · fbdd5353
      Johannes Berg authored
      commit 43c771a1 upstream.
      
      When in world roaming mode, allow 40 MHz to be used
      on channels 12 and 13 so that an AP that is, e.g.,
      using HT40+ on channel 9 (in the UK) can be used.
      Reported-by: default avatarEddie Chapman <eddie@ehuk.net>
      Tested-by: default avatarEddie Chapman <eddie@ehuk.net>
      Acked-by: default avatarLuis R. Rodriguez <mcgrof@qca.qualcomm.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      fbdd5353
    • Martin Schwidefsky's avatar
      s390/signal: set correct address space control · b6908c58
      Martin Schwidefsky authored
      commit fa968ee2 upstream.
      
      If user space is running in primary mode it can switch to secondary
      or access register mode, this is used e.g. in the clock_gettime code
      of the vdso. If a signal is delivered to the user space process while
      it has been running in access register mode the signal handler is
      executed in access register mode as well which will result in a crash
      most of the time.
      
      Set the address space control bits in the PSW to the default for the
      execution of the signal handler and make sure that the previous
      address space control is restored on signal return. Take care
      that user space can not switch to the kernel address space by
      modifying the registers in the signal frame.
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      [bwh: Backported to 3.2:
       - Adjust filename
       - The RI bit is not included in PSW_MASK_USER]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      b6908c58
    • Misael Lopez Cruz's avatar
      ASoC: dapm: Use card_list during DAPM shutdown · 5f7f7869
      Misael Lopez Cruz authored
      commit 445632ad upstream.
      
      DAPM shutdown incorrectly uses "list" field of codec struct while
      iterating over probed components (codec_dev_list). "list" field
      refers to codecs registered in the system, "card_list" field is
      used for probed components.
      Signed-off-by: default avatarMisael Lopez Cruz <misael.lopez@ti.com>
      Signed-off-by: default avatarLiam Girdwood <lrg@ti.com>
      Signed-off-by: default avatarMark Brown <broonie@opensource.wolfsonmicro.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      5f7f7869
    • Tejun Heo's avatar
      device_cgroup: fix RCU usage · c5ee5868
      Tejun Heo authored
      commit 201e72ac upstream.
      
      dev_cgroup->exceptions is protected with devcgroup_mutex for writes
      and RCU for reads; however, RCU usage isn't correct.
      
      * dev_exception_clean() doesn't use RCU variant of list_del() and
        kfree().  The function can race with may_access() and may_access()
        may end up dereferencing already freed memory.  Use list_del_rcu()
        and kfree_rcu() instead.
      
      * may_access() may be called only with RCU read locked but doesn't use
        RCU safe traversal over ->exceptions.  Use list_for_each_entry_rcu().
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Acked-by: default avatarSerge E. Hallyn <serge.hallyn@ubuntu.com>
      Cc: Aristeu Rozanski <aris@redhat.com>
      Cc: Li Zefan <lizefan@huawei.com>
      [bwh: Backported to 3.2:
       - Adjust context
       - Exception list is called whitelist]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      c5ee5868
    • Eric Millbrandt's avatar
      ASoC: wm8978: pll incorrectly configured when codec is master · 3e1fab33
      Eric Millbrandt authored
      commit 55c6f4cb upstream.
      
      When MCLK is supplied externally and BCLK and LRC are configured as outputs
      (codec is master), the PLL values are only calculated correctly on the first
      transmission.  On subsequent transmissions, at differenct sample rates, the
      wrong PLL values are used.  Test for f_opclk instead of f_pllout to determine
      if the PLL values are needed.
      Signed-off-by: default avatarEric Millbrandt <emillbrandt@dekaresearch.com>
      Signed-off-by: default avatarMark Brown <broonie@opensource.wolfsonmicro.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      3e1fab33
    • Arik Nemtsov's avatar
      mac80211: sync acccess to tx_filtered/ps_tx_buf queues · 3686bdea
      Arik Nemtsov authored
      commit 987c285c upstream.
      
      These are accessed without a lock when ending STA PSM. If the
      sta_cleanup timer accesses these lists at the same time, we might crash.
      
      This may fix some mysterious crashes we had during
      ieee80211_sta_ps_deliver_wakeup.
      Signed-off-by: default avatarArik Nemtsov <arik@wizery.com>
      Signed-off-by: default avatarIdo Yariv <ido@wizery.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      3686bdea
    • Thomas Gleixner's avatar
      futex: Handle futex_pi OWNER_DIED take over correctly · 104d7aa3
      Thomas Gleixner authored
      commit 59fa6245 upstream.
      
      Siddhesh analyzed a failure in the take over of pi futexes in case the
      owner died and provided a workaround.
      See: http://sourceware.org/bugzilla/show_bug.cgi?id=14076
      
      The detailed problem analysis shows:
      
      Futex F is initialized with PTHREAD_PRIO_INHERIT and
      PTHREAD_MUTEX_ROBUST_NP attributes.
      
      T1 lock_futex_pi(F);
      
      T2 lock_futex_pi(F);
         --> T2 blocks on the futex and creates pi_state which is associated
             to T1.
      
      T1 exits
         --> exit_robust_list() runs
             --> Futex F userspace value TID field is set to 0 and
                 FUTEX_OWNER_DIED bit is set.
      
      T3 lock_futex_pi(F);
         --> Succeeds due to the check for F's userspace TID field == 0
         --> Claims ownership of the futex and sets its own TID into the
             userspace TID field of futex F
         --> returns to user space
      
      T1 --> exit_pi_state_list()
             --> Transfers pi_state to waiter T2 and wakes T2 via
             	   rt_mutex_unlock(&pi_state->mutex)
      
      T2 --> acquires pi_state->mutex and gains real ownership of the
             pi_state
         --> Claims ownership of the futex and sets its own TID into the
             userspace TID field of futex F
         --> returns to user space
      
      T3 --> observes inconsistent state
      
      This problem is independent of UP/SMP, preemptible/non preemptible
      kernels, or process shared vs. private. The only difference is that
      certain configurations are more likely to expose it.
      
      So as Siddhesh correctly analyzed the following check in
      futex_lock_pi_atomic() is the culprit:
      
      	if (unlikely(ownerdied || !(curval & FUTEX_TID_MASK))) {
      
      We check the userspace value for a TID value of 0 and take over the
      futex unconditionally if that's true.
      
      AFAICT this check is there as it is correct for a different corner
      case of futexes: the WAITERS bit became stale.
      
      Now the proposed change
      
      -	if (unlikely(ownerdied || !(curval & FUTEX_TID_MASK))) {
      +       if (unlikely(ownerdied ||
      +                       !(curval & (FUTEX_TID_MASK | FUTEX_WAITERS)))) {
      
      solves the problem, but it's not obvious why and it wreckages the
      "stale WAITERS bit" case.
      
      What happens is, that due to the WAITERS bit being set (T2 is blocked
      on that futex) it enforces T3 to go through lookup_pi_state(), which
      in the above case returns an existing pi_state and therefor forces T3
      to legitimately fight with T2 over the ownership of the pi_state (via
      pi_state->mutex). Probelm solved!
      
      Though that does not work for the "WAITERS bit is stale" problem
      because if lookup_pi_state() does not find existing pi_state it
      returns -ERSCH (due to TID == 0) which causes futex_lock_pi() to
      return -ESRCH to user space because the OWNER_DIED bit is not set.
      
      Now there is a different solution to that problem. Do not look at the
      user space value at all and enforce a lookup of possibly available
      pi_state. If pi_state can be found, then the new incoming locker T3
      blocks on that pi_state and legitimately races with T2 to acquire the
      rt_mutex and the pi_state and therefor the proper ownership of the
      user space futex.
      
      lookup_pi_state() has the correct order of checks. It first tries to
      find a pi_state associated with the user space futex and only if that
      fails it checks for futex TID value = 0. If no pi_state is available
      nothing can create new state at that point because this happens with
      the hash bucket lock held.
      
      So the above scenario changes to:
      
      T1 lock_futex_pi(F);
      
      T2 lock_futex_pi(F);
         --> T2 blocks on the futex and creates pi_state which is associated
             to T1.
      
      T1 exits
         --> exit_robust_list() runs
             --> Futex F userspace value TID field is set to 0 and
                 FUTEX_OWNER_DIED bit is set.
      
      T3 lock_futex_pi(F);
         --> Finds pi_state and blocks on pi_state->rt_mutex
      
      T1 --> exit_pi_state_list()
             --> Transfers pi_state to waiter T2 and wakes it via
             	   rt_mutex_unlock(&pi_state->mutex)
      
      T2 --> acquires pi_state->mutex and gains ownership of the pi_state
         --> Claims ownership of the futex and sets its own TID into the
             userspace TID field of futex F
         --> returns to user space
      
      This covers all gazillion points on which T3 might come in between
      T1's exit_robust_list() clearing the TID field and T2 fixing it up. It
      also solves the "WAITERS bit stale" problem by forcing the take over.
      
      Another benefit of changing the code this way is that it makes it less
      dependent on untrusted user space values and therefor minimizes the
      possible wreckage which might be inflicted.
      
      As usual after staring for too long at the futex code my brain hurts
      so much that I really want to ditch that whole optimization of
      avoiding the syscall for the non contended case for PI futexes and rip
      out the maze of corner case handling code. Unfortunately we can't as
      user space relies on that existing behaviour, but at least thinking
      about it helps me to preserve my mental sanity. Maybe we should
      nevertheless :)
      Reported-and-tested-by: default avatarSiddhesh Poyarekar <siddhesh.poyarekar@gmail.com>
      Link: http://lkml.kernel.org/r/alpine.LFD.2.02.1210232138540.2756@ionosAcked-by: default avatarDarren Hart <dvhart@linux.intel.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      104d7aa3
    • Artem Bityutskiy's avatar
      UBIFS: fix mounting problems after power cuts · c26a0f67
      Artem Bityutskiy authored
      commit a28ad42a upstream.
      
      This is a bugfix for a problem with the following symptoms:
      
      1. A power cut happens
      2. After reboot, we try to mount UBIFS
      3. Mount fails with "No space left on device" error message
      
      UBIFS complains like this:
      
      UBIFS error (pid 28225): grab_empty_leb: could not find an empty LEB
      
      The root cause of this problem is that when we mount, not all LEBs are
      categorized. Only those which were read are. However, the
      'ubifs_find_free_leb_for_idx()' function assumes that all LEBs were
      categorized and 'c->freeable_cnt' is valid, which is a false assumption.
      
      This patch fixes the problem by teaching 'ubifs_find_free_leb_for_idx()'
      to always fall back to LPT scanning if no freeable LEBs were found.
      
      This problem was reported by few people in the past, but Brent Taylor
      was able to reproduce it and send me a flash image which cannot be mounted,
      which made it easy to hunt the bug. Kudos to Brent.
      Reported-by: default avatarBrent Taylor <motobud@gmail.com>
      Signed-off-by: default avatarArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      c26a0f67
    • Artem Bityutskiy's avatar
      UBIFS: introduce categorized lprops counter · fd132e04
      Artem Bityutskiy authored
      commit 98a1eebd upstream.
      
      This commit is a preparation for a subsequent bugfix. We introduce a
      counter for categorized lprops.
      Signed-off-by: default avatarArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      fd132e04
  2. 16 Nov, 2012 28 commits