Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
Commits on Nov 17, 2012
  1. @gregkh

    Linux 3.4.19

    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. @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>
  5. @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>
  6. @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>
  7. @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>
  8. @gregkh

    drm/radeon/si: add some missing regs to the VM reg checker

    Alex Deucher authored gregkh committed
    commit f418b88 upstream.
    
    This register is needed for streamout to work properly.
    
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  9. @gregkh

    drm/radeon/cayman: add some missing regs to the VM reg checker

    Alex Deucher authored gregkh committed
    commit 860fe2f upstream.
    
    These regs were being wronly rejected leading to rendering
    issues.
    
    fixes:
    https://bugs.freedesktop.org/show_bug.cgi?id=56876
    
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  10. @gregkh

    drm/vmwgfx: Fix a case where the code would BUG when trying to pin GM…

    Thomas Hellstrom authored gregkh committed
    …R memory
    
    commit afcc87a upstream.
    
    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>
  11. @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>
  12. @cjb @gregkh

    mmc: sdhci: fix NULL dereference in sdhci_request() tuning

    cjb authored gregkh committed
    commit 14efd95 upstream.
    
    Commit 473b095 ("mmc: sdhci: fix incorrect command used in tuning")
    introduced a NULL dereference at resume-time if an SD 3.0 host controller
    raises the SDHCI_NEEDS_TUNING flag while no card is inserted.  Seen on an
    OLPC XO-4 with sdhci-pxav3, but presumably affects other controllers too.
    
    Signed-off-by: Chris Ball <cjb@laptop.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  13. @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>
  14. @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>
  15. @regit @gregkh

    af-packet: fix oops when socket is not present

    regit authored gregkh committed
    [ Upstream commit a3d744e ]
    
    Due to a NULL dereference, the following patch is causing oops
    in normal trafic condition:
    
    commit c0de08d
    Author: Eric Leblond <eric@regit.org>
    Date:   Thu Aug 16 22:02:58 2012 +0000
    
        af_packet: don't emit packet on orig fanout group
    
    This buggy patch was a feature fix and has reached most stable
    branches.
    
    When skb->sk is NULL and when packet fanout is used, there is a
    crash in match_fanout_group where skb->sk is accessed.
    This patch fixes the issue by returning false as soon as the
    socket is NULL: this correspond to the wanted behavior because
    the kernel as to resend the skb to all the listening socket in
    this case.
    
    Signed-off-by: Eric Leblond <eric@regit.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  16. @cyrillos @gregkh

    net: inet_diag -- Return error code if protocol handler is missed

    cyrillos authored gregkh committed
    [ Upstream commit cacb6ba ]
    
    We've observed that in case if UDP diag module is not
    supported in kernel the netlink returns NLMSG_DONE without
    notifying a caller that handler is missed.
    
    This patch makes __inet_diag_dump to return error code instead.
    
    So as example it become possible to detect such situation
    and handle it gracefully on userspace level.
    
    Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
    CC: David Miller <davem@davemloft.net>
    CC: Eric Dumazet <eric.dumazet@gmail.com>
    CC: Pavel Emelyanov <xemul@parallels.com>
    Acked-by: Pavel Emelyanov <xemul@parallels.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  17. @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>
  18. @petersenna @gregkh

    drivers/net/ethernet/nxp/lpc_eth.c: Call mdiobus_unregister before md…

    petersenna authored gregkh committed
    …iobus_free
    
    [ Upstream commit 57c10b6 ]
    
    Based on commit b27393a
    
    Calling mdiobus_free without calling mdiobus_unregister causes
    BUG_ON(). This patch fixes the issue.
    
    The semantic patch that found this issue(http://coccinelle.lip6.fr/):
    // <smpl>
    @@
    expression E;
    @@
      ... when != mdiobus_unregister(E);
    
    + mdiobus_unregister(E);
      mdiobus_free(E);
    // </smpl>
    
    Signed-off-by: Peter Senna Tschudin <peter.senna@gmail.com>
    Tested-by: Roland Stigge <stigge@antcom.de>
    Tested-by: Alexandre Pereira da Silva <aletes.xgr@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  19. @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>
  20. @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>
  21. @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>
  22. @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>
  23. @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>
  24. @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>
  25. @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>
  26. @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>
  27. @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>
  28. @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>
  29. @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>
  30. @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>
  31. @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>
  32. @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>
  33. @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>
  34. @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>
  35. @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>
Something went wrong with that request. Please try again.