Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Commits on Nov 17, 2012
  1. @gregkh

    Linux 3.0.52

    gregkh authored
  2. @tiwai @gregkh

    ALSA: usb-audio: Fix mutex deadlock at disconnection

    tiwai authored gregkh committed
    commit 10e4423 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>
  3. @tiwai @gregkh

    ALSA: Fix card refcount unbalance

    tiwai authored gregkh committed
    commit 8bb4d9c upstream.
    
    There are uncovered cases whether the card refcount introduced by the
    commit a0830db 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>
  4. @rolandd @gregkh

    intel-iommu: Fix AB-BA lockdep report

    rolandd authored gregkh committed
    commit 3e7abe2 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>
  5. @gregkh

    xfs: fix reading of wrapped log data

    Dave Chinner authored gregkh committed
    commit 6ce377a 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>
  6. @jhovold @gregkh

    USB: mos7840: remove unused variable

    jhovold authored gregkh committed
    Fix warning about unused variable introduced by commit e681b66
    ("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>
  7. @danvet @gregkh

    drm/i915: clear the entire sdvo infoframe buffer

    danvet authored gregkh committed
    commit b6e0e54 upstream.
    
    Like in the case of native hdmi, which is fixed already in
    
    commit adf00b2
    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>
  8. @danvet @gregkh

    drm/i915: fixup infoframe support for sdvo

    danvet authored gregkh committed
    commit 81014b9 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
    
    3c17fe4 is the first bad commit
    commit 3c17fe4
    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>
  9. @gregkh

    drm/vmwgfx: Fix hibernation device reset

    Thomas Hellstrom authored gregkh committed
    commit 95e8f6a 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>
  10. @gregkh

    futex: Handle futex_pi OWNER_DIED take over correctly

    Thomas Gleixner authored gregkh committed
    commit 59fa624 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>
  11. @hannes @gregkh

    ipv6: send unsolicited neighbour advertisements to all-nodes

    hannes authored gregkh committed
    [ Upstream commit 60713a0 ]
    
    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>
  12. @gregkh

    l2tp: fix oops in l2tp_eth_create() error path

    Tom Parkin authored gregkh committed
    [ Upstream commit 7893363 ]
    
    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>
  13. @netoptimizer @gregkh

    net: fix divide by zero in tcp algorithm illinois

    netoptimizer authored gregkh committed
    [ Upstream commit 8f363b7 ]
    
    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>
  14. @gregkh

    net: usb: Fix memory leak on Tx data path

    Hemant Kumar authored gregkh committed
    [ Upstream commit 39707c2 ]
    
    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>
  15. @gregkh

    ipv6: Set default hoplimit as zero.

    Li RongQing authored gregkh committed
    [ Upstream commit 14edd87 ]
    
    Commit a02e4b7(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 a37e6e3(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>
  16. @gregkh

    tcp: fix FIONREAD/SIOCINQ

    Eric Dumazet authored gregkh committed
    [ Upstream commit a3374c4 ]
    
    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>
  17. @gregkh

    netlink: use kfree_rcu() in netlink_release()

    Eric Dumazet authored gregkh committed
    [ Upstream commit 6d772ac ]
    
    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>
  18. @gregkh

    sctp: fix call to SCTP_CMD_PROCESS_SACK in sctp_cmd_interpreter()

    Zijie Pan authored gregkh committed
    [ Upstream commit f6e80ab ]
    
    Bug introduced by commit edfee03
    (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>
  19. @tiwai @gregkh

    ALSA: Avoid endless sleep after disconnect

    tiwai authored gregkh committed
    commit 0914f79 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>
  20. @tiwai @gregkh

    ALSA: Add a reference counter to card instance

    tiwai authored gregkh committed
    commit a0830db 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>
  21. @tiwai @gregkh

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

    tiwai authored gregkh committed
    commit 888ea7d 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>
  22. @tiwai @gregkh

    ALSA: usb-audio: Use rwsem for disconnect protection

    tiwai authored gregkh committed
    commit 34f3c89 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>
  23. @tiwai @gregkh

    ALSA: usb-audio: Fix races at disconnection

    tiwai authored gregkh committed
    commit 978520b 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>
  24. @tiwai @gregkh

    ALSA: PCM: Fix some races at disconnection

    tiwai authored gregkh committed
    commit 9b0573c 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>
  25. @gregkh

    hwmon: (w83627ehf) Force initial bank selection

    Jean Delvare authored gregkh committed
    commit 3300fb4 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>
  26. @ihadzic @gregkh

    drm: restore open_count if drm_setup fails

    ihadzic authored gregkh committed
    commit 0f1cb1b 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>
  27. @gregkh

    NFS: Fix Oopses in nfs_lookup_revalidate and nfs4_lookup_revalidate

    Trond Myklebust authored gregkh committed
    [Fixed upstream as part of 0b728e1, 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 0b728e1 (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>
  28. @neilbrown @gregkh

    NFS: fix bug in legacy DNS resolver.

    neilbrown authored gregkh committed
    commit 8d96b10 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 c5b29f8
         "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>
  29. @gregkh

    nfsd: add get_uint for u32's

    J. Bruce Fields authored gregkh committed
    commit a007c4c 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>
  30. @gregkh

    NFSv4: nfs4_locku_done must release the sequence id

    Trond Myklebust authored gregkh committed
    commit 2b1bc30 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>
  31. @gregkh

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

    Ben Hutchings authored gregkh committed
    commit 97a5486 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>
  32. @scottmayhew @gregkh

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

    scottmayhew authored gregkh committed
    …outs
    
    commit acce94e 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>
  33. @gregkh

    mac80211: fix SSID copy on IBSS JOIN

    Antonio Quartulli authored gregkh committed
    commit badecb0 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>
  34. @jmberg @gregkh

    mac80211: check management frame header length

    jmberg authored gregkh committed
    commit 4a4f1a5 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>
  35. @e4t @gregkh

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

    e4t authored gregkh committed
    commit 83325d0 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>
Something went wrong with that request. Please try again.