Linux 3.0.28

commit 0527fde0639955203ad48a9fd83bd6fc35e82e07
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Fri Apr 13 08:26:29 2012 -0700

    Linux 3.0.28

commit 073c4aec557b87d0c5b6f8b6b1910b356088eaf3
Author: Peter Hurley <peter@hurleysoftware.com>
Date:   Mon Apr 2 13:44:56 2012 +0200

    Bluetooth: Fix l2cap conn failures for ssp devices

    commit 18daf1644e634bae951a6e3d4d19d89170209762 upstream

    Commit 330605423c fixed l2cap conn establishment for non-ssp remote
    devices by not setting HCI_CONN_ENCRYPT_PEND every time conn security
    is tested (which was always returning failure on any subsequent
    security checks).

    However, this broke l2cap conn establishment for ssp remote devices
    when an ACL link was already established at SDP-level security. This
    fix ensures that encryption must be pending whenever authentication
    is also pending.

    Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
    Tested-by: Daniel Wagner <daniel.wagner@bmw-carit.de>
    Acked-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>

commit d5748309bb8d75852c92966477277d4572d8920a
Author: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Date:   Tue Apr 10 20:54:43 2012 -0500

    TOMOYO: Fix mount flags checking order.

    commit df91e49477a9be15921cb2854e1d12a3bdb5e425 upstream.

    Userspace can pass in arbitrary combinations of MS_* flags to mount().

    If both MS_BIND and one of MS_SHARED/MS_PRIVATE/MS_SLAVE/MS_UNBINDABLE are
    passed, device name which should be checked for MS_BIND was not checked because
    MS_SHARED/MS_PRIVATE/MS_SLAVE/MS_UNBINDABLE had higher priority than MS_BIND.

    If both one of MS_BIND/MS_MOVE and MS_REMOUNT are passed, device name which
    should not be checked for MS_REMOUNT was checked because MS_BIND/MS_MOVE had
    higher priority than MS_REMOUNT.

    Fix these bugs by changing priority to MS_REMOUNT -> MS_BIND ->
    MS_SHARED/MS_PRIVATE/MS_SLAVE/MS_UNBINDABLE -> MS_MOVE as with do_mount() does.

    Also, unconditionally return -EINVAL if more than one of
    MS_SHARED/MS_PRIVATE/MS_SLAVE/MS_UNBINDABLE is passed so that TOMOYO will not
    generate inaccurate audit logs, for commit 7a2e8a8f "VFS: Sanity check mount
    flags passed to change_mnt_propagation()" clarified that these flags must be
    exclusively passed.

    Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
    Signed-off-by: James Morris <james.l.morris@oracle.com>
    Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1a92416a1d37fd96427bd8d8a5fb52b54429c26f
Author: Joerg Roedel <joerg.roedel@amd.com>
Date:   Wed Apr 11 18:45:52 2012 +0200

    iommu/amd: Make sure IOMMU interrupts are re-enabled on resume

    commit 9ddd592a191b32f2ee6c4b6ed2bd52665c3a49f5 upstream.

    Unfortunatly the interrupts for the event log and the
    peripheral page-faults are only enabled at boot but not
    re-enabled at resume. Fix that.

    Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
    [bwh: Backport to 3.0:
     - Drop change to PPR log which was added in 3.3
      - Source is under arch/x86/kernel]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a27f3e06be07cd3719f8c42092de3ebfc9202923
Author: Oleg Nesterov <oleg@redhat.com>
Date:   Mon Apr 9 21:03:50 2012 +0200

    cred: copy_process() should clear child->replacement_session_keyring

    commit 79549c6dfda0603dba9a70a53467ce62d9335c33 upstream.

    keyctl_session_to_parent(task) sets ->replacement_session_keyring,
    it should be processed and cleared by key_replace_session_keyring().

    However, this task can fork before it notices TIF_NOTIFY_RESUME and
    the new child gets the bogus ->replacement_session_keyring copied by
    dup_task_struct(). This is obviously wrong and, if nothing else, this
    leads to put_cred(already_freed_cred).

    change copy_creds() to clear this member. If copy_process() fails
    before this point the wrong ->replacement_session_keyring doesn't
    matter, exit_creds() won't be called.

    Signed-off-by: Oleg Nesterov <oleg@redhat.com>
    Acked-by: David Howells <dhowells@redhat.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 49d06c03741d3329e568ba7d88cb32e700ef9156
Author: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Date:   Wed Apr 4 23:28:01 2012 -0700

    ASoC: ak4642: fixup: mute needs +1 step

    commit 1f99e44cf059d2ed43c5a0724fa738b83800f725 upstream.

    ak4642 out_tlv is +12.0dB to -115.0 dB, and it supports mute.
    But current settings didn't care +1 step for mute.
    This patch adds it

    Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
    Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1f69f7ff6a5f4bbdf1cd6619593fe0db9ff5e5c2
Author: Guan Xin <guanx.bac@gmail.com>
Date:   Mon Mar 26 04:11:46 2012 +0000

    USB: Add Motorola Rokr E6 Id to the USBNet driver "zaurus"

    commit a2daf263107ba3eb6db33931881731fa51c95045 upstream.

    Added Vendor/Device Id of Motorola Rokr E6 (22b8:6027) so it can be
    recognized by the "zaurus" USBNet driver.
    Applies to Linux 3.2.13 and 2.6.39.4.
    Signed-off-by: Guan Xin <guanx.bac@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 40788de827b48ddfeda82e1aa401a3d9a7ece136
Author: Nishanth Menon <nm@ti.com>
Date:   Wed Feb 22 20:03:45 2012 -0600

    mfd: Clear twl6030 IRQ status register only once

    commit 3f8349e6e98ba0455437724589072523865eae5e upstream.

    TWL6030 family of PMIC use a shadow interrupt status register
    while kernel processes the current interrupt event.
    However, any write(0 or 1) to register INT_STS_A, INT_STS_B or
    INT_STS_C clears all 3 interrupt status registers.

    Since clear of the interrupt is done on 32k clk, depending on I2C
    bus speed, we could in-adverently clear the status of a interrupt
    status pending on shadow register in the current implementation.
    This is due to the fact that multi-byte i2c write operation into
    three seperate status register could result in multiple load
    and clear of status and result in lost interrupts.

    Instead, doing a single byte write to INT_STS_A register with 0x0
    will clear all three interrupt status registers without the related
    risk.

    Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
    Signed-off-by: Nishanth Menon <nm@ti.com>
    Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ee9c2e08d37dae695a4f4cfb4dc003c5c2576f79
Author: Salman Qazi <sqazi@google.com>
Date:   Fri Mar 9 16:41:01 2012 -0800

    sched/x86: Fix overflow in cyc2ns_offset

    commit 9993bc635d01a6ee7f6b833b4ee65ce7c06350b1 upstream.

    When a machine boots up, the TSC generally gets reset.  However,
    when kexec is used to boot into a kernel, the TSC value would be
    carried over from the previous kernel.  The computation of
    cycns_offset in set_cyc2ns_scale is prone to an overflow, if the
    machine has been up more than 208 days prior to the kexec.  The
    overflow happens when we multiply *scale, even though there is
    enough room to store the final answer.

    We fix this issue by decomposing tsc_now into the quotient and
    remainder of division by CYC2NS_SCALE_FACTOR and then performing
    the multiplication separately on the two components.

    Refactor code to share the calculation with the previous
    fix in __cycles_2_ns().

    Signed-off-by: Salman Qazi <sqazi@google.com>
    Acked-by: John Stultz <john.stultz@linaro.org>
    Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Cc: Paul Turner <pjt@google.com>
    Cc: john stultz <johnstul@us.ibm.com>
    Link: http://lkml.kernel.org/r/20120310004027.19291.88460.stgit@dungbeetle.mtv.corp.google.com
    Signed-off-by: Ingo Molnar <mingo@elte.hu>
    Cc: Mike Galbraith <efault@gmx.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1802657ecb10d7ca620c3cf642920009d1aa2ec3
Author: Lee, Chun-Yi <joeyli.kernel@gmail.com>
Date:   Fri Mar 23 12:36:44 2012 +0800

    acer-wmi: No wifi rfkill on Sony machines

    commit 5719b81988f3c24ff694dc3a37e35b35630a3966 upstream.

    The wireless rfkill should charged by sony-laptop but not acer-wmi.
    So, add Sony's SNY5001 acpi device to blacklist in acer-wmi.

    Tested on Sony Vaio

    Cc: Carlos Corbacho <carlos@strangeworlds.co.uk>
    Cc: Matthew Garrett <mjg@redhat.com>
    Cc: Mattia Dongili <malattia@linux.it>
    Cc: Dimitris N <ddarlac@gmail.com>
    Tested-by: Dimitris N <ddarlac@gmail.com>
    Signed-off-by: Lee, Chun-Yi <jlee@suse.com>
    Signed-off-by: Matthew Garrett <mjg@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fb83b374f23848545068c9258500b92a36d18fe0
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Tue Apr 10 16:04:49 2012 -0700

    Revert "x86/ioapic: Add register level checks to detect bogus io-apic entries"

    This reverts commit c2ec63edaf48c90c3495eeb0b75bb05102fbf71a
    [73d63d038ee9f769f5e5b46792d227fe20e442c5 upstream]

    It causes problems, so needs to be reverted from 3.2-stable for now.

    Reported-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Cc: Jon Dufresne <jon@jondufresne.org>
    Cc: Suresh Siddha <suresh.b.siddha@intel.com>
    Cc: <yinghai@kernel.org>
    Cc: Josh Boyer <jwboyer@redhat.com>
    Cc: Ingo Molnar <mingo@elte.hu>
    Cc: Teck Choon Giam <giamteckchoon@gmail.com>
    Cc: Ben Guthro <ben@guthro.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 37e008cfe9c8790d24d35b00f659a754209ab9a7
Author: Jonathan Nieder <jrnieder@gmail.com>
Date:   Tue Feb 28 15:31:35 2012 -0600

    x86/PCI: do not tie MSI MS-7253 use_crs quirk to BIOS version

    commit a97f4f5e524bcd09a85ef0b8821a14d35e69335f upstream.

    Carlos was getting

    	WARNING: at drivers/pci/pci.c:118 pci_ioremap_bar+0x24/0x52()

    when probing his sound card, and sound did not work.  After adding
    pci=use_crs to the kernel command line, no more trouble.

    Ok, we can add a quirk.  dmidecode output reveals that this is an MSI
    MS-7253, for which we already have a quirk, but the short-sighted
    author tied the quirk to a single BIOS version, making it not kick in
    on Carlos's machine with BIOS V1.2.  If a later BIOS update makes it
    no longer necessary to look at the _CRS info it will still be
    harmless, so let's stop trying to guess which versions have and don't
    have accurate _CRS tables.

    Addresses https://bugtrack.alsa-project.org/alsa-bug/view.php?id=5533
    Also see <https://bugzilla.kernel.org/show_bug.cgi?id=42619>.

    Reported-by: Carlos Luna <caralu74@gmail.com>
    Reviewed-by: Bjorn Helgaas <bhelgaas@google.com>
    Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
    Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 06bcd9526cab45751fe74466064d41211b3b45d6
Author: Jonathan Nieder <jrnieder@gmail.com>
Date:   Tue Feb 28 11:51:10 2012 -0700

    x86/PCI: use host bridge _CRS info on MSI MS-7253

    commit 8411371709610c826bf65684f886bfdfb5780ca1 upstream.

    In the spirit of commit 29cf7a30f8a0 ("x86/PCI: use host bridge _CRS
    info on ASUS M2V-MX SE"), this DMI quirk turns on "pci_use_crs" by
    default on a board that needs it.

    This fixes boot failures and oopses introduced in 3e3da00c01d0
    ("x86/pci: AMD one chain system to use pci read out res").  The quirk
    is quite targetted (to a specific board and BIOS version) for two
    reasons:

     (1) to emphasize that this method of tackling the problem one quirk
         at a time is a little insane

     (2) to give BIOS vendors an opportunity to use simpler tables and
         allow us to return to generic behavior (whatever that happens to
         be) with a later BIOS update

    In other words, I am not at all happy with having quirks like this.
    But it is even worse for the kernel not to work out of the box on
    these machines, so...

    Reference: https://bugzilla.kernel.org/show_bug.cgi?id=42619
    Reported-by: Svante Signell <svante.signell@telia.com>
    Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d13149924c357cbdb4ce577f17ace9bee927d4ed
Author: Frank Rowand <frank.rowand@am.sony.com>
Date:   Mon Apr 9 17:59:03 2012 -0700

    modpost: Fix modpost license checking of vmlinux.o

    commit 258f742635360175564e9470eb060ff4d4b984e7 upstream.

    Commit f02e8a6596b7 ("module: Sort exported symbols") sorts symbols
    placing each of them in its own elf section.  This sorting and merging
    into the canonical sections are done by the linker.

    Unfortunately modpost to generate Module.symvers file parses vmlinux.o
    (which is not linked yet) and all modules object files (which aren't
    linked yet).  These aren't sanitized by the linker yet.  That breaks
    modpost that can't detect license properly for modules.

    This patch makes modpost aware of the new exported symbols structure.

    [ This above is a slightly corrected version of the explanation of the
      problem, copied from commit 62a2635610db ("modpost: Fix modpost's
      license checking V3").  That commit fixed the problem for module
      object files, but not for vmlinux.o.  This patch fixes modpost for
      vmlinux.o. ]

    Signed-off-by: Frank Rowand <frank.rowand@am.sony.com>
    Signed-off-by: Alessio Igor Bogani <abogani@kernel.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e189ac814b74b6604ee5b727f711b3294044cc32
Author: Alessio Igor Bogani <abogani@kernel.org>
Date:   Thu Jul 14 08:51:16 2011 +0200

    modpost: Fix modpost's license checking V3

    commit 62a2635610dbc83c5e8d724e00941eee4d18c186 upstream.

    The commit f02e8a6 sorts symbols placing each of them in its own elf section.
    The sorting and merging into the canonical sections are done by the linker.
    Unfortunately modpost to generate Module.symvers file parses vmlinux
    (already linked) and all modules object files (which aren't linked yet).
    These aren't sanitized by the linker yet. That breaks modpost that can't
    detect license properly for modules. This patch makes modpost aware of
    the new exported symbols structure.

    Thanks to Arnaud Lacombe <lacombar@gmail.com> and Anders Kaseorg
    <andersk@ksplice.com> for providing useful suggestions about code.

    This work was supported by a hardware donation from the CE Linux Forum.

    Reported-by: Jan Beulich <jbeulich@novell.com>
    Signed-off-by: Alessio Igor Bogani <abogani@kernel.org>
    Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 41ae97bd8c2166184bf0552b7c41868b74344039
Author: Kees Cook <keescook@chromium.org>
Date:   Wed Apr 4 11:40:19 2012 -0700

    sysctl: fix write access to dmesg_restrict/kptr_restrict

    commit 620f6e8e855d6d447688a5f67a4e176944a084e8 upstream.

    Commit bfdc0b4 adds code to restrict access to dmesg_restrict,
    however, it incorrectly alters kptr_restrict rather than
    dmesg_restrict.

    The original patch from Richard Weinberger
    (https://lkml.org/lkml/2011/3/14/362) alters dmesg_restrict as
    expected, and so the patch seems to have been misapplied.

    This adds the CAP_SYS_ADMIN check to both dmesg_restrict and
    kptr_restrict, since both are sensitive.

    Reported-by: Phillip Lougher <plougher@redhat.com>
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Acked-by: Serge Hallyn <serge.hallyn@canonical.com>
    Acked-by: Richard Weinberger <richard@nod.at>
    Signed-off-by: James Morris <james.l.morris@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 52a77de9f23e3b3d88354ee59a8923d566935abd
Author: Ludovic Desroches <ludovic.desroches@atmel.com>
Date:   Wed Mar 28 12:28:33 2012 +0200

    mmc: atmel-mci: correct data timeout computation

    commit 66292ad92c6d3f2f1c137a1c826b331ca8595dfd upstream.

    The HSMCI operates at a rate of up to Master Clock divided by two.
    Moreover previous calculation can cause overflows and so wrong
    timeouts.

    Signed-off-by: Ludovic Desroches <ludovic.desroches@atmel.com>
    Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
    Signed-off-by: Chris Ball <cjb@laptop.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e5acefebad4863015271b91f865c62def9bfed82
Author: Jason Wessel <jason.wessel@windriver.com>
Date:   Fri Mar 23 09:35:05 2012 -0500

    x86,kgdb: Fix DEBUG_RODATA limitation using text_poke()

    commit 3751d3e85cf693e10e2c47c03c8caa65e171099b upstream.

    There has long been a limitation using software breakpoints with a
    kernel compiled with CONFIG_DEBUG_RODATA going back to 2.6.26. For
    this particular patch, it will apply cleanly and has been tested all
    the way back to 2.6.36.

    The kprobes code uses the text_poke() function which accommodates
    writing a breakpoint into a read-only page.  The x86 kgdb code can
    solve the problem similarly by overriding the default breakpoint
    set/remove routines and using text_poke() directly.

    The x86 kgdb code will first attempt to use the traditional
    probe_kernel_write(), and next try using a the text_poke() function.
    The break point install method is tracked such that the correct break
    point removal routine will get called later on.

    Cc: x86@kernel.org
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: H. Peter Anvin <hpa@zytor.com>
    Inspried-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
    Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a492297156b336c3fde50ca35e40eb9ddde95478
Author: Jason Wessel <jason.wessel@windriver.com>
Date:   Thu Mar 29 17:41:24 2012 -0500

    kgdbts: (2 of 2) fix single step awareness to work correctly with SMP

    commit 23bbd8e346f1ef3fc1219c79cea53d8d52b207d8 upstream.

    The do_fork and sys_open tests have never worked properly on anything
    other than a UP configuration with the kgdb test suite.  This is
    because the test suite did not fully implement the behavior of a real
    debugger.  A real debugger tracks the state of what thread it asked to
    single step and can correctly continue other threads of execution or
    conditionally stop while waiting for the original thread single step
    request to return.

    Below is a simple method to cause a fatal kernel oops with the kgdb
    test suite on a 2 processor ARM system:

    while [ 1 ] ; do ls > /dev/null 2> /dev/null; done&
    while [ 1 ] ; do ls > /dev/null 2> /dev/null; done&
    echo V1I1F100 > /sys/module/kgdbts/parameters/kgdbts

    Very soon after starting the test the kernel will start warning with
    messages like:

    kgdbts: BP mismatch c002487c expected c0024878
    ------------[ cut here ]------------
    WARNING: at drivers/misc/kgdbts.c:317 check_and_rewind_pc+0x9c/0xc4()
    [<c01f6520>] (check_and_rewind_pc+0x9c/0xc4)
    [<c01f595c>] (validate_simple_test+0x3c/0xc4)
    [<c01f60d4>] (run_simple_test+0x1e8/0x274)

    The kernel will eventually recovers, but the test suite has completely
    failed to test anything useful.

    This patch implements behavior similar to a real debugger that does
    not rely on hardware single stepping by using only software planted
    breakpoints.

    In order to mimic a real debugger, the kgdb test suite now tracks the
    most recent thread that was continued (cont_thread_id), with the
    intent to single step just this thread.  When the response to the
    single step request stops in a different thread that hit the original
    break point that thread will now get continued, while the debugger
    waits for the thread with the single step pending.  Here is a high
    level description of the sequence of events.

       cont_instead_of_sstep = 0;

    1) set breakpoint at do_fork
    2) continue
    3)   Save the thread id where we stop to cont_thread_id
    4) Remove breakpoint at do_fork
    5) Reset the PC if needed depending on kernel exception type
    6) soft single step
    7)   Check where we stopped
           if current thread != cont_thread_id {
               if (here for more than 2 times for the same thead) {
                  ### must be a really busy system, start test again ###
    	      goto step 1
               }
               goto step 5
           } else {
               cont_instead_of_sstep = 0;
           }
    8) clean up and run test again if needed
    9) Clear out any threads that were waiting on a break point at the
       point in time the test is ended with get_cont_catch().  This
       happens sometimes because breakpoints are used in place of single
       stepping and some threads could have been in the debugger exception
       handling queue because breakpoints were hit concurrently on
       different CPUs.  This also means we wait at least one second before
       unplumbing the debugger connection at the very end, so as respond
       to any debug threads waiting to be serviced.

    Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4c5793d6886aea4a9f8f2b9f48db01be3a188480
Author: Jason Wessel <jason.wessel@windriver.com>
Date:   Thu Mar 29 17:41:24 2012 -0500

    kgdbts: (1 of 2) fix single step awareness to work correctly with SMP

    commit 486c5987a00a89d56c2c04c506417ef8f823ca2e upstream.

    The do_fork and sys_open tests have never worked properly on anything
    other than a UP configuration with the kgdb test suite.  This is
    because the test suite did not fully implement the behavior of a real
    debugger.  A real debugger tracks the state of what thread it asked to
    single step and can correctly continue other threads of execution or
    conditionally stop while waiting for the original thread single step
    request to return.

    Below is a simple method to cause a fatal kernel oops with the kgdb
    test suite on a 4 processor x86 system:

    while [ 1 ] ; do ls > /dev/null 2> /dev/null; done&
    while [ 1 ] ; do ls > /dev/null 2> /dev/null; done&
    while [ 1 ] ; do ls > /dev/null 2> /dev/null; done&
    while [ 1 ] ; do ls > /dev/null 2> /dev/null; done&
    echo V1I1F1000 > /sys/module/kgdbts/parameters/kgdbts

    Very soon after starting the test the kernel will oops with a message like:

    kgdbts: BP mismatch 3b7da66480 expected ffffffff8106a590
    WARNING: at drivers/misc/kgdbts.c:303 check_and_rewind_pc+0xe0/0x100()
    Call Trace:
     [<ffffffff812994a0>] check_and_rewind_pc+0xe0/0x100
     [<ffffffff81298945>] validate_simple_test+0x25/0xc0
     [<ffffffff81298f77>] run_simple_test+0x107/0x2c0
     [<ffffffff81298a18>] kgdbts_put_char+0x18/0x20

    The warn will turn to a hard kernel crash shortly after that because
    the pc will not get properly rewound to the right value after hitting
    a breakpoint leading to a hard lockup.

    This change is broken up into 2 pieces because archs that have hw
    single stepping (2.6.26 and up) need different changes than archs that
    do not have hw single stepping (3.0 and up).  This change implements
    the correct behavior for an arch that supports hw single stepping.

    A minor defect was fixed where sys_open should be do_sys_open
    for the sys_open break point test.  This solves the problem of running
    a 64 bit with a 32 bit user space.  The sys_open() never gets called
    when using the 32 bit file system for the kgdb testsuite because the
    32 bit binaries invoke the compat_sys_open() call leading to the test
    never completing.

    In order to mimic a real debugger, the kgdb test suite now tracks the
    most recent thread that was continued (cont_thread_id), with the
    intent to single step just this thread.  When the response to the
    single step request stops in a different thread that hit the original
    break point that thread will now get continued, while the debugger
    waits for the thread with the single step pending.  Here is a high
    level description of the sequence of events.

       cont_instead_of_sstep = 0;

    1) set breakpoint at do_fork
    2) continue
    3)   Save the thread id where we stop to cont_thread_id
    4) Remove breakpoint at do_fork
    5) Reset the PC if needed depending on kernel exception type
    6) if (cont_instead_of_sstep) { continue } else { single step }
    7)   Check where we stopped
           if current thread != cont_thread_id {
               cont_instead_of_sstep = 1;
               goto step 5
           } else {
               cont_instead_of_sstep = 0;
           }
    8) clean up and run test again if needed

    Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d7ee7c0d8270ad76adf12901fafb04c99a57accc
Author: Jason Wessel <jason.wessel@windriver.com>
Date:   Thu Mar 29 06:55:44 2012 -0500

    kgdbts: Fix kernel oops with CONFIG_DEBUG_RODATA

    commit 456ca7ff24841bf2d2a2dfd690fe7d42ef70d932 upstream.

    On x86 the kgdb test suite will oops when the kernel is compiled with
    CONFIG_DEBUG_RODATA and you run the tests after boot time. This is
    regression has existed since 2.6.26 by commit: b33cb815 (kgdbts: Use
    HW breakpoints with CONFIG_DEBUG_RODATA).

    The test suite can use hw breakpoints for all the tests, but it has to
    execute the hardware breakpoint specific tests first in order to
    determine that the hw breakpoints actually work.  Specifically the
    very first test causes an oops:

    # echo V1I1 > /sys/module/kgdbts/parameters/kgdbts
    kgdb: Registered I/O driver kgdbts.
    kgdbts:RUN plant and detach test

    Entering kdb (current=0xffff880017aa9320, pid 1078) on processor 0 due to Keyboard Entry
    [0]kdb> kgdbts: ERROR PUT: end of test buffer on 'plant_and_detach_test' line 1 expected OK got $E14#aa
    WARNING: at drivers/misc/kgdbts.c:730 run_simple_test+0x151/0x2c0()
    [...oops clipped...]

    This commit re-orders the running of the tests and puts the RODATA
    check into its own function so as to correctly avoid the kernel oops
    by detecting and using the hw breakpoints.

    Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1374668fa85ed172c982be6eda7fab795bc4fcb5
Author: Jason Wessel <jason.wessel@windriver.com>
Date:   Wed Mar 21 10:17:03 2012 -0500

    kgdb,debug_core: pass the breakpoint struct instead of address and memory

    commit 98b54aa1a2241b59372468bd1e9c2d207bdba54b upstream.

    There is extra state information that needs to be exposed in the
    kgdb_bpt structure for tracking how a breakpoint was installed.  The
    debug_core only uses the the probe_kernel_write() to install
    breakpoints, but this is not enough for all the archs.  Some arch such
    as x86 need to use text_poke() in order to install a breakpoint into a
    read only page.

    Passing the kgdb_bpt structure to kgdb_arch_set_breakpoint() and
    kgdb_arch_remove_breakpoint() allows other archs to set the type
    variable which indicates how the breakpoint was installed.

    Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 56e0f058235a7d8aca4a792e97fe65861a683cf7
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Sat Mar 24 23:51:30 2012 +0100

    drm/i915: quirk away broken OpRegion VBT

    commit 25e341cfc33d94435472983825163e97fe370a6c upstream.

    Somehow the BIOS manages to screw things up when copying the VBT
    around, because the one we scrap from the VBIOS rom actually works.

    Tested-by: Markus Heinz <markus.heinz@uni-dortmund.de>
    Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
    Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=28812
    Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4482e98a406487cf1adadd88d23b99e40ca44aa8
Author: Sean Paul <seanpaul@chromium.org>
Date:   Fri Mar 23 08:52:58 2012 -0400

    drm/i915: Add lock on drm_helper_resume_force_mode

    commit 927a2f119e8235238a2fc64871051b16c9bdae75 upstream.

    i915_drm_thaw was not locking the mode_config lock when calling
    drm_helper_resume_force_mode. When there were multiple wake sources,
    this caused FDI training failure on SNB which in turn corrupted the
    display.

    Signed-off-by: Sean Paul <seanpaul@chromium.org>
    Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
    Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 628280f36e4fdbde6c2efac3f3c574d5a41dee88
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Thu Mar 22 15:00:50 2012 +0000

    drm/i915: Sanitize BIOS debugging bits from PIPECONF

    commit f47166d2b0001fcb752b40c5a2d4db986dfbea68 upstream.

    Quoting the BSpec from time immemorial:

      PIPEACONF, bits 28:27: Frame Start Delay (Debug)

      Used to delay the frame start signal that is sent to the display planes.
      Care must be taken to insure that there are enough lines during VBLANK
      to support this setting.

    An instance of the BIOS leaving these bits set was found in the wild,
    where it caused our modesetting to go all squiffy and skewiff.

    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=47271
    Reported-and-tested-by: Eva Wang <evawang@linpus.com>
    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=43012
    Reported-and-tested-by: Carl Richell <carl@system76.com>
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b51aa5a05a594d19b900b23e54b401f453be2f90
Author: Anisse Astier <anisse@astier.eu>
Date:   Wed Mar 7 18:36:35 2012 +0100

    drm/i915: no-lvds quirk on MSI DC500

    commit 97effadb65ed08809e1720c8d3ee80b73a93665c upstream.

    This hardware doesn't have an LVDS, it's a desktop box. Fix incorrect
    LVDS detection.

    Signed-off-by: Anisse Astier <anisse@astier.eu>
    Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit df03e202e63939fd43665ef933ec88e20ca0078c
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Thu Mar 29 19:04:08 2012 -0400

    drm/radeon/kms: fix fans after resume

    commit 402976fe51b2d1a58a29ba06fa1ca5ace3a4cdcd upstream.

    On pre-R600 asics, the SpeedFanControl table is not
    executed as part of ASIC_Init as it is on newer asics.

    Fixes:
    https://bugzilla.kernel.org/show_bug.cgi?id=29412

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

commit ce6e47c818057c59786fd9a7f10c6d4bb48cb950
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Mon Mar 26 21:15:53 2012 +0100

    drm: Validate requested virtual size against allocated fb size

    commit 62fb376e214d3c1bfdf6fbb77dac162f6da04d7e upstream.

    mplayer -vo fbdev tries to create a screen that is twice as tall as the
    allocated framebuffer for "doublebuffering". By default, and all in-tree
    users, only sufficient memory is allocated and mapped to satisfy the
    smallest framebuffer and the virtual size is no larger than the actual.
    For these users, we should therefore reject any userspace request to
    create a screen that requires a buffer larger than the framebuffer
    originally allocated.

    References: https://bugs.freedesktop.org/show_bug.cgi?id=38138
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eb221774b352966c562b5c92a28d01ddc1bc4393
Author: Stanislaw Gruszka <sgruszka@redhat.com>
Date:   Mon Mar 19 16:00:26 2012 +0100

    mac80211: fix possible tid_rx->reorder_timer use after free

    commit d72308bff5c2fa207949a5925b020bce74495e33 upstream.

    Is possible that we will arm the tid_rx->reorder_timer after
    del_timer_sync() in ___ieee80211_stop_rx_ba_session(). We need to stop
    timer after RCU grace period finish, so move it to
    ieee80211_free_tid_rx(). Timer will not be armed again, as
    rcu_dereference(sta->ampdu_mlme.tid_rx[tid]) will return NULL.

    Debug object detected problem with the following warning:
    ODEBUG: free active (active state 0) object type: timer_list hint: sta_rx_agg_reorder_timer_expired+0x0/0xf0 [mac80211]

    Bug report (with all warning messages):
    https://bugzilla.redhat.com/show_bug.cgi?id=804007

    Reported-by: "jan p. springer" <jsd@igroup.org>
    Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7c11d1dd6e0c348d7ff0915842720acf373aa24c
Author: Geert Uytterhoeven <geert@linux-m68k.org>
Date:   Sun Mar 18 13:21:38 2012 +0100

    m68k/mac: Add missing platform check before registering platform devices

    commit 6cfeba53911d6d2f17ebbd1246893557d5ff5aeb upstream.

    On multi-platform kernels, the Mac platform devices should be registered
    when running on Mac only. Else it may crash later.

    Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c9f514e30019562ad19044e992248ad7865b37cd
Author: Wolfgang Mauerer <wolfgang.mauerer@siemens.com>
Date:   Thu Mar 22 11:18:20 2012 +0100

    tracing: Fix ftrace stack trace entries

    commit 01de982abf8c9e10fc3089e10585cd2cc914bdab upstream.

    8 hex characters tell only half the tale for 64 bit CPUs,
    so use the appropriate length.

    Link: http://lkml.kernel.org/r/1332411501-8059-2-git-send-email-wolfgang.mauerer@siemens.com

    Signed-off-by: Wolfgang Mauerer <wolfgang.mauerer@siemens.com>
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8132f98d51bd6a11e9d053b84c17c1af52e371f2
Author: Jiang Liu <liuj97@gmail.com>
Date:   Fri Mar 30 23:11:33 2012 +0800

    genirq: Adjust irq thread affinity on IRQ_SET_MASK_OK_NOCOPY return value

    commit f5cb92ac82d06cb583c1f66666314c5c0a4d7913 upstream.

    irq_move_masked_irq() checks the return code of
    chip->irq_set_affinity() only for 0, but IRQ_SET_MASK_OK_NOCOPY is
    also a valid return code, which is there to avoid a redundant copy of
    the cpumask. But in case of IRQ_SET_MASK_OK_NOCOPY we not only avoid
    the redundant copy, we also fail to adjust the thread affinity of an
    eventually threaded interrupt handler.

    Handle IRQ_SET_MASK_OK (==0) and IRQ_SET_MASK_OK_NOCOPY(==1) return
    values correctly by checking the valid return values seperately.

    Signed-off-by: Jiang Liu <jiang.liu@huawei.com>
    Cc: Jiang Liu <liuj97@gmail.com>
    Cc: Keping Chen <chenkeping@huawei.com>
    Link: http://lkml.kernel.org/r/1333120296-13563-2-git-send-email-jiang.liu@huawei.com
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e601f243f04282ff17b173fb7c15e6d1c6e7252f
Author: Jan Beulich <JBeulich@suse.com>
Date:   Thu Mar 8 09:41:25 2012 +0000

    modpost: fix ALL_INIT_DATA_SECTIONS

    commit 9aaf440f8fabcebf9ea79a62ccf4c212e6544b49 upstream.

    This was lacking a comma between two supposed to be separate strings.

    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Signed-off-by: Michal Marek <mmarek@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 618f8985e7f0ff20f23660f3d1ebbe34fec0a996
Author: Julian Anastasov <ja@ssi.bg>
Date:   Thu Feb 23 22:40:43 2012 +0200

    ACPICA: Fix regression in FADT revision checks

    commit 3e80acd1af40fcd91a200b0416a7616b20c5d647 upstream.

    	commit 64b3db22c04586997ab4be46dd5a5b99f8a2d390 (2.6.39),
    "Remove use of unreliable FADT revision field" causes regression
    for old P4 systems because now cst_control and other fields are
    not reset to 0.

    	The effect is that acpi_processor_power_init will notice
    cst_control != 0 and a write to CST_CNT register is performed
    that should not happen. As result, the system oopses after the
    "No _CST, giving up" message, sometimes in acpi_ns_internalize_name,
    sometimes in acpi_ns_get_type, usually at random places. May be
    during migration to CPU 1 in acpi_processor_get_throttling.

    	Every one of these settings help to avoid this problem:
     - acpi=off
     - processor.nocst=1
     - maxcpus=1

    	The fix is to update acpi_gbl_FADT.header.length after
    the original value is used to check for old revisions.

    https://bugzilla.kernel.org/show_bug.cgi?id=42700
    https://bugzilla.redhat.com/show_bug.cgi?id=727865

    Signed-off-by: Julian Anastasov <ja@ssi.bg>
    Acked-by: Bob Moore <robert.moore@intel.com>
    Signed-off-by: Len Brown <len.brown@intel.com>
    Cc: Jonathan Nieder <jrnieder@gmail.com>
    Cc: Josh Boyer <jwboyer@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f622c87aa350b3be25c98937dc4ae850aee5dee8
Author: Yinghai Lu <yinghai@kernel.org>
Date:   Sat Mar 3 13:29:20 2012 -0800

    PNPACPI: Fix device ref leaking in acpi_pnp_match

    commit 89e96ada572fb216e582dbe3f64e1a6939a37f74 upstream.

    During testing pci root bus removal, found some root bus bridge is not freed.
    If booting with pnpacpi=off, those hostbridge could be freed without problem.
    It turns out that some devices reference are not released during acpi_pnp_match.
    that match should not hold one device ref during every calling.
    Add pu_device calling before returning.

    Signed-off-by: Yinghai Lu <yinghai@kernel.org>
    Signed-off-by: Len Brown <len.brown@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d70e0fd149e70e664b1f9673a710799e1f432606
Author: Andi Kleen <andi@firstfloor.org>
Date:   Mon Feb 6 08:17:11 2012 -0800

    ACPI: Do cpufreq clamping for throttling per package v2

    commit 2815ab92ba3ab27556212cc306288dc95692824b upstream.

    On Intel CPUs the processor typically uses the highest frequency
    set by any logical CPU. When the system overheats
    Linux first forces the frequency to the lowest available one
    to lower the temperature.

    However this was done only per logical CPU, which means all
    logical CPUs in a package would need to go through this before
    the frequency is actually lowered.

    Worse this delay actually prevents real throttling, because
    the real throttle code only proceeds when the lowest frequency
    is already reached.

    So when a throttle event happens force the lowest frequency
    for all CPUs in the package where it happened. The per CPU
    state is now kept per package, not per logical CPU. An alternative
    would be to do it per cpufreq unit, but since we want to bring
    down the temperature of the complete chip it's better
    to do it for all.

    In principle it may even make sense to do it for all CPUs,
    but I kept it on the package for now.

    With this change the frequency is actually lowered, which
    in terms also allows real throttling to proceed.

    I also removed an unnecessary per cpu variable initialization.

    v2: Fix package mapping

    Signed-off-by: Andi Kleen <ak@linux.intel.com>
    Signed-off-by: Len Brown <len.brown@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 19f0f33c99c20ba6d34ab935642cf98fa23d0ca3
Author: Brian Norris <computersforpeace@gmail.com>
Date:   Tue Jan 31 00:06:03 2012 -0800

    mtd: m25p80: set writebufsize

    commit b54f47c8bcfc5f766bf13ec31bd7dd1d4726d33b upstream.

    Using UBI on m25p80 can give messages like:

        UBI error: io_init: bad write buffer size 0 for 1 min. I/O unit

    We need to initialize writebufsize; I think "page_size" is the correct
    "bufsize", although I'm not sure. Comments?

    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@linuxfoundation.org>

commit a4585d8f7a51e32175eed9cdcb85bbe7df84e035
Author: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Date:   Fri Feb 3 09:53:28 2012 +0200

    mtd: lart: initialize writebufsize

    commit fcc44a07dae0af16e84e93425fc8afe642ddc603 upstream.

    The writebufsize concept was introduce by commit
    "0e4ca7e mtd: add writebufsize field to mtd_info struct" and it represents
    the maximum amount of data the device writes to the media at a time. This is
    an important parameter for UBIFS which is used during recovery and which
    basically defines how big a corruption caused by a power cut can be.

    Set writebufsize to 4 because this drivers writes at max 4 bytes at a time.

    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@linuxfoundation.org>

commit 95821644270132ee2968204119dceb5fa005c840
Author: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Date:   Fri Feb 3 09:32:44 2012 +0200

    mtd: block2mtd: initialize writebufsize

    commit b604387411ec6a072e95910099262616edd2bd2f upstream.

    The writebufsize concept was introduce by commit
    "0e4ca7e mtd: add writebufsize field to mtd_info struct" and it represents
    the maximum amount of data the device writes to the media at a time. This is
    an important parameter for UBIFS which is used during recovery and which
    basically defines how big a corruption caused by a power cut can be.

    However, we forgot to set this parameter for block2mtd. Set it to PAGE_SIZE
    because this is actually the amount of data we write at a time.

    Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
    Acked-by: Joern Engel <joern@lazybastard.org>
    Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f18fbe02726fffd8c7dac0ff7e95c05ef81d2d47
Author: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Date:   Fri Feb 3 10:16:50 2012 +0200

    mtd: sst25l: initialize writebufsize

    commit c4cc625ea5958d065c21cc0fcea29e9ed8f3d2bc upstream.

    The writebufsize concept was introduce by commit
    "0e4ca7e mtd: add writebufsize field to mtd_info struct" and it represents
    the maximum amount of data the device writes to the media at a time. This is
    an important parameter for UBIFS which is used during recovery and which
    basically defines how big a corruption caused by a power cut can be.

    Set writebufsize to the flash page size because it is the maximum amount of
    data it writes at a time.

    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@linuxfoundation.org>

commit 4e8d37e8fccbe4a558062e4b6416dbc23dcdd8ad
Author: Rabin Vincent <rabin@rab.in>
Date:   Thu Mar 29 07:15:15 2012 +0000

    net: usb: cdc_eem: fix mtu

    [ Upstream commit 78fb72f7936c01d5b426c03a691eca082b03f2b9 ]

    Make CDC EEM recalculate the hard_mtu after adjusting the
    hard_header_len.

    Without this, usbnet adjusts the MTU down to 1494 bytes, and the host is
    unable to receive standard 1500-byte frames from the device.

    Tested with the Linux USB Ethernet gadget.

    Cc: Oliver Neukum <oliver@neukum.name>
    Signed-off-by: Rabin Vincent <rabin@rab.in>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cea90bebaab0e962cf9a954ef41cc1893da7b3bf
Author: danborkmann@iogearbox.net <danborkmann@iogearbox.net>
Date:   Tue Mar 27 22:47:43 2012 +0000

    rose_dev: fix memcpy-bug in rose_set_mac_address

    [ Upstream commit 81213b5e8ae68e204aa7a3f83c4f9100405dbff9 ]

    If both addresses equal, nothing needs to be done. If the device is down,
    then we simply copy the new address to dev->dev_addr. If the device is up,
    then we add another loopback device with the new address, and if that does
    not fail, we remove the loopback device with the old address. And only
    then, we update the dev->dev_addr.

    Signed-off-by: Daniel Borkmann <daniel.borkmann@tik.ee.ethz.ch>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 62a48bcddfa2b4cabef5b58564cb7d843658fe19
Author: zhuangfeiran@ict.ac.cn <zhuangfeiran@ict.ac.cn>
Date:   Wed Mar 28 23:27:00 2012 +0000

    x86 bpf_jit: fix a bug in emitting the 16-bit immediate operand of AND

    [ Upstream commit 1d24fb3684f347226747c6b11ea426b7b992694e ]

    When K >= 0xFFFF0000, AND needs the two least significant bytes of K as
    its operand, but EMIT2() gives it the least significant byte of K and
    0x2. EMIT() should be used here to replace EMIT2().

    Signed-off-by: Feiran Zhuang  <zhuangfeiran@ict.ac.cn>
    Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>