Linux 3.0.22

commit a4a663513af05a98d6085d92f85c16bb64ac4050
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Mon Feb 20 13:43:19 2012 -0800

    Linux 3.0.22

commit 7b5644ec051e133d59249b7f19d2d8fef9a8d323
Author: Alexey Dobriyan <adobriyan@gmail.com>
Date:   Sat Jan 14 21:44:49 2012 +0300

    crypto: sha512 - use standard ror64()

    commit f2ea0f5f04c97b48c88edccba52b0682fbe45087 upstream.

    Use standard ror64() instead of hand-written.
    There is no standard ror64, so create it.

    The difference is shift value being "unsigned int" instead of uint64_t
    (for which there is no reason). gcc starts to emit native ROR instructions
    which it doesn't do for some reason currently. This should make the code
    faster.

    Patch survives in-tree crypto test and ping flood with hmac(sha512) on.

    Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 16c7560fcca939095d099da4316f2df66aebc3ba
Author: Eric Dumazet <eric.dumazet@gmail.com>
Date:   Tue Dec 13 04:57:06 2011 +0100

    slub: fix a possible memleak in __slab_alloc()

    commit 73736e0387ba0e6d2b703407b4d26168d31516a7 upstream.

    Zhihua Che reported a possible memleak in slub allocator on
    CONFIG_PREEMPT=y builds.

    It is possible current thread migrates right before disabling irqs in
    __slab_alloc(). We must check again c->freelist, and perform a normal
    allocation instead of scratching c->freelist.

    Many thanks to Zhihua Che for spotting this bug, introduced in 2.6.39

    V2: Its also possible an IRQ freed one (or several) object(s) and
    populated c->freelist, so its not a CONFIG_PREEMPT only problem.

    Reported-by: Zhihua Che <zhihua.che@gmail.com>
    Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
    Acked-by: Christoph Lameter <cl@linux.com>
    Signed-off-by: Pekka Enberg <penberg@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d3a6a79cfe7641d797ab74eea55b93e0f35f66d7
Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date:   Mon Jan 30 14:31:46 2012 +0000

    xen pvhvm: do not remap pirqs onto evtchns if !xen_have_vector_callback

    commit 207d543f472c1ac9552df79838dc807cbcaa9740 upstream.

    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c17b9573c236874b9a8a6c4c03c02accf70c9cd5
Author: Daniel T Chen <crimsun@ubuntu.com>
Date:   Mon Feb 13 23:44:22 2012 -0500

    ALSA: intel8x0: Fix default inaudible sound on Gateway M520

    commit 27c3afe6e1cf129faac90405121203962da08ff4 upstream.

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

    The reporter states that audio is inaudible by default without muting
    'External Amplifier'. Add a quirk to handle his SSID so that changing
    the control is not necessary.

    Reported-and-tested-by: Benjamin Carlson <elderbubba0810@gmail.com>
    Signed-off-by: Daniel T Chen <crimsun@ubuntu.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c29e3ddfbd904f0b7cf600c04c4263c71c1f4830
Author: Herbert Xu <herbert@gondor.apana.org.au>
Date:   Sun Feb 5 15:09:28 2012 +1100

    crypto: sha512 - Avoid stack bloat on i386

    commit 3a92d687c8015860a19213e3c102cad6b722f83c upstream.

    Unfortunately in reducing W from 80 to 16 we ended up unrolling
    the loop twice.  As gcc has issues dealing with 64-bit ops on
    i386 this means that we end up using even more stack space (>1K).

    This patch solves the W reduction by moving LOAD_OP/BLEND_OP
    into the loop itself, thus avoiding the need to duplicate it.

    While the stack space still isn't great (>0.5K) it is at least
    in the same ball park as the amount of stack used for our C sha1
    implementation.

    Note that this patch basically reverts to the original code so
    the diff looks bigger than it really is.

    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d122aed32ad780e0c337551121c36a5d5e1c2ee0
Author: Herbert Xu <herbert@gondor.apana.org.au>
Date:   Thu Jan 26 15:03:16 2012 +1100

    crypto: sha512 - Use binary and instead of modulus

    commit 58d7d18b5268febb8b1391c6dffc8e2aaa751fcd upstream.

    The previous patch used the modulus operator over a power of 2
    unnecessarily which may produce suboptimal binary code.  This
    patch changes changes them to binary ands instead.

    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0f74c152fd01e1070c141eb10c70cc0f6fb39e22
Author: Nikolaus Schulz <schulz@macnetix.de>
Date:   Wed Feb 8 18:56:08 2012 +0100

    hwmon: (f75375s) Fix automatic pwm mode setting for F75373 & F75375

    commit 09e87e5c4f9af656af2a8a3afc03487c5d9287c3 upstream.

    In order to enable temperature mode aka automatic mode for the F75373 and
    F75375 chips, the two FANx_MODE bits in the fan configuration register
    need be set to 01, not 10.

    Signed-off-by: Nikolaus Schulz <mail@microschulz.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8a6e41581a4537b53c038a328c558d455a6f3e3a
Author: David Jander <david@protonic.nl>
Date:   Wed Jun 8 11:37:45 2011 -0600

    gpio/pca953x: Fix warning of enabled interrupts in handler

    commit 6dd599f8af0166805951f4421a78ba716d78321a upstream.

    When using nested threaded irqs, use handle_nested_irq(). This function
    does not call the chip handler, so no handler is set.

    Signed-off-by: David Jander <david@protonic.nl>
    Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
    Cc: Steven Rostedt <rostedt@goodmis.org>
    Cc: Yong Zhang <yong.zhang0@gmail.com>
    Cc: Manfred Gruber <m.gruber@unverspurt.at>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a5e2201319ef3c88cf8d777466c0e097625ba942
Author: Wu Fengguang <fengguang.wu@intel.com>
Date:   Sat Feb 4 20:54:03 2012 -0600

    writeback: fix dereferencing NULL bdi->dev on trace_writeback_queue

    commit 977b7e3a52a7421ad33a393a38ece59f3d41c2fa upstream.

    When a SD card is hot removed without umount, del_gendisk() will call
    bdi_unregister() without destroying/freeing it. This leaves the bdi in
    the bdi->dev = NULL, bdi->wb.task = NULL, bdi->bdi_list removed state.

    When sync(2) gets the bdi before bdi_unregister() and calls
    bdi_queue_work() after the unregister, trace_writeback_queue will be
    dereferencing the NULL bdi->dev. Fix it with a simple test for NULL.

    LKML-reference: http://lkml.org/lkml/2012/1/18/346
    Reported-by: Rabin Vincent <rabin@rab.in>
    Tested-by: Namjae Jeon <linkinjeon@gmail.com>
    Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 36935521cd67e3df9a1db71591cf224252d6082c
Author: Eliad Peller <eliad@wizery.com>
Date:   Wed Feb 1 18:48:09 2012 +0200

    mac80211: timeout a single frame in the rx reorder buffer

    commit 07ae2dfcf4f7143ce191c6436da1c33f179af0d6 upstream.

    The current code checks for stored_mpdu_num > 1, causing
    the reorder_timer to be triggered indefinitely, but the
    frame is never timed-out (until the next packet is received)

    Signed-off-by: Eliad Peller <eliad@wizery.com>
    Acked-by: Johannes Berg <johannes@sipsolutions.net>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4ac2f3d3f1d4a08ad6a450127c4b0f590fe28bdf
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Fri Feb 10 09:03:58 2012 +0100

    relay: prevent integer overflow in relay_open()

    commit f6302f1bcd75a042df69866d98b8d775a668f8f1 upstream.

    "subbuf_size" and "n_subbufs" come from the user and they need to be
    capped to prevent an integer overflow.

    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9a3626a437ddbc0d8e60bda9480739cd850bb48f
Author: Wu Fengguang <fengguang.wu@intel.com>
Date:   Mon Jan 9 11:53:50 2012 -0600

    lib: proportion: lower PROP_MAX_SHIFT to 32 on 64-bit kernel

    commit 3310225dfc71a35a2cc9340c15c0e08b14b3c754 upstream.

    PROP_MAX_SHIFT should be set to <=32 on 64-bit box. This fixes two bugs
    in the below lines of bdi_dirty_limit():

    	bdi_dirty *= numerator;
    	do_div(bdi_dirty, denominator);

    1) divide error: do_div() only uses the lower 32 bit of the denominator,
       which may trimmed to be 0 when PROP_MAX_SHIFT > 32.

    2) overflow: (bdi_dirty * numerator) could easily overflow if numerator
       used up to 48 bits, leaving only 16 bits to bdi_dirty

    Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Reported-by: Ilya Tumaykin <librarian_rus@yahoo.com>
    Tested-by: Ilya Tumaykin <librarian_rus@yahoo.com>
    Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eafbec56be4c3cfd8f3b5098a0c5f7397a1e48b0
Author: Nikolaus Schulz <schulz@macnetix.de>
Date:   Wed Feb 8 18:56:10 2012 +0100

    hwmon: (f75375s) Fix bit shifting in f75375_write16

    commit eb2f255b2d360df3f500042a2258dcf2fcbe89a2 upstream.

    In order to extract the high byte of the 16-bit word, shift the word to
    the right, not to the left.

    Signed-off-by: Nikolaus Schulz <mail@microschulz.de>
    Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0eac4fa19d910c7ce80e48b89eaec1f08bc816ef
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Wed Feb 8 16:42:52 2012 +0100

    drm/i915: no lvds quirk for AOpen MP45

    commit e57b6886f555ab57f40a01713304e2053efe51ec upstream.

    According to a bug report, it doesn't have one.

    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44263
    Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
    Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Keith Packard <keithp@keithp.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f021e004b62bf213e3dfa70f747f1d3d6304fa6b
Author: Jiri Olsa <jolsa@redhat.com>
Date:   Mon Feb 6 18:54:06 2012 -0200

    perf tools: Fix perf stack to non executable on x86_64

    commit 7a0153ee15575a4d07b5da8c96b79e0b0fd41a12 upstream.

    By adding following objects:
      bench/mem-memcpy-x86-64-asm.o
    the x86_64 perf binary ended up with executable stack.

    The reason was that above object are assembler sourced and is missing the
    GNU-stack note section. In such case the linker assumes that the final binary
    should not be restricted at all and mark the stack as RWX.

    Adding section ".note.GNU-stack" definition to mentioned object, with all
    flags disabled, thus omiting this object from linker stack flags decision.

    Problem introduced in:

      $ git describe ea7872b
      v2.6.37-rc2-19-gea7872b

    Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=783570
    Reported-by: Clark Williams <williams@redhat.com>
    Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
    Cc: Corey Ashford <cjashfor@linux.vnet.ibm.com>
    Cc: Ingo Molnar <mingo@elte.hu>
    Cc: Paul Mackerras <paulus@samba.org>
    Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Link: http://lkml.kernel.org/r/1328100848-5630-1-git-send-email-jolsa@redhat.com
    Signed-off-by: Jiri Olsa <jolsa@redhat.com>
    [ committer note: Backported fix to perf/urgent (3.3-rc2+) ]
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 795f18956b547f0cfbcaa6d907d2bb05726a6a3e
Author: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
Date:   Fri Feb 3 22:31:13 2012 +0530

    perf evsel: Fix an issue where perf report fails to show the proper percentage

    commit a4a03fc7ef89020baca4f19174e6a43767c6d78a upstream.

    This patch fixes an issue where perf report shows nan% for certain
    perf.data files. The below is from a report for a do_fork probe:

       -nan%           sshd  [kernel.kallsyms]  [k] do_fork
       -nan%    packagekitd  [kernel.kallsyms]  [k] do_fork
       -nan%    dbus-daemon  [kernel.kallsyms]  [k] do_fork
       -nan%           bash  [kernel.kallsyms]  [k] do_fork

    A git bisect shows commit f3bda2c as the cause. However, looking back
    through the git history, I saw commit 640c03c which seems to have
    removed the required initialization for perf_sample->period. The problem
    only started showing after commit f3bda2c. The below patch re-introduces
    the initialization and it fixes the problem for me.

    With the below patch, for the same perf.data:

      73.08%             bash  [kernel.kallsyms]  [k] do_fork
       8.97%      11-dhclient  [kernel.kallsyms]  [k] do_fork
       6.41%             sshd  [kernel.kallsyms]  [k] do_fork
       3.85%        20-chrony  [kernel.kallsyms]  [k] do_fork
       2.56%         sendmail  [kernel.kallsyms]  [k] do_fork

    This patch applies over current linux-tip commit 9949284.

    Problem introduced in:

    $ git describe 640c03c
    v2.6.37-rc3-83-g640c03c

    Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
    Cc: Ingo Molnar <mingo@elte.hu>
    Cc: Robert Richter <robert.richter@amd.com>
    Cc: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
    Link: http://lkml.kernel.org/r/20120203170113.5190.25558.stgit@localhost6.localdomain6
    Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Linux 3.0.23

commit bf6a68d2a214e07f7c0d6538e00e17b826714160
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Wed Feb 29 16:35:02 2012 -0800

    Linux 3.0.23

commit 6b06abace47c8ac0afb6cac21a133b85cd296e50
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Mon Feb 6 10:20:45 2012 +0100

    cdrom: use copy_to_user() without the underscores

    commit 822bfa51ce44f2c63c300fdb76dc99c4d5a5ca9f upstream.

    "nframes" comes from the user and "nframes * CD_FRAMESIZE_RAW" can wrap
    on 32 bit systems.  That would have been ok if we used the same wrapped
    value for the copy, but we use a shifted value.  We should just use the
    checked version of copy_to_user() because it's not going to make a
    difference to the speed.

    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 547740231f76185aadbef34dfa83c3e7dba3b34b
Author: Jason Baron <jbaron@redhat.com>
Date:   Thu Jan 12 17:17:43 2012 -0800

    epoll: limit paths

    commit 28d82dc1c4edbc352129f97f4ca22624d1fe61de upstream.

    The current epoll code can be tickled to run basically indefinitely in
    both loop detection path check (on ep_insert()), and in the wakeup paths.
    The programs that tickle this behavior set up deeply linked networks of
    epoll file descriptors that cause the epoll algorithms to traverse them
    indefinitely.  A couple of these sample programs have been previously
    posted in this thread: https://lkml.org/lkml/2011/2/25/297.

    To fix the loop detection path check algorithms, I simply keep track of
    the epoll nodes that have been already visited.  Thus, the loop detection
    becomes proportional to the number of epoll file descriptor and links.
    This dramatically decreases the run-time of the loop check algorithm.  In
    one diabolical case I tried it reduced the run-time from 15 mintues (all
    in kernel time) to .3 seconds.

    Fixing the wakeup paths could be done at wakeup time in a similar manner
    by keeping track of nodes that have already been visited, but the
    complexity is harder, since there can be multiple wakeups on different
    cpus...Thus, I've opted to limit the number of possible wakeup paths when
    the paths are created.

    This is accomplished, by noting that the end file descriptor points that
    are found during the loop detection pass (from the newly added link), are
    actually the sources for wakeup events.  I keep a list of these file
    descriptors and limit the number and length of these paths that emanate
    from these 'source file descriptors'.  In the current implemetation I
    allow 1000 paths of length 1, 500 of length 2, 100 of length 3, 50 of
    length 4 and 10 of length 5.  Note that it is sufficient to check the
    'source file descriptors' reachable from the newly added link, since no
    other 'source file descriptors' will have newly added links.  This allows
    us to check only the wakeup paths that may have gotten too long, and not
    re-check all possible wakeup paths on the system.

    In terms of the path limit selection, I think its first worth noting that
    the most common case for epoll, is probably the model where you have 1
    epoll file descriptor that is monitoring n number of 'source file
    descriptors'.  In this case, each 'source file descriptor' has a 1 path of
    length 1.  Thus, I believe that the limits I'm proposing are quite
    reasonable and in fact may be too generous.  Thus, I'm hoping that the
    proposed limits will not prevent any workloads that currently work to
    fail.

    In terms of locking, I have extended the use of the 'epmutex' to all
    epoll_ctl add and remove operations.  Currently its only used in a subset
    of the add paths.  I need to hold the epmutex, so that we can correctly
    traverse a coherent graph, to check the number of paths.  I believe that
    this additional locking is probably ok, since its in the setup/teardown
    paths, and doesn't affect the running paths, but it certainly is going to
    add some extra overhead.  Also, worth noting is that the epmuex was
    recently added to the ep_ctl add operations in the initial path loop
    detection code using the argument that it was not on a critical path.

    Another thing to note here, is the length of epoll chains that is allowed.
    Currently, eventpoll.c defines:

    /* Maximum number of nesting allowed inside epoll sets */
    #define EP_MAX_NESTS 4

    This basically means that I am limited to a graph depth of 5 (EP_MAX_NESTS
    + 1).  However, this limit is currently only enforced during the loop
    check detection code, and only when the epoll file descriptors are added
    in a certain order.  Thus, this limit is currently easily bypassed.  The
    newly added check for wakeup paths, stricly limits the wakeup paths to a
    length of 5, regardless of the order in which ep's are linked together.
    Thus, a side-effect of the new code is a more consistent enforcement of
    the graph depth.

    Thus far, I've tested this, using the sample programs previously
    mentioned, which now either return quickly or return -EINVAL.  I've also
    testing using the piptest.c epoll tester, which showed no difference in
    performance.  I've also created a number of different epoll networks and
    tested that they behave as expectded.

    I believe this solves the original diabolical test cases, while still
    preserving the sane epoll nesting.

    Signed-off-by: Jason Baron <jbaron@redhat.com>
    Cc: Nelson Elhage <nelhage@ksplice.com>
    Cc: Davide Libenzi <davidel@xmailserver.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 d10e3b2952f0df0f23896e32ed54a5a6c916058e
Author: Oleg Nesterov <oleg@redhat.com>
Date:   Fri Feb 24 20:07:29 2012 +0100

    epoll: ep_unregister_pollwait() can use the freed pwq->whead

    commit 971316f0503a5c50633d07b83b6db2f15a3a5b00 upstream.

    signalfd_cleanup() ensures that ->signalfd_wqh is not used, but
    this is not enough. eppoll_entry->whead still points to the memory
    we are going to free, ep_unregister_pollwait()->remove_wait_queue()
    is obviously unsafe.

    Change ep_poll_callback(POLLFREE) to set eppoll_entry->whead = NULL,
    change ep_unregister_pollwait() to check pwq->whead != NULL under
    rcu_read_lock() before remove_wait_queue(). We add the new helper,
    ep_remove_wait_queue(), for this.

    This works because sighand_cachep is SLAB_DESTROY_BY_RCU and because
    ->signalfd_wqh is initialized in sighand_ctor(), not in copy_sighand.
    ep_unregister_pollwait()->remove_wait_queue() can play with already
    freed and potentially reused ->sighand, but this is fine. This memory
    must have the valid ->signalfd_wqh until rcu_read_unlock().

    Reported-by: Maxime Bizon <mbizon@freebox.fr>
    Signed-off-by: Oleg Nesterov <oleg@redhat.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 391d7bfe9ce7a08a700f1ff3dc950a347b23e3cb
Author: Oleg Nesterov <oleg@redhat.com>
Date:   Fri Feb 24 20:07:11 2012 +0100

    epoll: introduce POLLFREE to flush ->signalfd_wqh before kfree()

    commit d80e731ecab420ddcb79ee9d0ac427acbc187b4b upstream.

    This patch is intentionally incomplete to simplify the review.
    It ignores ep_unregister_pollwait() which plays with the same wqh.
    See the next change.

    epoll assumes that the EPOLL_CTL_ADD'ed file controls everything
    f_op->poll() needs. In particular it assumes that the wait queue
    can't go away until eventpoll_release(). This is not true in case
    of signalfd, the task which does EPOLL_CTL_ADD uses its ->sighand
    which is not connected to the file.

    This patch adds the special event, POLLFREE, currently only for
    epoll. It expects that init_poll_funcptr()'ed hook should do the
    necessary cleanup. Perhaps it should be defined as EPOLLFREE in
    eventpoll.

    __cleanup_sighand() is changed to do wake_up_poll(POLLFREE) if
    ->signalfd_wqh is not empty, we add the new signalfd_cleanup()
    helper.

    ep_poll_callback(POLLFREE) simply does list_del_init(task_list).
    This make this poll entry inconsistent, but we don't care. If you
    share epoll fd which contains our sigfd with another process you
    should blame yourself. signalfd is "really special". I simply do
    not know how we can define the "right" semantics if it used with
    epoll.

    The main problem is, epoll calls signalfd_poll() once to establish
    the connection with the wait queue, after that signalfd_poll(NULL)
    returns the different/inconsistent results depending on who does
    EPOLL_CTL_MOD/signalfd_read/etc. IOW: apart from sigmask, signalfd
    has nothing to do with the file, it works with the current thread.

    In short: this patch is the hack which tries to fix the symptoms.
    It also assumes that nobody can take tasklist_lock under epoll
    locks, this seems to be true.

    Note:

    	- we do not have wake_up_all_poll() but wake_up_poll()
    	  is fine, poll/epoll doesn't use WQ_FLAG_EXCLUSIVE.

    	- signalfd_cleanup() uses POLLHUP along with POLLFREE,
    	  we need a couple of simple changes in eventpoll.c to
    	  make sure it can't be "lost".

    Reported-by: Maxime Bizon <mbizon@freebox.fr>
    Signed-off-by: Oleg Nesterov <oleg@redhat.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 809a6d6fddb556579e651ad1fb652d6012f8a102
Author: Nikolaus Schulz <schulz@macnetix.de>
Date:   Wed Feb 22 23:18:44 2012 +0100

    hwmon: (f75375s) Fix register write order when setting fans to full speed

    commit c1c1a3d012fe5e82a9a025fb4b5a4f8ee67a53f6 upstream.

    By hwmon sysfs interface convention, setting pwm_enable to zero sets a fan
    to full speed.  In the f75375s driver, this need be done by enabling
    manual fan control, plus duty mode for the F875387 chip, and then setting
    the maximum duty cycle.  Fix a bug where the two necessary register writes
    were swapped, effectively discarding the setting to full-speed.

    Signed-off-by: Nikolaus Schulz <mail@microschulz.de>
    Cc: Riku Voipio <riku.voipio@iki.fi>
    Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c79db0b57006fddace56ac038e7340bdea18077b
Author: Janne Grunau <j@jannau.net>
Date:   Thu Feb 2 13:35:21 2012 -0300

    hdpvr: fix race conditon during start of streaming

    commit afa159538af61f1a65d48927f4e949fe514fb4fc upstream.

    status has to be set to STREAMING before the streaming worker is
    queued. hdpvr_transmit_buffers() will exit immediately otherwise.

    Reported-by: Joerg Desch <vvd.joede@googlemail.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 674b8d57dbaaed07f3825584c856b977716ec3bd
Author: Ben Hutchings <ben@decadent.org.uk>
Date:   Wed Feb 15 14:17:29 2012 +0000

    builddeb: Don't create files in /tmp with predictable names

    commit 6c635224602d760c1208ada337562f40d8ae93a5 upstream.

    The current use of /tmp for file lists is insecure.  Put them under
    $objtree/debian instead.

    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Acked-by: maximilian attems <max@stro.at>
    Signed-off-by: Michal Marek <mmarek@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 841099b95f7490cb33f1af48aac8e619ba1712c7
Author: Christian Riesch <christian.riesch@omicron.at>
Date:   Thu Feb 23 01:14:17 2012 +0000

    davinci_emac: Do not free all rx dma descriptors during init

    commit 5d69703263d588dbb03f4e57091afd8942d96e6d upstream.

    This patch fixes a regression that was introduced by

    commit 0a5f38467765ee15478db90d81e40c269c8dda20
    davinci_emac: Add Carrier Link OK check in Davinci RX Handler

    Said commit adds a check whether the carrier link is ok. If the link is
    not ok, the skb is freed and no new dma descriptor added to the rx dma
    channel. This causes trouble during initialization when the carrier
    status has not yet been updated. If a lot of packets are received while
    netif_carrier_ok returns false, all dma descriptors are freed and the
    rx dma transfer is stopped.

    The bug occurs when the board is connected to a network with lots of
    traffic and the ifconfig down/up is done, e.g., when reconfiguring
    the interface with DHCP.

    The bug can be reproduced by flood pinging the davinci board while doing
    ifconfig eth0 down
    ifconfig eth0 up
    on the board.

    After that, the rx path stops working and the overrun value reported
    by ifconfig is counting up.

    This patch reverts commit 0a5f38467765ee15478db90d81e40c269c8dda20
    and instead issues warnings only if cpdma_chan_submit returns -ENOMEM.

    Signed-off-by: Christian Riesch <christian.riesch@omicron.at>
    Cc: <stable@vger.kernel.org>
    Cc: Cyril Chemparathy <cyril@ti.com>
    Cc: Sascha Hauer <s.hauer@pengutronix.de>
    Tested-by: Rajashekhara, Sudhakar <sudhakar.raj@ti.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 405b695987efa52866d0df612cdb67d71daf055d
Author: Guo-Fu Tseng <cooldavid@cooldavid.org>
Date:   Wed Feb 22 08:58:10 2012 +0000

    jme: Fix FIFO flush issue

    commit ba9adbe67e288823ac1deb7f11576ab5653f833e upstream.

    Set the RX FIFO flush watermark lower.
    According to Federico and JMicron's reply,
    setting it to 16QW would be stable on most platforms.
    Otherwise, user might experience packet drop issue.

    Reported-by: Federico Quagliata <federico@quagliata.org>
    Fixed-by: Federico Quagliata <federico@quagliata.org>
    Signed-off-by: Guo-Fu Tseng <cooldavid@cooldavid.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 426f45680cc71385a8929f11654c789f5019315c
Author: Simon Horman <horms@verge.net.au>
Date:   Fri Jan 27 10:45:27 2012 +0900

    ipvs: fix matching of fwmark templates during scheduling

    commit e0aac52e17a3db68fe2ceae281780a70fc69957f upstream.

    	Commit f11017ec2d1859c661f4e2b12c4a8d250e1f47cf (2.6.37)
    moved the fwmark variable in subcontext that is invalidated before
    reaching the ip_vs_ct_in_get call. As vaddr is provided as pointer
    in the param structure make sure the fwmark variable is in
    same context. As the fwmark templates can not be matched,
    more and more template connections are created and the
    controlled connections can not go to single real server.

    Signed-off-by: Julian Anastasov <ja@ssi.bg>
    Signed-off-by: Simon Horman <horms@verge.net.au>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4b3b9e9efc80ceae3370e42009ec17b682776734
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Fri Feb 17 16:25:08 2012 -0500

    scsi_pm: Fix bug in the SCSI power management handler

    commit fea6d607e154cf96ab22254ccb48addfd43d4cb5 upstream.

    This patch (as1520) fixes a bug in the SCSI layer's power management
    implementation.

    LUN scanning can be carried out asynchronously in do_scan_async(), and
    sd uses an asynchronous thread for the time-consuming parts of disk
    probing in sd_probe_async().  Currently nothing coordinates these
    async threads with system sleep transitions; they can and do attempt
    to continue scanning/probing SCSI devices even after the host adapter
    has been suspended.  As one might expect, the outcome is not ideal.

    This is what the "prepare" stage of system suspend was created for.
    After the prepare callback has been called for a host, target, or
    device, drivers are not allowed to register any children underneath
    them.  Currently the SCSI prepare callback is not implemented; this
    patch rectifies that omission.

    For SCSI hosts, the prepare routine calls scsi_complete_async_scans()
    to wait until async scanning is finished.  It might be slightly more
    efficient to wait only until the host in question has been scanned,
    but there's currently no way to do that.  Besides, during a sleep
    transition we will ultimately have to wait until all the host scanning
    has finished anyway.

    For SCSI devices, the prepare routine calls async_synchronize_full()
    to wait until sd probing is finished.  The routine does nothing for
    SCSI targets, because asynchronous target scanning is done only as
    part of host scanning.

    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bbfe8a71f0a352ffaf4b8e390024b0ebb90f1030
Author: Huajun Li <huajun.li.lee@gmail.com>
Date:   Sun Feb 12 19:59:14 2012 +0800

    scsi_scan: Fix 'Poison overwritten' warning caused by using freed 'shost'

    commit 267a6ad4aefaafbde607804c60945bcf97f91c1b upstream.

    In do_scan_async(), calling scsi_autopm_put_host(shost) may reference
    freed shost, and cause Posison overwitten warning.
    Yes, this case can happen, for example, an USB is disconnected just
    when do_scan_async() thread starts to run, then scsi_host_put() called
    in scsi_finish_async_scan() will lead to shost be freed(because the
    refcount of shost->shost_gendev decreases to 1 after USB disconnects),
    at this point, if references shost again, system will show following
    warning msg.

    To make scsi_autopm_put_host(shost) always reference a valid shost,
    put it just before scsi_host_put() in function
    scsi_finish_async_scan().

    [  299.281565] =============================================================================
    [  299.281634] BUG kmalloc-4096 (Tainted: G          I ): Poison overwritten
    [  299.281682] -----------------------------------------------------------------------------
    [  299.281684]
    [  299.281752] INFO: 0xffff880056c305d0-0xffff880056c305d0. First byte
    0x6a instead of 0x6b
    [  299.281816] INFO: Allocated in scsi_host_alloc+0x4a/0x490 age=1688
    cpu=1 pid=2004
    [  299.281870] 	__slab_alloc+0x617/0x6c1
    [  299.281901] 	__kmalloc+0x28c/0x2e0
    [  299.281931] 	scsi_host_alloc+0x4a/0x490
    [  299.281966] 	usb_stor_probe1+0x5b/0xc40 [usb_storage]
    [  299.282010] 	storage_probe+0xa4/0xe0 [usb_storage]
    [  299.282062] 	usb_probe_interface+0x172/0x330 [usbcore]
    [  299.282105] 	driver_probe_device+0x257/0x3b0
    [  299.282138] 	__driver_attach+0x103/0x110
    [  299.282171] 	bus_for_each_dev+0x8e/0xe0
    [  299.282201] 	driver_attach+0x26/0x30
    [  299.282230] 	bus_add_driver+0x1c4/0x430
    [  299.282260] 	driver_register+0xb6/0x230
    [  299.282298] 	usb_register_driver+0xe5/0x270 [usbcore]
    [  299.282337] 	0xffffffffa04ab03d
    [  299.282364] 	do_one_initcall+0x47/0x230
    [  299.282396] 	sys_init_module+0xa0f/0x1fe0
    [  299.282429] INFO: Freed in scsi_host_dev_release+0x18a/0x1d0 age=85
    cpu=0 pid=2008
    [  299.282482] 	__slab_free+0x3c/0x2a1
    [  299.282510] 	kfree+0x296/0x310
    [  299.282536] 	scsi_host_dev_release+0x18a/0x1d0
    [  299.282574] 	device_release+0x74/0x100
    [  299.282606] 	kobject_release+0xc7/0x2a0
    [  299.282637] 	kobject_put+0x54/0xa0
    [  299.282668] 	put_device+0x27/0x40
    [  299.282694] 	scsi_host_put+0x1d/0x30
    [  299.282723] 	do_scan_async+0x1fc/0x2b0
    [  299.282753] 	kthread+0xdf/0xf0
    [  299.282782] 	kernel_thread_helper+0x4/0x10
    [  299.282817] INFO: Slab 0xffffea00015b0c00 objects=7 used=7 fp=0x
          (null) flags=0x100000000004080
    [  299.282882] INFO: Object 0xffff880056c30000 @offset=0 fp=0x          (null)
    [  299.282884]
    ...

    Signed-off-by: Huajun Li <huajun.li.lee@gmail.com>
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fd844dabebb45631b2e99a02ee6601ca136f10bd
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Wed Feb 8 11:57:52 2012 +0100

    genirq: Handle pending irqs in irq_startup()

    commit b4bc724e82e80478cba5fe9825b62e71ddf78757 upstream.

    An interrupt might be pending when irq_startup() is called, but the
    startup code does not invoke the resend logic. In some cases this
    prevents the device from issuing another interrupt which renders the
    device non functional.

    Call the resend function in irq_startup() to keep things going.

    Reported-and-tested-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b7f0787da3657100fe8fc8b3f0565b0bee341510
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Tue Feb 7 17:58:03 2012 +0100

    genirq: Unmask oneshot irqs when thread was not woken

    commit ac5637611150281f398bb7a47e3fcb69a09e7803 upstream.

    When the primary handler of an interrupt which is marked IRQ_ONESHOT
    returns IRQ_HANDLED or IRQ_NONE, then the interrupt thread is not
    woken and the unmask logic of the interrupt line is never
    invoked. This keeps the interrupt masked forever.

    This was not noticed as most IRQ_ONESHOT users wake the thread
    unconditionally (usually because they cannot access the underlying
    device from hard interrupt context). Though this behaviour was nowhere
    documented and not necessarily intentional. Some drivers can avoid the
    thread wakeup in certain cases and run into the situation where the
    interrupt line s kept masked.

    Handle it gracefully.

    Reported-and-tested-by: Lothar Wassmann <lw@karo-electronics.de>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6778e220c09cdfb19a326192fd25ee146755b95d
Author: Pavel Roskin <proski@gnu.org>
Date:   Sat Feb 11 10:01:53 2012 -0500

    ath9k: stop on rates with idx -1 in ath9k rate control's .tx_status

    commit 2504a6423b9ab4c36df78227055995644de19edb upstream.

    Rate control algorithms are supposed to stop processing when they
    encounter a rate with the index -1.  Checking for rate->count not being
    zero is not enough.

    Allowing a rate with negative index leads to memory corruption in
    ath_debug_stat_rc().

    One consequence of the bug is discussed at
    https://bugzilla.redhat.com/show_bug.cgi?id=768639

    Signed-off-by: Pavel Roskin <proski@gnu.org>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 534b465e1cf6e3bbceebbc7866a204107b83eb95
Author: Andreas Herrmann <andreas.herrmann3@amd.com>
Date:   Wed Feb 8 20:52:29 2012 +0100

    x86/amd: Fix L1i and L2 cache sharing information for AMD family 15h processors

    commit 32c3233885eb10ac9cb9410f2f8cd64b8df2b2a1 upstream.

    For L1 instruction cache and L2 cache the shared CPU information
    is wrong. On current AMD family 15h CPUs those caches are shared
    between both cores of a compute unit.

    This fixes https://bugzilla.kernel.org/show_bug.cgi?id=42607

    Signed-off-by: Andreas Herrmann <andreas.herrmann3@amd.com>
    Cc: Petkov Borislav <Borislav.Petkov@amd.com>
    Cc: Dave Jones <davej@redhat.com>
    Link: http://lkml.kernel.org/r/20120208195229.GA17523@alberich.amd.com
    Signed-off-by: Ingo Molnar <mingo@elte.hu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5fa70afe044fc0ede6c5ac99c60533e5867ea346
Author: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Date:   Thu Feb 23 13:20:13 2012 -0800

    USB: Don't fail USB3 probe on missing legacy PCI IRQ.

    commit 68d07f64b8a11a852d48d1b05b724c3e20c0d94b upstream

    Intel has a PCI USB xhci host controller on a new platform. It doesn't
    have a line IRQ definition in BIOS.  The Linux driver refuses to
    initialize this controller, but Windows works well because it only depends
    on MSI.

    Actually, Linux also can work for MSI.  This patch avoids the line IRQ
    checking for USB3 HCDs in usb core PCI probe.  It allows the xHCI driver
    to try to enable MSI or MSI-X first.  It will fail the probe if MSI
    enabling failed and there's no legacy PCI IRQ.

    This patch should be backported to kernels as old as 2.6.32.

    [Maintainer note: This patch is a backport of commit
    68d07f64b8a11a852d48d1b05b724c3e20c0d94b "USB: Don't fail USB3 probe on
    missing legacy PCI IRQ." to the 3.0 kernel.  Note, the original patch
    description was wrong.  We should not back port this to kernels older
    than 2.6.36, since that was the first kernel to support MSI and MSI-X
    for xHCI hosts.  These systems will just not work without MSI support,
    so the probe should fail on kernels older than 2.6.36.]

    Signed-off-by: Alex Shi <alex.shi@intel.com>
    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 721eaa34e5daf7b41458046649d8aee834a92b55
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Tue Feb 21 13:16:32 2012 -0500

    usb-storage: fix freezing of the scanning thread

    commit bb94a406682770a35305daaa241ccdb7cab399de upstream.

    This patch (as1521b) fixes the interaction between usb-storage's
    scanning thread and the freezer.  The current implementation has a
    race: If the device is unplugged shortly after being plugged in and
    just as a system sleep begins, the scanning thread may get frozen
    before the khubd task.  Khubd won't be able to freeze until the
    disconnect processing is complete, and the disconnect processing can't
    proceed until the scanning thread finishes, so the sleep transition
    will fail.

    The implementation in the 3.2 kernel suffers from an additional
    problem.  There the scanning thread calls set_freezable_with_signal(),
    and the signals sent by the freezer will mess up the thread's I/O
    delays, which are all interruptible.

    The solution to both problems is the same: Replace the kernel thread
    used for scanning with a delayed-work routine on the system freezable
    work queue.  Freezable work queues have the nice property that you can
    cancel a work item even while the work queue is frozen, and no signals
    are needed.

    The 3.2 version of this patch solves the problem in Bugzilla #42730.

    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Acked-by: Seth Forshee <seth.forshee@canonical.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f4def3f88dc57648d1603656f1ffdf498bfce1ee
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Sat Feb 18 12:56:35 2012 -0800

    i387: re-introduce FPU state preloading at context switch time

    commit 34ddc81a230b15c0e345b6b253049db731499f7e upstream.

    After all the FPU state cleanups and finally finding the problem that
    caused all our FPU save/restore problems, this re-introduces the
    preloading of FPU state that was removed in commit b3b0870ef3ff ("i387:
    do not preload FPU state at task switch time").

    However, instead of simply reverting the removal, this reimplements
    preloading with several fixes, most notably

     - properly abstracted as a true FPU state switch, rather than as
       open-coded save and restore with various hacks.

       In particular, implementing it as a proper FPU state switch allows us
       to optimize the CR0.TS flag accesses: there is no reason to set the
       TS bit only to then almost immediately clear it again.  CR0 accesses
       are quite slow and expensive, don't flip the bit back and forth for
       no good reason.

     - Make sure that the same model works for both x86-32 and x86-64, so
       that there are no gratuitous differences between the two due to the
       way they save and restore segment state differently due to
       architectural differences that really don't matter to the FPU state.

     - Avoid exposing the "preload" state to the context switch routines,
       and in particular allow the concept of lazy state restore: if nothing
       else has used the FPU in the meantime, and the process is still on
       the same CPU, we can avoid restoring state from memory entirely, just
       re-expose the state that is still in the FPU unit.

       That optimized lazy restore isn't actually implemented here, but the
       infrastructure is set up for it.  Of course, older CPU's that use
       'fnsave' to save the state cannot take advantage of this, since the
       state saving also trashes the state.

    In other words, there is now an actual _design_ to the FPU state saving,
    rather than just random historical baggage.  Hopefully it's easier to
    follow as a result.

    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0a9d89d976531bd5ea7fce618cee886c79b43e07
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Fri Feb 17 21:48:54 2012 -0800

    i387: move TS_USEDFPU flag from thread_info to task_struct

    commit f94edacf998516ac9d849f7bc6949a703977a7f3 upstream.

    This moves the bit that indicates whether a thread has ownership of the
    FPU from the TS_USEDFPU bit in thread_info->status to a word of its own
    (called 'has_fpu') in task_struct->thread.has_fpu.

    This fixes two independent bugs at the same time:

     - changing 'thread_info->status' from the scheduler causes nasty
       problems for the other users of that variable, since it is defined to
       be thread-synchronous (that's what the "TS_" part of the naming was
       supposed to indicate).

       So perfectly valid code could (and did) do

    	ti->status |= TS_RESTORE_SIGMASK;

       and the compiler was free to do that as separate load, or and store
       instructions.  Which can cause problems with preemption, since a task
       switch could happen in between, and change the TS_USEDFPU bit. The
       change to TS_USEDFPU would be overwritten by the final store.

       In practice, this seldom happened, though, because the 'status' field
       was seldom used more than once, so gcc would generally tend to
       generate code that used a read-modify-write instruction and thus
       happened to avoid this problem - RMW instructions are naturally low
       fat and preemption-safe.

     - On x86-32, the current_thread_info() pointer would, during interrupts
       and softirqs, point to a *copy* of the real thread_info, because
       x86-32 uses %esp to calculate the thread_info address, and thus the
       separate irq (and softirq) stacks would cause these kinds of odd
       thread_info copy aliases.

       This is normally not a problem, since interrupts aren't supposed to
       look at thread information anyway (what thread is running at
       interrupt time really isn't very well-defined), but it confused the
       heck out of irq_fpu_usable() and the code that tried to squirrel
       away the FPU state.

       (It also caused untold confusion for us poor kernel developers).

    It also turns out that using 'task_struct' is actually much more natural
    for most of the call sites that care about the FPU state, since they
    tend to work with the task struct for other reasons anyway (ie
    scheduling).  And the FPU data that we are going to save/restore is
    found there too.

    Thanks to Arjan Van De Ven <arjan@linux.intel.com> for pointing us to
    the %esp issue.

    Cc: Arjan van de Ven <arjan@linux.intel.com>
    Reported-and-tested-by: Raphael Prevost <raphael@buro.asia>
    Acked-and-tested-by: Suresh Siddha <suresh.b.siddha@intel.com>
    Tested-by: Peter Anvin <hpa@zytor.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 70b5ef05d889e2be250fd1d963e89f7ca1dd1965
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Thu Feb 16 19:11:15 2012 -0800

    i387: move AMD K7/K8 fpu fxsave/fxrstor workaround from save to restore

    commit 4903062b5485f0e2c286a23b44c9b59d9b017d53 upstream.

    The AMD K7/K8 CPUs don't save/restore FDP/FIP/FOP unless an exception is
    pending.  In order to not leak FIP state from one process to another, we
    need to do a floating point load after the fxsave of the old process,
    and before the fxrstor of the new FPU state.  That resets the state to
    the (uninteresting) kernel load, rather than some potentially sensitive
    user information.

    We used to do this directly after the FPU state save, but that is
    actually very inconvenient, since it

     (a) corrupts what is potentially perfectly good FPU state that we might
         want to lazy avoid restoring later and

     (b) on x86-64 it resulted in a very annoying ordering constraint, where
         "__unlazy_fpu()" in the task switch needs to be delayed until after
         the DS segment has been reloaded just to get the new DS value.

    Coupling it to the fxrstor instead of the fxsave automatically avoids
    both of these issues, and also ensures that we only do it when actually
    necessary (the FP state after a save may never actually get used).  It's
    simply a much more natural place for the leaked state cleanup.

    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 06f4bbda338e6aa42497b76a16cf38e2fdd29885
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Thu Feb 16 15:45:23 2012 -0800

    i387: do not preload FPU state at task switch time

    commit b3b0870ef3ffed72b92415423da864f440f57ad6 upstream.

    Yes, taking the trap to re-load the FPU/MMX state is expensive, but so
    is spending several days looking for a bug in the state save/restore
    code.  And the preload code has some rather subtle interactions with
    both paravirtualization support and segment state restore, so it's not
    nearly as simple as it should be.

    Also, now that we no longer necessarily depend on a single bit (ie
    TS_USEDFPU) for keeping track of the state of the FPU, we migth be able
    to do better.  If we are really switching between two processes that
    keep touching the FP state, save/restore is inevitable, but in the case
    of having one process that does most of the FPU usage, we may actually
    be able to do much better than the preloading.

    In particular, we may be able to keep track of which CPU the process ran
    on last, and also per CPU keep track of which process' FP state that CPU
    has.  For modern CPU's that don't destroy the FPU contents on save time,
    that would allow us to do a lazy restore by just re-enabling the
    existing FPU state - with no restore cost at all!

    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9221484f11c3902bfc84e18e6c6f50f8739134a7
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Thu Feb 16 13:33:12 2012 -0800

    i387: don't ever touch TS_USEDFPU directly, use helper functions

    commit 6d59d7a9f5b723a7ac1925c136e93ec83c0c3043 upstream.

    This creates three helper functions that do the TS_USEDFPU accesses, and
    makes everybody that used to do it by hand use those helpers instead.

    In addition, there's a couple of helper functions for the "change both
    CR0.TS and TS_USEDFPU at the same time" case, and the places that do
    that together have been changed to use those.  That means that we have
    fewer random places that open-code this situation.

    The intent is partly to clarify the code without actually changing any
    semantics yet (since we clearly still have some hard to reproduce bug in
    this area), but also to make it much easier to use another approach
    entirely to caching the CR0.TS bit for software accesses.

    Right now we use a bit in the thread-info 'status' variable (this patch
    does not change that), but we might want to make it a full field of its
    own or even make it a per-cpu variable.

    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0affff96641db67d43092de85c3c4c54028d62e9
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Thu Feb 16 12:22:48 2012 -0800

    i387: move TS_USEDFPU clearing out of __save_init_fpu and into callers

    commit b6c66418dcad0fcf83cd1d0a39482db37bf4fc41 upstream.

    Touching TS_USEDFPU without touching CR0.TS is confusing, so don't do
    it.  By moving it into the callers, we always do the TS_USEDFPU next to
    the CR0.TS accesses in the source code, and it's much easier to see how
    the two go hand in hand.

    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c3cb6440304a2f9afd240bd860860d4a4955d409
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Thu Feb 16 09:15:04 2012 -0800

    i387: fix x86-64 preemption-unsafe user stack save/restore

    commit 15d8791cae75dca27bfda8ecfe87dca9379d6bb0 upstream.

    Commit 5b1cbac37798 ("i387: make irq_fpu_usable() tests more robust")
    added a sanity check to the #NM handler to verify that we never cause
    the "Device Not Available" exception in kernel mode.

    However, that check actually pinpointed a (fundamental) race where we do
    cause that exception as part of the signal stack FPU state save/restore
    code.

    Because we use the floating point instructions themselves to save and
    restore state directly from user mode, we cannot do that atomically with
    testing the TS_USEDFPU bit: the user mode access itself may cause a page
    fault, which causes a task switch, which saves and restores the FP/MMX
    state from the kernel buffers.

    This kind of "recursive" FP state save is fine per se, but it means that
    when the signal stack save/restore gets restarted, it will now take the
    '#NM' exception we originally tried to avoid.  With preemption this can
    happen even without the page fault - but because of the user access, we
    cannot just disable preemption around the save/restore instruction.

    There are various ways to solve this, including using the
    "enable/disable_page_fault()" helpers to not allow page faults at all
    during the sequence, and fall back to copying things by hand without the
    use of the native FP state save/restore instructions.

    However, the simplest thing to do is to just allow the #NM from kernel
    space, but fix the race in setting and clearing CR0.TS that this all
    exposed: the TS bit changes and the TS_USEDFPU bit absolutely have to be
    atomic wrt scheduling, so while the actual state save/restore can be
    interrupted and restarted, the act of actually clearing/setting CR0.TS
    and the TS_USEDFPU bit together must not.

    Instead of just adding random "preempt_disable/enable()" calls to what
    is already excessively ugly code, this introduces some helper functions
    that mostly mirror the "kernel_fpu_begin/end()" functionality, just for
    the user state instead.

    Those helper functions should probably eventually replace the other
    ad-hoc CR0.TS and TS_USEDFPU tests too, but I'll need to think about it
    some more: the task switching functionality in particular needs to
    expose the difference between the 'prev' and 'next' threads, while the
    new helper functions intentionally were written to only work with
    'current'.

    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 09ffc93a8a1e8cf06547d20f5a0ddfe880179fe0
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Wed Feb 15 08:05:18 2012 -0800

    i387: fix sense of sanity check

    commit c38e23456278e967f094b08247ffc3711b1029b2 upstream.

    The check for save_init_fpu() (introduced in commit 5b1cbac37798: "i387:
    make irq_fpu_usable() tests more robust") was the wrong way around, but
    I hadn't noticed, because my "tests" were bogus: the FPU exceptions are
    disabled by default, so even doing a divide by zero never actually
    triggers this code at all unless you do extra work to enable them.

    So if anybody did enable them, they'd get one spurious warning.

    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 00717d1f238918b105ed561a466fcd4271206fb2
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Mon Feb 13 13:56:14 2012 -0800

    i387: make irq_fpu_usable() tests more robust

    commit 5b1cbac37798805c1fee18c8cebe5c0a13975b17 upstream.

    Some code - especially the crypto layer - wants to use the x86
    FP/MMX/AVX register set in what may be interrupt (typically softirq)
    context.

    That *can* be ok, but the tests for when it was ok were somewhat
    suspect.  We cannot touch the thread-specific status bits either, so
    we'd better check that we're not going to try to save FP state or
    anything like that.

    Now, it may be that the TS bit is always cleared *before* we set the
    USEDFPU bit (and only set when we had already cleared the USEDFP
    before), so the TS bit test may actually have been sufficient, but it
    certainly was not obviously so.

    So this explicitly verifies that we will not touch the TS_USEDFPU bit,
    and adds a few related sanity-checks.  Because it seems that somehow
    AES-NI is corrupting user FP state.  The cause is not clear, and this
    patch doesn't fix it, but while debugging it I really wanted the code to
    be more obviously correct and robust.

    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 454d147172263d0b022f32b86336f92243f89158
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Mon Feb 13 13:47:25 2012 -0800

    i387: math_state_restore() isn't called from asm

    commit be98c2cdb15ba26148cd2bd58a857d4f7759ed38 upstream.

    It was marked asmlinkage for some really old and stale legacy reasons.
    Fix that and the equally stale comment.

    Noticed when debugging the irq_fpu_usable() bugs.

    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ac29c0aeddba8f83dd73ec8a51c72f268c9b7b81
Author: Elric Fu <elricfu1@gmail.com>
Date:   Sat Feb 18 13:32:27 2012 +0800

    USB: Set hub depth after USB3 hub reset

    commit a45aa3b30583e7d54e7cf4fbcd0aa699348a6e5c upstream.

    The superspeed device attached to a USB 3.0 hub(such as VIA's)
    doesn't respond the address device command after resume. The
    root cause is the superspeed hub will miss the Hub Depth value
    that is used as an offset into the route string to locate the
    bits it uses to determine the downstream port number after
    reset, and all packets can't be routed to the device attached
    to the superspeed hub.

    Hub driver sends a Set Hub Depth request to the superspeed hub
    except for USB 3.0 root hub when the hub is initialized and
    doesn't send the request again after reset due to the resume
    process. So moving the code that sends the Set Hub Depth request
    to the superspeed hub from hub_configure() to hub_activate()
    is to cover those situations include initialization and reset.

    The patch should be backported to kernels as old as 2.6.39.

    Signed-off-by: Elric Fu <elricfu1@gmail.com>
    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5652021f25ea82e6fc30d5b970e30aafe7a6f367
Author: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Date:   Mon Feb 13 14:42:11 2012 -0800

    xhci: Fix encoding for HS bulk/control NAK rate.

    commit 340a3504fd39dad753ba908fb6f894ee81fc3ae2 upstream.

    The xHCI 0.96 spec says that HS bulk and control endpoint NAK rate must
    be encoded as an exponent of two number of microframes.  The endpoint
    descriptor has the NAK rate encoded in number of microframes.  We were
    just copying the value from the endpoint descriptor into the endpoint
    context interval field, which was not correct.  This lead to the VIA
    host rejecting the add of a bulk OUT endpoint from any USB 2.0 mass
    storage device.

    The fix is to use the correct encoding.  Refactor the code to convert
    number of frames to an exponential number of microframes, and make sure
    we convert the number of microframes in HS bulk and control endpoints to
    an exponent.

    This should be back ported to kernels as old as 2.6.31, that contain the
    commit dfa49c4ad120a784ef1ff0717168aa79f55a483a "USB: xhci - fix math
    in xhci_get_endpoint_interval"

    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Tested-by: Felipe Contreras <felipe.contreras@gmail.com>
    Suggested-by: Andiry Xu <andiry.xu@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit afa0cb70236ea5023e3616edc95045f4742afb24
Author: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Date:   Thu Feb 9 14:43:44 2012 -0800

    xhci: Fix oops caused by more USB2 ports than USB3 ports.

    commit 3278a55a1aebe2bbd47fbb5196209e5326a88b56 upstream.

    The code to set the device removable bits in the USB 2.0 roothub
    descriptor was accidentally looking at the USB 3.0 port registers
    instead of the USB 2.0 registers.  This can cause an oops if there are
    more USB 2.0 registers than USB 3.0 registers.

    This should be backported to kernels as old as 2.6.39, that contain the
    commit 4bbb0ace9a3de8392527e3c87926309d541d3b00 "xhci: Return a USB 3.0
    hub descriptor for USB3 roothub."

    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cce0edb3ee6cdbbac6ef1bc013fe415401d820bd
Author: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Date:   Tue Feb 7 15:11:46 2012 -0800

    USB: Fix handoff when BIOS disables host PCI device.

    commit cab928ee1f221c9cc48d6615070fefe2e444384a upstream.

    On some systems with an Intel Panther Point xHCI host controller, the
    BIOS disables the xHCI PCI device during boot, and switches the xHCI
    ports over to EHCI.  This allows the BIOS to access USB devices without
    having xHCI support.

    The downside is that the xHCI BIOS handoff mechanism will fail because
    memory mapped I/O is not enabled for the disabled PCI device.
    Jesse Barnes says this is expected behavior.  The PCI core will enable
    BARs before quirks run, but it will leave it in an undefined state, and
    it may not have memory mapped I/O enabled.

    Make the generic USB quirk handler call pci_enable_device() to re-enable
    MMIO, and call pci_disable_device() once the host-specific BIOS handoff
    is finished.  This will balance the ref counts in the PCI core.  When
    the PCI probe function is called, usb_hcd_pci_probe() will call
    pci_enable_device() again.

    This should be back ported to kernels as old as 2.6.31.  That was the
    first kernel with xHCI support, and no one has complained about BIOS
    handoffs failing due to memory mapped I/O being disabled on other hosts
    (EHCI, UHCI, or OHCI).

    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Acked-by: Oliver Neukum <oneukum@suse.de>
    Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 662785063f41640379bb9537b15074f8526f33be
Author: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Date:   Thu Jan 5 16:28:54 2012 -0800

    USB: Remove duplicate USB 3.0 hub feature #defines.

    commit d9f5343e35d9138432657202afa8e3ddb2ade360 upstream.

    Somehow we ended up with duplicate hub feature #defines in ch11.h.
    Tatyana Brokhman first created the USB 3.0 hub feature macros in 2.6.38
    with commit 0eadcc09203349b11ca477ec367079b23d32ab91 "usb: USB3.0 ch11
    definitions".  In 2.6.39, I modified a patch from John Youn that added
    similar macros in a different place in the same file, and committed
    dbe79bbe9dcb22cb3651c46f18943477141ca452 "USB 3.0 Hub Changes".

    Some of the #defines used different names for the same values.  Others
    used exactly the same names with the same values, like these gems:

     #define USB_PORT_FEAT_BH_PORT_RESET     28
    ...
     #define USB_PORT_FEAT_BH_PORT_RESET            28

    According to my very geeky husband (who looked it up in the C99 spec),
    it is allowed to have object-like macros with duplicate names as long as
    the replacement list is exactly the same.  However, he recalled that
    some compilers will give warnings when they find duplicate macros.  It's
    probably best to remove the duplicates in the stable tree, so that the
    code compiles for everyone.

    The macros are now fixed to move the feature requests that are specific
    to USB 3.0 hubs into a new section (out of the USB 2.0 hub feature
    section), and use the most common macro name.

    This patch should be backported to 2.6.39.

    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Cc: Tatyana Brokhman <tlinder@codeaurora.org>
    Cc: John Youn <johnyoun@synopsys.com>
    Cc: Jamey Sharp <jamey@minilop.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4ee72bce4407abc34f5efbd70e6d61b857b9adbc
Author: Andrew Lunn <andrew@lunn.ch>
Date:   Mon Feb 20 09:31:57 2012 +0100

    USB: Serial: ti_usb_3410_5052: Add Abbot Diabetes Care cable id

    commit 7fd25702ba616d9ba56e2a625472f29e5aff25ee upstream.

    This USB-serial cable with mini stereo jack enumerates as:
    Bus 001 Device 004: ID 1a61:3410 Abbott Diabetes Care

    It is a TI3410 inside.

    Signed-off-by: Andrew Lunn <andrew@lunn.ch>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e4388320d16815d4495358a9b9950263ba052157
Author: Rui li <li.rui27@zte.com.cn>
Date:   Tue Feb 14 10:35:01 2012 +0800

    USB: option: cleanup zte 3g-dongle's pid in option.c

    commit b9e44fe5ecda4158c22bc1ea4bffa378a4f83f65 upstream.

      1. Remove all old mass-storage ids's pid:
         0x0026,0x0053,0x0098,0x0099,0x0149,0x0150,0x0160;
      2. As the pid from 0x1401 to 0x1510 which have not surely assigned to
         use for serial-port or mass-storage port,so i think it should be
         removed now, and will re-add after it have assigned in future;
      3. sort the pid to WCDMA and CDMA.

    Signed-off-by: Rui li <li.rui27@zte.com.cn>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f887e1ac4775bd066690fd7c64b68a18b0b70b19
Author: Bruno Thomsen <bruno.thomsen@gmail.com>
Date:   Tue Feb 21 23:41:37 2012 +0100

    USB: Added Kamstrup VID/PIDs to cp210x serial driver.

    commit c6c1e4491dc8d1ed2509fa6aacffa7f34614fc38 upstream.

    Signed-off-by: Bruno Thomsen <bruno.thomsen@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 42ab5316ddcaa0de23e88e8a3d363c767b9ab0b3
Author: Eric Dumazet <eric.dumazet@gmail.com>
Date:   Fri Nov 18 15:24:32 2011 -0500

    ipv4: fix redirect handling

    [ Upstream commit 9cc20b268a5a14f5e57b8ad405a83513ab0d78dc ]

    commit f39925dbde77 (ipv4: Cache learned redirect information in
    inetpeer.) introduced a regression in ICMP redirect handling.

    It assumed ipv4_dst_check() would be called because all possible routes
    were attached to the inetpeer we modify in ip_rt_redirect(), but thats
    not true.

    commit 7cc9150ebe (route: fix ICMP redirect validation) tried to fix
    this but solution was not complete. (It fixed only one route)

    So we must lookup existing routes (including different TOS values) and
    call check_peer_redir() on them.

    Reported-by: Ivan Zahariev <famzah@icdsoft.com>
    Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
    CC: Flavio Leitner <fbl@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bebee22bcbf0026f92141990972bd5863ef9b69c
Author: Flavio Leitner <fbl@redhat.com>
Date:   Mon Oct 24 02:56:38 2011 -0400

    route: fix ICMP redirect validation

    [ Upstream commit 7cc9150ebe8ec06cafea9f1c10d92ddacf88d8ae ]

    The commit f39925dbde7788cfb96419c0f092b086aa325c0f
    (ipv4: Cache learned redirect information in inetpeer.)
    removed some ICMP packet validations which are required by
    RFC 1122, section 3.2.2.2:
    ...
      A Redirect message SHOULD be silently discarded if the new
      gateway address it specifies is not on the same connected
      (sub-) net through which the Redirect arrived [INTRO:2,
      Appendix A], or if the source of the Redirect is not the
      current first-hop gateway for the specified destination (see
      Section 3.3.1).

    Signed-off-by: Flavio Leitner <fbl@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 623f1904ef55789082259573bb6248df5fea3d92
Author: Neal Cardwell <ncardwell@google.com>
Date:   Mon Feb 13 20:22:08 2012 +0000

    tcp: fix tcp_shifted_skb() adjustment of lost_cnt_hint for FACK

    [ Upstream commit 0af2a0d0576205dda778d25c6c344fc6508fc81d ]

    This commit ensures that lost_cnt_hint is correctly updated in
    tcp_shifted_skb() for FACK TCP senders. The lost_cnt_hint adjustment
    in tcp_sacktag_one() only applies to non-FACK senders, so FACK senders
    need their own adjustment.

    This applies the spirit of 1e5289e121372a3494402b1b131b41bfe1cf9b7f -
    except now that the sequence range passed into tcp_sacktag_one() is
    correct we need only have a special case adjustment for FACK.

    Signed-off-by: Neal Cardwell <ncardwell@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dd31c1ce7ef7b363215081fde02f13bf3e50b5a1
Author: Neal Cardwell <ncardwell@google.com>
Date:   Sun Feb 12 18:37:10 2012 +0000

    tcp: fix range tcp_shifted_skb() passes to tcp_sacktag_one()

    [ Upstream commit daef52bab1fd26e24e8e9578f8fb33ba1d0cb412 ]

    Fix the newly-SACKed range to be the range of newly-shifted bytes.

    Previously - since 832d11c5cd076abc0aa1eaf7be96c81d1a59ce41 -
    tcp_shifted_skb() incorrectly called tcp_sacktag_one() with the start
    and end sequence numbers of the skb it passes in set to the range just
    beyond the range that is newly-SACKed.

    This commit also removes a special-case adjustment to lost_cnt_hint in
    tcp_shifted_skb() since the pre-existing adjustment of lost_cnt_hint
    in tcp_sacktag_one() now properly handles this things now that the
    correct start sequence number is passed in.

    Signed-off-by: Neal Cardwell <ncardwell@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 382e8f84cb3db5295aa2f142a11e42eac6544ab4
Author: Neal Cardwell <ncardwell@google.com>
Date:   Sun Feb 12 18:37:09 2012 +0000

    tcp: allow tcp_sacktag_one() to tag ranges not aligned with skbs

    [ Upstream commit cc9a672ee522d4805495b98680f4a3db5d0a0af9 ]

    This commit allows callers of tcp_sacktag_one() to pass in sequence
    ranges that do not align with skb boundaries, as tcp_shifted_skb()
    needs to do in an upcoming fix in this patch series.

    In fact, now tcp_sacktag_one() does not need to depend on an input skb
    at all, which makes its semantics and dependencies more clear.

    Signed-off-by: Neal Cardwell <ncardwell@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 39b73fb4fedd23980b720d0272e5e26510cd6940
Author: Shawn Lu <shawn.lu@ericsson.com>
Date:   Sat Feb 4 12:38:09 2012 +0000

    tcp_v4_send_reset: binding oif to iif in no sock case

    [ Upstream commit e2446eaab5585555a38ea0df4e01ff313dbb4ac9 ]

    Binding RST packet outgoing interface to incoming interface
    for tcp v4 when there is no socket associate with it.
    when sk is not NULL, using sk->sk_bound_dev_if instead.
    (suggested by Eric Dumazet).

    This has few benefits:
    1. tcp_v6_send_reset already did that.
    2. This helps tcp connect with SO_BINDTODEVICE set. When
    connection is lost, we still able to sending out RST using
    same interface.
    3. we are sending reply, it is most likely to be succeed
    if iif is used

    Signed-off-by: Shawn Lu <shawn.lu@ericsson.com>
    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>

commit d67f60702b0085eb2ad772b9f7ddf728fc42d7b8
Author: Hagen Paul Pfeifer <hagen@jauu.net>
Date:   Sat Feb 4 23:22:26 2012 +0000

    via-velocity: S3 resume fix.

    [ Upstream commit b530b1930bbd9d005345133f0ff0c556d2a52b19 ]

    Initially diagnosed on Ubuntu 11.04 with kernel 2.6.38.

    velocity_close is not called during a suspend / resume cycle in this
    driver and it has no business playing directly with power states.

    Signed-off-by: David Lv <DavidLv@viatech.com.cn>
    Acked-by: Francois Romieu <romieu@fr.zoreil.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1609e23b0c313d58664bcc0677eadd9464c8c2cc
Author: Hagen Paul Pfeifer <hagen@jauu.net>
Date:   Wed Jan 4 17:35:26 2012 +0000

    net_sched: Bug in netem reordering

    [ Upstream commit eb10192447370f19a215a8c2749332afa1199d46 ]

    Not now, but it looks you are correct. q->qdisc is NULL until another
    additional qdisc is attached (beside tfifo). See 50612537e9ab2969312.
    The following patch should work.

    From: Hagen Paul Pfeifer <hagen@jauu.net>

    netem: catch NULL pointer by updating the real qdisc statistic

    Reported-by: Vijay Subramanian <subramanian.vijay@gmail.com>
    Signed-off-by: Hagen Paul Pfeifer <hagen@jauu.net>
    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>

commit 9f8a28dca634c4aa13127ed2ea5de94c1e47dbb7
Author: Eric Dumazet <eric.dumazet@gmail.com>
Date:   Tue Feb 14 10:11:59 2012 +0000

    netpoll: netpoll_poll_dev() should access dev->flags

    [ Upstream commit 58e05f357a039a94aa36475f8c110256f693a239 ]

    commit 5a698af53f (bond: service netpoll arp queue on master device)
    tested IFF_SLAVE flag against dev->priv_flags instead of dev->flags

    Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
    Cc: WANG Cong <amwang@redhat.com>
    Acked-by: Neil Horman <nhorman@tuxdriver.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1831cd9e1fb43c2e700e795827cb9531e679b0ef
Author: Thomas Graf <tgraf@suug.ch>
Date:   Fri Feb 10 04:07:11 2012 +0000

    net: Don't proxy arp respond if iif == rt->dst.dev if private VLAN is disabled

    [ Upstream commit 70620c46ac2b45c24b0f22002fdf5ddd1f7daf81 ]

    Commit 653241 (net: RFC3069, private VLAN proxy arp support) changed
    the behavior of arp proxy to send arp replies back out on the interface
    the request came in even if the private VLAN feature is disabled.

    Previously we checked rt->dst.dev != skb->dev for in scenarios, when
    proxy arp is enabled on for the netdevice and also when individual proxy
    neighbour entries have been added.

    This patch adds the check back for the pneigh_lookup() scenario.

    Signed-off-by: Thomas Graf <tgraf@suug.ch>
    Acked-by: Jesper Dangaard Brouer <hawk@comx.dk>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dbde1bae2933018c576abcc28daf082fcd17c8d3
Author: Julian Anastasov <ja@ssi.bg>
Date:   Sat Feb 4 13:04:46 2012 +0000

    ipv4: reset flowi parameters on route connect

    [ Upstream commit e6b45241c57a83197e5de9166b3b0d32ac562609 ]

    Eric Dumazet found that commit 813b3b5db83
    (ipv4: Use caller's on-stack flowi as-is in output
    route lookups.) that comes in 3.0 added a regression.
    The problem appears to be that resulting flowi4_oif is
    used incorrectly as input parameter to some routing lookups.
    The result is that when connecting to local port without
    listener if the IP address that is used is not on a loopback
    interface we incorrectly assign RTN_UNICAST to the output
    route because no route is matched by oif=lo. The RST packet
    can not be sent immediately by tcp_v4_send_reset because
    it expects RTN_LOCAL.

    	So, change ip_route_connect and ip_route_newports to
    update the flowi4 fields that are input parameters because
    we do not want unnecessary binding to oif.

    	To make it clear what are the input parameters that
    can be modified during lookup and to show which fields of
    floiw4 are reused add a new function to update the flowi4
    structure: flowi4_update_output.

    Thanks to Yurij M. Plotnikov for providing a bug report including a
    program to reproduce the problem.

    Thanks to Eric Dumazet for tracking the problem down to
    tcp_v4_send_reset and providing initial fix.

    Reported-by: Yurij M. Plotnikov <Yurij.Plotnikov@oktetlabs.ru>
    Signed-off-by: Julian Anastasov <ja@ssi.bg>
    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>

commit ab2fd30a38e23f0b6f2e331889b31f4f6fb2378a
Author: Li Wei <lw@cn.fujitsu.com>
Date:   Thu Feb 9 21:15:25 2012 +0000

    ipv4: Fix wrong order of ip_rt_get_source() and update iph->daddr.

    [ Upstream commit 5dc7883f2a7c25f8df40d7479687153558cd531b ]

    This patch fix a bug which introduced by commit ac8a4810 (ipv4: Save
    nexthop address of LSRR/SSRR option to IPCB.).In that patch, we saved
    the nexthop of SRR in ip_option->nexthop and update iph->daddr until
    we get to ip_forward_options(), but we need to update it before
    ip_rt_get_source(), otherwise we may get a wrong src.

    Signed-off-by: Li Wei <lw@cn.fujitsu.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5805d4729059f578c8283ccc44021342fbe8c93d
Author: Li Wei <lw@cn.fujitsu.com>
Date:   Tue Nov 22 23:33:10 2011 +0000

    ipv4: Save nexthop address of LSRR/SSRR option to IPCB.

    [ Upstream commit ac8a48106be49c422575ddc7531b776f8eb49610 ]

    We can not update iph->daddr in ip_options_rcv_srr(), It is too early.
    When some exception ocurred later (eg. in ip_forward() when goto
    sr_failed) we need the ip header be identical to the original one as
    ICMP need it.

    Add a field 'nexthop' in struct ip_options to save nexthop of LSRR
    or SSRR option.

    Signed-off-by: Li Wei <lw@cn.fujitsu.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c4f2403478002bdb0a46a62f87909aeda8058d8b
Author: Li Wei <lw@cn.fujitsu.com>
Date:   Tue Nov 8 21:39:28 2011 +0000

    ipv4: fix for ip_options_rcv_srr() daddr update.

    [ Upstream commit b12f62efb8ec0b9523bdb6c2d412c07193086de9 ]

    When opt->srr_is_hit is set skb_rtable(skb) has been updated for
    'nexthop' and iph->daddr should always equals to skb_rtable->rt_dst
    holds, We need update iph->daddr either.

    Signed-off-by: Li Wei <lw@cn.fujitsu.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 24190a04c967d91e718bbe7a871e418edb9424aa
Author: Ben Greear <greearb@candelatech.com>
Date:   Fri Sep 23 13:11:01 2011 +0000

    ipv6-multicast: Fix memory leak in IPv6 multicast.

    [ Upstream commit 67928c4041606f02725f3c95c4c0404e4532df1b ]

    If reg_vif_xmit cannot find a routing entry, be sure to
    free the skb before returning the error.

    Signed-off-by: Ben Greear <greearb@candelatech.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 23b139ecf944b097a0493262cbc04886363bd8e6
Author: Ben Greear <greearb@candelatech.com>
Date:   Tue Sep 27 15:16:08 2011 -0400

    ipv6-multicast: Fix memory leak in input path.

    [ Upstream commit 2015de5fe2a47086a3260802275932bfd810884e ]

    Have to free the skb before returning if we fail
    the fib lookup.

    Signed-off-by: Ben Greear <greearb@candelatech.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d6be19f41ab91acca04abdca61353245d57d9ffc
Author: Eric Dumazet <eric.dumazet@gmail.com>
Date:   Tue Feb 14 10:27:09 2012 +0000

    3c59x: shorten timer period for slave devices

    [ Upstream commit 3013dc0cceb9baaf25d5624034eeaa259bf99004 ]

    Jean Delvare reported bonding on top of 3c59x adapters was not detecting
    network cable removal fast enough.

    3c59x indeed uses a 60 seconds timer to check link status if carrier is
    on, and 5 seconds if carrier is off.

    This patch reduces timer period to 5 seconds if device is a bonding
    slave.

    Reported-by: Jean Delvare <jdelvare@suse.de>
    Acked-by: Jean Delvare <jdelvare@suse.de>
    Acked-by: Steffen Klassert <steffen.klassert@secunet.com>
    Signed-off-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>

commit 497f51fc64d0bce7f1a40ebed20b2ba5090777a3
Author: Thomas Graf <tgraf@suug.ch>
Date:   Wed Feb 15 04:09:46 2012 +0000

    veth: Enforce minimum size of VETH_INFO_PEER

    [ Upstream commit 237114384ab22c174ec4641e809f8e6cbcfce774 ]

    VETH_INFO_PEER carries struct ifinfomsg plus optional IFLA
    attributes. A minimal size of sizeof(struct ifinfomsg) must be
    enforced or we may risk accessing that struct beyond the limits
    of the netlink message.

    Signed-off-by: Thomas Graf <tgraf@suug.ch>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 32fa5d83232b026092505e9165e119e5806b930d
Author: Eric Dumazet <eric.dumazet@gmail.com>
Date:   Wed Feb 8 08:51:50 2012 +0000

    gro: more generic L2 header check

    [ Upstream commit 5ca3b72c5da47d95b83857b768def6172fbc080a ]

    Shlomo Pongratz reported GRO L2 header check was suited for Ethernet
    only, and failed on IB/ipoib traffic.

    He provided a patch faking a zeroed header to let GRO aggregates frames.

    Roland Dreier, Herbert Xu, and others suggested we change GRO L2 header
    check to be more generic, ie not assuming L2 header is 14 bytes, but
    taking into account hard_header_len.

    __napi_gro_receive() has special handling for the common case (Ethernet)
    to avoid a memcmp() call and use an inline optimized function instead.

    Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
    Reported-by: Shlomo Pongratz <shlomop@mellanox.com>
    Cc: Roland Dreier <roland@kernel.org>
    Cc: Or Gerlitz <ogerlitz@mellanox.com>
    Cc: Herbert Xu <herbert@gondor.apana.org.au>
    Tested-by: Sean Hefty <sean.hefty@intel.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit aca5efd17c1a1ed6303537792517e7352cf74edd
Author: Roland Dreier <roland@purestorage.com>
Date:   Tue Feb 7 14:51:21 2012 +0000

    IPoIB: Stop lying about hard_header_len and use skb->cb to stash LL addresses

    [ Upstream commit 936d7de3d736e0737542641269436f4b5968e9ef ]

    Commit a0417fa3a18a ("net: Make qdisc_skb_cb upper size bound
    explicit.") made it possible for a netdev driver to use skb->cb
    between its header_ops.create method and its .ndo_start_xmit
    method.  Use this in ipoib_hard_header() to stash away the LL address
    (GID + QPN), instead of the "ipoib_pseudoheader" hack.  This allows
    IPoIB to stop lying about its hard_header_len, which will let us fix
    the L2 check for GRO.

    Signed-off-by: Roland Dreier <roland@purestorage.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c3e8445f6ec4ad66c5143d6df8528f7440429b91
Author: David S. Miller <davem@davemloft.net>
Date:   Mon Feb 6 15:14:37 2012 -0500

    net: Make qdisc_skb_cb upper size bound explicit.

    [ Upstream commit 16bda13d90c8d5da243e2cfa1677e62ecce26860 ]

    Just like skb->cb[], so that qdisc_skb_cb can be encapsulated inside
    of other data structures.

    This is intended to be used by IPoIB so that it can remember
    addressing information stored at hard_header_ops->create() time that
    it can fetch when the packet gets to the transmit routine.

    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bbb8ae42eb210ba2bdff67450f3737e10cb042f3
Author: Rabin Vincent <rabin@rab.in>
Date:   Wed Feb 15 16:01:42 2012 +0100

    ARM: 7325/1: fix v7 boot with lockdep enabled

    commit 8e43a905dd574f54c5715d978318290ceafbe275 upstream.

    Bootup with lockdep enabled has been broken on v7 since b46c0f74657d
    ("ARM: 7321/1: cache-v7: Disable preemption when reading CCSIDR").

    This is because v7_setup (which is called very early during boot) calls
    v7_flush_dcache_all, and the save_and_disable_irqs added by that patch
    ends up attempting to call into lockdep C code (trace_hardirqs_off())
    when we are in no position to execute it (no stack, MMU off).

    Fix this by using a notrace variant of save_and_disable_irqs.  The code
    already uses the notrace variant of restore_irqs.

    Reviewed-by: Nicolas Pitre <nico@linaro.org>
    Acked-by: Stephen Boyd <sboyd@codeaurora.org>
    Cc: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Rabin Vincent <rabin@rab.in>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ad15d5c6dc9f1272fe1dde3de87ab775f65a6d77
Author: Stephen Boyd <sboyd@codeaurora.org>
Date:   Tue Feb 7 19:42:07 2012 +0100

    ARM: 7321/1: cache-v7: Disable preemption when reading CCSIDR

    commit b46c0f74657d1fe1c1b0c1452631cc38a9e6987f upstream.

    armv7's flush_cache_all() flushes caches via set/way. To
    determine the cache attributes (line size, number of sets,
    etc.) the assembly first writes the CSSELR register to select a
    cache level and then reads the CCSIDR register. The CSSELR register
    is banked per-cpu and is used to determine which cache level CCSIDR
    reads. If the task is migrated between when the CSSELR is written and
    the CCSIDR is read the CCSIDR value may be for an unexpected cache
    level (for example L1 instead of L2) and incorrect cache flushing
    could occur.

    Disable interrupts across the write and read so that the correct
    cache attributes are read and used for the cache flushing
    routine. We disable interrupts instead of disabling preemption
    because the critical section is only 3 instructions and we want
    to call v7_dcache_flush_all from __v7_setup which doesn't have a
    full kernel stack with a struct thread_info.

    This fixes a problem we see in scm_call() when flush_cache_all()
    is called from preemptible context and sometimes the L2 cache is
    not properly flushed out.

    Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
    Acked-by: Catalin Marinas <catalin.marinas@arm.com>
    Reviewed-by: Nicolas Pitre <nico@linaro.org>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2efb4f6b48f54918213f0b8c3f7135aca328f8f3
Author: Trond Myklebust <Trond.Myklebust@netapp.com>
Date:   Thu Feb 9 15:31:36 2012 -0500

    NFSv4: Ensure we throw out bad delegation stateids on NFS4ERR_BAD_STATEID

    commit b9f9a03150969e4bd9967c20bce67c4de769058f upstream.

    To ensure that we don't just reuse the bad delegation when we attempt to
    recover the nfs4_state that received the bad stateid error.

    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e9513216eb2c0276e227fbb9a6f754e16c9c7510
Author: Johan Rudholm <johan.rudholm@stericsson.com>
Date:   Wed Nov 23 09:05:58 2011 +0100

    mmc: core: check for zero length ioctl data

    commit 4d6144de8ba263eb3691a737c547e5b2fdc45287 upstream.

    If the read or write buffer size associated with the command sent
    through the mmc_blk_ioctl is zero, do not prepare data buffer.

    This enables a ioctl(2) call to for instance send a MMC_SWITCH to set
    a byte in the ext_csd.

    Signed-off-by: Johan Rudholm <johan.rudholm@stericsson.com>
    Signed-off-by: Chris Ball <cjb@laptop.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e8b827b4f14a1a25b909236a08a5fe63b92a658f
Author: Takashi Iwai <tiwai@suse.de>
Date:   Wed Feb 22 17:02:38 2012 +0100

    ALSA: hda - Fix redundant jack creations for cx5051

    [Note that since the patch isn't applicable (and unnecessary) to
    3.3-rc, there is no corresponding upstream fix.]

    The cx5051 parser calls snd_hda_input_jack_add() in the init callback
    to create and initialize the jack detection instances.  Since the init
    callback is called at each time when the device gets woken up after
    suspend or power-saving mode, the duplicated instances are accumulated
    at each call.  This ends up with the kernel warnings with the too
    large array size.

    The fix is simply to move the calls of snd_hda_input_jack_add() into
    the parser section instead of the init callback.

    The fix is needed only up to 3.2 kernel, since the HD-audio jack layer
    was redesigned in the 3.3 kernel.

    Reported-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Tested-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d870401f171a25a362ae7ce1eeebafdd3fc080fd
Author: Tyler Hicks <tyhicks@canonical.com>
Date:   Tue Feb 7 17:55:40 2012 -0600

    eCryptfs: Copy up lower inode attrs after setting lower xattr

    commit 545d680938be1e86a6c5250701ce9abaf360c495 upstream.

    After passing through a ->setxattr() call, eCryptfs needs to copy the
    inode attributes from the lower inode to the eCryptfs inode, as they
    may have changed in the lower filesystem's ->setxattr() path.

    One example is if an extended attribute containing a POSIX Access
    Control List is being set. The new ACL may cause the lower filesystem to
    modify the mode of the lower inode and the eCryptfs inode would need to
    be updated to reflect the new mode.

    https://launchpad.net/bugs/926292

    Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
    Reported-by: Sebastien Bacher <seb128@ubuntu.com>
    Cc: John Johansen <john.johansen@canonical.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit aa4e084812c0f03c0363bacdad6a0fff95826544
Author: Tim Gardner <tim.gardner@canonical.com>
Date:   Wed Feb 15 07:50:15 2012 +0000

    ipheth: Add iPhone 4S

    commit 72ba009b8a159e995e40d3b4e5d7d265acead983 upstream.

    BugLink: http://bugs.launchpad.net/bugs/900802

    Signed-off-by: Till Kamppeter <till.kamppeter@gmail.com>
    Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0a3e045705af3ea9d61560d4f6ffe2ce62f81992
Author: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
Date:   Thu Feb 9 19:59:43 2012 +0530

    mac80211: Fix a rwlock bad magic bug

    commit b57e6b560fc2a2742910ac5ca0eb2c46e45aeac2 upstream.

    read_lock(&tpt_trig->trig.leddev_list_lock) is accessed via the path
    ieee80211_open (->) ieee80211_do_open (->) ieee80211_mod_tpt_led_trig
    (->) ieee80211_start_tpt_led_trig (->) tpt_trig_timer before initializing
    it.
    the intilization of this read/write lock happens via the path
    ieee80211_led_init (->) led_trigger_register, but we are doing
    'ieee80211_led_init'  after 'ieeee80211_if_add' where we
    register netdev_ops.
    so we access leddev_list_lock before initializing it and causes the
    following bug in chrome laptops with AR928X cards with the following
    script

    while true
    do
    sudo modprobe -v ath9k
    sleep 3
    sudo modprobe -r ath9k
    sleep 3
    done

    	BUG: rwlock bad magic on CPU#1, wpa_supplicant/358, f5b9eccc
    	Pid: 358, comm: wpa_supplicant Not tainted 3.0.13 #1
    	Call Trace:

    	[<8137b9df>] rwlock_bug+0x3d/0x47
    	[<81179830>] do_raw_read_lock+0x19/0x29
    	[<8137f063>] _raw_read_lock+0xd/0xf
    	[<f9081957>] tpt_trig_timer+0xc3/0x145 [mac80211]
    	[<f9081f3a>] ieee80211_mod_tpt_led_trig+0x152/0x174 [mac80211]
    	[<f9076a3f>] ieee80211_do_open+0x11e/0x42e [mac80211]
    	[<f9075390>] ? ieee80211_check_concurrent_iface+0x26/0x13c [mac80211]
    	[<f9076d97>] ieee80211_open+0x48/0x4c [mac80211]
    	[<812dbed8>] __dev_open+0x82/0xab
    	[<812dc0c9>] __dev_change_flags+0x9c/0x113
    	[<812dc1ae>] dev_change_flags+0x18/0x44
    	[<8132144f>] devinet_ioctl+0x243/0x51a
    	[<81321ba9>] inet_ioctl+0x93/0xac
    	[<812cc951>] sock_ioctl+0x1c6/0x1ea
    	[<812cc78b>] ? might_fault+0x20/0x20
    	[<810b1ebb>] do_vfs_ioctl+0x46e/0x4a2
    	[<810a6ebb>] ? fget_light+0x2f/0x70
    	[<812ce549>] ? sys_recvmsg+0x3e/0x48
    	[<810b1f35>] sys_ioctl+0x46/0x69
    	[<8137fa77>] sysenter_do_call+0x12/0x2

    Cc: Gary Morain <gmorain@google.com>
    Cc: Paul Stewart <pstew@google.com>
    Cc: Abhijit Pradhan <abhijit@qca.qualcomm.com>
    Cc: Vasanthakumar Thiagarajan <vthiagar@qca.qualcomm.com>
    Cc: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
    Acked-by: Johannes Berg <johannes.berg@intel.com>
    Tested-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
    Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e4907ec10117f491d4a5630994a04bc0d3a7d0f1
Author: Yinghai Lu <yinghai.lu@oracle.com>
Date:   Mon Jan 30 12:25:24 2012 +0100

    PCI: workaround hard-wired bus number V2

    commit 71f6bd4a23130cd2f4b036010c5790b1295290b9 upstream.

    Fixes PCI device detection on IBM xSeries IBM 3850 M2 / x3950 M2
    when using ACPI resources (_CRS).
    This is default, a manual workaround (without this patch)
    would be pci=nocrs boot param.

    V2: Add dev_warn if the workaround is hit. This should reveal
    how common such setups are (via google) and point to possible
    problems if things are still not working as expected.
    -> Suggested by Jan Beulich.

    Tested-by: garyhade@us.ibm.com
    Signed-off-by: Yinghai Lu <yinghai.lu@oracle.com>
    Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fe12043438bcd8c739e286977c8f44ff87483c62
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Mon Feb 13 16:36:34 2012 -0500

    drm/radeon/kms: fix MSI re-arm on rv370+

    commit b7f5b7dec3d539a84734f2bcb7e53fbb1532a40b upstream.

    MSI_REARM_EN register is a write only trigger register.
    There is no need RMW when re-arming.

    May fix:
    https://bugs.freedesktop.org/show_bug.cgi?id=41668

    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 49f936fe90802f0923f47d28f755c83d358feac9
Author: Anton Blanchard <anton@samba.org>
Date:   Wed Feb 15 18:48:22 2012 +0000

    powerpc/perf: power_pmu_start restores incorrect values, breaking frequency events

    commit 9a45a9407c69d068500923480884661e2b9cc421 upstream.

    perf on POWER stopped working after commit e050e3f0a71b (perf: Fix
    broken interrupt rate throttling). That patch exposed a bug in
    the POWER perf_events code.

    Since the PMCs count upwards and take an exception when the top bit
    is set, we want to write 0x80000000 - left in power_pmu_start. We were
    instead programming in left which effectively disables the counter
    until we eventually hit 0x80000000. This could take seconds or longer.

    With the patch applied I get the expected number of samples:

              SAMPLE events:       9948

    Signed-off-by: Anton Blanchard <anton@samba.org>
    Acked-by: Paul Mackerras <paulus@samba.org>
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8507fb05c966cdd3a808bb267d2595a41db87512
Author: Guenter Roeck <guenter.roeck@ericsson.com>
Date:   Wed Feb 22 08:13:52 2012 -0800

    hwmon: (ads1015) Fix file leak in probe function

    commit 363434b5dc352464ac7601547891e5fc9105f124 upstream.

    An error while creating sysfs attribute files in the driver's probe function
    results in an error abort, but already created files are not removed. This patch
    fixes the problem.

    Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
    Cc: Dirk Eibach <eibach@gdsys.de>
    Acked-by: Jean Delvare <khali@linux-fr.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5774b2eec1698c9647162a52431e514d6628471f
Author: Chris D Schimp <silverchris@gmail.com>
Date:   Mon Feb 20 17:44:59 2012 -0500

    hwmon: (max6639) Fix PPR register initialization to set both channels

    commit 2f2da1ac0ba5b6cc6e1957c4da5ff20e67d8442b upstream.

    Initialize PPR register for both channels, and set correct PPR register bits.
    Also remove unnecessary variable initializations.

    Signed-off-by: Chris D Schimp <silverchris@gmail.com>
    [guenter.roeck@ericsson.com: Merged two patches into one]
    Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
    Acked-by: Roland Stigge <stigge@antcom.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e1efaccd1c67efe24e3708c916e51330bf770299
Author: Chris D Schimp <silverchris@gmail.com>
Date:   Mon Feb 20 16:59:24 2012 -0500

    hwmon: (max6639) Fix FAN_FROM_REG calculation

    commit b63d97a36edb1aecf8c13e5f5783feff4d64c24b upstream.

    RPM calculation from tachometer value does not depend on PPR.
    Also, do not report negative RPM values.

    Signed-off-by: Chris D Schimp <silverchris@gmail.com>
    [guenter.roeck@ericsson.com: do not report negative RPM values]
    Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
    Acked-by: Roland Stigge <stigge@antcom.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 251ebc7bb45c7e27b8868b13fb56fedeedfc1da4
Author: David Howells <dhowells@redhat.com>
Date:   Thu Feb 23 13:50:35 2012 +0000

    NOMMU: Lock i_mmap_mutex for access to the VMA prio list

    commit 918e556ec214ed2f584e4cac56d7b29e4bb6bf27 upstream.

    Lock i_mmap_mutex for access to the VMA prio list to prevent concurrent
    access.  Currently, certain parts of the mmap handling are protected by
    the region mutex, but not all.

    Reported-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: David Howells <dhowells@redhat.com>
    Acked-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 62797c459126d343df0e9095fe1aa9ae3ebb3f89
Author: Mark Brown <broonie@opensource.wolfsonmicro.com>
Date:   Mon Feb 13 22:00:47 2012 -0800

    ASoC: wm8962: Fix sidetone enumeration texts

    commit 31794bc37bf2db84f085da52b72bfba65739b2d2 upstream.

    The sidetone enumeration texts have left and right swapped.

    Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>