Linux 3.0.18
commit 235eae6e5e402f5f723203e4444f10c16c7c3be3
Author: Greg Kroah-Hartman <gregkh@suse.de>
Date:   Wed Jan 25 17:26:46 2012 -0800

    Linux 3.0.18

commit 20ef6312522d42407e8030bb17f25c4fde724a37
Author: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Date:   Wed Jan 11 15:13:27 2012 +0200

    UBIFS: make debugging messages light again

    commit 1f5d78dc4823a85f112aaa2d0f17624f8c2a6c52 upstream.

    We switch to dynamic debugging in commit
    56e46742e846e4de167dde0e1e1071ace1c882a5 but did not take into account that
    now we do not control anymore whether a specific message is enabled or not.
    So now we lock the "dbg_lock" and release it in every debugging macro, which
    make them not so light-weight.

    This commit removes the "dbg_lock" protection from the debugging macros to
    fix the issue.

    The downside is that now our DBGKEY() stuff is broken, but this is not
    critical at all and will be fixed later.

    Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit e4ae34bbc7386489a0c8253f246e7a5d316f249a
Author: Stanislaw Gruszka <sgruszka@redhat.com>
Date:   Fri Dec 23 08:13:50 2011 +0100

    iwlegacy: 3945: fix hw passive scan on radar channels

    commit 68acc4afb040d98ddfd2cae0de09e2f4e1ee127f 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>

commit dd558f1e43567fd51a258f61081809e60735f9f4
Author: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Date:   Thu Nov 10 06:55:04 2011 -0800

    iwlagn: check for SMPS mode

    commit b2ccccdca46273c7b321ecf5041c362cd950da20 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>

commit bcbef18db94dfb991bd3025069b3413cbc52f8b6
Author: Michal Hocko <mhocko@suse.cz>
Date:   Fri Jan 20 14:33:55 2012 -0800

    mm: fix NULL ptr dereference in __count_immobile_pages

    commit 687875fb7de4a95223af20ee024282fa9099f860 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>

commit c2c9f543718e15227a4aa0135e793480b94c4d97
Author: Will Deacon <will.deacon@arm.com>
Date:   Fri Jan 20 14:34:09 2012 -0800

    proc: clear_refs: do not clear reserved pages

    commit 85e72aa5384b1a614563ad63257ded0e91d1a620 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 ec706dab ("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>

commit b8f256956a063ebc60a674ec5795c7ca5aaa79c6
Author: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
Date:   Fri Jan 20 14:34:04 2012 -0800

    kprobes: initialize before using a hlist

    commit d496aab567e7e52b3e974c9192a5de6e77dce32c upstream.

    Commit ef53d9c5e ("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>

commit 72a82010500dea88b2d786a76b063a871e2a4603
Author: Dan Rosenberg <drosenberg@vsecurity.com>
Date:   Fri Jan 20 14:34:27 2012 -0800

    score: fix off-by-one index into syscall table

    commit c25a785d6647984505fa165b5cd84cfc9a95970b 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>

commit a6007c036e0a0e10c0b4dbd533576d201b822a90
Author: Toshiharu Okada <toshiharu-linux@dsn.okisemi.com>
Date:   Mon Sep 26 16:16:23 2011 +0900

    i2c-eg20t: modified the setting of transfer rate.

    commit ff35e8b18984ad2a82cbd259fc07f0be4b34b1aa 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>

commit d7531928ae349a5d59a6820bc3a5e46c9907f5ad
Author: Dirk Eibach <eibach@gdsys.de>
Date:   Tue Oct 18 03:04:11 2011 +0000

    net: Fix driver name for mdio-gpio.c

    commit f42af6c486aa5ca6ee62800cb45c5b252020509d upstream.

    Since commit
    "7488876... dt/net: Eliminate users of of_platform_{,un}register_driver"
    there are two platform drivers named "mdio-gpio" registered.
    I renamed the of variant to "mdio-ofgpio".

    Signed-off-by: Dirk Eibach <eibach@gdsys.de>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 5e383255dab2f12e7e111e23c057a30955de8cf3
Author: Boaz Harrosh <bharrosh@panasas.com>
Date:   Fri Jan 6 09:31:20 2012 +0200

    pnfs-obj: Must return layout on IO error

    commit fe0fe83585f88346557868a803a479dfaaa0688a upstream.

    As mandated by the standard. In case of an IO error, a pNFS
    objects layout driver must return it's layout. This is because
    all device errors are reported to the server as part of the
    layout return buffer.

    This is implemented the same way PNFS_LAYOUTRET_ON_SETATTR
    is done, through a bit flag on the pnfs_layoutdriver_type->flags
    member. The flag is set by the layout driver that wants a
    layout_return preformed at pnfs_ld_{write,read}_done in case
    of an error.
    (Though I have not defined a wrapper like pnfs_ld_layoutret_on_setattr
     because this code is never called outside of pnfs.c and pnfs IO
     paths)

    Without this patch 3.[0-2] Kernels leak memory and have an annoying
    WARN_ON after every IO error utilizing the pnfs-obj driver.

    Signed-off-by: Boaz Harrosh <bharrosh@panasas.com>
    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 8edf7c13515fa2dee528ab348919058b14454457
Author: Boaz Harrosh <bharrosh@panasas.com>
Date:   Fri Jan 6 09:28:12 2012 +0200

    pnfs-obj: pNFS errors are communicated on iodata->pnfs_error

    commit 5c0b4129c07b902b27d3f3ebc087757f534a3abd upstream.

    Some time along the way pNFS IO errors were switched to
    communicate with a special iodata->pnfs_error member instead
    of the regular RPC members. But objlayout was not switched
    over.

    Fix that!
    Without this fix any IO error is hanged, because IO is not
    switched to MDS and pages are never cleared or read.

    Signed-off-by: Boaz Harrosh <bharrosh@panasas.com>
    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit ac631973a9ad6bba3d666f687288ebeb819c0df0
Author: Stanislaw Gruszka <sgruszka@redhat.com>
Date:   Fri Jan 13 12:59:32 2012 +0100

    rt2800pci: fix spurious interrupts generation

    commit dfd00c4c8f3dfa1fd7cec45f83d98b2a49743dcd 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
    4ba7d9997869d25bd223dea7536fc1ce9fab3b3b "rt2800pci: handle spurious
    interrupts", but it was reverted in commit
    82e5fc2a34fa9ffea38f00c4066b7e600a0ca5e6
    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>

commit 415b95df641c998a7cf15c916047f338ab2ce87b
Author: Cliff Wickman <cpw@sgi.com>
Date:   Mon Jan 16 15:18:48 2012 -0600

    x86/UV2: Fix BAU destination timeout initialization

    commit d059f9fa84a30e04279c6ff615e9e2cf3b260191 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>

commit 6c8e76e158a9bc849ec946ab030595e06ad89210
Author: Alexander Aring <a.aring@phytec.de>
Date:   Thu Dec 8 15:43:53 2011 +0100

    I2C: OMAP: correct SYSC register offset for OMAP4

    commit 2727b1753934e154931d6b3bdf20c9b2398457a2 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>

commit 06a23648ebbb532745eb85c1a381b83dd90e94af
Author: Roland Dreier <roland@purestorage.com>
Date:   Tue Dec 13 14:55:33 2011 -0800

    target: Set additional sense length field in sense data

    commit 895f3022523361e9b383cf48f51feb1f7d5e7e53 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>

commit 640bb6ec4ff89b0349d1c7cb42aa25db191b4f63
Author: Roland Dreier <roland@purestorage.com>
Date:   Tue Dec 6 10:02:09 2011 -0800

    target: Set response format in INQUIRY response

    commit ce136176fea522fc8f4c16dcae7e8ed1d890ca39 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>

commit 7b3e8a2073d9875dbdcdfec5d40ff54c8e8c418c
Author: Stratos Psomadakis <psomas@gentoo.org>
Date:   Sun Dec 4 02:23:54 2011 +0200

    sym53c8xx: Fix NULL pointer dereference in slave_destroy

    commit cced5041ed5a2d1352186510944b0ddfbdbe4c0b 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>

commit 68e6689b9b35c8a2fa73e00947238d2c5cb0387c
Author: Lin Ming <ming.m.lin@intel.com>
Date:   Tue Dec 13 09:36:03 2011 +0800

    ACPI: processor: fix acpi_get_cpuid for UP processor

    commit d640113fe80e45ebd4a5b420b220d3f6bf37f682 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>

commit 55bd02eb4c6e40c2870aee19c5e36d1a85713be8
Author: Lin Ming <ming.m.lin@intel.com>
Date:   Tue Nov 29 22:13:35 2011 +0800

    ACPICA: Put back the call to acpi_os_validate_address

    commit da4d8b287abe783d30e968155614531a0937d090 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>

commit 0076d42a31bac7853d3c77c3858d2685f6fe8f2d
Author: Kurt Garloff <kurt@garloff.de>
Date:   Tue Jan 17 04:21:49 2012 -0500

    ACPI, ia64: Use SRAT table rev to use 8bit or 16/32bit PXM fields (ia64)

    commit 9f10f6a520deb3639fac78d81151a3ade88b4e7f 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>

commit ef9a04d5b336853aeb3f3975c4e52b07c1c4d3ec
Author: Kurt Garloff <kurt@garloff.de>
Date:   Tue Jan 17 04:20:31 2012 -0500

    ACPI, x86: Use SRAT table rev to use 8bit or 32bit PXM fields (x86/x86-64)

    commit cd298f60a2451a16e0f077404bf69b62ec868733 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>

commit 643147c50fde7eb0456953f468cc277d621f629e
Author: Kurt Garloff <kurt@garloff.de>
Date:   Tue Jan 17 04:18:02 2012 -0500

    ACPI: Store SRAT table revision

    commit 8df0eb7c9d96f9e82f233ee8b74e0f0c8471f868 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>

commit e26a6033d0d0183e613a1ae5eafefd3baf7f3e6c
Author: Shaohua Li <shaohua.li@intel.com>
Date:   Tue Jan 10 15:48:19 2012 -0800

    intel_idle: fix API misuse

    commit 39a74fdedd1c1461d6fb6d330b5266886513c98f 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>

commit 57700d3c569071c4c43f220de637461850d027a1
Author: Thomas Renninger <trenn@suse.de>
Date:   Sun Dec 4 22:17:29 2011 +0100

    intel idle: Make idle driver more robust

    commit 5c2a9f06a9cd7194f884cdc88144866235dec07d upstream.

    kvm -cpu host passes the original cpuid info to the guest.

    Latest kvm version seem to return true for mwait_leaf cpuid
    function on recent Intel CPUs. But it does not return mwait
    C-states (mwait_substates), instead zero is returned.

    While real CPUs seem to always return non-zero values, the intel
    idle driver should not get active in kvm (mwait_substates == 0)
    case and bail out.
    Otherwise a Null pointer exception will happen later when the
    cpuidle subsystem tries to get active:
    [0.984807] BUG: unable to handle kernel NULL pointer dereference at (null)
    [0.984807] IP: [<(null)>] (null)
    ...
    [0.984807][<ffffffff8143cf34>] ? cpuidle_idle_call+0xb4/0x340
    [0.984807][<ffffffff8159e7bc>] ? __atomic_notifier_call_chain+0x4c/0x70
    [0.984807][<ffffffff81001198>] ? cpu_idle+0x78/0xd0

    Reference:
    https://bugzilla.novell.com/show_bug.cgi?id=726296

    Signed-off-by: Thomas Renninger <trenn@suse.de>
    CC: Bruno Friedmann <bruno@ioda-net.ch>
    Signed-off-by: Len Brown <len.brown@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit db52a757b355ec71670b4b0f85cd2d6f28306a79
Author: David Henningsson <david.henningsson@canonical.com>
Date:   Mon Jan 16 10:52:20 2012 +0100

    ALSA: HDA: Fix internal microphone on Dell Studio 16 XPS 1645

    commit ffe535edb9a9c5b4d5fe03dfa3d89a1495580f1b upstream.

    More than one user reports that changing the model from "both" to
    "dmic" makes their Internal Mic work.

    Tested-by: Martin Ling <martin-launchpad@earth.li>
    BugLink: https://bugs.launchpad.net/bugs/795823
    Signed-off-by: David Henningsson <david.henningsson@canonical.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit cb86f0a0920b63b179d2fa653c6c851db27d069a
Author: Clemens Ladisch <clemens@ladisch.de>
Date:   Sat Jan 14 16:42:24 2012 +0100

    ALSA: virtuoso: Xonar DS: fix polarity of front output

    commit f0e48b6bd4e407459715240cd241ddb6b89bdf81 upstream.

    The two DACs for the front output and the surround/center/LFE/back
    outputs are wired up out of phase, so when channels are duplicated,
    their sound can cancel out each other and result in a weaker bass
    response.  To fix this, reverse the polarity of the neutron flow to
    the front output.

    Reported-any-tested-by: Daniel Hill <daniel@enemyplanet.geek.nz>
    Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit c8fec258e5d1c35712795641350cc78da4334629
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Tue Jan 17 15:21:19 2012 -0800

    proc: clean up and fix /proc/<pid>/mem handling

    commit e268337dfe26dfc7efd422a804dbb27977a3cccc upstream.

    Jüri Aedla reported that the /proc/<pid>/mem handling really isn't very
    robust, and it also doesn't match the permission checking of any of the
    other related files.

    This changes it to do the permission checks at open time, and instead of
    tracking the process, it tracks the VM at the time of the open.  That
    simplifies the code a lot, but does mean that if you hold the file
    descriptor open over an execve(), you'll continue to read from the _old_
    VM.

    That is different from our previous behavior, but much simpler.  If
    somebody actually finds a load where this matters, we'll need to revert
    this commit.

    I suspect that nobody will ever notice - because the process mapping
    addresses will also have changed as part of the execve.  So you cannot
    actually usefully access the fd across a VM change simply because all
    the offsets for IO would have changed too.

    Reported-by: Jüri Aedla <asd@ut.ee>
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 12c3b3ac1e8004616b30aec6acee1bb91badeb99
Author: Paolo Bonzini <pbonzini@redhat.com>
Date:   Thu Jan 12 16:01:29 2012 +0100

    dm: do not forward ioctls from logical volumes to the underlying device

    commit ec8013beddd717d1740cfefb1a9b900deef85462 upstream.

    A logical volume can map to just part of underlying physical volume.
    In this case, it must be treated like a partition.

    Based on a patch from Alasdair G Kergon.

    Cc: Alasdair G Kergon <agk@redhat.com>
    Cc: dm-devel@redhat.com
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 8bd8442fec18284924e17a0fa8ef89d98b0a6d71
Author: Paolo Bonzini <pbonzini@redhat.com>
Date:   Thu Jan 12 16:01:28 2012 +0100

    block: fail SCSI passthrough ioctls on partition devices

    commit 0bfc96cb77224736dfa35c3c555d37b3646ef35e upstream.

    [ Changes with respect to 3.3: return -ENOTTY from scsi_verify_blk_ioctl
      and -ENOIOCTLCMD from sd_compat_ioctl. ]

    Linux allows executing the SG_IO ioctl on a partition or LVM volume, and
    will pass the command to the underlying block device.  This is
    well-known, but it is also a large security problem when (via Unix
    permissions, ACLs, SELinux or a combination thereof) a program or user
    needs to be granted access only to part of the disk.

    This patch lets partitions forward a small set of harmless ioctls;
    others are logged with printk so that we can see which ioctls are
    actually sent.  In my tests only CDROM_GET_CAPABILITY actually occurred.
    Of course it was being sent to a (partition on a) hard disk, so it would
    have failed with ENOTTY and the patch isn't changing anything in
    practice.  Still, I'm treating it specially to avoid spamming the logs.

    In principle, this restriction should include programs running with
    CAP_SYS_RAWIO.  If for example I let a program access /dev/sda2 and
    /dev/sdb, it still should not be able to read/write outside the
    boundaries of /dev/sda2 independent of the capabilities.  However, for
    now programs with CAP_SYS_RAWIO will still be allowed to send the
    ioctls.  Their actions will still be logged.

    This patch does not affect the non-libata IDE driver.  That driver
    however already tests for bd != bd->bd_contains before issuing some
    ioctl; it could be restricted further to forbid these ioctls even for
    programs running with CAP_SYS_ADMIN/CAP_SYS_RAWIO.

    Cc: linux-scsi@vger.kernel.org
    Cc: Jens Axboe <axboe@kernel.dk>
    Cc: James Bottomley <JBottomley@parallels.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    [ Make it also print the command name when warning - Linus ]
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 3b8373b85c761b2a12bdaf9fcee4c7a3eefa8459
Author: Paolo Bonzini <pbonzini@redhat.com>
Date:   Thu Jan 12 16:01:27 2012 +0100

    block: add and use scsi_blk_cmd_ioctl

    commit 577ebb374c78314ac4617242f509e2f5e7156649 upstream.

    Introduce a wrapper around scsi_cmd_ioctl that takes a block device.

    The function will then be enhanced to detect partition block devices
    and, in that case, subject the ioctls to whitelisting.

    Cc: linux-scsi@vger.kernel.org
    Cc: Jens Axboe <axboe@kernel.dk>
    Cc: James Bottomley <JBottomley@parallels.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 3ec3f83aee534f732fd7012ff6c04776952e47fd
Author: Martin Schwidefsky <schwidefsky@de.ibm.com>
Date:   Thu Dec 15 14:56:10 2011 +0100

    fix cputime overflow in uptime_proc_show

    commit c3e0ef9a298e028a82ada28101ccd5cf64d209ee upstream.

    For 32-bit architectures using standard jiffies the idletime calculation
    in uptime_proc_show will quickly overflow. It takes (2^32 / HZ) seconds
    of idle-time, or e.g. 12.45 days with no load on a quad-core with HZ=1000.
    Switch to 64-bit calculations.

    Cc: Michael Abbott <michael.abbott@diamond.ac.uk>
    Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 277a05f83af8c82291cf5f2ad0c2dd1aa6f29de7
Author: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Date:   Fri Dec 23 15:41:00 2011 +0100

    HID: multitouch: add support for 3M 32"

    commit c4fad877cd0efb51d8180ae2eaa791c99c92051c upstream.

    Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
    Acked-by: Henrik Rydberg <rydberg@euromail.se>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 1628de01ac388c9104ddc2816491ff591dfe28a8
Author: Benjamin Tissoires <benjamin.tissoires@enac.fr>
Date:   Wed Nov 23 10:54:33 2011 +0100

    HID: multitouch: add support for the MSI Windpad 110W

    commit 66f06127f34ad6e8a1b24a2c03144b694d19f99f upstream.

    Just another eGalax device.
    Please note that adding this device to have_special_driver
    in hid-core.c is not required anymore.

    Signed-off-by: Benjamin Tissoires <benjamin.tissoires@enac.fr>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit a92035b63540e2d47326540dc38625283143b770
Author: Marek Vasut <marek.vasut@gmail.com>
Date:   Wed Nov 23 10:54:32 2011 +0100

    HID: multitouch: Add egalax ID for Acer Iconia W500

    commit bb9ff21072043634f147c05ac65dbf8185d4af6d upstream.

    This patch adds USB ID for the touchpanel in Acer Iconia W500. The panel
    supports up to five fingers, therefore the need for a new addition of panel
    types.

    Signed-off-by: Marek Vasut <marek.vasut@gmail.com>
    Signed-off-by: Benjamin Tissoires <benjamin.tissoires@enac.fr>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 369f7532bcaa78eb3919306e1ff997aa14bbfbbb
Author: Benjamin Tissoires <benjamin.tissoires@enac.fr>
Date:   Wed Nov 23 10:54:31 2011 +0100

    HID: multitouch: cleanup with eGalax PID definitions

    commit e36f690b37945e0a9bb1554e1546eeec93f7d1f6 upstream.

    This is just a renaming of USB_DEVICE_ID_DWAV_EGALAX_MULTITOUCH{N}
    to USB_DEVICE_ID_DWAV_EGALAX_MULTITOUCH_{PID} to handle more eGalax
    devices.

    Signed-off-by: Benjamin Tissoires <benjamin.tissoires@enac.fr>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 242d5138b1a8f4a2519518027fff884fce3eeba4
Author: Chris Bagwell <chris@cnpbagwell.com>
Date:   Wed Nov 23 10:54:27 2011 +0100

    HID: hid-multitouch - add another eGalax id

    commit 1fd8f047490dd0ec4e4db710fcbc1bd4798d944c upstream.

    This allows ASUS Eee Slate touchscreens to work.

    Signed-off-by: Chris Bagwell <chris@cnpbagwell.com>
    Reviewed-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit c0ab420c6822529fa5aba05668e1e983b065460f
Author: Nick Bowler <nbowler@elliptictech.com>
Date:   Tue Nov 8 12:12:45 2011 +0000

    ah: Read nexthdr value before overwriting it in ahash input callback.

    commit b7ea81a58adc123a4e980cb0eff9eb5c144b5dc7 upstream.

    The AH4/6 ahash input callbacks read out the nexthdr field from the AH
    header *after* they overwrite that header.  This is obviously not going
    to end well.  Fix it up.

    Signed-off-by: Nick Bowler <nbowler@elliptictech.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit d253520a7b2c2223fb4f704f06d10f2c547bdeef
Author: Nick Bowler <nbowler@elliptictech.com>
Date:   Tue Nov 8 12:12:44 2011 +0000

    ah: Correctly pass error codes in ahash output callback.

    commit 069294e813ed5f27f82613b027609bcda5f1b914 upstream.

    The AH4/6 ahash output callbacks pass nexthdr to xfrm_output_resume
    instead of the error code.  This appears to be a copy+paste error from
    the input case, where nexthdr is expected.  This causes the driver to
    continuously add AH headers to the datagram until either an allocation
    fails and the packet is dropped or the ahash driver hits a synchronous
    fallback and the resulting monstrosity is transmitted.

    Correct this issue by simply passing the error code unadulterated.

    Signed-off-by: Nick Bowler <nbowler@elliptictech.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 8039a47e67451b8efd6100c4a7f27829fc2d8edd
Author: Miklos Szeredi <miklos@szeredi.hu>
Date:   Tue Jan 10 18:22:25 2012 +0100

    fix shrink_dcache_parent() livelock

    commit eaf5f9073533cde21c7121c136f1c3f072d9cf59 upstream.

    Two (or more) concurrent calls of shrink_dcache_parent() on the same dentry may
    cause shrink_dcache_parent() to loop forever.

    Here's what appears to happen:

    1 - CPU0: select_parent(P) finds C and puts it on dispose list, returns 1

    2 - CPU1: select_parent(P) locks P->d_lock

    3 - CPU0: shrink_dentry_list() locks C->d_lock
       dentry_kill(C) tries to lock P->d_lock but fails, unlocks C->d_lock

    4 - CPU1: select_parent(P) locks C->d_lock,
             moves C from dispose list being processed on CPU0 to the new
    dispose list, returns 1

    5 - CPU0: shrink_dentry_list() finds dispose list empty, returns

    6 - Goto 2 with CPU0 and CPU1 switched

    Basically select_parent() steals the dentry from shrink_dentry_list() and thinks
    it found a new one, causing shrink_dentry_list() to think it's making progress
    and loop over and over.

    One way to trigger this is to make udev calls stat() on the sysfs file while it
    is going away.

    Having a file in /lib/udev/rules.d/ with only this one rule seems to the trick:

    ATTR{vendor}=="0x8086", ATTR{device}=="0x10ca", ENV{PCI_SLOT_NAME}="%k", ENV{MATCHADDR}="$attr{address}", RUN+="/bin/true"

    Then execute the following loop:

    while true; do
            echo -bond0 > /sys/class/net/bonding_masters
            echo +bond0 > /sys/class/net/bonding_masters
            echo -bond1 > /sys/class/net/bonding_masters
            echo +bond1 > /sys/class/net/bonding_masters
    done

    One fix would be to check all callers and prevent concurrent calls to
    shrink_dcache_parent().  But I think a better solution is to stop the
    stealing behavior.

    This patch adds a new dentry flag that is set when the dentry is added to the
    dispose list.  The flag is cleared in dentry_lru_del() in case the dentry gets a
    new reference just before being pruned.

    If the dentry has this flag, select_parent() will skip it and let
    shrink_dentry_list() retry pruning it.  With select_parent() skipping those
    dentries there will not be the appearance of progress (new dentries found) when
    there is none, hence shrink_dcache_parent() will not loop forever.

    Set the flag is also set in prune_dcache_sb() for consistency as suggested by
    Linus.

    Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 087bc746ef05511c3e416846a8eae4588756462c
Author: Haogang Chen <haogangchen@gmail.com>
Date:   Tue Nov 29 18:32:25 2011 -0300

    uvcvideo: Fix integer overflow in uvc_ioctl_ctrl_map()

    commit 806e23e95f94a27ee445022d724060b9b45cb64a upstream.

    There is a potential integer overflow in uvc_ioctl_ctrl_map(). When a
    large xmap->menu_count is passed from the userspace, the subsequent call
    to kmalloc() will allocate a buffer smaller than expected.
    map->menu_count and map->menu_info would later be used in a loop (e.g.
    in uvc_query_v4l2_ctrl), which leads to out-of-bound access.

    The patch checks the ioctl argument and returns -EINVAL for zero or too
    large values in xmap->menu_count.

    Signed-off-by: Haogang Chen <haogangchen@gmail.com>
    [laurent.pinchart@ideasonboard.com Prevent excessive memory consumption]
    Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 9d3f99878bf33d36739bd772c7dafcb1f71387fb
Author: David Daney <david.daney@cavium.com>
Date:   Mon Dec 19 17:42:42 2011 -0800

    recordmcount: Fix handling of elf64 big-endian objects.

    commit 2e885057b7f75035f0b85e02f737891482815a81 upstream.

    In ELF64, the sh_flags field is 64-bits wide.  recordmcount was
    erroneously treating it as a 32-bit wide field.  For little endian
    objects this works because the flags of interest (SHF_EXECINSTR)
    reside in the lower 32 bits of the word, and you get the same result
    with either a 32-bit or 64-bit read.  Big endian objects on the
    other hand do not work at all with this error.

    The fix:  Correctly treat sh_flags as 64-bits wide in elf64 objects.

    The symptom I observed was that my
    __start_mcount_loc..__stop_mcount_loc was empty even though ftrace
    function tracing was enabled.

    Link: http://lkml.kernel.org/r/1324345362-12230-1-git-send-email-ddaney.cavm@gmail.com

    Signed-off-by: David Daney <david.daney@cavium.com>
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 15274414badc6ef0a893454e7102f3753f2c1ccd
Author: Jack Steiner <steiner@sgi.com>
Date:   Fri Jan 6 13:19:00 2012 -0600

    x86, UV: Update Boot messages for SGI UV2 platform

    commit da517a08ac5913cd80ce3507cddd00f2a091b13c upstream.

    SGI UV systems print a message during boot:

    	UV: Found <num> blades

    Due to packaging changes, the blade count is not accurate for
    on the next generation of the platform. This patch corrects the
    count.

    Signed-off-by: Jack Steiner <steiner@sgi.com>
    Link: http://lkml.kernel.org/r/20120106191900.GA19772@sgi.com
    Signed-off-by: Ingo Molnar <mingo@elte.hu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit a9680ece8e3874382fb2db1b8e247452c306b735
Author: Miklos Szeredi <mszeredi@suse.cz>
Date:   Thu Jan 12 17:59:46 2012 +0100

    fsnotify: don't BUG in fsnotify_destroy_mark()

    commit fed474857efbed79cd390d0aee224231ca718f63 upstream.

    Removing the parent of a watched file results in "kernel BUG at
    fs/notify/mark.c:139".

    To reproduce

      add "-w /tmp/audit/dir/watched_file" to audit.rules
      rm -rf /tmp/audit/dir

    This is caused by fsnotify_destroy_mark() being called without an
    extra reference taken by the caller.

    Reported by Francesco Cosoleto here:

      https://bugzilla.novell.com/show_bug.cgi?id=689860

    Fix by removing the BUG_ON and adding a comment about not accessing mark after
    the iput.

    Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 46a5392ffcb492b8042776ce44b5cc1c07be1b23
Author: Sasha Levin <levinsasha928@gmail.com>
Date:   Fri Nov 18 12:14:49 2011 +0200

    nfsd: Fix oops when parsing a 0 length export

    commit b2ea70afade7080360ac55c4e64ff7a5fafdb67b upstream.

    expkey_parse() oopses when handling a 0 length export. This is easily
    triggerable from usermode by writing 0 bytes into
    '/proc/[proc id]/net/rpc/nfsd.fh/channel'.

    Below is the log:

    [ 1402.286893] BUG: unable to handle kernel paging request at ffff880077c49fff
    [ 1402.287632] IP: [<ffffffff812b4b99>] expkey_parse+0x28/0x2e1
    [ 1402.287632] PGD 2206063 PUD 1fdfd067 PMD 1ffbc067 PTE 8000000077c49160
    [ 1402.287632] Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
    [ 1402.287632] CPU 1
    [ 1402.287632] Pid: 20198, comm: trinity Not tainted 3.2.0-rc2-sasha-00058-gc65cd37 #6
    [ 1402.287632] RIP: 0010:[<ffffffff812b4b99>]  [<ffffffff812b4b99>] expkey_parse+0x28/0x2e1
    [ 1402.287632] RSP: 0018:ffff880077f0fd68  EFLAGS: 00010292
    [ 1402.287632] RAX: ffff880077c49fff RBX: 00000000ffffffea RCX: 0000000001043400
    [ 1402.287632] RDX: 0000000000000000 RSI: ffff880077c4a000 RDI: ffffffff82283de0
    [ 1402.287632] RBP: ffff880077f0fe18 R08: 0000000000000001 R09: ffff880000000000
    [ 1402.287632] R10: 0000000000000000 R11: 0000000000000001 R12: ffff880077c4a000
    [ 1402.287632] R13: ffffffff82283de0 R14: 0000000001043400 R15: ffffffff82283de0
    [ 1402.287632] FS:  00007f25fec3f700(0000) GS:ffff88007d400000(0000) knlGS:0000000000000000
    [ 1402.287632] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
    [ 1402.287632] CR2: ffff880077c49fff CR3: 0000000077e1d000 CR4: 00000000000406e0
    [ 1402.287632] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    [ 1402.287632] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
    [ 1402.287632] Process trinity (pid: 20198, threadinfo ffff880077f0e000, task ffff880077db17b0)
    [ 1402.287632] Stack:
    [ 1402.287632]  ffff880077db17b0 ffff880077c4a000 ffff880077f0fdb8 ffffffff810b411e
    [ 1402.287632]  ffff880000000000 ffff880077db17b0 ffff880077c4a000 ffffffff82283de0
    [ 1402.287632]  0000000001043400 ffffffff82283de0 ffff880077f0fde8 ffffffff81111f63
    [ 1402.287632] Call Trace:
    [ 1402.287632]  [<ffffffff810b411e>] ? lock_release+0x1af/0x1bc
    [ 1402.287632]  [<ffffffff81111f63>] ? might_fault+0x97/0x9e
    [ 1402.287632]  [<ffffffff81111f1a>] ? might_fault+0x4e/0x9e
    [ 1402.287632]  [<ffffffff81a8bcf2>] cache_do_downcall+0x3e/0x4f
    [ 1402.287632]  [<ffffffff81a8c950>] cache_write.clone.16+0xbb/0x130
    [ 1402.287632]  [<ffffffff81a8c9df>] ? cache_write_pipefs+0x1a/0x1a
    [ 1402.287632]  [<ffffffff81a8c9f8>] cache_write_procfs+0x19/0x1b
    [ 1402.287632]  [<ffffffff8118dc54>] proc_reg_write+0x8e/0xad
    [ 1402.287632]  [<ffffffff8113fe81>] vfs_write+0xaa/0xfd
    [ 1402.287632]  [<ffffffff8114142d>] ? fget_light+0x35/0x9e
    [ 1402.287632]  [<ffffffff8113ff8b>] sys_write+0x48/0x6f
    [ 1402.287632]  [<ffffffff81bbdb92>] system_call_fastpath+0x16/0x1b
    [ 1402.287632] Code: c0 c9 c3 55 48 63 d2 48 89 e5 48 8d 44 32 ff 41 57 41 56 41 55 41 54 53 bb ea ff ff ff 48 81 ec 88 00 00 00 48 89 b5 58 ff ff ff
    [ 1402.287632]  38 0a 0f 85 89 02 00 00 c6 00 00 48 8b 3d 44 4a e5 01 48 85
    [ 1402.287632] RIP  [<ffffffff812b4b99>] expkey_parse+0x28/0x2e1
    [ 1402.287632]  RSP <ffff880077f0fd68>
    [ 1402.287632] CR2: ffff880077c49fff
    [ 1402.287632] ---[ end trace 368ef53ff773a5e3 ]---

    Cc: "J. Bruce Fields" <bfields@fieldses.org>
    Cc: Neil Brown <neilb@suse.de>
    Cc: linux-nfs@vger.kernel.org
    Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit a141a5eb3ab45131cb168e7a561d662722b43ec3
Author: J. Bruce Fields <bfields@redhat.com>
Date:   Tue Nov 29 17:00:26 2011 -0500

    svcrpc: avoid memory-corruption on pool shutdown

    commit b4f36f88b3ee7cf26bf0be84e6c7fc15f84dcb71 upstream.

    Socket callbacks use svc_xprt_enqueue() to add an xprt to a
    pool->sp_sockets list.  In normal operation a server thread will later
    come along and take the xprt off that list.  On shutdown, after all the
    threads have exited, we instead manually walk the sv_tempsocks and
    sv_permsocks lists to find all the xprt's and delete them.

    So the sp_sockets lists don't really matter any more.  As a result,
    we've mostly just ignored them and hoped they would go away.

    Which has gotten us into trouble; witness for example ebc63e531cc6
    "svcrpc: fix list-corrupting race on nfsd shutdown", the result of Ben
    Greear noticing that a still-running svc_xprt_enqueue() could re-add an
    xprt to an sp_sockets list just before it was deleted.  The fix was to
    remove it from the list at the end of svc_delete_xprt().  But that only
    made corruption less likely--I can see nothing that prevents a
    svc_xprt_enqueue() from adding another xprt to the list at the same
    moment that we're removing this xprt from the list.  In fact, despite
    the earlier xpo_detach(), I don't even see what guarantees that
    svc_xprt_enqueue() couldn't still be running on this xprt.

    So, instead, note that svc_xprt_enqueue() essentially does:
    	lock sp_lock
    		if XPT_BUSY unset
    			add to sp_sockets
    	unlock sp_lock

    So, if we do:

    	set XPT_BUSY on every xprt.
    	Empty every sp_sockets list, under the sp_socks locks.

    Then we're left knowing that the sp_sockets lists are all empty and will
    stay that way, since any svc_xprt_enqueue() will check XPT_BUSY under
    the sp_lock and see it set.

    And *then* we can continue deleting the xprt's.

    (Thanks to Jeff Layton for being correctly suspicious of this code....)

    Cc: Ben Greear <greearb@candelatech.com>
    Cc: Jeff Layton <jlayton@redhat.com>
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 7df22768c0af8769d805f6db21144d71d91fe13d
Author: J. Bruce Fields <bfields@redhat.com>
Date:   Tue Nov 29 11:35:35 2011 -0500

    svcrpc: destroy server sockets all at once

    commit 2fefb8a09e7ed251ae8996e0c69066e74c5aa560 upstream.

    There's no reason I can see that we need to call sv_shutdown between
    closing the two lists of sockets.

    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit b09577ca6680033a4315e2f5cb3a95ebbb8dea79
Author: J. Bruce Fields <bfields@redhat.com>
Date:   Thu Dec 22 18:22:49 2011 -0700

    svcrpc: fix double-free on shutdown of nfsd after changing pool mode

    commit 61c8504c428edcebf23b97775a129c5b393a302b upstream.

    The pool_to and to_pool fields of the global svc_pool_map are freed on
    shutdown, but are initialized in nfsd startup only in the
    SVC_POOL_PERCPU and SVC_POOL_PERNODE cases.

    They *are* initialized to zero on kernel startup.  So as long as you use
    only SVC_POOL_GLOBAL (the default), this will never be a problem.

    You're also OK if you only ever use SVC_POOL_PERCPU or SVC_POOL_PERNODE.

    However, the following sequence events leads to a double-free:

    	1. set SVC_POOL_PERCPU or SVC_POOL_PERNODE
    	2. start nfsd: both fields are initialized.
    	3. shutdown nfsd: both fields are freed.
    	4. set SVC_POOL_GLOBAL
    	5. start nfsd: the fields are left untouched.
    	6. shutdown nfsd: now we try to free them again.

    Step 4 is actually unnecessary, since (for some bizarre reason), nfsd
    automatically resets the pool mode to SVC_POOL_GLOBAL on shutdown.

    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit adc0186cfa38e2736048a638681db511e65e51fd
Author: Steven Rostedt <srostedt@redhat.com>
Date:   Fri Jan 13 17:53:40 2012 -0500

    kconfig/streamline-config.pl: Fix parsing Makefile with variables

    commit 364212fddaaa60c5a64f67a0f5624ad996ecc8a0 upstream.

    Thomas Lange reported that when he did a 'make localmodconfig', his
    config was missing the brcmsmac driver, even though he had the module
    loaded.

    Looking into this, I found the file:
    drivers/net/wireless/brcm80211/brcmsmac/Makefile
    had the following in the Makefile:

    MODULEPFX := brcmsmac

    obj-$(CONFIG_BRCMSMAC)  += $(MODULEPFX).o

    The way streamline-config.pl works, is parsing all the
     obj-$(CONFIG_FOO) += foo.o
    lines to find that CONFIG_FOO belongs to the module foo.ko.

    But in this case, the brcmsmac.o was not used, but a variable in its place.

    By changing streamline-config.pl to remember defined variables in Makefiles
    and substituting them when they are used in the obj-X lines, allows
    Thomas (and others) to have their brcmsmac module stay configured
    when it is loaded and running "make localmodconfig".

    Reported-by: Thomas Lange <thomas-lange2@gmx.de>
    Tested-by: Thomas Lange <thomas-lange2@gmx.de>
    Cc: Arend van Spriel <arend@broadcom.com>
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit e5303c25bfacd745f6c6b99a2604ef4e11926c34
Author: Steven Rostedt <srostedt@redhat.com>
Date:   Fri Jan 13 17:50:39 2012 -0500

    kconfig/streamline-config.pl: Simplify backslash line concatination

    commit d060d963e88f3e990cec2fe5214de49de9a49eca upstream.

    Simplify the way lines ending with backslashes (continuation) in Makefiles
    is parsed. This is needed to implement a necessary fix.

    Tested-by: Thomas Lange <thomas-lange2@gmx.de>
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 065449fd56d2f75cc943a6d501b292f6b0e40325
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Thu Jan 5 02:27:57 2012 -0300

    V4L/DVB: v4l2-ioctl: integer overflow in video_usercopy()

    commit 6c06108be53ca5e94d8b0e93883d534dd9079646 upstream.

    If ctrls->count is too high the multiplication could overflow and
    array_size would be lower than expected.  Mauro and Hans Verkuil
    suggested that we cap it at 1024.  That comes from the maximum
    number of controls with lots of room for expantion.

    $ grep V4L2_CID include/linux/videodev2.h | wc -l
    211

    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit b1830247c9927d7d2ca17c9f84908fc130051792
Author: Alexander Elbs <alex@segv.de>
Date:   Tue Jan 3 23:26:53 2012 -0500

    mmc: sd: Fix SDR12 timing regression

    commit dd8df17fe83483d7ea06ff229895e35a42071599 upstream.

    This patch fixes a failure to recognize SD cards reported on a Dell
    Vostro with O2 Micro SD card reader.  Patch 49c468f ("mmc: sd: add
    support for uhs bus speed mode selection") caused the problem, by
    setting the SDHCI_CTRL_HISPD flag even for legacy timings.

    Signed-off-by: Alexander Elbs <alex@segv.de>
    Acked-by: Philip Rakity <prakity@marvell.com>
    Acked-by: Arindam Nath <arindam.nath@amd.com>
    Signed-off-by: Chris Ball <cjb@laptop.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 62a0e438f7275e845bfbcccd6e641e07d4b89182
Author: Aaron Lu <aaron.lu@amd.com>
Date:   Wed Dec 28 11:11:12 2011 +0800

    mmc: sdhci: Fix tuning timer incorrect setting when suspending host

    commit c6ced0db08010ed75df221a2946c5228454b38d5 upstream.

    When suspending host, the tuning timer shoule be deactivated.
    And the HOST_NEEDS_TUNING flag should be set after tuning timer is
    deactivated.

    Signed-off-by: Philip Rakity <prakity@marvell.com>
    Signed-off-by: Aaron Lu <aaron.lu@amd.com>
    Acked-by: Adrian Hunter <adrian.hunter@intel.com>
    Signed-off-by: Chris Ball <cjb@laptop.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 1cfbbb9ba574157c9f2312d3267762fdde0bfc59
Author: Girish K S <girish.shivananjappa@linaro.org>
Date:   Thu Dec 15 17:27:42 2011 +0530

    mmc: core: Fix voltage select in DDR mode

    commit 913047e9e5787a90696533a9f109552b7694ecc9 upstream.

    This patch fixes the wrong comparison before setting the interface
    voltage in DDR mode.

    The assignment to the variable ddr before comaprison is either
    ddr = MMC_1_2V_DDR_MODE; or ddr == MMC_1_8V_DDR_MODE. But the comparison
    is done with the extended csd value if ddr == EXT_CSD_CARD_TYPE_DDR_1_2V.

    Signed-off-by: Girish K S <girish.shivananjappa@linaro.org>
    Acked-by: Subhash Jadavani <subhashj@codeaurora.org>
    Acked-by: Philip Rakity <prakity@marvell.com>
    Signed-off-by: Chris Ball <cjb@laptop.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit fcf53a1ed4225c1f23997ef02f2770a39e73c515
Author: Jean Delvare <khali@linux-fr.org>
Date:   Thu Jan 12 20:32:03 2012 +0100

    i2c: Fix error value returned by several bus drivers

    commit 7c1f59c9d5caf3a84f35549b5d58f3c055a68da5 upstream.

    When adding checks for ACPI resource conflicts to many bus drivers,
    not enough attention was paid to the error paths, and for several
    drivers this causes 0 to be returned on error in some cases. Fix this
    by properly returning a non-zero value on every error.

    Signed-off-by: Jean Delvare <khali@linux-fr.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 8aee2e296d19910d8ad4c676970f0055abc5b5e5
Author: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Date:   Tue Jan 10 19:32:30 2012 +0200

    UBIFS: fix debugging messages

    commit d34315da9146253351146140ea4b277193ee5e5f upstream.

    Patch 56e46742e846e4de167dde0e1e1071ace1c882a5 broke UBIFS debugging messages:
    before that commit when UBIFS debugging was enabled, users saw few useful
    debugging messages after mount. However, that patch turned 'dbg_msg()' into
    'pr_debug()', so to enable the debugging messages users have to enable them
    first via /sys/kernel/debug/dynamic_debug/control, which is very impractical.

    This commit makes 'dbg_msg()' to use 'printk()' instead of 'pr_debug()', just
    as it was before the breakage.

    Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit d8ece1b43acdec47c0823aa306910239754ef9e9
Author: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Date:   Tue Jan 10 19:32:30 2012 +0200

    UBI: fix debugging messages

    commit 72f0d453d81d35087b1d3ad7c8285628c2be6e1d upstream.

    Patch ab50ff684707031ed4bad2fdd313208ae392e5bb broke UBI debugging messages:
    before that commit when UBI debugging was enabled, users saw few useful
    debugging messages after attaching an MTD device. However, that patch turned
    'dbg_msg()' into 'pr_debug()', so to enable the debugging messages users have
    to enable them first via /sys/kernel/debug/dynamic_debug/control, which is
    very impractical.

    This commit makes 'dbg_msg()' to use 'printk()' instead of 'pr_debug()', just
    as it was before the breakage.

    Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 028bb43eac25b7423198b7e22cfea9bd3e870e24
Author: Richard Weinberger <richard@nod.at>
Date:   Fri Jan 13 15:07:40 2012 +0100

    UBI: fix nameless volumes handling

    commit 4a59c797a18917a5cf3ff7ade296b46134d91e6a upstream.

    Currently it's possible to create a volume without a name. E.g:
    ubimkvol -n 32 -s 2MiB -t static /dev/ubi0 -N ""

    After that vtbl_check() will always fail because it does not permit
    empty strings.

    Signed-off-by: Richard Weinberger <richard@nod.at>
    Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 59c43b2c3ef410e585646825ea552507cd51ccb1
Author: Ludwig Nussel <ludwig.nussel@suse.de>
Date:   Tue Nov 15 14:46:46 2011 -0800

    x86: Fix mmap random address range

    commit 9af0c7a6fa860698d080481f24a342ba74b68982 upstream.

    On x86_32 casting the unsigned int result of get_random_int() to
    long may result in a negative value.  On x86_32 the range of
    mmap_rnd() therefore was -255 to 255.  The 32bit mode on x86_64
    used 0 to 255 as intended.

    The bug was introduced by 675a081 ("x86: unify mmap_{32|64}.c")
    in January 2008.

    Signed-off-by: Ludwig Nussel <ludwig.nussel@suse.de>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: harvey.harrison@gmail.com
    Cc: "H. Peter Anvin" <hpa@zytor.com>
    Cc: Harvey Harrison <harvey.harrison@gmail.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Link: http://lkml.kernel.org/r/201111152246.pAFMklOB028527@wpaz5.hot.corp.google.com
    Signed-off-by: Ingo Molnar <mingo@elte.hu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit ea1c62778121f6ece5e0120250716b45e204cb13
Author: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Date:   Thu Jan 12 17:17:44 2012 -0800

    memcg: add mem_cgroup_replace_page_cache() to fix LRU issue

    commit ab936cbcd02072a34b60d268f94440fd5cf1970b upstream.

    Commit ef6a3c6311 ("mm: add replace_page_cache_page() function") added a
    function replace_page_cache_page().  This function replaces a page in the
    radix-tree with a new page.  WHen doing this, memory cgroup needs to fix
    up the accounting information.  memcg need to check PCG_USED bit etc.

    In some(many?) cases, 'newpage' is on LRU before calling
    replace_page_cache().  So, memcg's LRU accounting information should be
    fixed, too.

    This patch adds mem_cgroup_replace_page_cache() and removes the old hooks.
     In that function, old pages will be unaccounted without touching
    res_counter and new page will be accounted to the memcg (of old page).
    WHen overwriting pc->mem_cgroup of newpage, take zone->lru_lock and avoid
    races with LRU handling.

    Background:
      replace_page_cache_page() is called by FUSE code in its splice() handling.
      Here, 'newpage' is replacing oldpage but this newpage is not a newly allocated
      page and may be on LRU. LRU mis-accounting will be critical for memory cgroup
      because rmdir() checks the whole LRU is empty and there is no account leak.
      If a page is on the other LRU than it should be, rmdir() will fail.

    This bug was added in March 2011, but no bug report yet.  I guess there
    are not many people who use memcg and FUSE at the same time with upstream
    kernels.

    The result of this bug is that admin cannot destroy a memcg because of
    account leak.  So, no panic, no deadlock.  And, even if an active cgroup
    exist, umount can succseed.  So no problem at shutdown.

    Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
    Acked-by: Johannes Weiner <hannes@cmpxchg.org>
    Acked-by: Michal Hocko <mhocko@suse.cz>
    Cc: Miklos Szeredi <mszeredi@suse.cz>
    Cc: Hugh Dickins <hughd@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>

commit b9e11747e1227d7ad67c5b80be4b206e4059687e
Author: Stanislaw Gruszka <sgruszka@redhat.com>
Date:   Wed Jan 11 09:26:54 2012 +0100

    mac80211: fix rx->key NULL pointer dereference in promiscuous mode

    commit 1140afa862842ac3e56678693050760edc4ecde9 upstream.

    Since:

    commit 816c04fe7ef01dd9649f5ccfe796474db8708be5
    Author: Christian Lamparter <chunkeey@googlemail.com>
    Date:   Sat Apr 30 15:24:30 2011 +0200

        mac80211: consolidate MIC failure report handling

    is possible to that we dereference rx->key == NULL when driver set
    RX_FLAG_MMIC_STRIPPED and not RX_FLAG_IV_STRIPPED and we are in
    promiscuous mode. This happen with rt73usb and rt61pci at least.

    Before the commit we always check rx->key against NULL, so I assume
    fix should be done in mac80211 (also mic_fail path has similar check).

    References:
    https://bugzilla.redhat.com/show_bug.cgi?id=769766
    http://rt2x00.serialmonkey.com/pipermail/users_rt2x00.serialmonkey.com/2012-January/004395.html

    Reported-by: Stuart D Gathman <stuart@gathman.org>
    Reported-by: Kai Wohlfahrt <kai.scorpio@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>

commit 93d150e945fdaceb9e8fe18c7b9014569123195d
Author: Larry Finger <Larry.Finger@lwfinger.net>
Date:   Wed Jan 4 20:50:47 2012 -0600

    rtl8192se: Fix BUG caused by failure to check skb allocation

    commit d90db4b12bc1b9b8a787ef28550fdb767ee25a49 upstream.

    When downloading firmware into the device, the driver fails to check the
    return when allocating an skb. When the allocation fails, a BUG can be
    generated, as seen in https://bugzilla.redhat.com/show_bug.cgi?id=771656.

    Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 982e49a7cbcca1347b701e2098431153d83c3dd2
Author: Bjorn Helgaas <bhelgaas@google.com>
Date:   Thu Jan 5 14:27:24 2012 -0700

    PNP: work around Dell 1536/1546 BIOS MMCONFIG bug that breaks USB

    commit eb31aae8cb5eb54e234ed2d857ddac868195d911 upstream.

    Some Dell BIOSes have MCFG tables that don't report the entire
    MMCONFIG area claimed by the chipset.  If we move PCI devices into
    that claimed-but-unreported area, they don't work.

    This quirk reads the AMD MMCONFIG MSRs and adds PNP0C01 resources as
    needed to cover the entire area.

    Example problem scenario:

      BIOS-e820: 00000000cfec5400 - 00000000d4000000 (reserved)
      Fam 10h mmconf [d0000000, dfffffff]
      PCI: MMCONFIG for domain 0000 [bus 00-3f] at [mem 0xd0000000-0xd3ffffff] (base 0xd0000000)
      pnp 00:0c: [mem 0xd0000000-0xd3ffffff]
      pci 0000:00:12.0: reg 10: [mem 0xffb00000-0xffb00fff]
      pci 0000:00:12.0: no compatible bridge window for [mem 0xffb00000-0xffb00fff]
      pci 0000:00:12.0: BAR 0: assigned [mem 0xd4000000-0xd40000ff]

    Reported-by: Lisa Salimbas <lisa.salimbas@canonical.com>
    Reported-by: <thuban@singularity.fr>
    Tested-by: dann frazier <dann.frazier@canonical.com>
    References: https://bugzilla.kernel.org/show_bug.cgi?id=31602
    References: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/647043
    References: https://bugzilla.redhat.com/show_bug.cgi?id=770308
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit ffdfcb4347b7f5082e6e191175d46d74c235c2c7
Author: Roberto Sassu <roberto.sassu@polito.it>
Date:   Mon Dec 19 15:57:28 2011 +0100

    ima: fix invalid memory reference

    commit 7b7e5916aa2f46e57f8bd8cb89c34620ebfda5da upstream.

    Don't free a valid measurement entry on TPM PCR extend failure.

    Signed-off-by: Roberto Sassu <roberto.sassu@polito.it>
    Signed-off-by: Mimi Zohar <zohar@us.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 808f398267e920a772c1ae07781adfb0d4d1c48a
Author: Roberto Sassu <roberto.sassu@polito.it>
Date:   Mon Dec 19 15:57:27 2011 +0100

    ima: free duplicate measurement memory

    commit 45fae7493970d7c45626ccd96d4a74f5f1eea5a9 upstream.

    Info about new measurements are cached in the iint for performance.  When
    the inode is flushed from cache, the associated iint is flushed as well.
    Subsequent access to the inode will cause the inode to be re-measured and
    will attempt to add a duplicate entry to the measurement list.

    This patch frees the duplicate measurement memory, fixing a memory leak.

    Signed-off-by: Roberto Sassu <roberto.sassu@polito.it>
    Signed-off-by: Mimi Zohar <zohar@us.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 9919fe804d613e513ef13f5eedc9e583c4429d38
Author: Ian Campbell <Ian.Campbell@citrix.com>
Date:   Wed Jan 4 09:34:49 2012 +0000

    xen/xenbus: Reject replies with payload > XENSTORE_PAYLOAD_MAX.

    commit 9e7860cee18241633eddb36a4c34c7b61d8cecbc upstream.

    Haogang Chen found out that:

     There is a potential integer overflow in process_msg() that could result
     in cross-domain attack.

     	body = kmalloc(msg->hdr.len + 1, GFP_NOIO | __GFP_HIGH);

     When a malicious guest passes 0xffffffff in msg->hdr.len, the subsequent
     call to xb_read() would write to a zero-length buffer.

     The other end of this connection is always the xenstore backend daemon
     so there is no guest (malicious or otherwise) which can do this. The
     xenstore daemon is a trusted component in the system.

     However this seem like a reasonable robustness improvement so we should
     have it.

    And Ian when read the API docs found that:
            The payload length (len field of the header) is limited to 4096
            (XENSTORE_PAYLOAD_MAX) in both directions.  If a client exceeds the
            limit, its xenstored connection will be immediately killed by
            xenstored, which is usually catastrophic from the client's point of
            view.  Clients (particularly domains, which cannot just reconnect)
            should avoid this.

    so this patch checks against that instead.

    This also avoids a potential integer overflow pointed out by Haogang Chen.

    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Cc: Haogang Chen <haogangchen@gmail.com>
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 73669debb5f508962ffcc8b632ffb2971c606e5c
Author: nagalakshmi.nandigama@lsi.com <nagalakshmi.nandigama@lsi.com>
Date:   Thu Dec 1 07:53:08 2011 +0530

    SCSI: mpt2sas : Fix for memory allocation error for large host credits

    commit aff132d95ffe14eca96cab90597cdd010b457af7 upstream.

    The amount of memory required for tracking chain buffers is rather
    large, and when the host credit count is big, memory allocation
    failure occurs inside __get_free_pages.

    The fix is to limit the number of chains to 100,000.  In addition,
    the number of host credits is limited to 30,000 IOs. However this
    limitation can be overridden this using the command line option
    max_queue_depth.  The algorithm for calculating the
    reply_post_queue_depth is changed so that it is equal to
    (reply_free_queue_depth + 16), previously it was (reply_free_queue_depth * 2).

    Signed-off-by: Nagalakshmi Nandigama <nagalakshmi.nandigama@lsi.com>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit de3f88ba084473ce5365632f0209c3e95aeb55e9
Author: nagalakshmi.nandigama@lsi.com <nagalakshmi.nandigama@lsi.com>
Date:   Thu Dec 1 07:52:56 2011 +0530

    SCSI: mpt2sas: Release spinlock for the raid device list before blocking it

    commit 30c43282f3d347f47f9e05199d2b14f56f3f2837 upstream.

    Added code to release the spinlock that is used to protect the
    raid device list before calling a function that can block. The
    blocking was causing a reschedule, and subsequently it is tried
    to acquire the same lock, resulting in a panic (NMI Watchdog
    detecting a CPU lockup).

    Signed-off-by: Nagalakshmi Nandigama <nagalakshmi.nandigama@lsi.com>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 72ce943013baaba4af7afec76c3556b16b9f6de4
Author: Bjorn Helgaas <bhelgaas@google.com>
Date:   Thu Jan 12 08:01:40 2012 -0700

    x86/PCI: build amd_bus.o only when CONFIG_AMD_NB=y

    commit 5cf9a4e69c1ff0ccdd1d2b7404f95c0531355274 upstream.

    We only need amd_bus.o for AMD systems with PCI.  arch/x86/pci/Makefile
    already depends on CONFIG_PCI=y, so this patch just adds the dependency
    on CONFIG_AMD_NB.

    Cc: Yinghai Lu <yinghai@kernel.org>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 45e7e24360e799f7753f37ca5642a0d6e29b9c62
Author: Bjorn Helgaas <bhelgaas@google.com>
Date:   Thu Jan 5 14:27:19 2012 -0700

    x86/PCI: amd: factor out MMCONFIG discovery

    commit 24d25dbfa63c376323096660bfa9ad45a08870ce upstream.

    This factors out the AMD native MMCONFIG discovery so we can use it
    outside amd_bus.c.

    amd_bus.c reads AMD MSRs so it can remove the MMCONFIG area from the
    PCI resources.  We may also need the MMCONFIG information to work
    around BIOS defects in the ACPI MCFG table.

    Cc: Borislav Petkov <borislav.petkov@amd.com>
    Cc: Yinghai Lu <yinghai@kernel.org>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 0a4179971477550df61b9218e664eb9128abf2e3
Author: Gary Hade <garyhade@us.ibm.com>
Date:   Mon Nov 14 15:42:16 2011 -0800

    x86/PCI: Ignore CPU non-addressable _CRS reserved memory resources

    commit ae5cd86455381282ece162966183d3f208c6fad7 upstream.

    This assures that a _CRS reserved host bridge window or window region is
    not used if it is not addressable by the CPU.  The new code either trims
    the window to exclude the non-addressable portion or totally ignores the
    window if the entire window is non-addressable.

    The current code has been shown to be problematic with 32-bit non-PAE
    kernels on systems where _CRS reserves resources above 4GB.

    Signed-off-by: Gary Hade <garyhade@us.ibm.com>
    Reviewed-by: Bjorn Helgaas <bhelgaas@google.com>
    Cc: Thomas Renninger <trenn@novell.com>
    Cc: linux-kernel@vger.kernel.org
    Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 65d61b46700e059210b4c9f63355d57dc0e1a18e
Author: Eric W. Biederman <ebiederm@xmission.com>
Date:   Mon Oct 17 11:46:06 2011 -0700

    PCI: msi: Disable msi interrupts when we initialize a pci device

    commit a776c491ca5e38c26d9f66923ff574d041e747f4 upstream.

    I traced a nasty kexec on panic boot failure to the fact that we had
    screaming msi interrupts and we were not disabling the msi messages at
    kernel startup.  The booting kernel had not enabled those interupts so
    was not prepared to handle them.

    I can see no reason why we would ever want to leave the msi interrupts
    enabled at boot if something else has enabled those interrupts.  The pci
    spec specifies that msi interrupts should be off by default.  Drivers
    are expected to enable the msi interrupts if they want to use them.  Our
    interrupt handling code reprograms the interrupt handlers at boot and
    will not be be able to do anything useful with an unexpected interrupt.

    This patch applies cleanly all of the way back to 2.6.32 where I noticed
    the problem.

    Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
    Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 58f98e86f9138e283b98766541727af91a58e849
Author: Alex Williamson <alex.williamson@redhat.com>
Date:   Wed Nov 16 09:24:16 2011 -0700

    PCI: Fix PCI_EXP_TYPE_RC_EC value

    commit 1830ea91c20b06608f7cdb2455ce05ba834b3214 upstream.

    Spec shows this as 1010b = 0xa

    Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
    Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit c16686fc0c9c8f6fa46741e50c6ab621ab507cf9
Author: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Date:   Thu Jan 5 10:47:18 2012 +0200

    UBI: fix use-after-free on error path

    commit e57e0d8e818512047fe379157c3f77f1b9fabffb upstream.

    When we fail to erase a PEB, we free the corresponding erase entry object,
    but then re-schedule this object if the error code was something like -EAGAIN.
    Obviously, it is a bug to use the object after we have freed it.

    Reported-by: Emese Revfy <re.emese@gmail.com>
    Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 75947f78d026b6eb2c4f16c54042325f97e3288a
Author: Bhavesh Parekh <bparekh@nvidia.com>
Date:   Wed Nov 30 17:43:42 2011 +0530

    UBI: fix missing scrub when there is a bit-flip

    commit e801e128b2200c40a0ec236cf2330b2586b6e05a upstream.

    Under some cases, when scrubbing the PEB if we did not get the lock on
    the PEB it fails to scrub. Add that PEB again to the scrub list

    Artem: minor amendments.

    Signed-off-by: Bhavesh Parekh <bparekh@nvidia.com>
    Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 729a9768761809079d07c9716f656da20a14eb2f
Author: Chase Douglas <chase.douglas@canonical.com>
Date:   Mon Nov 7 11:08:05 2011 -0800

    HID: bump maximum global item tag report size to 96 bytes

    commit e46e927b9b7e8d95526e69322855243882b7e1a3 upstream.

    This allows the latest N-Trig devices to function properly.

    BugLink: https://bugs.launchpad.net/bugs/724831

    Signed-off-by: Chase Douglas <chase.douglas@canonical.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit dbbef3cbdef5e2363caeb343efa68650f20d7bfc
Author: Jeff Layton <jlayton@redhat.com>
Date:   Tue Dec 20 06:57:45 2011 -0500

    nfs: fix regression in handling of context= option in NFSv4

    commit 8a0d551a59ac92d8ff048d6cb29d3a02073e81e8 upstream.

    Setting the security context of a NFSv4 mount via the context= mount
    option is currently broken. The NFSv4 codepath allocates a parsed
    options struct, and then parses the mount options to fill it. It
    eventually calls nfs4_remote_mount which calls security_init_mnt_opts.
    That clobbers the lsm_opts struct that was populated earlier. This bug
    also looks like it causes a small memory leak on each v4 mount where
    context= is used.

    Fix this by moving the initialization of the lsm_opts into
    nfs_alloc_parsed_mount_data. Also, add a destructor for
    nfs_parsed_mount_data to make it easier to free all of the allocations
    hanging off of it, and to ensure that the security_free_mnt_opts is
    called whenever security_init_mnt_opts is.

    I believe this regression was introduced quite some time ago, probably
    by commit c02d7adf.

    Signed-off-by: Jeff Layton <jlayton@redhat.com>
    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 58a902db8896b6bb4c779a223f6e8e7b289cdcc9
Author: Andy Adamson <andros@netapp.com>
Date:   Wed Nov 9 13:58:20 2011 -0500

    NFSv4.1: fix backchannel slotid off-by-one bug

    commit 61f2e5106582d02f30b6807e3f9c07463c572ccb upstream.

    Signed-off-by: Andy Adamson <andros@netapp.com>
    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 2dda99b3d5f3f6be05f0c9cc7cf0b05740e6e9f5
Author: Chuck Lever <chuck.lever@oracle.com>
Date:   Mon Dec 5 15:40:30 2011 -0500

    NFS: Retry mounting NFSROOT

    commit 43717c7daebf10b43f12e68512484b3095bb1ba5 upstream.

    Lukas Razik <linux@razik.name> reports that on his SPARC system,
    booting with an NFS root file system stopped working after commit
    56463e50 "NFS: Use super.c for NFSROOT mount option parsing."

    We found that the network switch to which Lukas' client was attached
    was delaying access to the LAN after the client's NIC driver reported
    that its link was up.  The delay was longer than the timeouts used in
    the NFS client during mounting.

    NFSROOT worked for Lukas before commit 56463e50 because in those
    kernels, the client's first operation was an rpcbind request to
    determine which port the NFS server was listening on.  When that
    request failed after a long timeout, the client simply selected the
    default NFS port (2049).  By that time the switch was allowing access
    to the LAN, and the mount succeeded.

    Neither of these client behaviors is desirable, so reverting 56463e50
    is really not a choice.  Instead, introduce a mechanism that retries
    the NFSROOT mount request several times.  This is the same tactic that
    normal user space NFS mounts employ to overcome server and network
    delays.

    Signed-off-by: Lukas Razik <linux@razik.name>
    [ cel: match kernel coding style, add proper patch description ]
    [ cel: add exponential back-off ]
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Tested-by: Lukas Razik <linux@razik.name>
    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit be2ef85142e6f00c7f6c8842d903701bdf88cb5c
Author: Michel Dänzer <michel.daenzer@amd.com>
Date:   Thu Jan 5 18:42:17 2012 +0100

    radeon: Fix disabling PCI bus mastering on big endian hosts.

    commit 3df96909b75835d487a9178761622b0cbd7310d4 upstream.

    It would previously write basically random bits to PCI configuration space...
    Not very surprising that the GPU tended to stop responding completely. The
    resulting MCE even froze the whole machine sometimes.

    Now resetting the GPU after a lockup has at least a fighting chance of
    succeeding.

    Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
    Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit a674b8b3e345496a96aec389446650455b2fdfa1
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Tue Jan 3 09:48:38 2012 -0500

    drm/radeon/kms: disable writeback on pre-R300 asics

    commit 28eebb703e28bc455ba704adb1026f76649b768c upstream.

    We often end up missing fences on older asics with
    writeback enabled which leads to delays in the userspace
    accel code, so just disable it by default on those asics.

    Reported-by: Helge Deller <deller@gmx.de>
    Reported-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit b48620dfff7a12774bb83348a88eddb5921dcdd2
Author: Rafał Miłecki <zajec5@gmail.com>
Date:   Fri Dec 23 20:32:18 2011 +0100

    drm/radeon/kms: workaround invalid AVI infoframe checksum issue

    commit 92db7f6c860b8190571a9dc1fcbc16d003422fe8 upstream.

    This change was verified to fix both issues with no video I've
    investigated. I've also checked checksum calculation with fglrx on:
    RV620, HD54xx, HD5450, HD6310, HD6320.

    Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 24973a17310bd933969d79cf4080049df85aff2c
Author: Takashi Iwai <tiwai@suse.de>
Date:   Tue Jan 10 12:41:22 2012 +0100

    ALSA: hda - Return the error from get_wcaps_type() for invalid NIDs

    commit 3a90274de3548ebb2aabfbf488cea8e275a73dc6 upstream.

    When an invalid NID is given, get_wcaps() returns zero as the error,
    but get_wcaps_type() takes it as the normal value and returns a bogus
    AC_WID_AUD_OUT value.  This confuses the parser.

    With this patch, get_wcaps_type() returns -1 when value 0 is given,
    i.e. an invalid NID is passed to get_wcaps().

    Bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=740118

    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 35cdd5ea88762e22c9d21c5c826cbd7ef1edd7db
Author: Pavel Hofman <pavel.hofman@ivitera.com>
Date:   Thu Jan 5 23:05:18 2012 +0100

    ALSA: ice1724 - Check for ac97 to avoid kernel oops

    commit e7848163aa2a649d9065f230fadff80dc3519775 upstream.

    Cards with identical PCI ids but no AC97 config in EEPROM do not have
    the ac97 field initialized. We must check for this case to avoid kernel oops.

    Signed-off-by: Pavel Hofman <pavel.hofman@ivitera.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 730580b66c412cd8fbe9c7077ce42c55a85e6281
Author: Karsten Wiese <fzu@wemgehoertderstaat.de>
Date:   Fri Dec 30 01:42:01 2011 +0100

    ALSA: snd-usb-us122l: Delete calls to preempt_disable

    commit d0f3a2eb9062560bebca8b923424f3ca02a331ba upstream.

    They are not needed here.

    Signed-off-by: Karsten Wiese <fzu@wemgehoertderstaat.de>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 0146b288f47cc3ef3f0791b3023643ccdeeeb339
Author: Xi Wang <xi.wang@gmail.com>
Date:   Tue Jan 10 11:51:10 2012 -0500

    ext4: fix undefined behavior in ext4_fill_flex_info()

    commit d50f2ab6f050311dbf7b8f5501b25f0bf64a439b upstream.

    Commit 503358ae01b70ce6909d19dd01287093f6b6271c ("ext4: avoid divide by
    zero when trying to mount a corrupted file system") fixes CVE-2009-4307
    by performing a sanity check on s_log_groups_per_flex, since it can be
    set to a bogus value by an attacker.

    	sbi->s_log_groups_per_flex = sbi->s_es->s_log_groups_per_flex;
    	groups_per_flex = 1 << sbi->s_log_groups_per_flex;

    	if (groups_per_flex < 2) { ... }

    This patch fixes two potential issues in the previous commit.

    1) The sanity check might only work on architectures like PowerPC.
    On x86, 5 bits are used for the shifting amount.  That means, given a
    large s_log_groups_per_flex value like 36, groups_per_flex = 1 << 36
    is essentially 1 << 4 = 16, rather than 0.  This will bypass the check,
    leaving s_log_groups_per_flex and groups_per_flex inconsistent.

    2) The sanity check relies on undefined behavior, i.e., oversized shift.
    A standard-confirming C compiler could rewrite the check in unexpected
    ways.  Consider the following equivalent form, assuming groups_per_flex
    is unsigned for simplicity.

    	groups_per_flex = 1 << sbi->s_log_groups_per_flex;
    	if (groups_per_flex == 0 || groups_per_flex == 1) {

    We compile the code snippet using Clang 3.0 and GCC 4.6.  Clang will
    completely optimize away the check groups_per_flex == 0, leaving the
    patched code as vulnerable as the original.  GCC keeps the check, but
    there is no guarantee that future versions will do the same.

    Signed-off-by: Xi Wang <xi.wang@gmail.com>
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 922d41ed4740408d2719a8c99d9f80138e562c03
Author: Ben Hutchings <ben@decadent.org.uk>
Date:   Tue Jan 10 15:11:02 2012 -0800

    drivers/rtc/interface.c: fix alarm rollover when day or month is out-of-range

    commit e74a8f2edb92cb690b467cea0ab652c509e9f624 upstream.

    Commit f44f7f96a20a ("RTC: Initialize kernel state from RTC") introduced a
    potential infinite loop.  If an alarm time contains a wildcard month and
    an invalid day (> 31), or a wildcard year and an invalid month (>= 12),
    the loop searching for the next matching date will never terminate.  Treat
    the invalid values as wildcards.

    Fixes <http://bugs.debian.org/646429>, <http://bugs.debian.org/653331>

    Reported-by: leo weppelman <leoweppelman@googlemail.com>
    Reported-by: "P. van Gaans" <mailme667@yahoo.co.uk>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
    Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
    Cc: Marcelo Roberto Jimenez <mroberto@cpti.cetuc.puc-rio.br>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: John Stultz <john.stultz@linaro.org>
    Acked-by: Alessandro Zummo <a.zummo@towertech.it>
    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>

commit f3a6e79c583423a55f7068ccdad732a5f4a0faad
Author: Wolfram Sang <w.sang@pengutronix.de>
Date:   Tue Nov 29 15:34:08 2011 +0100

    mtd: tests: stresstest: bail out if device has not enough eraseblocks

    commit 2f4478ccff7df845dc9c0f8996a96373122c4417 upstream.

    stresstest needs at least two eraseblocks. Bail out gracefully if that
    condition is not met. Fixes the following 'division by zero' OOPS:

    [  619.100000] mtd_stresstest: MTD device size 131072, eraseblock size 131072, page size 2048, count of eraseblocks 1, pages per eraseblock 64, OOB size 64
    [  619.120000] mtd_stresstest: scanning for bad eraseblocks
    [  619.120000] mtd_stresstest: scanned 1 eraseblocks, 0 are bad
    [  619.130000] mtd_stresstest: doing operations
    [  619.130000] mtd_stresstest: 0 operations done
    [  619.140000] Division by zero in kernel.
    ...

    caused by

            /* Read or write up 2 eraseblocks at a time - hence 'ebcnt - 1' */
            eb %= (ebcnt - 1);

    Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
    Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
    Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 488e572df737befdfc783503642d70ea18b3a001
Author: Brian Norris <computersforpeace@gmail.com>
Date:   Mon Nov 7 15:51:05 2011 -0800

    mtd: mtd_blkdevs: don't increase 'open' count on error path

    commit 342ff28f5a2e5aa3236617bd2bddf6c749677ef2 upstream.

    Some error paths in mtd_blkdevs were fixed in the following commit:

        commit 94735ec4044a6d318b83ad3c5794e931ed168d10
        mtd: mtd_blkdevs: fix error path in blktrans_open

    But on these error paths, the block device's `dev->open' count is
    already incremented before we check for errors. This meant that, while
    the error path was handled correctly on the first time through
    blktrans_open(), the device is erroneously considered already open on
    the second time through.

    This problem can be seen, for instance, when a UBI volume is
    simultaneously mounted as a UBIFS partition and read through its
    corresponding gluebi mtdblockX device. This results in blktrans_open()
    passing its error checks (with `dev->open > 0') without actually having
    a handle on the device. Here's a summarized log of the actions and
    results with nandsim:

        # modprobe nandsim
        # modprobe mtdblock
        # modprobe gluebi
        # modprobe ubifs
        # ubiattach /dev/ubi_ctrl -m 0
        ...
        # ubimkvol /dev/ubi0 -N test -s 16MiB
        ...
        # mount -t ubifs ubi0:test /mnt
        # ls /dev/mtdblock*
        /dev/mtdblock0  /dev/mtdblock1
        # cat /dev/mtdblock1 > /dev/null
        cat: can't open '/dev/mtdblock4': Device or resource busy
        # cat /dev/mtdblock1 > /dev/null

        CPU 0 Unable to handle kernel paging request at virtual address
        fffffff0, epc == 8031536c, ra == 8031f280
        Oops[#1]:
        ...
        Call Trace:
        [<8031536c>] ubi_leb_read+0x14/0x164
        [<8031f280>] gluebi_read+0xf0/0x148
        [<802edba8>] mtdblock_readsect+0x64/0x198
        [<802ecfe4>] mtd_blktrans_thread+0x330/0x3f4
        [<8005be98>] kthread+0x88/0x90
        [<8000bc04>] kernel_thread_helper+0x10/0x18

    Signed-off-by: Brian Norris <computersforpeace@gmail.com>
    Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@linux.intel.com>
    Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 13205eedda9d80daf129ddad54bd6ffe5df92dff
Author: Roman Tereshonkov <roman.tereshonkov@nokia.com>
Date:   Fri Dec 2 15:07:17 2011 +0200

    mtd: mtdoops: skip reading initially bad blocks

    commit 3538c56329936c78f7d356889908790006d0124c upstream.

    Use block_isbad to check and skip the bad blocks reading.
    This will allow to get rid of the read errors if bad blocks
    are present initially.

    Signed-off-by: Roman Tereshonkov <roman.tereshonkov@nokia.com>
    Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
    Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 63f0d35a610b2ef1139b5d763ee74cab5257a8c8
Author: Roman Tereshonkov <roman.tereshonkov@nokia.com>
Date:   Tue Nov 29 12:49:18 2011 +0200

    mtdoops: fix the oops_page_used array size

    commit 556f063580db2953a7e53cd46b47724246320f60 upstream.

    The array of unsigned long pointed by oops_page_used is allocated
    by vmalloc which requires the size to be in bytes.

    BITS_PER_LONG is equal to 32.
    If we want to allocate memory for 32 pages with one bit per page then
    32 / BITS_PER_LONG  is equal to 1 byte that is 8 bits.
    To fix it we need to multiply the result by sizeof(unsigned long) equal to 4.

    Signed-off-by: Roman Tereshonkov <roman.tereshonkov@nokia.com>
    Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@linux.intel.com>
    Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>