1. 17 May, 2012 1 commit
  2. 14 May, 2012 7 commits
  3. 09 May, 2012 9 commits
  4. 07 May, 2012 4 commits
  5. 06 May, 2012 5 commits
  6. 05 May, 2012 10 commits
  7. 04 May, 2012 4 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