1. 21 May, 2012 17 commits
  2. 07 May, 2012 3 commits
  3. 06 May, 2012 5 commits
  4. 05 May, 2012 10 commits
  5. 04 May, 2012 5 commits
    • Linus Torvalds's avatar
      Merge branch 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · f756beba
      Linus Torvalds authored
      Pull timer fix from Thomas Gleixner.
      
      * 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        rtc: Fix possible null pointer dereference in rtc-mpc5121.c
      f756beba
    • Linus Torvalds's avatar
      Merge git://git.samba.org/sfrench/cifs-2.6 · c6de1687
      Linus Torvalds authored
      Pull CIFS fixes from Steve French.
      
      * git://git.samba.org/sfrench/cifs-2.6:
        fs/cifs: fix parsing of dfs referrals
        cifs: make sure we ignore the credentials= and cred= options
        [CIFS] Update cifs version to 1.78
        cifs - check S_AUTOMOUNT in revalidate
        cifs: add missing initialization of server->req_lock
        cifs: don't cap ra_pages at the same level as default_backing_dev_info
        CIFS: Fix indentation in cifs_show_options
      c6de1687
    • Dave Jones's avatar
      CPU frequency drivers MAINTAINERS update · a03a09b2
      Dave Jones authored
      Remove myself as cpufreq maintainer.
      x86 driver changes can go through the regular x86/ACPI trees.
      ARM driver changes through the ARM trees.
      cpufreq core changes are rare these days, and can just go to lkml/direct.
      Signed-off-by: default avatarDave Jones <davej@redhat.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      a03a09b2
    • Linus Torvalds's avatar
      seqlock: add 'raw_seqcount_begin()' function · 4f988f15
      Linus Torvalds authored
      The normal read_seqcount_begin() function will wait for any current
      writers to exit their critical region by looping until the sequence
      count is even.
      
      That "wait for sequence count to stabilize" is the right thing to do if
      the read-locker will just retry the whole operation on contention: no
      point in doing a potentially expensive reader sequence if we know at the
      beginning that we'll just end up re-doing it all.
      
      HOWEVER.  Some users don't actually retry the operation, but instead
      will abort and do the operation with proper locking.  So the sequence
      count case may be the optimistic quick case, but in the presense of
      writers you may want to do full locking in order to guarantee forward
      progress.  The prime example of this would be the RCU name lookup.
      
      And in that case, you may well be better off without the "retry early",
      and are in a rush to instead get to the failure handling.  Thus this
      "raw" interface that just returns the sequence number without testing it
      - it just forces the low bit to zero so that read_seqcount_retry() will
      always fail such a "active concurrent writer" scenario.
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      4f988f15
    • Linus Torvalds's avatar
      Fix __read_seqcount_begin() to use ACCESS_ONCE for sequence value read · 2f624278
      Linus Torvalds authored
      We really need to use a ACCESS_ONCE() on the sequence value read in
      __read_seqcount_begin(), because otherwise the compiler might end up
      reloading the value in between the test and the return of it.  As a
      result, it might end up returning an odd value (which means that a write
      is in progress).
      
      If the reader is then fast enough that that odd value is still the
      current one when the read_seqcount_retry() is done, we might end up with
      a "successful" read sequence, even despite the concurrent write being
      active.
      
      In practice this probably never really happens - there just isn't
      anything else going on around the read of the sequence count, and the
      common case is that we end up having a read barrier immediately
      afterwards.
      
      So the code sequence in which gcc might decide to reaload from memory is
      small, and there's no reason to believe it would ever actually do the
      reload.  But if the compiler ever were to decide to do so, it would be
      incredibly annoying to debug.  Let's just make sure.
      
      Cc: stable@kernel.org
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      2f624278