Linux 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 instead of 0.

    Correct way to detect that FIN was received is to test SOCK_DONE.

    Reported-by: Elliot Hughes <enh@google.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Neal Cardwell <ncardwell@google.com>
    Cc: Tom Herbert <therbert@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fdc00abab6858f9da6a40e03c831c252b4f419bd
Author: Eric Dumazet <edumazet@google.com>
Date:   Thu Oct 18 03:21:55 2012 +0000

    netlink: use kfree_rcu() in netlink_release()

    [ Upstream commit 6d772ac5578f711d1ce7b03535d1c95bffb21dff ]

    On some suspend/resume operations involving wimax device, we have
    noticed some intermittent memory corruptions in netlink code.

    Stéphane Marchesin tracked this corruption in netlink_update_listeners()
    and suggested a patch.

    It appears netlink_release() should use kfree_rcu() instead of kfree()
    for the listeners structure as it may be used by other cpus using RCU
    protection.

    netlink_release() must set to NULL the listeners pointer when
    it is about to be freed.

    Also have to protect netlink_update_listeners() and
    netlink_has_listeners() if listeners is NULL.

    Add a nl_deref_protected() lockdep helper to properly document which
    locks protects us.

    Reported-by: Jonathan Kliegman <kliegs@google.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Stéphane Marchesin <marcheu@google.com>
    Cc: Sam Leffler <sleffler@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b23270416da409bd4e637a5acbe31a1126235fb6
Author: Zijie Pan <zijie.pan@6wind.com>
Date:   Mon Oct 15 03:56:39 2012 +0000

    sctp: fix call to SCTP_CMD_PROCESS_SACK in sctp_cmd_interpreter()

    [ Upstream commit f6e80abeab928b7c47cc1fbf53df13b4398a2bec ]

    Bug introduced by commit edfee0339e681a784ebacec7e8c2dc97dc6d2839
    (sctp: check src addr when processing SACK to update transport state)

    Signed-off-by: Zijie Pan <zijie.pan@6wind.com>
    Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
    Acked-by: Vlad Yasevich <vyasevich@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8a7173c58c8a1e25d7b2d572f045da837bb373bf
Author: Takashi Iwai <tiwai@suse.de>
Date:   Wed Nov 7 12:44:13 2012 +0100

    ALSA: Avoid endless sleep after disconnect

    commit 0914f7961babbf28aaa2f19b453951fb4841c03f upstream.

    When disconnect callback is called, each component should wake up
    sleepers and check card->shutdown flag for avoiding the endless sleep
    blocking the proper resource release.

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

commit 40edba667959559aa4385a5ec047420fcfeb5f03
Author: Takashi Iwai <tiwai@suse.de>
Date:   Wed Nov 7 12:44:12 2012 +0100

    ALSA: Add a reference counter to card instance

    commit a0830dbd4e42b38aefdf3fb61ba5019a1a99ea85 upstream.

    For more strict protection for wild disconnections, a refcount is
    introduced to the card instance, and let it up/down when an object is
    referred via snd_lookup_*() in the open ops.

    The free-after-last-close check is also changed to check this refcount
    instead of the empty list, too.

    Reported-by: Matthieu CASTET <matthieu.castet@parrot.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fb434cc26173c2285d48d640c639493bc6a6c5f5
Author: Takashi Iwai <tiwai@suse.de>
Date:   Wed Nov 7 12:44:11 2012 +0100

    ALSA: usb-audio: Fix races at disconnection in mixer_quirks.c

    commit 888ea7d5ac6815ba16b3b3a20f665a92c7af6724 upstream.

    Similar like the previous commit, cover with chip->shutdown_rwsem
    and chip->shutdown checks.

    Reported-by: Matthieu CASTET <matthieu.castet@parrot.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 14565776bea2c57d2f8d1cd7aeee6a0723ac2a05
Author: Takashi Iwai <tiwai@suse.de>
Date:   Wed Nov 7 12:44:10 2012 +0100

    ALSA: usb-audio: Use rwsem for disconnect protection

    commit 34f3c89fda4fba9fe689db22253ca8db2f5e6386 upstream.

    Replace mutex with rwsem for codec->shutdown protection so that
    concurrent accesses are allowed.

    Also add the protection to snd_usb_autosuspend() and
    snd_usb_autoresume(), too.

    Reported-by: Matthieu CASTET <matthieu.castet@parrot.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ea7b69a0b6816926e85cedbe5e1b1b8d3e2e5500
Author: Takashi Iwai <tiwai@suse.de>
Date:   Wed Nov 7 12:44:09 2012 +0100

    ALSA: usb-audio: Fix races at disconnection

    commit 978520b75f0a1ce82b17e1e8186417250de6d545 upstream.

    Close some races at disconnection of a USB audio device by adding the
    chip->shutdown_mutex and chip->shutdown check at appropriate places.

    The spots to put bandaids are:
    - PCM prepare, hw_params and hw_free
    - where the usb device is accessed for communication or get speed, in
     mixer.c and others; the device speed is now cached in subs->speed
     instead of accessing to chip->dev

    The accesses in PCM open and close don't need the mutex protection
    because these are already handled in the core PCM disconnection code.

    The autosuspend/autoresume codes are still uncovered by this patch
    because of possible mutex deadlocks.  They'll be covered by the
    upcoming change to rwsem.

    Also the mixer codes are untouched, too.  These will be fixed in
    another patch, too.

    Reported-by: Matthieu CASTET <matthieu.castet@parrot.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 61bc2855cf2e28f7ef3928c04453daa07dfffd9b
Author: Takashi Iwai <tiwai@suse.de>
Date:   Wed Nov 7 12:39:51 2012 +0100

    ALSA: PCM: Fix some races at disconnection

    commit 9b0573c07f278e9888c352aa9724035c75784ea0 upstream.

    Fix races at PCM disconnection:
    - while a PCM device is being opened or closed
    - while the PCM state is being changed without lock in prepare,
      hw_params, hw_free ops

    Reported-by: Matthieu CASTET <matthieu.castet@parrot.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ec1f5bf6b3a9f42284371d41a7c998c05c49abcb
Author: Jean Delvare <khali@linux-fr.org>
Date:   Mon Nov 5 21:54:39 2012 +0100

    hwmon: (w83627ehf) Force initial bank selection

    commit 3300fb4f88688029fff8dfb9ec0734f6e4cba3e7 upstream.

    Don't assume bank 0 is selected at device probe time. This may not be
    the case. Force bank selection at first register access to guarantee
    that we read the right registers upon driver loading.

    Signed-off-by: Jean Delvare <khali@linux-fr.org>
    Reviewed-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 356c93d57c40513a321380f274560504a0778c6b
Author: Ilija Hadzic <ilijahadzic@gmail.com>
Date:   Mon Oct 29 17:35:00 2012 +0000

    drm: restore open_count if drm_setup fails

    commit 0f1cb1bd94a9c967cd4ad3de51cfdabe61eb5dcc upstream.

    If drm_setup (called at first open) fails, the whole
    open call has failed, so we should not keep the
    open_count incremented.

    Signed-off-by: Ilija Hadzic <ihadzic@research.bell-labs.com>
    Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-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
    (relative) rather that a timeout (absolute).  This confused me when
    I wrote
      commit c5b29f885afe890f953f7f23424045cdad31d3e4
         "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 Quartulli <ordex@autistici.org>
Date:   Fri Oct 26 18:54:25 2012 +0200

    mac80211: 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>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f100fdf3a97be683cf57802a566cfe0cce89fc7a
Author: Roland Dreier <roland@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>