patch to linux kernel 3.0.52
commit 89d2d133c6947c04a8ab539b997f266535beaafe
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Sat Nov 17 13:14:48 2012 -0800

    Linux 3.0.52

commit 093371484195393366f3407465b6f6c53eefdc57
Author: Takashi Iwai <tiwai@suse.de>
Date:   Tue Nov 13 11:22:48 2012 +0100

    ALSA: usb-audio: Fix mutex deadlock at disconnection

    commit 10e44239f67d0b6fb74006e61a7e883b8075247a upstream.

    The recent change for USB-audio disconnection race fixes introduced a
    mutex deadlock again.  There is a circular dependency between
    chip->shutdown_rwsem and pcm->open_mutex, depicted like below, when a
    device is opened during the disconnection operation:

    A. snd_usb_audio_disconnect() ->
         card.c::register_mutex ->
           chip->shutdown_rwsem (write) ->
             snd_card_disconnect() ->
               pcm.c::register_mutex ->
                 pcm->open_mutex

    B. snd_pcm_open() ->
         pcm->open_mutex ->
           snd_usb_pcm_open() ->
             chip->shutdown_rwsem (read)

    Since the chip->shutdown_rwsem protection in the case A is required
    only for turning on the chip->shutdown flag and it doesn't have to be
    taken for the whole operation, we can reduce its window in
    snd_usb_audio_disconnect().

    Reported-by: Jiri Slaby <jslaby@suse.cz>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit aaf238baf31e14cb1c111815193c3a78770b1873
Author: Takashi Iwai <tiwai@suse.de>
Date:   Thu Nov 8 14:36:18 2012 +0100

    ALSA: Fix card refcount unbalance

    commit 8bb4d9ce08b0a92ca174e41d92c180328f86173f upstream.

    There are uncovered cases whether the card refcount introduced by the
    commit a0830dbd isn't properly increased or decreased:
    - OSS PCM and mixer success paths
    - When lookup function gets NULL

    This patch fixes these places.

    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=50251

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

commit 919609d3cba52431b16501a63e6a5d45266a25c6
Author: Roland Dreier <roland@purestorage.com>
Date:   Wed Jul 20 06:22:21 2011 -0700

    intel-iommu: Fix AB-BA lockdep report

    commit 3e7abe2556b583e87dabda3e0e6178a67b20d06f upstream.

    When unbinding a device so that I could pass it through to a KVM VM, I
    got the lockdep report below.  It looks like a legitimate lock
    ordering problem:

     - domain_context_mapping_one() takes iommu->lock and calls
       iommu_support_dev_iotlb(), which takes device_domain_lock (inside
       iommu->lock).

     - domain_remove_one_dev_info() starts by taking device_domain_lock
       then takes iommu->lock inside it (near the end of the function).

    So this is the classic AB-BA deadlock.  It looks like a safe fix is to
    simply release device_domain_lock a bit earlier, since as far as I can
    tell, it doesn't protect any of the stuff accessed at the end of
    domain_remove_one_dev_info() anyway.

    BTW, the use of device_domain_lock looks a bit unsafe to me... it's
    at least not obvious to me why we aren't vulnerable to the race below:

      iommu_support_dev_iotlb()
                                              domain_remove_dev_info()

      lock device_domain_lock
        find info
      unlock device_domain_lock

                                              lock device_domain_lock
                                                find same info
                                              unlock device_domain_lock

                                              free_devinfo_mem(info)

      do stuff with info after it's free

    However I don't understand the locking here well enough to know if
    this is a real problem, let alone what the best fix is.

    Anyway here's the full lockdep output that prompted all of this:

         =======================================================
         [ INFO: possible circular locking dependency detected ]
         2.6.39.1+ #1
         -------------------------------------------------------
         bash/13954 is trying to acquire lock:
          (&(&iommu->lock)->rlock){......}, at: [<ffffffff812f6421>] domain_remove_one_dev_info+0x121/0x230

         but task is already holding lock:
          (device_domain_lock){-.-...}, at: [<ffffffff812f6508>] domain_remove_one_dev_info+0x208/0x230

         which lock already depends on the new lock.

         the existing dependency chain (in reverse order) is:

         -> #1 (device_domain_lock){-.-...}:
                [<ffffffff8109ca9d>] lock_acquire+0x9d/0x130
                [<ffffffff81571475>] _raw_spin_lock_irqsave+0x55/0xa0
                [<ffffffff812f8350>] domain_context_mapping_one+0x600/0x750
                [<ffffffff812f84df>] domain_context_mapping+0x3f/0x120
                [<ffffffff812f9175>] iommu_prepare_identity_map+0x1c5/0x1e0
                [<ffffffff81ccf1ca>] intel_iommu_init+0x88e/0xb5e
                [<ffffffff81cab204>] pci_iommu_init+0x16/0x41
                [<ffffffff81002165>] do_one_initcall+0x45/0x190
                [<ffffffff81ca3d3f>] kernel_init+0xe3/0x168
                [<ffffffff8157ac24>] kernel_thread_helper+0x4/0x10

         -> #0 (&(&iommu->lock)->rlock){......}:
                [<ffffffff8109bf3e>] __lock_acquire+0x195e/0x1e10
                [<ffffffff8109ca9d>] lock_acquire+0x9d/0x130
                [<ffffffff81571475>] _raw_spin_lock_irqsave+0x55/0xa0
                [<ffffffff812f6421>] domain_remove_one_dev_info+0x121/0x230
                [<ffffffff812f8b42>] device_notifier+0x72/0x90
                [<ffffffff8157555c>] notifier_call_chain+0x8c/0xc0
                [<ffffffff81089768>] __blocking_notifier_call_chain+0x78/0xb0
                [<ffffffff810897b6>] blocking_notifier_call_chain+0x16/0x20
                [<ffffffff81373a5c>] __device_release_driver+0xbc/0xe0
                [<ffffffff81373ccf>] device_release_driver+0x2f/0x50
                [<ffffffff81372ee3>] driver_unbind+0xa3/0xc0
                [<ffffffff813724ac>] drv_attr_store+0x2c/0x30
                [<ffffffff811e4506>] sysfs_write_file+0xe6/0x170
                [<ffffffff8117569e>] vfs_write+0xce/0x190
                [<ffffffff811759e4>] sys_write+0x54/0xa0
                [<ffffffff81579a82>] system_call_fastpath+0x16/0x1b

         other info that might help us debug this:

         6 locks held by bash/13954:
          #0:  (&buffer->mutex){+.+.+.}, at: [<ffffffff811e4464>] sysfs_write_file+0x44/0x170
          #1:  (s_active#3){++++.+}, at: [<ffffffff811e44ed>] sysfs_write_file+0xcd/0x170
          #2:  (&__lockdep_no_validate__){+.+.+.}, at: [<ffffffff81372edb>] driver_unbind+0x9b/0xc0
          #3:  (&__lockdep_no_validate__){+.+.+.}, at: [<ffffffff81373cc7>] device_release_driver+0x27/0x50
          #4:  (&(&priv->bus_notifier)->rwsem){.+.+.+}, at: [<ffffffff8108974f>] __blocking_notifier_call_chain+0x5f/0xb0
          #5:  (device_domain_lock){-.-...}, at: [<ffffffff812f6508>] domain_remove_one_dev_info+0x208/0x230

         stack backtrace:
         Pid: 13954, comm: bash Not tainted 2.6.39.1+ #1
         Call Trace:
          [<ffffffff810993a7>] print_circular_bug+0xf7/0x100
          [<ffffffff8109bf3e>] __lock_acquire+0x195e/0x1e10
          [<ffffffff810972bd>] ? trace_hardirqs_off+0xd/0x10
          [<ffffffff8109d57d>] ? trace_hardirqs_on_caller+0x13d/0x180
          [<ffffffff8109ca9d>] lock_acquire+0x9d/0x130
          [<ffffffff812f6421>] ? domain_remove_one_dev_info+0x121/0x230
          [<ffffffff81571475>] _raw_spin_lock_irqsave+0x55/0xa0
          [<ffffffff812f6421>] ? domain_remove_one_dev_info+0x121/0x230
          [<ffffffff810972bd>] ? trace_hardirqs_off+0xd/0x10
          [<ffffffff812f6421>] domain_remove_one_dev_info+0x121/0x230
          [<ffffffff812f8b42>] device_notifier+0x72/0x90
          [<ffffffff8157555c>] notifier_call_chain+0x8c/0xc0
          [<ffffffff81089768>] __blocking_notifier_call_chain+0x78/0xb0
          [<ffffffff810897b6>] blocking_notifier_call_chain+0x16/0x20
          [<ffffffff81373a5c>] __device_release_driver+0xbc/0xe0
          [<ffffffff81373ccf>] device_release_driver+0x2f/0x50
          [<ffffffff81372ee3>] driver_unbind+0xa3/0xc0
          [<ffffffff813724ac>] drv_attr_store+0x2c/0x30
          [<ffffffff811e4506>] sysfs_write_file+0xe6/0x170
          [<ffffffff8117569e>] vfs_write+0xce/0x190
          [<ffffffff811759e4>] sys_write+0x54/0xa0
          [<ffffffff81579a82>] system_call_fastpath+0x16/0x1b

    Signed-off-by: Roland Dreier <roland@purestorage.com>
    Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
    Cc: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 11b34bb13aebb075ba47e3a292443ab3cd9638f7
Author: Dave Chinner <dchinner@redhat.com>
Date:   Fri Nov 2 11:38:44 2012 +1100

    xfs: fix reading of wrapped log data

    commit 6ce377afd1755eae5c93410ca9a1121dfead7b87 upstream.

    Commit 4439647 ("xfs: reset buffer pointers before freeing them") in
    3.0-rc1 introduced a regression when recovering log buffers that
    wrapped around the end of log. The second part of the log buffer at
    the start of the physical log was being read into the header buffer
    rather than the data buffer, and hence recovery was seeing garbage
    in the data buffer when it got to the region of the log buffer that
    was incorrectly read.

    Reported-by: Torsten Kaiser <just.for.lkml@googlemail.com>
    Signed-off-by: Dave Chinner <dchinner@redhat.com>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Reviewed-by: Mark Tinguely <tinguely@sgi.com>
    Signed-off-by: Ben Myers <bpm@sgi.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 87725c35384baf9b6fbea6342807aab7071b0462
Author: Johan Hovold <jhovold@gmail.com>
Date:   Thu Nov 8 18:28:59 2012 +0100

    USB: mos7840: remove unused variable

    Fix warning about unused variable introduced by commit e681b66f2e19fa
    ("USB: mos7840: remove invalid disconnect handling") upstream.

    A subsequent fix which removed the disconnect function got rid of the
    warning but that one was only backported to v3.6.

    Reported-by: Jiri Slaby <jslaby@suse.cz>
    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b7832d49e5e0f4be7328efb271f097d39f61804a
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Sun Oct 21 12:52:39 2012 +0200

    drm/i915: clear the entire sdvo infoframe buffer

    commit b6e0e543f75729f207b9c72b0162ae61170635b2 upstream.

    Like in the case of native hdmi, which is fixed already in

    commit adf00b26d18e1b3570451296e03bcb20e4798cdd
    Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
    Date:   Tue Sep 25 13:23:34 2012 -0300

        drm/i915: make sure we write all the DIP data bytes

    we need to clear the entire sdvo buffer to avoid upsetting the
    display.

    Since infoframe buffer writing is now a bit more elaborate, extract it
    into it's own function. This will be useful if we ever get around to
    properly update the ELD for sdvo. Also #define proper names for the
    two buffer indexes with fixed usage.

    v2: Cite the right commit above, spotted by Paulo Zanoni.

    v3: I'm too stupid to paste the right commit.

    v4: Ben Hutchings noticed that I've failed to handle an underflow in
    my loop logic, breaking it for i >= length + 8. Since I've just lost C
    programmer license, use his solution. Also, make the frustrated 0-base
    buffer size a notch more clear.

    Reported-and-tested-by: Jürg Billeter <j@bitron.ch>
    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=25732
    Cc: Paulo Zanoni <przanoni@gmail.com>
    Cc: Ben Hutchings <ben@decadent.org.uk>
    Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9615dee441f72d194234455ed30660c145260973
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Sat May 12 20:22:00 2012 +0200

    drm/i915: fixup infoframe support for sdvo

    commit 81014b9d0b55fb0b48f26cd2a943359750d532db upstream.

    At least the worst offenders:
    - SDVO specifies that the encoder should compute the ecc. Testing also
      shows that we must not send the ecc field, so copy the dip_infoframe
      struct to a temporay place and avoid the ecc field. This way the avi
      infoframe is exactly 17 bytes long, which agrees with what the spec
      mandates as a minimal storage capacity (with the ecc field it would
      be 18 bytes).
    - Only 17 when sending the avi infoframe. The SDVO spec explicitly
      says that sending more data than what the device announces results
      in undefined behaviour.
    - Add __attribute__((packed)) to the avi and spd infoframes, for
      otherwise they're wrongly aligned. Noticed because the avi infoframe
      ended up being 18 bytes large instead of 17. We haven't noticed this
      yet because we don't use the uint16_t fields yet (which are the only
      ones that would be wrongly aligned).

    This regression has been introduce by

    3c17fe4b8f40a112a85758a9ab2aebf772bdd647 is the first bad commit
    commit 3c17fe4b8f40a112a85758a9ab2aebf772bdd647
    Author: David Härdeman <david@hardeman.nu>
    Date:   Fri Sep 24 21:44:32 2010 +0200

        i915: enable AVI infoframe for intel_hdmi.c [v4]

    Patch tested on my g33 with a sdvo hdmi adaptor.

    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=25732
    Tested-by: Peter Ross <pross@xvid.org> (G35 SDVO-HDMI)
    Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
    Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Cc: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d18edec7ace955fad9948eb3ee71d34f79d377ca
Author: Thomas Hellstrom <thellstrom@vmware.com>
Date:   Fri Nov 9 10:05:57 2012 +0100

    drm/vmwgfx: Fix hibernation device reset

    commit 95e8f6a21996c4cc2c4574b231c6e858b749dce3 upstream.

    The device would not reset properly when resuming from hibernation.

    Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
    Reviewed-by: Brian Paul <brianp@vmware.com>
    Reviewed-by: Dmitry Torokhov <dtor@vmware.com>
    Cc: linux-graphics-maintainer@vmware.com
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2f56580d924c9283292d10567fb7744d9c0fd2b2
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Tue Oct 23 22:29:38 2012 +0200

    futex: Handle futex_pi OWNER_DIED take over correctly

    commit 59fa6245192159ab5e1e17b8e31f15afa9cff4bf upstream.

    Siddhesh analyzed a failure in the take over of pi futexes in case the
    owner died and provided a workaround.
    See: http://sourceware.org/bugzilla/show_bug.cgi?id=14076

    The detailed problem analysis shows:

    Futex F is initialized with PTHREAD_PRIO_INHERIT and
    PTHREAD_MUTEX_ROBUST_NP attributes.

    T1 lock_futex_pi(F);

    T2 lock_futex_pi(F);
       --> T2 blocks on the futex and creates pi_state which is associated
           to T1.

    T1 exits
       --> exit_robust_list() runs
           --> Futex F userspace value TID field is set to 0 and
               FUTEX_OWNER_DIED bit is set.

    T3 lock_futex_pi(F);
       --> Succeeds due to the check for F's userspace TID field == 0
       --> Claims ownership of the futex and sets its own TID into the
           userspace TID field of futex F
       --> returns to user space

    T1 --> exit_pi_state_list()
           --> Transfers pi_state to waiter T2 and wakes T2 via
           	   rt_mutex_unlock(&pi_state->mutex)

    T2 --> acquires pi_state->mutex and gains real ownership of the
           pi_state
       --> Claims ownership of the futex and sets its own TID into the
           userspace TID field of futex F
       --> returns to user space

    T3 --> observes inconsistent state

    This problem is independent of UP/SMP, preemptible/non preemptible
    kernels, or process shared vs. private. The only difference is that
    certain configurations are more likely to expose it.

    So as Siddhesh correctly analyzed the following check in
    futex_lock_pi_atomic() is the culprit:

    	if (unlikely(ownerdied || !(curval & FUTEX_TID_MASK))) {

    We check the userspace value for a TID value of 0 and take over the
    futex unconditionally if that's true.

    AFAICT this check is there as it is correct for a different corner
    case of futexes: the WAITERS bit became stale.

    Now the proposed change

    -	if (unlikely(ownerdied || !(curval & FUTEX_TID_MASK))) {
    +       if (unlikely(ownerdied ||
    +                       !(curval & (FUTEX_TID_MASK | FUTEX_WAITERS)))) {

    solves the problem, but it's not obvious why and it wreckages the
    "stale WAITERS bit" case.

    What happens is, that due to the WAITERS bit being set (T2 is blocked
    on that futex) it enforces T3 to go through lookup_pi_state(), which
    in the above case returns an existing pi_state and therefor forces T3
    to legitimately fight with T2 over the ownership of the pi_state (via
    pi_state->mutex). Probelm solved!

    Though that does not work for the "WAITERS bit is stale" problem
    because if lookup_pi_state() does not find existing pi_state it
    returns -ERSCH (due to TID == 0) which causes futex_lock_pi() to
    return -ESRCH to user space because the OWNER_DIED bit is not set.

    Now there is a different solution to that problem. Do not look at the
    user space value at all and enforce a lookup of possibly available
    pi_state. If pi_state can be found, then the new incoming locker T3
    blocks on that pi_state and legitimately races with T2 to acquire the
    rt_mutex and the pi_state and therefor the proper ownership of the
    user space futex.

    lookup_pi_state() has the correct order of checks. It first tries to
    find a pi_state associated with the user space futex and only if that
    fails it checks for futex TID value = 0. If no pi_state is available
    nothing can create new state at that point because this happens with
    the hash bucket lock held.

    So the above scenario changes to:

    T1 lock_futex_pi(F);

    T2 lock_futex_pi(F);
       --> T2 blocks on the futex and creates pi_state which is associated
           to T1.

    T1 exits
       --> exit_robust_list() runs
           --> Futex F userspace value TID field is set to 0 and
               FUTEX_OWNER_DIED bit is set.

    T3 lock_futex_pi(F);
       --> Finds pi_state and blocks on pi_state->rt_mutex

    T1 --> exit_pi_state_list()
           --> Transfers pi_state to waiter T2 and wakes it via
           	   rt_mutex_unlock(&pi_state->mutex)

    T2 --> acquires pi_state->mutex and gains ownership of the pi_state
       --> Claims ownership of the futex and sets its own TID into the
           userspace TID field of futex F
       --> returns to user space

    This covers all gazillion points on which T3 might come in between
    T1's exit_robust_list() clearing the TID field and T2 fixing it up. It
    also solves the "WAITERS bit stale" problem by forcing the take over.

    Another benefit of changing the code this way is that it makes it less
    dependent on untrusted user space values and therefor minimizes the
    possible wreckage which might be inflicted.

    As usual after staring for too long at the futex code my brain hurts
    so much that I really want to ditch that whole optimization of
    avoiding the syscall for the non contended case for PI futexes and rip
    out the maze of corner case handling code. Unfortunately we can't as
    user space relies on that existing behaviour, but at least thinking
    about it helps me to preserve my mental sanity. Maybe we should
    nevertheless :)

    Reported-and-tested-by: Siddhesh Poyarekar <siddhesh.poyarekar@gmail.com>
    Link: http://lkml.kernel.org/r/alpine.LFD.2.02.1210232138540.2756@ionos
    Acked-by: Darren Hart <dvhart@linux.intel.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2e570a4eeaf48f9a8302a0f71ff96ff9d0b723f6
Author: Hannes Frederic Sowa <hannes@stressinduktion.org>
Date:   Tue Nov 6 16:18:41 2012 +0000

    ipv6: send unsolicited neighbour advertisements to all-nodes

    [ Upstream commit 60713a0ca7fd6651b951cc1b4dbd528d1fc0281b ]

    As documented in RFC4861 (Neighbor Discovery for IP version 6) 7.2.6.,
    unsolicited neighbour advertisements should be sent to the all-nodes
    multicast address.

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

commit 5a3e425d67aab6b6f0b3bd3fb372b8044b8e981b
Author: Tom Parkin <tparkin@katalix.com>
Date:   Mon Oct 29 23:41:48 2012 +0000

    l2tp: fix oops in l2tp_eth_create() error path

    [ Upstream commit 789336360e0a2aeb9750c16ab704a02cbe035e9e ]

    When creating an L2TPv3 Ethernet session, if register_netdev() should fail for
    any reason (for example, automatic naming for "l2tpeth%d" interfaces hits the
    32k-interface limit), the netdev is freed in the error path.  However, the
    l2tp_eth_sess structure's dev pointer is left uncleared, and this results in
    l2tp_eth_delete() then attempting to unregister the same netdev later in the
    session teardown.  This results in an oops.

    To avoid this, clear the session dev pointer in the error path.

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

commit 798c7dba9071df9cdd935da16066e1a17580d9ee
Author: Jesper Dangaard Brouer <brouer@redhat.com>
Date:   Wed Oct 31 02:45:32 2012 +0000

    net: fix divide by zero in tcp algorithm illinois

    [ Upstream commit 8f363b77ee4fbf7c3bbcf5ec2c5ca482d396d664 ]

    Reading TCP stats when using TCP Illinois congestion control algorithm
    can cause a divide by zero kernel oops.

    The division by zero occur in tcp_illinois_info() at:
     do_div(t, ca->cnt_rtt);
    where ca->cnt_rtt can become zero (when rtt_reset is called)

    Steps to Reproduce:
     1. Register tcp_illinois:
         # sysctl -w net.ipv4.tcp_congestion_control=illinois
     2. Monitor internal TCP information via command "ss -i"
         # watch -d ss -i
     3. Establish new TCP conn to machine

    Either it fails at the initial conn, or else it needs to wait
    for a loss or a reset.

    This is only related to reading stats.  The function avg_delay() also
    performs the same divide, but is guarded with a (ca->cnt_rtt > 0) at its
    calling point in update_params().  Thus, simply fix tcp_illinois_info().

    Function tcp_illinois_info() / get_info() is called without
    socket lock.  Thus, eliminate any race condition on ca->cnt_rtt
    by using a local stack variable.  Simply reuse info.tcpv_rttcnt,
    as its already set to ca->cnt_rtt.
    Function avg_delay() is not affected by this race condition, as
    its called with the socket lock.

    Cc: Petr Matousek <pmatouse@redhat.com>
    Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
    Acked-by: Eric Dumazet <edumazet@google.com>
    Acked-by: Stephen Hemminger <shemminger@vyatta.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 690bfe52ce0784e7a24ae8a37929580b6bd65bc9
Author: Hemant Kumar <hemantk@codeaurora.org>
Date:   Thu Oct 25 18:17:54 2012 +0000

    net: usb: Fix memory leak on Tx data path

    [ Upstream commit 39707c2a3ba5011038b363f84d37c8a98d2d9db1 ]

    Driver anchors the tx urbs and defers the urb submission if
    a transmit request comes when the interface is suspended.
    Anchoring urb increments the urb reference count. These
    deferred urbs are later accessed by calling usb_get_from_anchor()
    for submission during interface resume. usb_get_from_anchor()
    unanchors the urb but urb reference count remains same.
    This causes the urb reference count to remain non-zero
    after usb_free_urb() gets called and urb never gets freed.
    Hence call usb_put_urb() after anchoring the urb to properly
    balance the reference count for these deferred urbs. Also,
    unanchor these deferred urbs during disconnect, to free them
    up.

    Signed-off-by: Hemant Kumar <hemantk@codeaurora.org>
    Acked-by: Oliver Neukum <oneukum@suse.de>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit db138ef294594d3721dae6409d9e13d6ebf3df39
Author: Li RongQing <roy.qing.li@gmail.com>
Date:   Wed Oct 24 14:01:18 2012 +0800

    ipv6: Set default hoplimit as zero.

    [ Upstream commit 14edd87dc67311556f1254a8f29cf4dd6cb5b7d1 ]

    Commit a02e4b7dae4551(Demark default hoplimit as zero) only changes the
    hoplimit checking condition and default value in ip6_dst_hoplimit, not
    zeros all hoplimit default value.

    Keep the zeroing ip6_template_metrics[RTAX_HOPLIMIT - 1] to force it as
    const, cause as a37e6e344910(net: force dst_default_metrics to const
    section)

    Signed-off-by: Li RongQing <roy.qing.li@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3297d60d4ebc83a4dc6c44abad18d181c6680b9e
Author: Eric Dumazet <edumazet@google.com>
Date:   Thu Oct 18 09:14:12 2012 +0000

    tcp: fix FIONREAD/SIOCINQ

    [ Upstream commit a3374c42aa5f7237e87ff3b0622018636b0c847e ]

    tcp_ioctl() tries to take into account if tcp socket received a FIN
    to report correct number bytes in receive queue.

    But its flaky because if the application ate the last skb,
    we return 1 insteKroah-Hartman <gregkh@linuxfoundation.org>

commit 4d02840c82b479b4a4c316bd279e1a83649e59ed
Author: Trond Myklebust <Trond.Myklebust@netapp.com>
Date:   Wed Aug 22 16:08:17 2012 -0400

    NFS: Fix Oopses in nfs_lookup_revalidate and nfs4_lookup_revalidate

    [Fixed upstream as part of 0b728e1911c, but that's a much larger patch,
    this is only the nfs portion backported as needed.]

    Fix the following Oops in 3.5.1:

     BUG: unable to handle kernel NULL pointer dereference at 0000000000000038
     IP: [<ffffffffa03789cd>] nfs_lookup_revalidate+0x2d/0x480 [nfs]
     PGD 337c63067 PUD 0
     Oops: 0000 [#1] SMP
     CPU 5
     Modules linked in: nfs fscache nfsd lockd nfs_acl auth_rpcgss sunrpc af_packet binfmt_misc cpufreq_conservative cpufreq_userspace cpufreq_powersave dm_mod acpi_cpufreq mperf coretemp gpio_ich kvm_intel joydev kvm ioatdma hid_generic igb lpc_ich i7core_edac edac_core ptp serio_raw dca pcspkr i2c_i801 mfd_core sg pps_core usbhid crc32c_intel microcode button autofs4 uhci_hcd ttm drm_kms_helper drm i2c_algo_bit sysimgblt sysfillrect syscopyarea ehci_hcd usbcore usb_common scsi_dh_rdac scsi_dh_emc scsi_dh_hp_sw scsi_dh_alua scsi_dh edd fan ata_piix thermal processor thermal_sys

     Pid: 30431, comm: java Not tainted 3.5.1-2-default #1 Supermicro X8DTT/X8DTT
     RIP: 0010:[<ffffffffa03789cd>]  [<ffffffffa03789cd>] nfs_lookup_revalidate+0x2d/0x480 [nfs]
     RSP: 0018:ffff8801b418bd38  EFLAGS: 00010292
     RAX: 00000000fffffff6 RBX: ffff88032016d800 RCX: 0000000000000020
     RDX: ffffffff00000000 RSI: 0000000000000000 RDI: ffff8801824a7b00
     RBP: ffff8801b418bdf8 R08: 7fffff0034323030 R09: fffffffff04c03ed
     R10: ffff8801824a7b00 R11: 0000000000000002 R12: ffff8801824a7b00
     R13: ffff8801824a7b00 R14: 0000000000000000 R15: ffff8803201725d0
     FS:  00002b53a46cb700(0000) GS:ffff88033fc20000(0000) knlGS:0000000000000000
     CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
     CR2: 0000000000000038 CR3: 000000020a426000 CR4: 00000000000007e0
     DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
     DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
     Process java (pid: 30431, threadinfo ffff8801b418a000, task ffff8801b5d20600)
     Stack:
      ffff8801b418be44 ffff88032016d800 ffff8801b418bdf8 0000000000000000
      ffff8801824a7b00 ffff8801b418bdd7 ffff8803201725d0 ffffffff8116a9c0
      ffff8801b5c38dc0 0000000000000007 ffff88032016d800 0000000000000000
     Call Trace:
      [<ffffffff8116a9c0>] lookup_dcache+0x80/0xe0
      [<ffffffff8116aa43>] __lookup_hash+0x23/0x90
      [<ffffffff8116b4a5>] lookup_one_len+0xc5/0x100
      [<ffffffffa03869a3>] nfs_sillyrename+0xe3/0x210 [nfs]
      [<ffffffff8116cadf>] vfs_unlink.part.25+0x7f/0xe0
      [<ffffffff8116f22c>] do_unlinkat+0x1ac/0x1d0
      [<ffffffff815717b9>] system_call_fastpath+0x16/0x1b
      [<00002b5348b5f527>] 0x2b5348b5f526
     Code: ec 38 b8 f6 ff ff ff 4c 89 64 24 18 4c 89 74 24 28 49 89 fc 48 89 5c 24 08 48 89 6c 24 10 49 89 f6 4c 89 6c 24 20 4c 89 7c 24 30 <f6> 46 38 40 0f 85 d1 00 00 00 e8 c4 c4 df e0 48 8b 58 30 49 89
     RIP  [<ffffffffa03789cd>] nfs_lookup_revalidate+0x2d/0x480 [nfs]
      RSP <ffff8801b418bd38>
     CR2: 0000000000000038
     ---[ end trace 845113ed191985dd ]---

    This Oops affects 3.5 kernels and older, and is due to lookup_one_len()
    calling down to the dentry revalidation code with a NULL pointer
    to struct nameidata.

    It is fixed upstream by commit 0b728e1911c (stop passing nameidata *
    to ->d_revalidate())

    Reported-by: Richard Ems <richard.ems@cape-horn-eng.com>
    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 095a51831f6e6956b80bd5f921f412a6530f1bc2
Author: NeilBrown <neilb@suse.de>
Date:   Wed Oct 31 12:16:01 2012 +1100

    NFS: fix bug in legacy DNS resolver.

    commit 8d96b10639fb402357b75b055b1e82a65ff95050 upstream.

    The DNS resolver's use of the sunrpc cache involves a 'ttl' number
    (relatafe890f953f7f23424045cdad31d3e4
         "sunrpc: use seconds since boot in expiry cache"

    and I managed to break it.  The effect is that any TTL is interpreted
    as 0, and nothing useful gets into the cache.

    This patch removes the use of get_expiry() - which really expects an
    expiry time - and uses get_uint() instead, treating the int correctly
    as a ttl.

    This fixes a regression that has been present since 2.6.37, causing
    certain NFS accesses in certain environments to incorrectly fail.

    Reported-by: Chuck Lever <chuck.lever@oracle.com>
    Tested-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: NeilBrown <neilb@suse.de>
    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 110d3a25cc089af6a8b7ddee3f01e65aeb55ae49
Author: J. Bruce Fields <bfields@redhat.com>
Date:   Tue Jun 12 16:54:16 2012 -0400

    nfsd: add get_uint for u32's

    commit a007c4c3e943ecc054a806c259d95420a188754b upstream.

    I don't think there's a practical difference for the range of values
    these interfaces should see, but it would be safer to be unambiguous.

    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Cc: Sasha Levin <sasha.levin@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f354d0c0ca37522c2efcced954ade7cdca479a98
Author: Trond Myklebust <Trond.Myklebust@netapp.com>
Date:   Mon Oct 29 18:53:23 2012 -0400

    NFSv4: nfs4_locku_done must release the sequence id

    commit 2b1bc308f492589f7d49012ed24561534ea2be8c upstream.

    If the state recovery machinery is triggered by the call to
    nfs4_async_handle_error() then we can deadlock.

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

commit 6fbd3cdb9365377e3d0fb5b4c86e16d71678103b
Author: Ben Hutchings <ben@decadent.org.uk>
Date:   Sun Oct 21 19:23:52 2012 +0100

    nfs: Show original device name verbatim in /proc/*/mount{s,info}

    commit 97a54868262da1629a3e65121e65b8e8c4419d9f upstream.

    Since commit c7f404b ('vfs: new superblock methods to override
    /proc/*/mount{s,info}'), nfs_path() is used to generate the mounted
    device name reported back to userland.

    nfs_path() always generates a trailing slash when the given dentry is
    the root of an NFS mount, but userland may expect the original device
    name to be returned verbatim (as it used to be).  Make this
    canonicalisation optional and change the callers accordingly.

    [jrnieder@gmail.com: use flag instead of bool argument]
    Reported-and-tested-by: Chris Hiestand <chiestand@salk.edu>
    Reference: http://bugs.debian.org/669314
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e4648b149c10256dbc4d4ce5d1c052e733d224f5
Author: Scott Mayhew <smayhew@redhat.com>
Date:   Tue Oct 16 13:22:19 2012 -0400

    nfsv3: Make v3 mounts fail with ETIMEDOUTs instead EIO on mountd timeouts

    commit acce94e68a0f346115fd41cdc298197d2d5a59ad upstream.

    In very busy v3 environment, rpc.mountd can respond to the NULL
    procedure but not the MNT procedure in a timely manner causing
    the MNT procedure to time out. The problem is the mount system
    call returns EIO which causes the mount to fail, instead of
    ETIMEDOUT, which would cause the mount to be retried.

    This patch sets the RPC_TASK_SOFT|RPC_TASK_TIMEOUT flags to
    the rpc_call_sync() call in nfs_mount() which causes
    ETIMEDOUT to be returned on timed out connections.

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

commit 9c750c9809ddeb36dffc376ad26e7864d4c2a259
Author: Antonio Q11: fix SSID copy on IBSS JOIN

    commit badecb001a310408d3473b1fc2ed5aefd0bc92a9 upstream.

    The 'ssid' field of the cfg80211_ibss_params is a u8 pointer and
    its length is likely to be less than IEEE80211_MAX_SSID_LEN most
    of the time.

    This patch fixes the ssid copy in ieee80211_ibss_join() by using
    the SSID length to prevent it from reading beyond the string.

    Signed-off-by: Antonio Quartulli <ordex@autistici.org>
    [rewrapped commit message, small rewording]
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 03938ad82dcc45ecc5695ed14f7869b06b233b8d
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Fri Oct 26 00:33:36 2012 +0200

    mac80211: check management frame header length

    commit 4a4f1a5808c8bb0b72a4f6e5904c53fb8c9cd966 upstream.

    Due to pskb_may_pull() checking the skb length, all
    non-management frames are checked on input whether
    their 802.11 header is fully present. Also add that
    check for management frames and remove a check that
    is now duplicate. This prevents accessing skb data
    beyond the frame end.

    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2dda2bb41abe27bdfab30234d56320339a411b3d
Author: Egbert Eich <eich@suse.de>
Date:   Wed Oct 24 18:29:49 2012 +0200

    DRM/Radeon: Fix Load Detection on legacy primary DAC.

    commit 83325d072185899b706de2956170b246585aaec9 upstream.

    An uninitialized variable led to broken load detection.

    Signed-off-by: Egbert Eich <eich@suse.de>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6f8acfdc74e6b117623f84de77c4822656f95c53
Author: Javier Cardona <javier@cozybit.com>
Date:   Thu Oct 25 11:10:18 2012 -0700

    mac80211: don't inspect Sequence Control field on control frames

    commit f7fbf70ee9db6da6033ae50d100e017ac1f26555 upstream.

    Per IEEE Std. 802.11-2012, Sec 8.2.4.4.1, the sequence Control field is
    not present in control frames.  We noticed this problem when processing
    Block Ack Requests.

    Signed-off-by: Javier Cardona <javier@cozybit.com>
    Signed-off-by: Javier Lopez <jlopex@cozybit.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4bdd5ed8d955d712e77bbabb42e9a3c4c50a47df
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Thu Oct 25 21:51:59 2012 +0200

    wireless: drop invalid mesh address extension frames

    commit 7dd111e8ee10cc6816669eabcad3334447673236 upstream.

    The mesh header can have address extension by a 4th
    or a 5th and 6th address, but never both. Drop such
    frames in 802.11 -> 802.3 conversion along with any
    frames that have the wrong extension.

    Reviewed-by: Javier Cardona <javier@cozybit.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 58bca02682d3df9975ccabae2196f6aefcfeda3d
Author: Felix Fietkau <nbd@openwrt.org>
Date:   Wed Oct 17 13:56:19 2012 +0200

    cfg80211: fix antenna gain handling

    commit c4a9fafc77a5318f5ed26c509bbcddf03e18c201 upstream.

    No driver initializes chan->max_antenna_gain to something sensible, and
    the only place where it is being used right now is inside ath9k. This
    leads to ath9k potentially using less tx power than it can use, which can
    decrease performance/range in some rare cases.

    Rather than going through every single driver, this patch initializes
    chan->orig_mag in wiphy_register(), ignoring whatever value the driver
    left in there. If a driver for some reason wishes to limit it independent
    from regulatory rulesets, it can do so internally.

    Signed-off-by: Felix Fietkau <nbd@openwrt.org>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
  purestorage.com>
Date:   Wed Oct 31 09:16:44 2012 -0700

    target: Don't return success from module_init() if setup fails

    commit 0d0f9dfb31e0a6c92063e235417b42df185b3275 upstream.

    If the call to core_dev_release_virtual_lun0() fails, then nothing
    sets ret to anything other than 0, so even though everything is
    torn down and freed, target_core_init_configfs() will seem to succeed
    and the module will be loaded.  Fix this by passing the return value
    on up the chain.

    Signed-off-by: Roland Dreier <roland@purestorage.com>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4a7dfa5ea7f7a4736ba9425cbd343d0eb18f521f
Author: Stanislaw Gruszka <sgruszka@redhat.com>
Date:   Thu Oct 25 09:51:39 2012 +0200

    rt2800: validate step value for temperature compensation

    commit bf7e1abe434ba9e22e8dc04a4cba4ab504b788b8 upstream.

    Some hardware has correct (!= 0xff) value of tssi_bounds[4] in the
    EEPROM, but step is equal to 0xff. This results on ridiculous delta
    calculations and completely broke TX power settings.

    Reported-and-tested-by: Pavel Lucik <pavel.lucik@gmail.com>
    Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
    Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a699cd395b19aa262fbffcbe79aec1c57238e489
Author: Felix Fietkau <nbd@openwrt.org>
Date:   Fri Oct 26 00:31:11 2012 +0200

    ath9k: fix stale pointers potentially causing access to free'd skbs

    commit 8c6e30936a7893a85f6222084f0f26aceb81137a upstream.

    bf->bf_next is only while buffers are chained as part of an A-MPDU
    in the tx queue. When a tid queue is flushed (e.g. on tearing down
    an aggregation session), frames can be enqueued again as normal
    transmission, without bf_next being cleared. This can lead to the
    old pointer being dereferenced again later.

    This patch might fix crashes and "Failed to stop TX DMA!" messages.

    Signed-off-by: Felix Fietkau <nbd@openwrt.org>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bluetooth: Send Disconnection reason to Bluez

Send device disconnection reason to bluez on receiving the
diconnection complete event so that low energy profiles
such as proximity can decide to reconnect if the reason
is link loss.

CRs-Fixed: 378240
Signed-off-by: Archana Ramachandran <archanar@codeaurora.org>
(cherry picked from commit da09d26a75ee1c7c1911dcfbe0128fd09f6631f4)

Change-Id: I7aa5ed6685e96c936b9c9513eebe4e16bc10269e
Signed-off-by: Gopal Goberu <ggober@codeaurora.org>
msm_fb: display: fix division-by-zero bug

Panel v_back_porch could be zero for virtual panels, so the check for
zero is added to fix the bug.

Signed-off-by: Huaibin Yang <huaibiny@codeaurora.org>
(cherry picked from commit d49fe89aa7eb042947a64f1d5b5f12f54d2c033b)

Conflicts:

	drivers/video/msm/mdp4_overlay.c

Change-Id: I48808daf26afd3b10b24f58c10068a7e11da40a5
Signed-off-by: Sudhir Sharma <sudsha@codeaurora.org>
msm_fb: display: add mdp clk rate calculation for low vbp

For the panels that have low v_back_porch, if h/w FIR scaling is used,
during vbp time, mdp clk should be fast enough to output a line from 4
input lines. MDP rate equation for very small scaling, e.g. 1 or 2
pixels' upscaling or downscaling cannot cover this case, where
underruns are seen on those panels.

Signed-off-by: Huaibin Yang <huaibiny@codeaurora.org>
(cherry picked from commit e9d4bc826ca849b873f9e91bda68004aa7d78b25)

Conflicts:

	drivers/video/msm/mdp4_overlay.c

Change-Id: I63aadf8e322c17fad2019b2c4081b0d13209f504
Signed-off-by: Sudhir Sharma <sudsha@codeaurora.org>
msm_fb: display: fix the underrun issue when playing interlaced videos

Interlaced videos require higher mdp clk rate and the current code
sets mdp clk to max and return. However mdp clk calculation may still
give a result higher than max mdp clk, for this case the result is
kept and used later to enable blt mode to avoid underrun.

Change-Id: I185d0d15e5b79e94561e790e41713cdb405f8bf4
Signed-off-by: Huaibin Yang <huaibiny@codeaurora.org>
(cherry picked from commit 5dcea9b4522d3bdc1a0fe38406881b264ce074b8)
msm_fb: display: fix division-by-zero bug

Panel v_back_porch could be zero for virtual panels, so the check for
zero is added to fix the bug.

Signed-off-by: Huaibin Yang <huaibiny@codeaurora.org>
(cherry picked from commit d49fe89aa7eb042947a64f1d5b5f12f54d2c033b)

Change-Id: I7da4d37c90f6830335a2d818eaae15c78a19c0b5
Signed-off-by: Gopal Goberu <ggober@codeaurora.org>
msm_fb: display: proper mdp core clock selection for 7x30

Add proper calculation for MDP core clocks for MDDI panel.
Also, add 10 % blanking in the case where the panel where
horizontal and vertical porch values are not available.

Change-Id: I63b7ac902f6826dd300e385c42e7eb975d6390c5
Signed-off-by: Jeevan Shriram <jshriram@codeaurora.org>
msm_fb: Calculate mdp core clock during every pan display

Calculate the mdp core clock value for MDDI panel for every pan
display. This helps in setting the clock only to the required
value based on the use case.

Change-Id: I40f8be9835a8993733b94393e363a393b7efb000
Signed-off-by: Jeevan Shriram <jshriram@codeaurora.org>
msm_fb: display: Fix blend configuration for command mode panels

For command mode panels, do the blend configuration in play call
itself instead of doing in isr.

CRs-Fixed: 410029
CRs-Fixed: 415553
Signed-off-by: Mayank Chopra <makchopra@codeaurora.org>
(cherry picked from commit 9b2be0d1adabacfbe539a4e7f05f6d6e5579c611)

Change-Id: I638b27e445c0c4b6c98ff9bee0a3055e87caead4
Signed-off-by: Gopal Goberu <ggober@codeaurora.org>
msm_fb: display: quick workaround to fix build