Permalink
Commits on Jan 26, 2012
  1. Merge branch 'version-3.2' into pf-3.2

    Oleksandr Natalenko committed Jan 26, 2012
  2. version-3.2: bump version to 3.2.2-pf

    Oleksandr Natalenko committed Jan 26, 2012
  3. fix merge conflict

    Oleksandr Natalenko committed Jan 26, 2012
  4. Linux 3.2.2

    gregkh committed Jan 26, 2012
  5. SHM_UNLOCK: fix Unevictable pages stranded after swap

    commit 2451326 upstream.
    
    Commit cc39c6a ("mm: account skipped entries to avoid looping in
    find_get_pages") correctly fixed an infinite loop; but left a problem
    that find_get_pages() on shmem would return 0 (appearing to callers to
    mean end of tree) when it meets a run of nr_pages swap entries.
    
    The only uses of find_get_pages() on shmem are via pagevec_lookup(),
    called from invalidate_mapping_pages(), and from shmctl SHM_UNLOCK's
    scan_mapping_unevictable_pages().  The first is already commented, and
    not worth worrying about; but the second can leave pages on the
    Unevictable list after an unusual sequence of swapping and locking.
    
    Fix that by using shmem_find_get_pages_and_swap() (then ignoring the
    swap) instead of pagevec_lookup().
    
    But I don't want to contaminate vmscan.c with shmem internals, nor
    shmem.c with LRU locking.  So move scan_mapping_unevictable_pages() into
    shmem.c, renaming it shmem_unlock_mapping(); and rename
    check_move_unevictable_page() to check_move_unevictable_pages(), looping
    down an array of pages, oftentimes under the same lock.
    
    Leave out the "rotate unevictable list" block: that's a leftover from
    when this was used for /proc/sys/vm/scan_unevictable_pages, whose flawed
    handling involved looking at pages at tail of LRU.
    
    Was there significance to the sequence first ClearPageUnevictable, then
    test page_evictable, then SetPageUnevictable here? I think not, we're
    under LRU lock, and have no barriers between those.
    
    Signed-off-by: Hugh Dickins <hughd@google.com>
    Reviewed-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
    Cc: Minchan Kim <minchan.kim@gmail.com>
    Cc: Rik van Riel <riel@redhat.com>
    Cc: Shaohua Li <shaohua.li@intel.com>
    Cc: Eric Dumazet <eric.dumazet@gmail.com>
    Cc: Johannes Weiner <hannes@cmpxchg.org>
    Cc: Michel Lespinasse <walken@google.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Hugh Dickins committed with gregkh Jan 20, 2012
  6. SHM_UNLOCK: fix long unpreemptible section

    commit 8504657 upstream.
    
    scan_mapping_unevictable_pages() is used to make SysV SHM_LOCKed pages
    evictable again once the shared memory is unlocked.  It does this with
    pagevec_lookup()s across the whole object (which might occupy most of
    memory), and takes 300ms to unlock 7GB here.  A cond_resched() every
    PAGEVEC_SIZE pages would be good.
    
    However, KOSAKI-san points out that this is called under shmem.c's
    info->lock, and it's also under shm.c's shm_lock(), both spinlocks.
    There is no strong reason for that: we need to take these pages off the
    unevictable list soonish, but those locks are not required for it.
    
    So move the call to scan_mapping_unevictable_pages() from shmem.c's
    unlock handling up to shm.c's unlock handling.  Remove the recently
    added barrier, not needed now we have spin_unlock() before the scan.
    
    Use get_file(), with subsequent fput(), to make sure we have a reference
    to mapping throughout scan_mapping_unevictable_pages(): that's something
    that was previously guaranteed by the shm_lock().
    
    Remove shmctl's lru_add_drain_all(): we don't fault in pages at SHM_LOCK
    time, and we lazily discover them to be Unevictable later, so it serves
    no purpose for SHM_LOCK; and serves no purpose for SHM_UNLOCK, since
    pages still on pagevec are not marked Unevictable.
    
    The original code avoided redundant rescans by checking VM_LOCKED flag
    at its level: now avoid them by checking shp's SHM_LOCKED.
    
    The original code called scan_mapping_unevictable_pages() on a locked
    area at shm_destroy() time: perhaps we once had accounting cross-checks
    which required that, but not now, so skip the overhead and just let
    inode eviction deal with them.
    
    Put check_move_unevictable_page() and scan_mapping_unevictable_pages()
    under CONFIG_SHMEM (with stub for the TINY case when ramfs is used),
    more as comment than to save space; comment them used for SHM_UNLOCK.
    
    Signed-off-by: Hugh Dickins <hughd@google.com>
    Reviewed-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
    Cc: Minchan Kim <minchan.kim@gmail.com>
    Cc: Rik van Riel <riel@redhat.com>
    Cc: Shaohua Li <shaohua.li@intel.com>
    Cc: Eric Dumazet <eric.dumazet@gmail.com>
    Cc: Johannes Weiner <hannes@cmpxchg.org>
    Cc: Michel Lespinasse <walken@google.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Hugh Dickins committed with gregkh Jan 20, 2012
  7. iwlegacy: 3945: fix hw passive scan on radar channels

    commit 68acc4a upstream.
    
    Patch fix firmware error on "iw dev wlan0 scan passive" for
    hardware scanning (with disable_hw_scan=0 module parameter).
    
     iwl3945 0000:03:00.0: Microcode SW error detected. Restarting 0x82000008.
     iwl3945 0000:03:00.0: Loaded firmware version: 15.32.2.9
     iwl3945 0000:03:00.0: Start IWL Error Log Dump:
     iwl3945 0000:03:00.0: Status: 0x0002A2E4, count: 1
     iwl3945 0000:03:00.0: Desc       Time       asrtPC blink2 ilink1  nmiPC   Line
     iwl3945 0000:03:00.0: SYSASSERT     (0x5) 0041263900 0x13756 0x0031C 0x00000 764
     iwl3945 0000:03:00.0: Error Reply type 0x000002FC cmd C_SCAN (0x80) seq 0x443E ser 0x00340000
     iwl3945 0000:03:00.0: Command C_SCAN failed: FW Error
     iwl3945 0000:03:00.0: Can't stop Rx DMA.
    
    We have disable ability to change passive scanning to active on
    particular channel when traffic is detected on that channel. Otherwise
    firmware will report error, when we try to do passive scan on radar
    channels.
    
    Reported-and-debugged-by: Pedro Francisco <pedrogfrancisco@gmail.com>
    Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    sgruszka committed with gregkh Dec 23, 2011
  8. iwlagn: check for SMPS mode

    commit b2ccccd upstream.
    
    Check and report WARN only when its invalid
    
    Resolves:
    https://bugzilla.kernel.org/show_bug.cgi?id=42621
    https://bugzilla.redhat.com/show_bug.cgi?id=766071
    
    Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Wey-Yi Guy committed with gregkh Nov 10, 2011
  9. mm: fix NULL ptr dereference in __count_immobile_pages

    commit 687875f upstream.
    
    Fix the following NULL ptr dereference caused by
    
      cat /sys/devices/system/memory/memory0/removable
    
    Pid: 13979, comm: sed Not tainted 3.0.13-0.5-default #1 IBM BladeCenter LS21 -[7971PAM]-/Server Blade
    RIP: __count_immobile_pages+0x4/0x100
    Process sed (pid: 13979, threadinfo ffff880221c36000, task ffff88022e788480)
    Call Trace:
      is_pageblock_removable_nolock+0x34/0x40
      is_mem_section_removable+0x74/0xf0
      show_mem_removable+0x41/0x70
      sysfs_read_file+0xfe/0x1c0
      vfs_read+0xc7/0x130
      sys_read+0x53/0xa0
      system_call_fastpath+0x16/0x1b
    
    We are crashing because we are trying to dereference NULL zone which
    came from pfn=0 (struct page ffffea0000000000). According to the boot
    log this page is marked reserved:
    e820 update range: 0000000000000000 - 0000000000010000 (usable) ==> (reserved)
    
    and early_node_map confirms that:
    early_node_map[3] active PFN ranges
        1: 0x00000010 -> 0x0000009c
        1: 0x00000100 -> 0x000bffa3
        1: 0x00100000 -> 0x00240000
    
    The problem is that memory_present works in PAGE_SECTION_MASK aligned
    blocks so the reserved range sneaks into the the section as well.  This
    also means that free_area_init_node will not take care of those reserved
    pages and they stay uninitialized.
    
    When we try to read the removable status we walk through all available
    sections and hope that the zone is valid for all pages in the section.
    But this is not true in this case as the zone and nid are not initialized.
    
    We have only one node in this particular case and it is marked as node=1
    (rather than 0) and that made the problem visible because page_to_nid will
    return 0 and there are no zones on the node.
    
    Let's check that the zone is valid and that the given pfn falls into its
    boundaries and mark the section not removable.  This might cause some
    false positives, probably, but we do not have any sane way to find out
    whether the page is reserved by the platform or it is just not used for
    whatever other reasons.
    
    Signed-off-by: Michal Hocko <mhocko@suse.cz>
    Acked-by: Mel Gorman <mgorman@suse.de>
    Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
    Cc: Andrea Arcangeli <aarcange@redhat.com>
    Cc: David Rientjes <rientjes@google.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Michal Hocko committed with gregkh Jan 20, 2012
  10. proc: clear_refs: do not clear reserved pages

    commit 85e72aa upstream.
    
    /proc/pid/clear_refs is used to clear the Referenced and YOUNG bits for
    pages and corresponding page table entries of the task with PID pid, which
    includes any special mappings inserted into the page tables in order to
    provide things like vDSOs and user helper functions.
    
    On ARM this causes a problem because the vectors page is mapped as a
    global mapping and since ec706da ("ARM: add a vma entry for the user
    accessible vector page"), a VMA is also inserted into each task for this
    page to aid unwinding through signals and syscall restarts.  Since the
    vectors page is required for handling faults, clearing the YOUNG bit (and
    subsequently writing a faulting pte) means that we lose the vectors page
    *globally* and cannot fault it back in.  This results in a system deadlock
    on the next exception.
    
    To see this problem in action, just run:
    
    	$ echo 1 > /proc/self/clear_refs
    
    on an ARM platform (as any user) and watch your system hang.  I think this
    has been the case since 2.6.37
    
    This patch avoids clearing the aforementioned bits for reserved pages,
    therefore leaving the vectors page intact on ARM.  Since reserved pages
    are not candidates for swap, this change should not have any impact on the
    usefulness of clear_refs.
    
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Reported-by: Moussa Ba <moussaba@micron.com>
    Acked-by: Hugh Dickins <hughd@google.com>
    Cc: David Rientjes <rientjes@google.com>
    Cc: Russell King <rmk@arm.linux.org.uk>
    Acked-by: Nicolas Pitre <nico@linaro.org>
    Cc: Matt Mackall <mpm@selenic.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    wildea01 committed with gregkh Jan 20, 2012
  11. kprobes: initialize before using a hlist

    commit d496aab upstream.
    
    Commit ef53d9c ("kprobes: improve kretprobe scalability with hashed
    locking") introduced a bug where we can potentially leak
    kretprobe_instances since we initialize a hlist head after having used
    it.
    
    Initialize the hlist head before using it.
    
    Reported by: Jim Keniston <jkenisto@us.ibm.com>
    Acked-by: Jim Keniston <jkenisto@us.ibm.com>
    Signed-off-by: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
    Acked-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
    Cc: Srinivasa D S <srinivasa@in.ibm.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Ananth N Mavinakayanahalli committed with gregkh Jan 20, 2012
  12. cifs: lower default wsize when unix extensions are not used

    commit ce91acb upstream.
    
    We've had some reports of servers (namely, the Solaris in-kernel CIFS
    server) that don't deal properly with writes that are "too large" even
    though they set CAP_LARGE_WRITE_ANDX. Change the default to better
    mirror what windows clients do.
    
    Cc: Pavel Shilovsky <piastry@etersoft.ru>
    Reported-by: Nick Davis <phireph0x@yahoo.com>
    Signed-off-by: Jeff Layton <jlayton@redhat.com>
    Signed-off-by: Steve French <smfrench@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    jtlayton committed with gregkh Jan 17, 2012
  13. score: fix off-by-one index into syscall table

    commit c25a785 upstream.
    
    If the provided system call number is equal to __NR_syscalls, the
    current check will pass and a function pointer just after the system
    call table may be called, since sys_call_table is an array with total
    size __NR_syscalls.
    
    Whether or not this is a security bug depends on what the compiler puts
    immediately after the system call table.  It's likely that this won't do
    anything bad because there is an additional NULL check on the syscall
    entry, but if there happens to be a non-NULL value immediately after the
    system call table, this may result in local privilege escalation.
    
    Signed-off-by: Dan Rosenberg <drosenberg@vsecurity.com>
    Cc: Chen Liqin <liqin.chen@sunplusct.com>
    Cc: Lennox Wu <lennox.wu@gmail.com>
    Cc: Eugene Teo <eugeneteo@kernel.sg>
    Cc: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Dan Rosenberg committed with gregkh Jan 20, 2012
  14. i2c-eg20t: modified the setting of transfer rate.

    commit ff35e8b upstream.
    
    This patch modified the setting value of
    I2C Bus Transfer Rate Setting Counter regisrer.
    
    Signed-off-by: Toshiharu Okada <toshiharu-linux@dsn.okisemi.com>
    Signed-off-by: Ben Dooks <ben-linux@fluff.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Toshiharu Okada committed with gregkh Sep 26, 2011
  15. xfs: fix endian conversion issue in discard code

    commit b1c770c upstream
    
    When finding the longest extent in an AG, we read the value directly
    out of the AGF buffer without endian conversion. This will give an
    incorrect length, resulting in FITRIM operations potentially not
    trimming everything that it should.
    
    Signed-off-by: Dave Chinner <dchinner@redhat.com>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Ben Myers <bpm@sgi.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Dave Chinner committed with gregkh Jan 18, 2012
  16. rt2800pci: fix spurious interrupts generation

    commit dfd00c4 upstream.
    
    Same devices can generate interrupt without properly setting bit in
    INT_SOURCE_CSR register (spurious interrupt), what will cause IRQ line
    will be disabled by interrupts controller driver.
    
    We discovered that clearing INT_MASK_CSR stops such behaviour. We
    previously first read that register, and then clear all know interrupt
    sources bits and do not touch reserved bits. After this patch, we write
    to all register content (I believe writing to reserved bits on that
    register will not cause any problems, I tested that on my rt2800pci
    device).
    
    This fix very bad performance problem, practically making device
    unusable (since worked without interrupts), reported in:
    https://bugzilla.redhat.com/show_bug.cgi?id=658451
    
    We previously tried to workaround that issue in commit
    4ba7d99 "rt2800pci: handle spurious
    interrupts", but it was reverted in commit
    82e5fc2
    as thing, that will prevent to detect real spurious interrupts.
    
    Reported-and-tested-by: Amir Hedayaty <hedayaty@gmail.com>
    Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
    Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    sgruszka committed with gregkh Jan 13, 2012
  17. ath9k_hw: fix interpretation of the rx KeyMiss flag

    commit 7a532fe upstream.
    
    Documentation states that the KeyMiss flag is only valid if RxFrameOK is
    unset, however empirical evidence has shown that this is false.
    When KeyMiss is set (and RxFrameOK is 1), the hardware passes a valid frame
    which has not been decrypted. The driver then falsely marks the frame
    as decrypted, and when using CCMP this corrupts the rx CCMP PN, leading
    to connection hangs.
    
    Signed-off-by: Felix Fietkau <nbd@openwrt.org>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Felix Fietkau committed with gregkh Jan 14, 2012
  18. x86/UV2: Work around BAU bug

    commit c5d35d3 upstream.
    
    This patch implements a workaround for a UV2 hardware bug.
    The bug is a non-atomic update of a memory-mapped register. When
    hardware message delivery and software message acknowledge occur
    simultaneously the pending message acknowledge for the arriving
    message may be lost.  This causes the sender's message status to
    stay busy.
    
    Part of the workaround is to not acknowledge a completed message
    until it is verified that no other message is actually using the
    resource that is mistakenly recorded in the completed message.
    
    Part of the workaround is to test for long elapsed time in such
    a busy condition, then handle it by using a spare sending
    descriptor. The stay-busy condition is eventually timed out by
    hardware, and then the original sending descriptor can be
    re-used. Most of that logic change is in keeping track of the
    current descriptor and the state of the spares.
    
    The occurrences of the workaround are added to the BAU
    statistics.
    
    Signed-off-by: Cliff Wickman <cpw@sgi.com>
    Link: http://lkml.kernel.org/r/20120116211947.GC5767@sgi.com
    Signed-off-by: Ingo Molnar <mingo@elte.hu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    cpwickman committed with gregkh Jan 16, 2012
  19. x86/UV2: Fix BAU destination timeout initialization

    commit d059f9f upstream.
    
    Move the call to enable_timeouts() forward so that
    BAU_MISC_CONTROL is initialized before using it in
    calculate_destination_timeout().
    
    Fix the calculation of a BAU destination timeout
    for UV2 (in calculate_destination_timeout()).
    
    Signed-off-by: Cliff Wickman <cpw@sgi.com>
    Link: http://lkml.kernel.org/r/20120116211848.GB5767@sgi.com
    Signed-off-by: Ingo Molnar <mingo@elte.hu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    cpwickman committed with gregkh Jan 16, 2012
  20. x86/UV2: Fix new UV2 hardware by using native UV2 broadcast mode

    commit da87c93 upstream.
    
    Update the use of the Broadcast Assist Unit on SGI Altix UV2 to
    the use of native UV2 mode on new hardware (not the legacy mode).
    
    UV2 native mode has a different format for a broadcast message.
    We also need quick differentiaton between UV1 and UV2.
    
    Signed-off-by: Cliff Wickman <cpw@sgi.com>
    Link: http://lkml.kernel.org/r/20120116211750.GA5767@sgi.com
    Signed-off-by: Ingo Molnar <mingo@elte.hu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    cpwickman committed with gregkh Jan 16, 2012
  21. I2C: OMAP: correct SYSC register offset for OMAP4

    commit 2727b17 upstream.
    
    Correct OMAP_I2C_SYSC_REG offset in omap4 register map.
    Offset 0x20 is reserved and OMAP_I2C_SYSC_REG has 0x10 as offset.
    
    Signed-off-by: Alexander Aring <a.aring@phytec.de>
    [khilman@ti.com: minor changelog edits]
    Signed-off-by: Kevin Hilman <khilman@ti.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Alexander Aring committed with gregkh Dec 8, 2011
  22. tracepoints/module: Fix disabling tracepoints with taint CRAP or OOT

    commit c10076c upstream.
    
    Tracepoints are disabled for tainted modules, which is usually because the
    module is either proprietary or was forced, and we don't want either of them
    using kernel tracepoints.
    
    But, a module can also be tainted by being in the staging directory or
    compiled out of tree. Either is fine for use with tracepoints, no need
    to punish them.  I found this out when I noticed that my sample trace event
    module, when done out of tree, stopped working.
    
    Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
    Cc: Ben Hutchings <ben@decadent.org.uk>
    Cc: Dave Jones <davej@redhat.com>
    Cc: Greg Kroah-Hartman <gregkh@suse.de>
    Cc: Rusty Russell <rusty@rustcorp.com.au>
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Steven Rostedt committed with gregkh Jan 14, 2012
  23. tuner: Fix numberspace conflict between xc4000 and pti 5nf05 tuners

    commit cd4ca7a upstream.
    
    Update xc4000 tuner definition, number 81 is already in use by
    TUNER_PARTSNIC_PTI_5NF05.
    
    Signed-off-by: Miroslav Slugen <thunder.mmm@gmail.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Miroslav Slugen committed with gregkh Dec 11, 2011
  24. cx88: fix: don't duplicate xc4000 entry for radio

    commit b6854e3 upstream.
    
    All radio tuners in cx88 driver using same address for radio and tuner,
    so there is no need to probe it twice for same tuner and we can use
    radio_type UNSET, this also fix broken radio since kernel 2.6.39-rc1
    for those tuners.
    
    Signed-off-by: Miroslav Slugen <thunder.mmm@gmail.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Miroslav Slugen committed with gregkh Dec 11, 2011
  25. cx23885-dvb: check if dvb_attach() succeded

    commit a7c8aad upstream.
    
    Fix possible null dereference for Leadtek DTV 3200H
    XC4000 tuner when no firmware file available.
    
    Signed-off-by: Miroslav Slugen <thunder.mmm@gmail.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Miroslav Slugen committed with gregkh Dec 11, 2011
  26. bcma: invalidate the mapped core over suspend/resume

    commit 28e7d21 upstream.
    
    This clears the currently mapped core when suspending, to force
    re-mapping after resume. Without that we were touching default core
    registers believing some other core is mapped. Such a behaviour
    resulted in lockups on some machines.
    
    Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    rmilecki committed with gregkh Jan 13, 2012
  27. target: Set additional sense length field in sense data

    commit 895f302 upstream.
    
    The target code was not setting the additional sense length field in the
    sense data it returned, which meant that at least the Linux stack
    ignored the ASC/ASCQ fields.  For example, without this patch, on a
    tcm_loop device:
    
        # sg_raw -v /dev/sda 2 0 0 0 0 0
    
    gives
    
            cdb to send: 02 00 00 00 00 00
        SCSI Status: Check Condition
    
        Sense Information:
         Fixed format, current;  Sense key: Illegal Request
          Raw sense data (in hex):
                70 00 05 00 00 00 00 00
    
    while after the patch we correctly get the following (which matches what
    a regular disk returns):
    
            cdb to send: 02 00 00 00 00 00
        SCSI Status: Check Condition
    
        Sense Information:
         Fixed format, current;  Sense key: Illegal Request
         Additional sense: Invalid command operation code
         Raw sense data (in hex):
                70 00 05 00 00 00 00 0a  00 00 00 00 20 00 00 00
                00 00
    
    Signed-off-by: Roland Dreier <roland@purestorage.com>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    rolandd committed with gregkh Dec 13, 2011
  28. target: Set response format in INQUIRY response

    commit ce13617 upstream.
    
    Current SCSI specs say that the "response format" field in the standard
    INQUIRY response should be set to 2, and all the real SCSI devices I
    have do put 2 here.  So let's do that too.
    
    Signed-off-by: Roland Dreier <roland@purestorage.com>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    rolandd committed with gregkh Dec 6, 2011
  29. sym53c8xx: Fix NULL pointer dereference in slave_destroy

    commit cced504 upstream.
    
    sym53c8xx_slave_destroy unconditionally assumes that sym53c8xx_slave_alloc has
    succesesfully allocated a sym_lcb. This can lead to a NULL pointer dereference
    (exposed by commit 4e6c82b).
    
    Signed-off-by: Stratos Psomadakis <psomas@gentoo.org>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    psomas committed with gregkh Dec 4, 2011
  30. ACPI: processor: fix acpi_get_cpuid for UP processor

    commit d640113 upstream.
    
    For UP processor, it is likely that no _MAT method or MADT table defined.
    So currently acpi_get_cpuid(...) always return -1 for UP processor.
    This is wrong. It should return valid value for CPU0.
    
    In the other hand, BIOS may define multiple CPU handles even for UP
    processor, for example
    
            Scope (_PR)
            {
                Processor (CPU0, 0x00, 0x00000410, 0x06) {}
                Processor (CPU1, 0x01, 0x00000410, 0x06) {}
                Processor (CPU2, 0x02, 0x00000410, 0x06) {}
                Processor (CPU3, 0x03, 0x00000410, 0x06) {}
            }
    
    We should only return valid value for CPU0's acpi handle.
    And return invalid value for others.
    
    http://marc.info/?t=132329819900003&r=1&w=2
    
    Reported-and-tested-by: wallak@free.fr
    Signed-off-by: Lin Ming <ming.m.lin@intel.com>
    Signed-off-by: Len Brown <len.brown@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Lin Ming committed with gregkh Dec 13, 2011
  31. ACPICA: Put back the call to acpi_os_validate_address

    commit da4d8b2 upstream.
    
    The call to acpi_os_validate_address in acpi_ds_get_region_arguments was
    removed by mistake in commit 9ad19ac(ACPICA: Split large dsopcode and
    dsload.c files).
    
    Put it back.
    
    Reported-and-bisected-by: Luca Tettamanti <kronos.it@gmail.com>
    Signed-off-by: Lin Ming <ming.m.lin@intel.com>
    Signed-off-by: Len Brown <len.brown@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Lin Ming committed with gregkh Nov 29, 2011
  32. ACPI, ia64: Use SRAT table rev to use 8bit or 16/32bit PXM fields (ia64)

    commit 9f10f6a upstream.
    
    In SRAT v1, we had 8bit proximity domain (PXM) fields; SRAT v2 provides
    32bits for these. The new fields were reserved before.
    According to the ACPI spec, the OS must disregrard reserved fields.
    
    ia64 did handle the PXM fields almost consistently, but depending on
    sgi's sn2 platform. This patch leaves the sn2 logic in, but does also
    use 16/32 bits for PXM if the SRAT has rev 2 or higher.
    
    The patch also adds __init to the two pxm accessor functions, as they
    access __initdata now and are called from an __init function only anyway.
    
    Note that the code only uses 16 bits for the PXM field in the processor
    proximity field; the patch does not address this as 16 bits are more than
    enough.
    
    Signed-off-by: Kurt Garloff <kurt@garloff.de>
    Signed-off-by: Len Brown <len.brown@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    garloff committed with gregkh Jan 17, 2012
  33. ACPI, x86: Use SRAT table rev to use 8bit or 32bit PXM fields (x86/x8…

    …6-64)
    
    commit cd298f6 upstream.
    
    In SRAT v1, we had 8bit proximity domain (PXM) fields; SRAT v2 provides
    32bits for these. The new fields were reserved before.
    According to the ACPI spec, the OS must disregrard reserved fields.
    
    x86/x86-64 was rather inconsistent prior to this patch; it used 8 bits
    for the pxm field in cpu_affinity, but 32 bits in mem_affinity.
    This patch makes it consistent: Either use 8 bits consistently (SRAT
    rev 1 or lower) or 32 bits (SRAT rev 2 or higher).
    
    cc: x86@kernel.org
    Signed-off-by: Kurt Garloff <kurt@garloff.de>
    Signed-off-by: Len Brown <len.brown@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    garloff committed with gregkh Jan 17, 2012
  34. ACPI: Store SRAT table revision

    commit 8df0eb7 upstream.
    
    In SRAT v1, we had 8bit proximity domain (PXM) fields; SRAT v2 provides
    32bits for these. The new fields were reserved before.
    According to the ACPI spec, the OS must disregrard reserved fields.
    In order to know whether or not, we must know what version the SRAT
    table has.
    
    This patch stores the SRAT table revision for later consumption
    by arch specific __init functions.
    
    Signed-off-by: Kurt Garloff <kurt@garloff.de>
    Signed-off-by: Len Brown <len.brown@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    garloff committed with gregkh Jan 17, 2012
  35. intel_idle: fix API misuse

    commit 39a74fd upstream.
    
    smp_call_function() only lets all other CPUs execute a specific function,
    while we expect all CPUs do in intel_idle.  Without the fix, we could have
    one cpu which has auto_demotion enabled or has no broadcast timer setup.
    Usually we don't see impact because auto demotion just harms power and the
    intel_idle init is called in CPU 0, where boradcast timer delivers
    interrupt, but this still could be a problem.
    
    Signed-off-by: Shaohua Li <shaohua.li@intel.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Len Brown <len.brown@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Shaohua Li committed with gregkh Jan 10, 2012