Linux 3.0.35

commit 839cf7a236278ae358ff12141a168c0982fa0cd9
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Sun Jun 17 11:23:33 2012 -0700

    Linux 3.0.35

commit 2209ffb965c6b17602aae5e637961e4f0f8a4162
Author: Dave Hansen <dave@linux.vnet.ibm.com>
Date:   Tue May 29 15:06:46 2012 -0700

    hugetlb: fix resv_map leak in error path

    commit c50ac050811d6485616a193eb0f37bfbd191cc89 and
    4523e1458566a0e8ecfaff90f380dd23acc44d27 upstream.

    When called for anonymous (non-shared) mappings, hugetlb_reserve_pages()
    does a resv_map_alloc().  It depends on code in hugetlbfs's
    vm_ops->close() to release that allocation.

    However, in the mmap() failure path, we do a plain unmap_region() without
    the remove_vma() which actually calls vm_ops->close().

    This is a decent fix.  This leak could get reintroduced if new code (say,
    after hugetlb_reserve_pages() in hugetlbfs_file_mmap()) decides to return
    an error.  But, I think it would have to unroll the reservation anyway.

    Christoph's test case:

    	http://marc.info/?l=linux-mm&m=133728900729735

    This patch applies to 3.4 and later.  A version for earlier kernels is at
    https://lkml.org/lkml/2012/5/22/418.

    Signed-off-by: Dave Hansen <dave@linux.vnet.ibm.com>
    Acked-by: Mel Gorman <mel@csn.ul.ie>
    Acked-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
    Reported-by: Christoph Lameter <cl@linux.com>
    Tested-by: Christoph Lameter <cl@linux.com>
    Cc: Andrea Arcangeli <aarcange@redhat.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@linuxfoundation.org>

commit c201beec4842674cd4773771931d25c9a5d45d66
Author: KyongHo <pullip.cho@samsung.com>
Date:   Tue May 29 15:06:49 2012 -0700

    mm: fix faulty initialization in vmalloc_init()

    commit dbda591d920b4c7692725b13e3f68ecb251e9080 upstream.

    The transfer of ->flags causes some of the static mapping virtual
    addresses to be prematurely freed (before the mapping is removed) because
    VM_LAZY_FREE gets "set" if tmp->flags has VM_IOREMAP set.  This might
    cause subsequent vmalloc/ioremap calls to fail because it might allocate
    one of the freed virtual address ranges that aren't unmapped.

    va->flags has different types of flags from tmp->flags.  If a region with
    VM_IOREMAP set is registered with vm_area_add_early(), it will be removed
    by __purge_vmap_area_lazy().

    Fix vmalloc_init() to correctly initialize vmap_area for the given
    vm_struct.

    Also initialise va->vm.  If it is not set, find_vm_area() for the early
    vm regions will always fail.

    Signed-off-by: KyongHo Cho <pullip.cho@samsung.com>
    Cc: "Olav Haugan" <ohaugan@codeaurora.org>
    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@linuxfoundation.org>

commit 5c2d31dda012797578d012425a785d58e14d2053
Author: Minchan Kim <minchan@kernel.org>
Date:   Tue Jan 10 15:08:39 2012 -0800

    mm/vmalloc.c: change void* into explict vm_struct*

    commit db1aecafef58b5dda39c4228debe2c845e4a27ab upstream.

    vmap_area->private is void* but we don't use the field for various purpose
    but use only for vm_struct.  So change it to a vm_struct* with naming to
    improve for readability and type checking.

    Signed-off-by: Minchan Kim <minchan@kernel.org>
    Acked-by: 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@linuxfoundation.org>

commit 52f81dc563e58bfbd22f1b0e2037da855a26b995
Author: Dean Nelson <dnelson@redhat.com>
Date:   Thu Aug 25 14:39:24 2011 +0000

    e1000: save skb counts in TX to avoid cache misses

    commit 31c15a2f24ebdab14333d9bf5df49757842ae2ec upstream.

    Virtual Machines with emulated e1000 network adapter running on Parallels'
    server were seeing kernel panics due to the e1000 driver dereferencing an
    unexpected NULL pointer retrieved from buffer_info->skb.

    The problem has been addressed for the e1000e driver, but not for the e1000.
    Since the two drivers share similar code in the affected area, a port of the
    following e1000e driver commit solves the issue for the e1000 driver:

    commit 9ed318d546a29d7a591dbe648fd1a2efe3be1180
    Author: Tom Herbert <therbert@google.com>
    Date:   Wed May 5 14:02:27 2010 +0000

        e1000e: save skb counts in TX to avoid cache misses

        In e1000_tx_map, precompute number of segements and bytecounts which
        are derived from fields in skb; these are stored in buffer_info.  When
        cleaning tx in e1000_clean_tx_irq use the values in the associated
        buffer_info for statistics counting, this eliminates cache misses
        on skb fields.

    Signed-off-by: Dean Nelson <dnelson@redhat.com>
    Acked-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Roman Kagan <rkagan@parallels.com>

commit 6140710c5dba509a20b26dfe38b58f40baf2a2c8
Author: Pavel Shilovsky <piastry@etersoft.ru>
Date:   Thu May 10 19:49:38 2012 +0400

    fuse: fix stat call on 32 bit platforms

    commit 45c72cd73c788dd18c8113d4a404d6b4a01decf1 upstream.

    Now we store attr->ino at inode->i_ino, return attr->ino at the
    first time and then return inode->i_ino if the attribute timeout
    isn't expired. That's wrong on 32 bit platforms because attr->ino
    is 64 bit and inode->i_ino is 32 bit in this case.

    Fix this by saving 64 bit ino in fuse_inode structure and returning
    it every time we call getattr. Also squash attr->ino into inode->i_ino
    explicitly.

    Signed-off-by: Pavel Shilovsky <piastry@etersoft.ru>
    Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 33b3689af55ddec6efd608bd82f09a83e4e4042c
Author: Borislav Petkov <borislav.petkov@amd.com>
Date:   Mon Apr 16 18:01:53 2012 +0200

    x86, MCE, AMD: Make APIC LVT thresholding interrupt optional

    commit f227d4306cf30e1d5b6f231e8ef9006c34f3d186 upstream.

    Currently, the APIC LVT interrupt for error thresholding is implicitly
    enabled. However, there are models in the F15h range which do not enable
    it. Make the code machinery which sets up the APIC interrupt support
    an optional setting and add an ->interrupt_capable member to the bank
    representation mirroring that capability and enable the interrupt offset
    programming only if it is true.

    Simplify code and fixup comment style while at it.

    Signed-off-by: Borislav Petkov <borislav.petkov@amd.com>
    Signed-off-by: Robert Richter <robert.richter@amd.com>

commit e2b55892ceb923d9ff6c204e59be5f2b43a0009c
Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Date:   Wed Jun 6 09:13:36 2012 +0200

    iwlwifi: don't mess up the SCD when removing a key

    commit d6ee27eb13beab94056e0de52d81220058ca2297 upstream.

    When we remove a key, we put a key index which was supposed
    to tell the fw that we are actually removing the key. But
    instead the fw took that index as a valid index and messed
    up the SRAM of the device.

    This memory corruption on the device mangled the data of
    the SCD. The impact on the user is that SCD queue 2 got
    stuck after having removed keys.
    The message is the log that was printed is:

    Queue 2 stuck for 10000ms

    This doesn't seem to fix the higher queues that get stuck
    from time to time.

    Reviewed-by: Meenakshi Venkataraman <meenakshi.venkataraman@intel.com>
    Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 34b1a9eb1db3de73460f3a21d8ffb48ea7cbd338
Author: Dimitri Sivanich <sivanich@sgi.com>
Date:   Tue Jun 5 13:44:36 2012 -0500

    sched: Fix the relax_domain_level boot parameter

    commit a841f8cef4bb124f0f5563314d0beaf2e1249d72 upstream.

    It does not get processed because sched_domain_level_max is 0 at the
    time that setup_relax_domain_level() is run.

    Simply accept the value as it is, as we don't know the value of
    sched_domain_level_max until sched domain construction is completed.

    Fix sched_relax_domain_level in cpuset.  The build_sched_domain() routine calls
    the set_domain_attribute() routine prior to setting the sd->level, however,
    the set_domain_attribute() routine relies on the sd->level to decide whether
    idle load balancing will be off/on.

    Signed-off-by: Dimitri Sivanich <sivanich@sgi.com>
    Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Link: http://lkml.kernel.org/r/20120605184436.GA15668@sgi.com
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ae797dcdae86481103b6ed79d97ac09e57e2feef
Author: Alan Cox <alan@linux.intel.com>
Date:   Wed Apr 25 14:33:33 2012 +0100

    acpi_video: fix leaking PCI references

    commit cfb46f433a4da97c31780e08a259fac2cb6bd61f upstream.

    Signed-off-by: Alan Cox <alan@linux.intel.com>
    Acked-by: Matthew Garrett <mjg@redhat.com>
    Signed-off-by: Len Brown <len.brown@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 18f63bf60d507b4588f33ecfd8657f5d5e2a7b45
Author: Andre Przywara <andre.przywara@amd.com>
Date:   Fri Mar 23 10:02:17 2012 +0100

    hwmon: (fam15h_power) Increase output resolution

    commit 941a956b0e387b21f385f486c34ef67576775cfc upstream.

    On high CPU load the accumulating values in the running_avg_cap
    register are very low (below 10), so averaging them too early leads
    to unnecessary poor output resolution. Since we pretend to output
    micro-Watt we better keep all the bits we have as long as possible.

    Signed-off-by: Andre Przywara <andre.przywara@amd.com>
    Signed-off-by: Andreas Herrmann <andreas.herrmann3@amd.com>
    Acked-by: Guenter Roeck <guenter.roeck@ericsson.com>
    Signed-off-by: Jean Delvare <khali@linux-fr.org>
    Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4286e566ff410a64f5a329fb42f2d44193c52945
Author: AnilKumar Ch <anilkumar@ti.com>
Date:   Wed May 23 17:45:11 2012 +0530

    can: c_can: fix race condition in c_can_open()

    commit f461f27a4436dbe691908fe08b867ef888848cc3 upstream.

    Fix the issue of C_CAN interrupts getting disabled forever when canconfig
    utility is used multiple times. According to NAPI usage we disable all
    the hardware interrupts in ISR and re-enable them in poll(). Current
    implementation calls napi_enable() after hardware interrupts are enabled.
    If we get any interrupts between these two steps then we do not process
    those interrupts because napi is not enabled. Mostly these interrupts
    come because of STATUS is not 0x7 or ERROR interrupts. If napi_enable()
    happens before HW interrupts enabled then c_can_poll() function will be
    called eventual re-enabling.

    This patch moves the napi_enable() call before interrupts enabled.

    Signed-off-by: AnilKumar Ch <anilkumar@ti.com>
    Acked-by: Wolfgang Grandegger <wg@grandegger.com>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e3c8262d150883d1dbd9b5cbb03d6cca7cf68cad
Author: AnilKumar Ch <anilkumar@ti.com>
Date:   Wed May 23 17:45:10 2012 +0530

    can: c_can: fix an interrupt thrash issue with c_can driver

    commit 148c87c89e1a8863d3d965179f3ab1a06490569e upstream.

    This patch fixes an interrupt thrash issue with c_can driver.

    In c_can_isr() function interrupts are disabled and enabled only in
    c_can_poll() function. c_can_isr() & c_can_poll() both read the
    irqstatus flag. However, irqstatus is always read as 0 in c_can_poll()
    because all C_CAN interrupts are disabled in c_can_isr(). This causes
    all interrupts to be re-enabled in c_can_poll() which in turn causes
    another interrupt since the event is not really handled. This keeps
    happening causing a flood of interrupts.

    To fix this, read the irqstatus register in isr and use the same cached
    value in the poll function.

    Signed-off-by: AnilKumar Ch <anilkumar@ti.com>
    Acked-by: Wolfgang Grandegger <wg@grandegger.com>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2f99a5afd1a9752cf69c3ee006f3a9c1bb74013a
Author: AnilKumar Ch <anilkumar@ti.com>
Date:   Wed May 23 17:45:09 2012 +0530

    can: c_can: fix "BUG! echo_skb is occupied!" during transmit

    commit 617caccebe451716df21c069b079d5936ed7b0f3 upstream.

    This patch fixes an issue with transmit routine, which causes
    "can_put_echo_skb: BUG! echo_skb is occupied!" message when
    using "cansequence -p" on D_CAN controller.

    In c_can driver, while transmitting packets tx_echo flag holds
    the no of can frames put for transmission into the hardware.

    As the comment above c_can_do_tx() indicates, if we find any packet
    which is not transmitted then we should stop looking for more.
    In the current implementation this is not taken care of causing the
    said message.

    Also, fix the condition used to find if the packet is transmitted
    or not. Current code skips the first tx message object and ends up
    checking one extra invalid object.

    While at it, fix the comment on top of c_can_do_tx() to use the
    terminology "packet" instead of "package" since it is more
    standard.

    Signed-off-by: AnilKumar Ch <anilkumar@ti.com>
    Acked-by: Wolfgang Grandegger <wg@grandegger.com>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8f509b694f5d1f287188bdd3df11aafccc911c11
Author: Bjørn Mork <bjorn@mork.no>
Date:   Tue Jun 5 21:18:10 2012 +0000

    net: sierra_net: device IDs for Aircard 320U++

    commit dd03cff23d694cfb0fdae80cb618e7ced05ea696 upstream.

    Adding device IDs for Aircard 320U and two other devices
    found in the out-of-tree version of this driver.

    Cc: linux@sierrawireless.com
    Cc: Autif Khan <autif.mlist@gmail.com>
    Cc: Tom Cassidy <tomas.cassidy@gmail.com>
    Signed-off-by: Bjørn Mork <bjorn@mork.no>
    Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f90b005ff35ab8e6ed3ddcbf79dee0baa48c429a
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Tue Jun 5 12:16:50 2012 +0200

    cfg80211: fix interface combinations check

    commit 463454b5dbd8dbab6e2fc6c557329e5b811b9c32 upstream.

    If a given interface combination doesn't contain
    a required interface type then we missed checking
    that and erroneously allowed it even though iface
    type wasn't there at all. Add a check that makes
    sure that all interface types are accounted for.

    Reported-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 55fe02e968371dd1c0b5b1f9411f2fc8c2b84e7e
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Thu May 31 15:09:27 2012 +0200

    mac80211: clean up remain-on-channel on interface stop

    commit 71ecfa1893034eeb1c93e02e22ee2ad26d080858 upstream.

    When any interface goes down, it could be the one that we
    were doing a remain-on-channel with. We therefore need to
    cancel the remain-on-channel and flush the related work
    structs so they don't run after the interface has been
    removed or even destroyed.

    It's also possible in this case that an off-channel SKB
    was never transmitted, so free it if this is the case.
    Note that this can also happen if the driver finishes
    the off-channel period without ever starting it.

    Reported-by: Nirav Shah <nirav.j2.shah@intel.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9bef1b2492b95dc848cbde1ad021efc355a0b350
Author: Mathias Krause <minipli@googlemail.com>
Date:   Wed May 30 01:43:08 2012 +0200

    crypto: aesni-intel - fix unaligned cbc decrypt for x86-32

    commit 7c8d51848a88aafdb68f42b6b650c83485ea2f84 upstream.

    The 32 bit variant of cbc(aes) decrypt is using instructions requiring
    128 bit aligned memory locations but fails to ensure this constraint in
    the code. Fix this by loading the data into intermediate registers with
    load unaligned instructions.

    This fixes reported general protection faults related to aesni.

    References: https://bugzilla.kernel.org/show_bug.cgi?id=43223
    Reported-by: Daniel <garkein@mailueberfall.de>
    Signed-off-by: Mathias Krause <minipli@googlemail.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 238607e0800c37b64868e6ec2323fc0e25cd7363
Author: Steffen Rumler <steffen.rumler.ext@nsn.com>
Date:   Wed Jun 6 16:37:17 2012 +0200

    powerpc: Fix kernel panic during kernel module load

    commit 3c75296562f43e6fbc6cddd3de948a7b3e4e9bcf upstream.

    This fixes a problem which can causes kernel oopses while loading
    a kernel module.

    According to the PowerPC EABI specification, GPR r11 is assigned
    the dedicated function to point to the previous stack frame.
    In the powerpc-specific kernel module loader, do_plt_call()
    (in arch/powerpc/kernel/module_32.c), GPR r11 is also used
    to generate trampoline code.

    This combination crashes the kernel, in the case where the compiler
    chooses to use a helper function for saving GPRs on entry, and the
    module loader has placed the .init.text section far away from the
    .text section, meaning that it has to generate a trampoline for
    functions in the .init.text section to call the GPR save helper.
    Because the trampoline trashes r11, references to the stack frame
    using r11 can cause an oops.

    The fix just uses GPR r12 instead of GPR r11 for generating the
    trampoline code.  According to the statements from Freescale, this is
    safe from an EABI perspective.

    I've tested the fix for kernel 2.6.33 on MPC8541.

    Signed-off-by: Steffen Rumler <steffen.rumler.ext@nsn.com>
    [paulus@samba.org: reworded the description]
    Signed-off-by: Paul Mackerras <paulus@samba.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 29684ecb7a675061933fb19531407fa9f9971ab4
Author: Roland Dreier <roland@purestorage.com>
Date:   Thu Jun 7 14:21:13 2012 -0700

    btree: fix tree corruption in btree_get_prev()

    commit cbf8ae32f66a9ceb8907ad9e16663c2a29e48990 upstream.

    The memory the parameter __key points to is used as an iterator in
    btree_get_prev(), so if we save off a bkey() pointer in retry_key and
    then assign that to __key, we'll end up corrupting the btree internals
    when we do eg

    	longcpy(__key, bkey(geo, node, i), geo->keylen);

    to return the key value.  What we should do instead is use longcpy() to
    copy the key value that retry_key points to __key.

    This can cause a btree to get corrupted by seemingly read-only
    operations such as btree_for_each_safe.

    [akpm@linux-foundation.org: avoid the double longcpy()]
    Signed-off-by: Roland Dreier <roland@purestorage.com>
    Acked-by: Joern Engel <joern@logfs.org>
    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@linuxfoundation.org>

commit 3fbec23f6bc97f3721c5345659fbbb71542120c5
Author: Eugeni Dodonov <eugeni.dodonov@intel.com>
Date:   Wed Jun 6 11:59:06 2012 -0300

    char/agp: add another Ironlake host bridge

    commit 67384fe3fd450536342330f684ea1f7dcaef8130 upstream.

    This seems to come on Gigabyte H55M-S2V and was discovered through the
    https://bugs.freedesktop.org/show_bug.cgi?id=50381 debugging.

    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50381
    Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>