1. 21 May, 2012 17 commits
  2. 07 May, 2012 2 commits
  3. 06 May, 2012 6 commits
  4. 05 May, 2012 8 commits
  5. 04 May, 2012 7 commits
    • Lin Ming's avatar
      ACPI: Fix D3hot v D3cold confusion · 1cc0c998
      Lin Ming authored
      Before this patch, ACPI_STATE_D3 incorrectly referenced D3hot
      in some places, but D3cold in other places.
      
      After this patch, ACPI_STATE_D3 always means ACPI_STATE_D3_COLD;
      and all references to D3hot use ACPI_STATE_D3_HOT.
      
      ACPI's _PR3 method is used to enter both D3hot and D3cold states.
      What distinguishes D3hot from D3cold is the presence _PR3
      (Power Resources for D3hot)  If these resources are all ON,
      then the state is D3hot.  If _PR3 is not present,
      or all _PR0 resources for the devices are OFF,
      then the state is D3cold.
      
      This patch applies after Linux-3.4-rc1.
      A future syntax cleanup may remove ACPI_STATE_D3
      to emphasize that it always means ACPI_STATE_D3_COLD.
      Signed-off-by: default avatarLin Ming <ming.m.lin@intel.com>
      Acked-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
      Reviewed-by: default avatarAaron Lu <aaron.lu@amd.com>
      Signed-off-by: default avatarLen Brown <len.brown@intel.com>
      1cc0c998
    • Greg Kroah-Hartman's avatar
      hfsplus: Fix potential buffer overflows · 6f24f892
      Greg Kroah-Hartman authored
      Commit ec81aecb ("hfs: fix a potential buffer overflow") fixed a few
      potential buffer overflows in the hfs filesystem.  But as Timo Warns
      pointed out, these changes also need to be made on the hfsplus
      filesystem as well.
      Reported-by: default avatarTimo Warns <warns@pre-sense.de>
      Acked-by: default avatarWANG Cong <amwang@redhat.com>
      Cc: Alexey Khoroshilov <khoroshilov@ispras.ru>
      Cc: Miklos Szeredi <mszeredi@suse.cz>
      Cc: Sage Weil <sage@newdream.net>
      Cc: Eugene Teo <eteo@redhat.com>
      Cc: Roman Zippel <zippel@linux-m68k.org>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: Alexey Dobriyan <adobriyan@gmail.com>
      Cc: Dave Anderson <anderson@redhat.com>
      Cc: stable <stable@vger.kernel.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      6f24f892
    • 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