Linux 3.0.76

commit 27a2f7c50c87691fa4b6a0a8a77f779b8bbe648c
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Wed May 1 08:57:55 2013 -0700

    Linux 3.0.76

commit 7a0db699f49f9045484cf256316689cd6668f949
Author: Sam Ravnborg <sam@ravnborg.org>
Date:   Tue Dec 27 21:46:53 2011 +0100

    sparc32: support atomic64_t

    commit aea1181b0bd0a09c54546399768f359d1e198e45 upstream, Needed to
    compile ext4 for sparc32 since commit
    503f4bdcc078e7abee273a85ce322de81b18a224

    There is no-one that really require atomic64_t support on sparc32.
    But several drivers fails to build without proper atomic64 support.
    And for an allyesconfig build for sparc32 this is annoying.

    Include the generic atomic64_t support for sparc32.
    This has a text footprint cost:

    $size vmlinux (before atomic64_t support)
       text    data     bss     dec     hex filename
    3578860  134260  108781 3821901  3a514d vmlinux

    $size vmlinux (after atomic64_t support)
       text    data     bss     dec     hex filename
    3579892  130684  108781 3819357  3a475d vmlinux

    text increase (3579892 - 3578860) = 1032 bytes

    data decreases - but I fail to explain why!
    I have rebuild twice to check my numbers.

    Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Andreas Larsson <andreas@gaisler.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8a53479a31bed3ef13f55c6752cb1a3962affcff
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Apr 16 12:55:41 2013 +0000

    net: drop dst before queueing fragments

    [ Upstream commit 97599dc792b45b1669c3cdb9a4b365aad0232f65 ]

    Commit 4a94445c9a5c (net: Use ip_route_input_noref() in input path)
    added a bug in IP defragmentation handling, as non refcounted
    dst could escape an RCU protected section.

    Commit 64f3b9e203bd068 (net: ip_expire() must revalidate route) fixed
    the case of timeouts, but not the general problem.

    Tom Parkin noticed crashes in UDP stack and provided a patch,
    but further analysis permitted us to pinpoint the root cause.

    Before queueing a packet into a frag list, we must drop its dst,
    as this dst has limited lifetime (RCU protected)

    When/if a packet is finally reassembled, we use the dst of the very
    last skb, still protected by RCU and valid, as the dst of the
    reassembled packet.

    Use same logic in IPv6, as there is no need to hold dst references.

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

commit aad877b259293436b2bdfb1005c9bb29bb17cce5
Author: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Date:   Tue Apr 9 10:07:19 2013 +0800

    netrom: fix invalid use of sizeof in nr_recvmsg()

    [ Upstream commit c802d759623acbd6e1ee9fbdabae89159a513913 ]

    sizeof() when applied to a pointer typed expression gives the size of the
    pointer, not that of the pointed data.
    Introduced by commit 3ce5ef(netrom: fix info leak via msg_name in nr_recvmsg)

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

commit dc85f620e827440f520551b2ff6222bc92b00fa9
Author: Mathias Krause <minipli@googlemail.com>
Date:   Sun Apr 7 01:52:00 2013 +0000

    tipc: fix info leaks via msg_name in recv_msg/recv_stream

    [ Upstream commit 60085c3d009b0df252547adb336d1ccca5ce52ec ]

    The code in set_orig_addr() does not initialize all of the members of
    struct sockaddr_tipc when filling the sockaddr info -- namely the union
    is only partly filled. This will make recv_msg() and recv_stream() --
    the only users of this function -- leak kernel stack memory as the
    msg_name member is a local variable in net/socket.c.

    Additionally to that both recv_msg() and recv_stream() fail to update
    the msg_namelen member to 0 while otherwise returning with 0, i.e.
    "success". This is the case for, e.g., non-blocking sockets. This will
    lead to a 128 byte kernel stack leak in net/socket.c.

    Fix the first issue by initializing the memory of the union with
    memset(0). Fix the second one by setting msg_namelen to 0 early as it
    will be updated later if we're going to fill the msg_name member.

    Signed-off-by: Mathias Krause <minipli@googlemail.com>
    Cc: Jon Maloy <jon.maloy@ericsson.com>
    Cc: Allan Stephens <allan.stephens@windriver.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8576a59ab9134440a889b6728c49aeea105bacdf
Author: Mathias Krause <minipli@googlemail.com>
Date:   Sun Apr 7 01:51:59 2013 +0000

    rose: fix info leak via msg_name in rose_recvmsg()

    [ Upstream commit 4a184233f21645cf0b719366210ed445d1024d72 ]

    The code in rose_recvmsg() does not initialize all of the members of
    struct sockaddr_rose/full_sockaddr_rose when filling the sockaddr info.
    Nor does it initialize the padding bytes of the structure inserted by
    the compiler for alignment. This will lead to leaking uninitialized
    kernel stack bytes in net/socket.c.

    Fix the issue by initializing the memory used for sockaddr info with
    memset(0).

    Signed-off-by: Mathias Krause <minipli@googlemail.com>
    Cc: Ralf Baechle <ralf@linux-mips.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6ccd06ead508da8351bae3aab57a2efba954cb2d
Author: Mathias Krause <minipli@googlemail.com>
Date:   Sun Apr 7 01:51:57 2013 +0000

    netrom: fix info leak via msg_name in nr_recvmsg()

    [ Upstream commits 3ce5efad47b62c57a4f5c54248347085a750ce0e and
      c802d759623acbd6e1ee9fbdabae89159a513913 ]

    In case msg_name is set the sockaddr info gets filled out, as
    requested, but the code fails to initialize the padding bytes of
    struct sockaddr_ax25 inserted by the compiler for alignment. Also
    the sax25_ndigis member does not get assigned, leaking four more
    bytes.

    Both issues lead to the fact that the code will leak uninitialized
    kernel stack bytes in net/socket.c.

    Fix both issues by initializing the memory with memset(0).

    Signed-off-by: Mathias Krause <minipli@googlemail.com>
    Cc: Ralf Baechle <ralf@linux-mips.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit af9659917d0547ebb4233635d2dc496d29fd5d7c
Author: Mathias Krause <minipli@googlemail.com>
Date:   Sun Apr 7 01:51:56 2013 +0000

    llc: Fix missing msg_namelen update in llc_ui_recvmsg()

    [ Upstream commit c77a4b9cffb6215a15196ec499490d116dfad181 ]

    For stream sockets the code misses to update the msg_namelen member
    to 0 and therefore makes net/socket.c leak the local, uninitialized
    sockaddr_storage variable to userland -- 128 bytes of kernel stack
    memory. The msg_namelen update is also missing for datagram sockets
    in case the socket is shutting down during receive.

    Fix both issues by setting msg_namelen to 0 early. It will be
    updated later if we're going to fill the msg_name member.

    Signed-off-by: Mathias Krause <minipli@googlemail.com>
    Cc: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cbafa8a778286c4bd59bd0b9c028b416e0e6ac29
Author: Mathias Krause <minipli@googlemail.com>
Date:   Sun Apr 7 01:51:54 2013 +0000

    iucv: Fix missing msg_namelen update in iucv_sock_recvmsg()

    [ Upstream commit a5598bd9c087dc0efc250a5221e5d0e6f584ee88 ]

    The current code does not fill the msg_name member in case it is set.
    It also does not set the msg_namelen member to 0 and therefore makes
    net/socket.c leak the local, uninitialized sockaddr_storage variable
    to userland -- 128 bytes of kernel stack memory.

    Fix that by simply setting msg_namelen to 0 as obviously nobody cared
    about iucv_sock_recvmsg() not filling the msg_name in case it was set.

    Signed-off-by: Mathias Krause <minipli@googlemail.com>
    Cc: Ursula Braun <ursula.braun@de.ibm.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 65f4ea22548ffdd868d9d98cf91f50bc9978fb69
Author: Mathias Krause <minipli@googlemail.com>
Date:   Sun Apr 7 01:51:53 2013 +0000

    irda: Fix missing msg_namelen update in irda_recvmsg_dgram()

    [ Upstream commit 5ae94c0d2f0bed41d6718be743985d61b7f5c47d ]

    The current code does not fill the msg_name member in case it is set.
    It also does not set the msg_namelen member to 0 and therefore makes
    net/socket.c leak the local, uninitialized sockaddr_storage variable
    to userland -- 128 bytes of kernel stack memory.

    Fix that by simply setting msg_namelen to 0 as obviously nobody cared
    about irda_recvmsg_dgram() not filling the msg_name in case it was
    set.

    Signed-off-by: Mathias Krause <minipli@googlemail.com>
    Cc: Samuel Ortiz <samuel@sortiz.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3aa981cd3ed0ebaecde34fda510602f43180b37e
Author: Mathias Krause <minipli@googlemail.com>
Date:   Sun Apr 7 01:51:52 2013 +0000

    caif: Fix missing msg_namelen update in caif_seqpkt_recvmsg()

    [ Upstream commit 2d6fbfe733f35c6b355c216644e08e149c61b271 ]

    The current code does not fill the msg_name member in case it is set.
    It also does not set the msg_namelen member to 0 and therefore makes
    net/socket.c leak the local, uninitialized sockaddr_storage variable
    to userland -- 128 bytes of kernel stack memory.

    Fix that by simply setting msg_namelen to 0 as obviously nobody cared
    about caif_seqpkt_recvmsg() not filling the msg_name in case it was
    set.

    Signed-off-by: Mathias Krause <minipli@googlemail.com>
    Cc: Sjur Braendeland <sjur.brandeland@stericsson.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ebffd4ef7c48ec51176e5214d344eddf7283fa35
Author: Mathias Krause <minipli@googlemail.com>
Date:   Sun Apr 7 01:51:50 2013 +0000

    Bluetooth: RFCOMM - Fix missing msg_namelen update in rfcomm_sock_recvmsg()

    [ Upstream commit e11e0455c0d7d3d62276a0c55d9dfbc16779d691 ]

    If RFCOMM_DEFER_SETUP is set in the flags, rfcomm_sock_recvmsg() returns
    early with 0 without updating the possibly set msg_namelen member. This,
    in turn, leads to a 128 byte kernel stack leak in net/socket.c.

    Fix this by updating msg_namelen in this case. For all other cases it
    will be handled in bt_sock_stream_recvmsg().

    Signed-off-by: Mathias Krause <minipli@googlemail.com>
    Cc: Marcel Holtmann <marcel@holtmann.org>
    Cc: Gustavo Padovan <gustavo@padovan.org>
    Cc: Johan Hedberg <johan.hedberg@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0a740ea0de6c84544fe8e68d235da75341f30edd
Author: Mathias Krause <minipli@googlemail.com>
Date:   Sun Apr 7 01:51:49 2013 +0000

    Bluetooth: fix possible info leak in bt_sock_recvmsg()

    [ Upstream commit 4683f42fde3977bdb4e8a09622788cc8b5313778 ]

    In case the socket is already shutting down, bt_sock_recvmsg() returns
    with 0 without updating msg_namelen leading to net/socket.c leaking the
    local, uninitialized sockaddr_storage variable to userland -- 128 bytes
    of kernel stack memory.

    Fix this by moving the msg_namelen assignment in front of the shutdown
    test.

    Signed-off-by: Mathias Krause <minipli@googlemail.com>
    Cc: Marcel Holtmann <marcel@holtmann.org>
    Cc: Gustavo Padovan <gustavo@padovan.org>
    Cc: Johan Hedberg <johan.hedberg@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9a627f671963d81b5fdf910ddcba905328215b1f
Author: Mathias Krause <minipli@googlemail.com>
Date:   Sun Apr 7 01:51:48 2013 +0000

    ax25: fix info leak via msg_name in ax25_recvmsg()

    [ Upstream commit ef3313e84acbf349caecae942ab3ab731471f1a1 ]

    When msg_namelen is non-zero the sockaddr info gets filled out, as
    requested, but the code fails to initialize the padding bytes of struct
    sockaddr_ax25 inserted by the compiler for alignment. Additionally the
    msg_namelen value is updated to sizeof(struct full_sockaddr_ax25) but is
    not always filled up to this size.

    Both issues lead to the fact that the code will leak uninitialized
    kernel stack bytes in net/socket.c.

    Fix both issues by initializing the memory with memset(0).

    Signed-off-by: Mathias Krause <minipli@googlemail.com>
    Cc: Ralf Baechle <ralf@linux-mips.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8d5746899e9a140317c229401bfcf844a11a0247
Author: Mathias Krause <minipli@googlemail.com>
Date:   Sun Apr 7 01:51:47 2013 +0000

    atm: update msg_namelen in vcc_recvmsg()

    [ Upstream commit 9b3e617f3df53822345a8573b6d358f6b9e5ed87 ]

    The current code does not fill the msg_name member in case it is set.
    It also does not set the msg_namelen member to 0 and therefore makes
    net/socket.c leak the local, uninitialized sockaddr_storage variable
    to userland -- 128 bytes of kernel stack memory.

    Fix that by simply setting msg_namelen to 0 as obviously nobody cared
    about vcc_recvmsg() not filling the msg_name in case it was set.

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

commit 73d2de1ad017f674ec21e57405e47028dbc884bf
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Fri Apr 19 15:32:32 2013 +0000

    net: fix incorrect credentials passing

    [ Upstream commit 83f1b4ba917db5dc5a061a44b3403ddb6e783494 ]

    Commit 257b5358b32f ("scm: Capture the full credentials of the scm
    sender") changed the credentials passing code to pass in the effective
    uid/gid instead of the real uid/gid.

    Obviously this doesn't matter most of the time (since normally they are
    the same), but it results in differences for suid binaries when the wrong
    uid/gid ends up being used.

    This just undoes that (presumably unintentional) part of the commit.

    Reported-by: Andy Lutomirski <luto@amacapital.net>
    Cc: Eric W. Biederman <ebiederm@xmission.com>
    Cc: Serge E. Hallyn <serge@hallyn.com>
    Cc: David S. Miller <davem@davemloft.net>
    Cc: stable@vger.kernel.org
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Acked-by: "Eric W. Biederman" <ebiederm@xmission.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7c79dac82743cab718a07520617810eb5fb8eb56
Author: Eric Dumazet <edumazet@google.com>
Date:   Fri Apr 19 07:19:48 2013 +0000

    tcp: call tcp_replace_ts_recent() from tcp_ack()

    [ Upstream commit 12fb3dd9dc3c64ba7d64cec977cca9b5fb7b1d4e ]

    commit bd090dfc634d (tcp: tcp_replace_ts_recent() should not be called
    from tcp_validate_incoming()) introduced a TS ecr bug in slow path
    processing.

    1 A > B P. 1:10001(10000) ack 1 <nop,nop,TS val 1001 ecr 200>
    2 B < A . 1:1(0) ack 1 win 257 <sack 9001:10001,TS val 300 ecr 1001>
    3 A > B . 1:1001(1000) ack 1 win 227 <nop,nop,TS val 1002 ecr 200>
    4 A > B . 1001:2001(1000) ack 1 win 227 <nop,nop,TS val 1002 ecr 200>

    (ecr 200 should be ecr 300 in packets 3 & 4)

    Problem is tcp_ack() can trigger send of new packets (retransmits),
    reflecting the prior TSval, instead of the TSval contained in the
    currently processed incoming packet.

    Fix this by calling tcp_replace_ts_recent() from tcp_ack() after the
    checks, but before the actions.

    Reported-by: Yuchung Cheng <ycheng@google.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Neal Cardwell <ncardwell@google.com>
    Acked-by: Neal Cardwell <ncardwell@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eaaeae50ea0230be49e4aca5ec48f6978537a242
Author: Daniel Borkmann <dborkman@redhat.com>
Date:   Thu Feb 7 00:55:37 2013 +0000

    net: sctp: sctp_auth_key_put: use kzfree instead of kfree

    [ Upstream commit 586c31f3bf04c290dc0a0de7fc91d20aa9a5ee53 ]

    For sensitive data like keying material, it is common practice to zero
    out keys before returning the memory back to the allocator. Thus, use
    kzfree instead of kfree.

    Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
    Acked-by: Neil Horman <nhorman@tuxdriver.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 fe18256f3e2410e574cc48dbf033a706d000b0ff
Author: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Date:   Sat Apr 13 15:49:03 2013 +0000

    esp4: fix error return code in esp_output()

    [ Upstream commit 06848c10f720cbc20e3b784c0df24930b7304b93 ]

    Fix to return a negative error code from the error handling
    case instead of 0, as returned elsewhere in this function.

    Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
    Acked-by: Steffen Klassert <steffen.klassert@secunet.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7b14772957275672b360e5ebd5604623561e0f30
Author: Dmitry Popov <dp@highloadlab.com>
Date:   Thu Apr 11 08:55:07 2013 +0000

    tcp: incoming connections might use wrong route under synflood

    [ Upstream commit d66954a066158781ccf9c13c91d0316970fe57b6 ]

    There is a bug in cookie_v4_check (net/ipv4/syncookies.c):
    	flowi4_init_output(&fl4, 0, sk->sk_mark, RT_CONN_FLAGS(sk),
    			   RT_SCOPE_UNIVERSE, IPPROTO_TCP,
    			   inet_sk_flowi_flags(sk),
    			   (opt && opt->srr) ? opt->faddr : ireq->rmt_addr,
    			   ireq->loc_addr, th->source, th->dest);

    Here we do not respect sk->sk_bound_dev_if, therefore wrong dst_entry may be
    taken. This dst_entry is used by new socket (get_cookie_sock ->
    tcp_v4_syn_recv_sock), so its packets may take the wrong path.

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

commit f5045d1c27676a8714142cd082e6b0e0e3e10138
Author: Michael Riesch <michael.riesch@omicron.at>
Date:   Mon Apr 8 05:45:26 2013 +0000

    rtnetlink: Call nlmsg_parse() with correct header length

    [ Upstream commit 88c5b5ce5cb57af6ca2a7cf4d5715fa320448ff9 ]

    Signed-off-by: Michael Riesch <michael.riesch@omicron.at>
    Cc: "David S. Miller" <davem@davemloft.net>
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Cc: Jiri Benc <jbenc@redhat.com>
    Cc: "Theodore Ts'o" <tytso@mit.edu>
    Cc: linux-kernel@vger.kernel.org
    Acked-by: Mark Rustad <mark.d.rustad@intel.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a57d91ae48c1bca556dcde0d0a6273f7d8fabe1e
Author: Patrick McHardy <kaber@trash.net>
Date:   Fri Apr 5 20:42:05 2013 +0200

    netfilter: don't reset nf_trace in nf_reset()

    [ Upstream commit 124dff01afbdbff251f0385beca84ba1b9adda68 ]

    Commit 130549fe ("netfilter: reset nf_trace in nf_reset") added code
    to reset nf_trace in nf_reset(). This is wrong and unnecessary.

    nf_reset() is used in the following cases:

    - when passing packets up the the socket layer, at which point we want to
      release all netfilter references that might keep modules pinned while
      the packet is queued. nf_trace doesn't matter anymore at this point.

    - when encapsulating or decapsulating IPsec packets. We want to continue
      tracing these packets after IPsec processing.

    - when passing packets through virtual network devices. Only devices on
      that encapsulate in IPv4/v6 matter since otherwise nf_trace is not
      used anymore. Its not entirely clear whether those packets should
      be traced after that, however we've always done that.

    - when passing packets through virtual network devices that make the
      packet cross network namespace boundaries. This is the only cases
      where we clearly want to reset nf_trace and is also what the
      original patch intended to fix.

    Add a new function nf_reset_trace() and use it in dev_forward_skb() to
    fix this properly.

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

commit d0625c06de1e0a10d00e207ad97ebcb9e337534d
Author: Eric W. Biederman <ebiederm@xmission.com>
Date:   Wed Apr 3 16:14:47 2013 +0000

    af_unix: If we don't care about credentials coallesce all messages

    [ Upstream commit 0e82e7f6dfeec1013339612f74abc2cdd29d43d2 ]

    It was reported that the following LSB test case failed
    https://lsbbugs.linuxfoundation.org/attachment.cgi?id=2144 because we
    were not coallescing unix stream messages when the application was
    expecting us to.

    The problem was that the first send was before the socket was accepted
    and thus sock->sk_socket was NULL in maybe_add_creds, and the second
    send after the socket was accepted had a non-NULL value for sk->socket
    and thus we could tell the credentials were not needed so we did not
    bother.

    The unnecessary credentials on the first message cause
    unix_stream_recvmsg to start verifying that all messages had the same
    credentials before coallescing and then the coallescing failed because
    the second message had no credentials.

    Ignoring credentials when we don't care in unix_stream_recvmsg fixes a
    long standing pessimization which would fail to coallesce messages when
    reading from a unix stream socket if the senders were different even if
    we did not care about their credentials.

    I have tested this and verified that the in the LSB test case mentioned
    above that the messages do coallesce now, while the were failing to
    coallesce without this change.

    Reported-by: Karel Srot <ksrot@redhat.com>
    Reported-by: Ding Tianhong <dingtianhong@huawei.com>
    Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3c53e8d24e96e85acf028dc4ccb1e60a5486f47d
Author: nikolay@redhat.com <nikolay@redhat.com>
Date:   Thu Apr 11 09:18:56 2013 +0000

    bonding: IFF_BONDING is not stripped on enslave failure

    [ Upstream commit b6a5a7b9a528a8b4c8bec940b607c5dd9102b8cc ]

    While enslaving a new device and after IFF_BONDING flag is set, in case
    of failure it is not stripped from the device's priv_flags while
    cleaning up, which could lead to other problems.
    Cleaning at err_close because the flag is set after dev_open().

    v2: no change

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

commit abd70dfd7e1df706a70fb9fa7d7777cf4428fe2c
Author: Hannes Frederic Sowa <hannes@stressinduktion.org>
Date:   Tue Apr 2 14:36:46 2013 +0000

    atl1e: limit gso segment size to prevent generation of wrong ip length fields

    [ Upstream commit 31d1670e73f4911fe401273a8f576edc9c2b5fea ]

    The limit of 0x3c00 is taken from the windows driver.

    Suggested-by: Huang, Xiong <xiong@qca.qualcomm.com>
    Cc: Huang, Xiong <xiong@qca.qualcomm.com>
    Cc: Eric Dumazet <eric.dumazet@gmail.com>
    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 d569e833b770b21d29147c1ed937ab3882647252
Author: Vlad Yasevich <vyasevic@redhat.com>
Date:   Tue Apr 2 17:10:07 2013 -0400

    net: count hw_addr syncs so that unsync works properly.

    [ Upstream commit 4543fbefe6e06a9e40d9f2b28d688393a299f079 ]

    A few drivers use dev_uc_sync/unsync to synchronize the
    address lists from master down to slave/lower devices.  In
    some cases (bond/team) a single address list is synched down
    to multiple devices.  At the time of unsync, we have a leak
    in these lower devices, because "synced" is treated as a
    boolean and the address will not be unsynced for anything after
    the first device/call.

    Treat "synced" as a count (same as refcount) and allow all
    unsync calls to work.

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

commit 6ac784dcc8f749f83bc551684044f15a544fc5fd
Author: Balakumaran Kannan <kumaran.4353@gmail.com>
Date:   Tue Apr 2 16:15:05 2013 +0530

    net IPv6 : Fix broken IPv6 routing table after loopback down-up

    [ Upstream commit 25fb6ca4ed9cad72f14f61629b68dc03c0d9713f ]

    IPv6 Routing table becomes broken once we do ifdown, ifup of the loopback(lo)
    interface. After down-up, routes of other interface's IPv6 addresses through
    'lo' are lost.

    IPv6 addresses assigned to all interfaces are routed through 'lo' for internal
    communication. Once 'lo' is down, those routing entries are removed from routing
    table. But those removed entries are not being re-created properly when 'lo' is
    brought up. So IPv6 addresses of other interfaces becomes unreachable from the
    same machine. Also this breaks communication with other machines because of
    NDISC packet processing failure.

    This patch fixes this issue by reading all interface's IPv6 addresses and adding
    them to IPv6 routing table while bringing up 'lo'.

    ==Testing==
    Before applying the patch:
    $ route -A inet6
    Kernel IPv6 routing table
    Destination                    Next Hop                   Flag Met Ref Use If
    2000::20/128                   ::                         U    256 0     0 eth0
    fe80::/64                      ::                         U    256 0     0 eth0
    ::/0                           ::                         !n   -1  1     1 lo
    ::1/128                        ::                         Un   0   1     0 lo
    2000::20/128                   ::                         Un   0   1     0 lo
    fe80::xxxx:xxxx:xxxx:xxxx/128  ::                         Un   0   1     0 lo
    ff00::/8                       ::                         U    256 0     0 eth0
    ::/0                           ::                         !n   -1  1     1 lo
    $ sudo ifdown lo
    $ sudo ifup lo
    $ route -A inet6
    Kernel IPv6 routing table
    Destination                    Next Hop                   Flag Met Ref Use If
    2000::20/128                   ::                         U    256 0     0 eth0
    fe80::/64                      ::                         U    256 0     0 eth0
    ::/0                           ::                         !n   -1  1     1 lo
    ::1/128                        ::                         Un   0   1     0 lo
    ff00::/8                       ::                         U    256 0     0 eth0
    ::/0                           ::                         !n   -1  1     1 lo
    $

    After applying the patch:
    $ route -A inet6
    Kernel IPv6 routing
    table
    Destination                    Next Hop                   Flag Met Ref Use If
    2000::20/128                   ::                         U    256 0     0 eth0
    fe80::/64                      ::                         U    256 0     0 eth0
    ::/0                           ::                         !n   -1  1     1 lo
    ::1/128                        ::                         Un   0   1     0 lo
    2000::20/128                   ::                         Un   0   1     0 lo
    fe80::xxxx:xxxx:xxxx:xxxx/128  ::                         Un   0   1     0 lo
    ff00::/8                       ::                         U    256 0     0 eth0
    ::/0                           ::                         !n   -1  1     1 lo
    $ sudo ifdown lo
    $ sudo ifup lo
    $ route -A inet6
    Kernel IPv6 routing table
    Destination                    Next Hop                   Flag Met Ref Use If
    2000::20/128                   ::                         U    256 0     0 eth0
    fe80::/64                      ::                         U    256 0     0 eth0
    ::/0                           ::                         !n   -1  1     1 lo
    ::1/128                        ::                         Un   0   1     0 lo
    2000::20/128                   ::                         Un   0   1     0 lo
    fe80::xxxx:xxxx:xxxx:xxxx/128  ::                         Un   0   1     0 lo
    ff00::/8                       ::                         U    256 0     0 eth0
    ::/0                           ::                         !n   -1  1     1 lo
    $

    Signed-off-by: Balakumaran Kannan <Balakumaran.Kannan@ap.sony.com>
    Signed-off-by: Maruthi Thotad <Maruthi.Thotad@ap.sony.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f7b8a0f5795aca696f78042db1b8c4b3d07e04c5
Author: Vasily Averin <vvs@parallels.com>
Date:   Mon Apr 1 03:01:32 2013 +0000

    cbq: incorrect processing of high limits

    [ Upstream commit f0f6ee1f70c4eaab9d52cf7d255df4bd89f8d1c2 ]

    currently cbq works incorrectly for limits > 10% real link bandwidth,
    and practically does not work for limits > 50% real link bandwidth.
    Below are results of experiments taken on 1 Gbit link

     In shaper | Actual Result
    -----------+---------------
      100M     | 108 Mbps
      200M     | 244 Mbps
      300M     | 412 Mbps
      500M     | 893 Mbps

    This happen because of q->now changes incorrectly in cbq_dequeue():
    when it is called before real end of packet transmitting,
    L2T is greater than real time delay, q_now gets an extra boost
    but never compensate it.

    To fix this problem we prevent change of q->now until its synchronization
    with real time.

    Signed-off-by: Vasily Averin <vvs@openvz.org>
    Reviewed-by: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
    Acked-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9758b79c56ae6dc93f660928a0d389ba45e530ed
Author: David S. Miller <davem@davemloft.net>
Date:   Fri Apr 19 17:26:26 2013 -0400

    sparc64: Fix race in TLB batch processing.

    [ Commits f36391d2790d04993f48da6a45810033a2cdf847 and
      f0af97070acbad5d6a361f485828223a4faaa0ee upstream. ]

    As reported by Dave Kleikamp, when we emit cross calls to do batched
    TLB flush processing we have a race because we do not synchronize on
    the sibling cpus completing the cross call.

    So meanwhile the TLB batch can be reset (tb->tlb_nr set to zero, etc.)
    and either flushes are missed or flushes will flush the wrong
    addresses.

    Fix this by using generic infrastructure to synchonize on the
    completion of the cross call.

    This first required getting the flush_tlb_pending() call out from
    switch_to() which operates with locks held and interrupts disabled.
    The problem is that smp_call_function_many() cannot be invoked with
    IRQs disabled and this is explicitly checked for with WARN_ON_ONCE().

    We get the batch processing outside of locked IRQ disabled sections by
    using some ideas from the powerpc port. Namely, we only batch inside
    of arch_{enter,leave}_lazy_mmu_mode() calls.  If we're not in such a
    region, we flush TLBs synchronously.

    1) Get rid of xcall_flush_tlb_pending and per-cpu type
       implementations.

    2) Do TLB batch cross calls instead via:

    	smp_call_function_many()
    		tlb_pending_func()
    			__flush_tlb_pending()

    3) Batch only in lazy mmu sequences:

    	a) Add 'active' member to struct tlb_batch
    	b) Define __HAVE_ARCH_ENTER_LAZY_MMU_MODE
    	c) Set 'active' in arch_enter_lazy_mmu_mode()
    	d) Run batch and clear 'active' in arch_leave_lazy_mmu_mode()
    	e) Check 'active' in tlb_batch_add_one() and do a synchronous
               flush if it's clear.

    4) Add infrastructure for synchronous TLB page flushes.

    	a) Implement __flush_tlb_page and per-cpu variants, patch
    	   as needed.
    	b) Likewise for xcall_flush_tlb_page.
    	c) Implement smp_flush_tlb_page() to invoke the cross-call.
    	d) Wire up global_flush_tlb_page() to the right routine based
               upon CONFIG_SMP

    5) It turns out that singleton batches are very common, 2 out of every
       3 batch flushes have only a single entry in them.

       The batch flush waiting is very expensive, both because of the poll
       on sibling cpu completeion, as well as because passing the tlb batch
       pointer to the sibling cpus invokes a shared memory dereference.

       Therefore, in flush_tlb_pending(), if there is only one entry in
       the batch perform a completely asynchronous global_flush_tlb_page()
       instead.

    Reported-by: Dave Kleikamp <dave.kleikamp@oracle.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Acked-by: Dave Kleikamp <dave.kleikamp@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 061bd83c6fd1c22fbcf0357d4b7e306ba5ea8591
Author: Jiri Slaby <jslaby@suse.cz>
Date:   Fri Apr 26 13:48:53 2013 +0200

    TTY: fix atime/mtime regression

    commit 37b7f3c76595e23257f61bd80b223de8658617ee upstream.

    In commit b0de59b5733d ("TTY: do not update atime/mtime on read/write")
    we removed timestamps from tty inodes to fix a security issue and waited
    if something breaks.  Well, 'w', the utility to find out logged users
    and their inactivity time broke.  It shows that users are inactive since
    the time they logged in.

    To revert to the old behaviour while still preventing attackers to
    guess the password length, we update the timestamps in one-minute
    intervals by this patch.

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

commit 6dd4ef3051173062350a4c53a2c4212d3f052e0c
Author: Jiri Slaby <jslaby@suse.cz>
Date:   Fri Feb 15 15:25:05 2013 +0100

    TTY: do not update atime/mtime on read/write

    commit b0de59b5733d18b0d1974a060860a8b5c1b36a2e upstream.

    On http://vladz.devzero.fr/013_ptmx-timing.php, we can see how to find
    out length of a password using timestamps of /dev/ptmx. It is
    documented in "Timing Analysis of Keystrokes and Timing Attacks on
    SSH". To avoid that problem, do not update time when reading
    from/writing to a TTY.

    I am afraid of regressions as this is a behavior we have since 0.97
    and apps may expect the time to be current, e.g. for monitoring
    whether there was a change on the TTY. Now, there is no change. So
    this would better have a lot of testing before it goes upstream.

    References: CVE-2013-0160

    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Linux 3.0.77

commit bff066a411684d07e23307405f03cf7e7fc4afab
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Tue May 7 20:08:48 2013 -0700

    Linux 3.0.77

commit 97a0b301f6520690724602497c699890144ccff6
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Mon May 6 11:30:43 2013 -0700

    Revert :can: sja1000: fix handling on dt properties on little endian systems"

    This reverts commit 55fe10a686c3a8bce7bddc149e4ebb12f5a18c25 which is
    commit 0443de5fbf224abf41f688d8487b0c307dc5a4b4 upstream.

    This causes a build breakage on 3.0, so we shouldn't apply it to that
    tree.

    Reported-by: Jiri Slaby <jslaby@suse.cz>
    Cc: Christoph Fritz <chf.fritz@googlemail.com>
    Cc: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2232c3d8b3d44591be5e7426b368858da68048ac
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Wed Apr 17 08:46:19 2013 -0700

    s390: move dummy io_remap_pfn_range() to asm/pgtable.h

    commit 4f2e29031e6c67802e7370292dd050fd62f337ee upstream.

    Commit b4cbb197c7e7 ("vm: add vm_iomap_memory() helper function") added
    a helper function wrapper around io_remap_pfn_range(), and every other
    architecture defined it in <asm/pgtable.h>.

    The s390 choice of <asm/io.h> may make sense, but is not very convenient
    for this case, and gratuitous differences like that cause unexpected errors like this:

       mm/memory.c: In function 'vm_iomap_memory':
       mm/memory.c:2439:2: error: implicit declaration of function 'io_remap_pfn_range' [-Werror=implicit-function-declaration]

    Glory be the kbuild test robot who noticed this, bisected it, and
    reported it to the guilty parties (ie me).

    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
    Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
    Cc: Jiri Slaby <jslaby@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eadb89490b7b35a5fbb169dfc59e7a3d07b4c492
Author: Lars-Peter Clausen <lars@metafoo.de>
Date:   Tue Feb 19 11:51:22 2013 +0100

    mfd: adp5520: Restore mode bits on resume

    commit c6cc25fda58da8685ecef3f179adc7b99c8253b2 upstream.

    The adp5520 unfortunately also clears the BL_EN bit when the nSTNDBY bit is
    cleared. So we need to make sure to restore it during resume if it was set
    before suspend.

    Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
    Acked-by: Michael Hennerich <michael.hennerich@analog.com>
    Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 92e5cc743134cec1532b43fa2b97340effd956a8
Author: Philip Rakity <prakity@yahoo.com>
Date:   Thu Apr 4 20:18:11 2013 +0100

    mmc: core: Fix bit width test failing on old eMMC cards

    commit 836dc2fe89c968c10cada87e0dfae6626f8f9da3 upstream.

    PARTITION_SUPPORT needs to be set before doing the compare on version
    number so the bit width test does not get invalid data.  Before this
    patch, a Sandisk iNAND eMMC card would detect 1-bit width although
    the hardware supports 4-bit.

    Only affects old emmc devices - pre 4.4 devices.

    Reported-by: Elad Yi <elad.yi@gmail.com>
    Signed-off-by: Philip Rakity <prakity@yahoo.com>
    Signed-off-by: Chris Ball <cjb@laptop.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e34eca4c2d2f1783c94fad22d72ebb304c3f0728
Author: Li Fei <fei.li@intel.com>
Date:   Fri Apr 26 20:50:11 2013 +0800

    x86: Eliminate irq_mis_count counted in arch_irq_stat

    commit f7b0e1055574ce06ab53391263b4e205bf38daf3 upstream.

    With the current implementation, kstat_cpu(cpu).irqs_sum is also
    increased in case of irq_mis_count increment.

    So there is no need to count irq_mis_count in arch_irq_stat,
    otherwise irq_mis_count will be counted twice in the sum of
    /proc/stat.

    Reported-by: Liu Chuansheng <chuansheng.liu@intel.com>
    Signed-off-by: Li Fei <fei.li@intel.com>
    Acked-by: Liu Chuansheng <chuansheng.liu@intel.com>
    Cc: tomoki.sekiyama.qu@hitachi.com
    Cc: joe@perches.com
    Link: http://lkml.kernel.org/r/1366980611.32469.7.camel@fli24-HP-Compaq-8100-Elite-CMT-PC
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8b715460ae5db65f37aefdd3d1330189e193f789
Author: Theodore Ts'o <tytso@mit.edu>
Date:   Sun Apr 21 20:32:03 2013 -0400

    ext4: fix Kconfig documentation for CONFIG_EXT4_DEBUG

    commit 7f3e3c7cfcec148ccca9c0dd2dbfd7b00b7ac10f upstream.

    Fox the Kconfig documentation for CONFIG_EXT4_DEBUG to match the
    change made by commit a0b30c1229: ext4: use module parameters instead
    of debugfs for mballoc_debug

    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9b2bdb66b65fcbdd4f3a3d08c28e4c46b4a59364
Author: Robin Holt <holt@sgi.com>
Date:   Tue Apr 30 19:15:54 2013 -0700

    ipc: sysv shared memory limited to 8TiB

    commit d69f3bad4675ac519d41ca2b11e1c00ca115cecd upstream.

    Trying to run an application which was trying to put data into half of
    memory using shmget(), we found that having a shmall value below 8EiB-8TiB
    would prevent us from using anything more than 8TiB.  By setting
    kernel.shmall greater than 8EiB-8TiB would make the job work.

    In the newseg() function, ns->shm_tot which, at 8TiB is INT_MAX.

    ipc/shm.c:
     458 static int newseg(struct ipc_namespace *ns, struct ipc_params *params)
     459 {
    ...
     465         int numpages = (size + PAGE_SIZE -1) >> PAGE_SHIFT;
    ...
     474         if (ns->shm_tot + numpages > ns->shm_ctlall)
     475                 return -ENOSPC;

    [akpm@linux-foundation.org: make ipc/shm.c:newseg()'s numpages size_t, not int]
    Signed-off-by: Robin Holt <holt@sgi.com>
    Reported-by: Alex Thorlton <athorlton@sgi.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d2a51f02ccc6fac30f8cdb7e5f2791b2fe43d129
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Tue Apr 16 14:32:26 2013 +0200

    wireless: regulatory: fix channel disabling race condition

    commit 990de49f74e772b6db5208457b7aa712a5f4db86 upstream.

    When a full scan 2.4 and 5 GHz scan is scheduled, but then the 2.4 GHz
    part of the scan disables a 5.2 GHz channel due to, e.g. receiving
    country or frequency information, that 5.2 GHz channel might already
    be in the list of channels to scan next. Then, when the driver checks
    if it should do a passive scan, that will return false and attempt an
    active scan. This is not only wrong but can also lead to the iwlwifi
    device firmware crashing since it checks regulatory as well.

    Fix this by not setting the channel flags to just disabled but rather
    OR'ing in the disabled flag. That way, even if the race happens, the
    channel will be scanned passively which is still (mostly) correct.

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

commit cfb0a900641f0d5c84bc1e68bbf3e312ae37c549
Author: Bryan Schumaker <bjschuma@netapp.com>
Date:   Fri Apr 19 16:09:38 2013 -0400

    nfsd: Decode and send 64bit time values

    commit bf8d909705e9d9bac31d9b8eac6734d2b51332a7 upstream.

    The seconds field of an nfstime4 structure is 64bit, but we are assuming
    that the first 32bits are zero-filled.  So if the client tries to set
    atime to a value before the epoch (touch -t 196001010101), then the
    server will save the wrong value on disk.

    Signed-off-by: Bryan Schumaker <bjschuma@netapp.com>
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bc2da6406bec3dfffde77426330468e40243b1ea
Author: J. Bruce Fields <bfields@redhat.com>
Date:   Thu Mar 28 20:37:14 2013 -0400

    nfsd4: don't close read-write opens too soon

    commit 0c7c3e67ab91ec6caa44bdf1fc89a48012ceb0c5 upstream.

    Don't actually close any opens until we don't need them at all.

    This means being left with write access when it's not really necessary,
    but that's better than putting a file that might still have posix locks
    held on it, as we have been.

    Reported-by: Toralf Förster <toralf.foerster@gmx.de>
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ebcd3f67c004ee5c51a9379d744e5546be73f227
Author: Trond Myklebust <Trond.Myklebust@netapp.com>
Date:   Mon Apr 1 15:34:05 2013 -0400

    NFSv4: Handle NFS4ERR_DELAY and NFS4ERR_GRACE in nfs4_open_delegation_recall

    commit 8b6cc4d6f841d31f72fe7478453759166d366274 upstream.

    A server shouldn't normally return NFS4ERR_GRACE if the client holds a
    delegation, since no conflicting lock reclaims can be granted, however
    the spec does not require the server to grant the open in this
    instance

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

commit 3b5f7654971e0dcb6c422d14cbae7309686bb344
Author: Trond Myklebust <Trond.Myklebust@netapp.com>
Date:   Sun Apr 21 18:01:06 2013 -0400

    LOCKD: Ensure that nlmclnt_block resets block->b_status after a server reboot

    commit 1dfd89af8697a299e7982ae740d4695ecd917eef upstream.

    After a server reboot, the reclaimer thread will recover all the existing
    locks. For locks that are blocked, however, it will change the value
    of block->b_status to nlm_lck_denied_grace_period in order to signal that
    they need to wake up and resend the original blocking lock request.

    Due to a bug, however, the block->b_status never gets reset after the
    blocked locks have been woken up, and so the process goes into an
    infinite loop of resends until the blocked lock is satisfied.

    Reported-by: Marc Eshel <eshel@us.ibm.com>
    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a35089a9cc44f621e58af899b3483d206bb89284
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Thu Apr 25 11:45:53 2013 +0200

    clockevents: Set dummy handler on CPU_DEAD shutdown

    commit 6f7a05d7018de222e40ca003721037a530979974 upstream.

    Vitaliy reported that a per cpu HPET timer interrupt crashes the
    system during hibernation. What happens is that the per cpu HPET timer
    gets shut down when the nonboot cpus are stopped. When the nonboot
    cpus are onlined again the HPET code sets up the MSI interrupt which
    fires before the clock event device is registered. The event handler
    is still set to hrtimer_interrupt, which then crashes the machine due
    to highres mode not being active.

    See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=700333

    There is no real good way to avoid that in the HPET code. The HPET
    code alrady has a mechanism to detect spurious interrupts when event
    handler == NULL for a similar reason.

    We can handle that in the clockevent/tick layer and replace the
    previous functional handler with a dummy handler like we do in
    tick_setup_new_device().

    The original clockevents code did this in clockevents_exchange_device(),
    but that got removed by commit 7c1e76897 (clockevents: prevent
    clockevent event_handler ending up handler_noop) which forgot to fix
    it up in tick_shutdown(). Same issue with the broadcast device.

    Reported-by: Vitaliy Fillipov <vitalif@yourcmc.ru>
    Cc: Ben Hutchings <ben@decadent.org.uk>
    Cc: 700333@bugs.debian.org
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ed0a169166af3fc21e3b8ee9f3020298a93f9bd7
Author: Li Zefan <lizefan@huawei.com>
Date:   Tue Mar 12 15:36:00 2013 -0700

    cgroup: fix an off-by-one bug which may trigger BUG_ON()

    commit 3ac1707a13a3da9cfc8f242a15b2fae6df2c5f88 upstream.

    The 3rd parameter of flex_array_prealloc() is the number of elements,
    not the index of the last element.

    The effect of the bug is, when opening cgroup.procs, a flex array will
    be allocated and all elements of the array is allocated with
    GFP_KERNEL flag, but the last one is GFP_ATOMIC, and if we fail to
    allocate memory for it, it'll trigger a BUG_ON().

    Signed-off-by: Li Zefan <lizefan@huawei.com>
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 10eb78f693be5d924d8ae19264efc8da2d6cb8a3
Author: Derek Basehore <dbasehore@chromium.org>
Date:   Mon Apr 29 16:20:23 2013 -0700

    drivers/rtc/rtc-cmos.c: don't disable hpet emulation on suspend

    commit e005715efaf674660ae59af83b13822567e3a758 upstream.

    There's a bug where rtc alarms are ignored after the rtc cmos suspends
    but before the system finishes suspend.  Since hpet emulation is
    disabled and it still handles the interrupts, a wake event is never
    registered which is done from the rtc layer.

    This patch reverts commit d1b2efa83fbf ("rtc: disable hpet emulation on
    suspend") which disabled hpet emulation.  To fix the problem mentioned
    in that commit, hpet_rtc_timer_init() is called directly on resume.

    Signed-off-by: Derek Basehore <dbasehore@chromium.org>
    Cc: Maxim Levitsky <maximlevitsky@gmail.com>
    Cc: "H. Peter Anvin" <hpa@zytor.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Ingo Molnar <mingo@elte.hu>
    Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a0f25ff9b9e74174def19cdad1f1d2e7f4894683
Author: Prarit Bhargava <prarit@redhat.com>
Date:   Mon Apr 8 08:47:15 2013 -0400

    hrtimer: Add expiry time overflow check in hrtimer_interrupt

    commit 8f294b5a139ee4b75e890ad5b443c93d1e558a8b upstream.

    The settimeofday01 test in the LTP testsuite effectively does

            gettimeofday(current time);
            settimeofday(Jan 1, 1970 + 100 seconds);
            settimeofday(current time);

    This test causes a stack trace to be displayed on the console during the
    setting of timeofday to Jan 1, 1970 + 100 seconds:

    [  131.066751] ------------[ cut here ]------------
    [  131.096448] WARNING: at kernel/time/clockevents.c:209 clockevents_program_event+0x135/0x140()
    [  131.104935] Hardware name: Dinar
    [  131.108150] Modules linked in: sg nfsv3 nfs_acl nfsv4 auth_rpcgss nfs dns_resolver fscache lockd sunrpc nf_conntrack_netbios_ns nf_conntrack_broadcast ipt_MASQUERADE ip6table_mangle ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 iptable_nat nf_nat_ipv4 nf_nat iptable_mangle ipt_REJECT nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter ip_tables kvm_amd kvm sp5100_tco bnx2 i2c_piix4 crc32c_intel k10temp fam15h_power ghash_clmulni_intel amd64_edac_mod pcspkr serio_raw edac_mce_amd edac_core microcode xfs libcrc32c sr_mod sd_mod cdrom ata_generic crc_t10dif pata_acpi radeon i2c_algo_bit drm_kms_helper ttm drm ahci pata_atiixp libahci libata usb_storage i2c_core dm_mirror dm_region_hash dm_log dm_mod
    [  131.176784] Pid: 0, comm: swapper/28 Not tainted 3.8.0+ #6
    [  131.182248] Call Trace:
    [  131.184684]  <IRQ>  [<ffffffff810612af>] warn_slowpath_common+0x7f/0xc0
    [  131.191312]  [<ffffffff8106130a>] warn_slowpath_null+0x1a/0x20
    [  131.197131]  [<ffffffff810b9fd5>] clockevents_program_event+0x135/0x140
    [  131.203721]  [<ffffffff810bb584>] tick_program_event+0x24/0x30
    [  131.209534]  [<ffffffff81089ab1>] hrtimer_interrupt+0x131/0x230
    [  131.215437]  [<ffffffff814b9600>] ? cpufreq_p4_target+0x130/0x130
    [  131.221509]  [<ffffffff81619119>] smp_apic_timer_interrupt+0x69/0x99
    [  131.227839]  [<ffffffff8161805d>] apic_timer_interrupt+0x6d/0x80
    [  131.233816]  <EOI>  [<ffffffff81099745>] ? sched_clock_cpu+0xc5/0x120
    [  131.240267]  [<ffffffff814b9ff0>] ? cpuidle_wrap_enter+0x50/0xa0
    [  131.246252]  [<ffffffff814b9fe9>] ? cpuidle_wrap_enter+0x49/0xa0
    [  131.252238]  [<ffffffff814ba050>] cpuidle_enter_tk+0x10/0x20
    [  131.257877]  [<ffffffff814b9c89>] cpuidle_idle_call+0xa9/0x260
    [  131.263692]  [<ffffffff8101c42f>] cpu_idle+0xaf/0x120
    [  131.268727]  [<ffffffff815f8971>] start_secondary+0x255/0x257
    [  131.274449] ---[ end trace 1151a50552231615 ]---

    When we change the system time to a low value like this, the value of
    timekeeper->offs_real will be a negative value.

    It seems that the WARN occurs because an hrtimer has been started in the time
    between the releasing of the timekeeper lock and the IPI call (via a call to
    on_each_cpu) in clock_was_set() in the do_settimeofday() code.  The end result
    is that a REALTIME_CLOCK timer has been added with softexpires = expires =
    KTIME_MAX.  The hrtimer_interrupt() fires/is called and the loop at
    kernel/hrtimer.c:1289 is executed.  In this loop the code subtracts the
    clock base's offset (which was set to timekeeper->offs_real in
    do_settimeofday()) from the current hrtimer_cpu_base->expiry value (which
    was KTIME_MAX):

    	KTIME_MAX - (a negative value) = overflow

    A simple check for an overflow can resolve this problem.  Using KTIME_MAX
    instead of the overflow value will result in the hrtimer function being run,
    and the reprogramming of the timer after that.

    Reviewed-by: Rik van Riel <riel@redhat.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Prarit Bhargava <prarit@redhat.com>
    [jstultz: Tweaked commit subject]
    Signed-off-by: John Stultz <john.stultz@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b0f97a448749144ed26634ed47323ce2217a7a4c
Author: David Engraf <david.engraf@sysgo.com>
Date:   Tue Mar 19 13:29:55 2013 +0100

    hrtimer: Fix ktime_add_ns() overflow on 32bit architectures

    commit 51fd36f3fad8447c487137ae26b9d0b3ce77bb25 upstream.

    One can trigger an overflow when using ktime_add_ns() on a 32bit
    architecture not supporting CONFIG_KTIME_SCALAR.

    When passing a very high value for u64 nsec, e.g. 7881299347898368000
    the do_div() function converts this value to seconds (7881299347) which
    is still to high to pass to the ktime_set() function as long. The result
    in is a negative value.

    The problem on my system occurs in the tick-sched.c,
    tick_nohz_stop_sched_tick() when time_delta is set to
    timekeeping_max_deferment(). The check for time_delta < KTIME_MAX is
    valid, thus ktime_add_ns() is called with a too large value resulting in
    a negative expire value. This leads to an endless loop in the ticker code:

    time_delta: 7881299347898368000
    expires = ktime_add_ns(last_update, time_delta)
    expires: negative value

    This fix caps the value to KTIME_MAX.

    This error doesn't occurs on 64bit or architectures supporting
    CONFIG_KTIME_SCALAR (e.g. ARM, x86-32).

    Signed-off-by: David Engraf <david.engraf@sysgo.com>
    [jstultz: Minor tweaks to commit message & header]
    Signed-off-by: John Stultz <john.stultz@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 748026dd8039469e20429b3e8090bbfbba234089
Author: Dylan Reid <dgreid@chromium.org>
Date:   Tue Apr 16 20:02:34 2013 -0700

    ASoC: max98088: Fix logging of hardware revision.

    commit 98682063549bedd6e2d2b6b7222f150c6fbce68c upstream.

    The hardware revision of the codec is based at 0x40.  Subtract that
    before convering to ASCII.  The same as it is done for 98095.

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

commit 430c701136b9168fbb63b6391af0b8f4216817a9
Author: Takashi Iwai <tiwai@suse.de>
Date:   Thu Apr 25 07:38:15 2013 +0200

    ALSA: usb-audio: Fix autopm error during probing

    commit 60af3d037eb8c670dcce31401501d1271e7c5d95 upstream.

    We've got strange errors in get_ctl_value() in mixer.c during
    probing, e.g. on Hercules RMX2 DJ Controller:

      ALSA mixer.c:352 cannot get ctl value: req = 0x83, wValue = 0x201, wIndex = 0xa00, type = 4
      ALSA mixer.c:352 cannot get ctl value: req = 0x83, wValue = 0x200, wIndex = 0xa00, type = 4
      ....

    It turned out that the culprit is autopm: snd_usb_autoresume() returns
    -ENODEV when called during card->probing = 1.

    Since the call itself during card->probing = 1 is valid, let's fix the
    return value of snd_usb_autoresume() as success.

    Reported-and-tested-by: Daniel Schürmann <daschuer@mixxx.org>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7d4dcfcf2e4351369720bbd8e6a65df56e0458d7
Author: Clemens Ladisch <clemens@ladisch.de>
Date:   Mon Apr 15 15:59:51 2013 +0200

    ALSA: usb-audio: disable autopm for MIDI devices

    commit cbc200bca4b51a8e2406d4b654d978f8503d430b upstream.

    Commit 88a8516a2128 (ALSA: usbaudio: implement USB autosuspend)
    introduced autopm for all USB audio/MIDI devices.  However, many MIDI
    devices, such as synthesizers, do not merely transmit MIDI messages but
    use their MIDI inputs to control other functions.  With autopm, these
    devices would get powered down as soon as the last MIDI port device is
    closed on the host.

    Even some plain MIDI interfaces could get broken: they automatically
    send Active Sensing messages while powered up, but as soon as these
    messages cease, the receiving device would interpret this as an
    accidental disconnection.

    Commit f5f165418cab (ALSA: usb-audio: Fix missing autopm for MIDI input)
    introduced another regression: some devices (e.g. the Roland GAIA SH-01)
    are self-powered but do a reset whenever the USB interface's power state
    changes.

    To work around all this, just disable autopm for all USB MIDI devices.

    Reported-by: Laurens Holst
    Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 204435f3d3f96513892dfd13aa65298abfeed130
Author: Anurup m <anurup.m@huawei.com>
Date:   Mon Apr 29 15:05:52 2013 -0700

    fs/fscache/stats.c: fix memory leak

    commit ec686c9239b4d472052a271c505d04dae84214cc upstream.

    There is a kernel memory leak observed when the proc file
    /proc/fs/fscache/stats is read.

    The reason is that in fscache_stats_open, single_open is called and the
    respective release function is not called during release.  Hence fix
    with correct release function - single_release().

    Addresses https://bugzilla.kernel.org/show_bug.cgi?id=57101

    Signed-off-by: Anurup m <anurup.m@huawei.com>
    Cc: shyju pv <shyju.pv@huawei.com>
    Cc: Sanil kumar <sanil.kumar@huawei.com>
    Cc: Nataraj m <nataraj.m@huawei.com>
    Cc: Li Zefan <lizefan@huawei.com>
    Cc: David Howells <dhowells@redhat.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2f0441ee08f711413b85c8c3a75734913fc6bca9
Author: Stephan Schreiber <info@fs-driver.org>
Date:   Tue Mar 19 15:27:12 2013 -0700

    Wrong asm register contraints in the kvm implementation

    commit de53e9caa4c6149ef4a78c2f83d7f5b655848767 upstream.

    The Linux Kernel contains some inline assembly source code which has
    wrong asm register constraints in arch/ia64/kvm/vtlb.c.

    I observed this on Kernel 3.2.35 but it is also true on the most
    recent Kernel 3.9-rc1.

    File arch/ia64/kvm/vtlb.c:

    u64 guest_vhpt_lookup(u64 iha, u64 *pte)
    {
    	u64 ret;
    	struct thash_data *data;

    	data = __vtr_lookup(current_vcpu, iha, D_TLB);
    	if (data != NULL)
    		thash_vhpt_insert(current_vcpu, data->page_flags,
    			data->itir, iha, D_TLB);

    	asm volatile (
    			"rsm psr.ic|psr.i;;"
    			"srlz.d;;"
    			"ld8.s r9=[%1];;"
    			"tnat.nz p6,p7=r9;;"
    			"(p6) mov %0=1;"
    			"(p6) mov r9=r0;"
    			"(p7) extr.u r9=r9,0,53;;"
    			"(p7) mov %0=r0;"
    			"(p7) st8 [%2]=r9;;"
    			"ssm psr.ic;;"
    			"srlz.d;;"
    			"ssm psr.i;;"
    			"srlz.d;;"
    			: "=r"(ret) : "r"(iha), "r"(pte):"memory");

    	return ret;
    }

    The list of output registers is
    			: "=r"(ret) : "r"(iha), "r"(pte):"memory");
    The constraint "=r" means that the GCC has to maintain that these vars
    are in registers and contain valid info when the program flow leaves
    the assembly block (output registers).
    But "=r" also means that GCC can put them in registers that are used
    as input registers. Input registers are iha, pte on the example.
    If the predicate p7 is true, the 8th assembly instruction
    			"(p7) mov %0=r0;"
    is the first one which writes to a register which is maintained by the
    register constraints; it sets %0. %0 means the first register operand;
    it is ret here.
    This instruction might overwrite the %2 register (pte) which is needed
    by the next instruction:
    			"(p7) st8 [%2]=r9;;"
    Whether it really happens depends on how GCC decides what registers it
    uses and how it optimizes the code.

    The attached patch  fixes the register operand constraints in
    arch/ia64/kvm/vtlb.c.
    The register constraints should be
    			: "=&r"(ret) : "r"(iha), "r"(pte):"memory");
    The & means that GCC must not use any of the input registers to place
    this output register in.

    This is Debian bug#702639
    (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=702639).

    The patch is applicable on Kernel 3.9-rc1, 3.2.35 and many other versions.

    Signed-off-by: Stephan Schreiber <info@fs-driver.org>
    Signed-off-by: Tony Luck <tony.luck@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 40b1161af55b80168e0188e9e34ee39b3dd8e2ed
Author: Stephan Schreiber <info@fs-driver.org>
Date:   Tue Mar 19 15:22:27 2013 -0700

    Wrong asm register contraints in the futex implementation

    commit 136f39ddc53db3bcee2befbe323a56d4fbf06da8 upstream.

    The Linux Kernel contains some inline assembly source code which has
    wrong asm register constraints in arch/ia64/include/asm/futex.h.

    I observed this on Kernel 3.2.23 but it is also true on the most
    recent Kernel 3.9-rc1.

    File arch/ia64/include/asm/futex.h:

    static inline int
    futex_atomic_cmpxchg_inatomic(u32 *uval, u32 __user *uaddr,
    			      u32 oldval, u32 newval)
    {
    	if (!access_ok(VERIFY_WRITE, uaddr, sizeof(u32)))
    		return -EFAULT;

    	{
    		register unsigned long r8 __asm ("r8");
    		unsigned long prev;
    		__asm__ __volatile__(
    			"	mf;;					\n"
    			"	mov %0=r0				\n"
    			"	mov ar.ccv=%4;;				\n"
    			"[1:]	cmpxchg4.acq %1=[%2],%3,ar.ccv		\n"
    			"	.xdata4 \"__ex_table\", 1b-., 2f-.	\n"
    			"[2:]"
    			: "=r" (r8), "=r" (prev)
    			: "r" (uaddr), "r" (newval),
    			  "rO" ((long) (unsigned) oldval)
    			: "memory");
    		*uval = prev;
    		return r8;
    	}
    }

    The list of output registers is
    			: "=r" (r8), "=r" (prev)
    The constraint "=r" means that the GCC has to maintain that these vars
    are in registers and contain valid info when the program flow leaves
    the assembly block (output registers).
    But "=r" also means that GCC can put them in registers that are used
    as input registers. Input registers are uaddr, newval, oldval on the
    example.
    The second assembly instruction
    			"	mov %0=r0				\n"
    is the first one which writes to a register; it sets %0 to 0. %0 means
    the first register operand; it is r8 here. (The r0 is read-only and
    always 0 on the Itanium; it can be used if an immediate zero value is
    needed.)
    This instruction might overwrite one of the other registers which are
    still needed.
    Whether it really happens depends on how GCC decides what registers it
    uses and how it optimizes the code.

    The objdump utility can give us disassembly.
    The futex_atomic_cmpxchg_inatomic() function is inline, so we have to
    look for a module that uses the funtion. This is the
    cmpxchg_futex_value_locked() function in
    kernel/futex.c:

    static int cmpxchg_futex_value_locked(u32 *curval, u32 __user *uaddr,
    				      u32 uval, u32 newval)
    {
    	int ret;

    	pagefault_disable();
    	ret = futex_atomic_cmpxchg_inatomic(curval, uaddr, uval, newval);
    	pagefault_enable();

    	return ret;
    }

    Now the disassembly. At first from the Kernel package 3.2.23 which has
    been compiled with GCC 4.4, remeber this Kernel seemed to work:
    objdump -d linux-3.2.23/debian/build/build_ia64_none_mckinley/kernel/futex.o

    0000000000000230 <cmpxchg_futex_value_locked>:
          230:	0b 18 80 1b 18 21 	[MMI]       adds r3=3168,r13;;
          236:	80 40 0d 00 42 00 	            adds r8=40,r3
          23c:	00 00 04 00       	            nop.i 0x0;;
          240:	0b 50 00 10 10 10 	[MMI]       ld4 r10=[r8];;
          246:	90 08 28 00 42 00 	            adds r9=1,r10
          24c:	00 00 04 00       	            nop.i 0x0;;
          250:	09 00 00 00 01 00 	[MMI]       nop.m 0x0
          256:	00 48 20 20 23 00 	            st4 [r8]=r9
          25c:	00 00 04 00       	            nop.i 0x0;;
          260:	08 10 80 06 00 21 	[MMI]       adds r2=32,r3
          266:	00 00 00 02 00 00 	            nop.m 0x0
          26c:	02 08 f1 52       	            extr.u r16=r33,0,61
          270:	05 40 88 00 08 e0 	[MLX]       addp4 r8=r34,r0
          276:	ff ff 0f 00 00 e0 	            movl r15=0xfffffffbfff;;
          27c:	f1 f7 ff 65
          280:	09 70 00 04 18 10 	[MMI]       ld8 r14=[r2]
          286:	00 00 00 02 00 c0 	            nop.m 0x0
          28c:	f0 80 1c d0       	            cmp.ltu p6,p7=r15,r16;;
          290:	08 40 fc 1d 09 3b 	[MMI]       cmp.eq p8,p9=-1,r14
          296:	00 00 00 02 00 40 	            nop.m 0x0
          29c:	e1 08 2d d0       	            cmp.ltu p10,p11=r14,r33
          2a0:	56 01 10 00 40 10 	[BBB] (p10) br.cond.spnt.few 2e0
    <cmpxchg_futex_value_locked+0xb0>
          2a6:	02 08 00 80 21 03 	      (p08) br.cond.dpnt.few 2b0
    <cmpxchg_futex_value_locked+0x80>
          2ac:	40 00 00 41       	      (p06) br.cond.spnt.few 2e0
    <cmpxchg_futex_value_locked+0xb0>
          2b0:	0a 00 00 00 22 00 	[MMI]       mf;;
          2b6:	80 00 00 00 42 00 	            mov r8=r0
          2bc:	00 00 04 00       	            nop.i 0x0
          2c0:	0b 00 20 40 2a 04 	[MMI]       mov.m ar.ccv=r8;;
          2c6:	10 1a 85 22 20 00 	            cmpxchg4.acq r33=[r33],r35,ar.ccv
          2cc:	00 00 04 00       	            nop.i 0x0;;
          2d0:	10 00 84 40 90 11 	[MIB]       st4 [r32]=r33
          2d6:	00 00 00 02 00 00 	            nop.i 0x0
          2dc:	20 00 00 40       	            br.few 2f0
    <cmpxchg_futex_value_locked+0xc0>
          2e0:	09 40 c8 f9 ff 27 	[MMI]       mov r8=-14
          2e6:	00 00 00 02 00 00 	            nop.m 0x0
          2ec:	00 00 04 00       	            nop.i 0x0;;
          2f0:	0b 58 20 1a 19 21 	[MMI]       adds r11=3208,r13;;
          2f6:	20 01 2c 20 20 00 	            ld4 r18=[r11]
          2fc:	00 00 04 00       	            nop.i 0x0;;
          300:	0b 88 fc 25 3f 23 	[MMI]       adds r17=-1,r18;;
          306:	00 88 2c 20 23 00 	            st4 [r11]=r17
          30c:	00 00 04 00       	            nop.i 0x0;;
          310:	11 00 00 00 01 00 	[MIB]       nop.m 0x0
          316:	00 00 00 02 00 80 	            nop.i 0x0
          31c:	08 00 84 00       	            br.ret.sptk.many b0;;

    The lines
          2b0:	0a 00 00 00 22 00 	[MMI]       mf;;
          2b6:	80 00 00 00 42 00 	            mov r8=r0
          2bc:	00 00 04 00       	            nop.i 0x0
          2c0:	0b 00 20 40 2a 04 	[MMI]       mov.m ar.ccv=r8;;
          2c6:	10 1a 85 22 20 00 	            cmpxchg4.acq r33=[r33],r35,ar.ccv
          2cc:	00 00 04 00       	            nop.i 0x0;;
    are the instructions of the assembly block.
    The line
          2b6:	80 00 00 00 42 00 	            mov r8=r0
    sets the r8 register to 0 and after that
          2c0:	0b 00 20 40 2a 04 	[MMI]       mov.m ar.ccv=r8;;
    prepares the 'oldvalue' for the cmpxchg but it takes it from r8. This
    is wrong.
    What happened here is what I explained above: An input register is
    overwritten which is still needed.
    The register operand constraints in futex.h are wrong.

    (The problem doesn't occur when the Kernel is compiled with GCC 4.6.)

    The attached patch fixes the register operand constraints in futex.h.
    The code after patching of it:

    static inline int
    futex_atomic_cmpxchg_inatomic(u32 *uval, u32 __user *uaddr,
    			      u32 oldval, u32 newval)
    {
    	if (!access_ok(VERIFY_WRITE, uaddr, sizeof(u32)))
    		return -EFAULT;

    	{
    		register unsigned long r8 __asm ("r8") = 0;
    		unsigned long prev;
    		__asm__ __volatile__(
    			"	mf;;					\n"
    			"	mov ar.ccv=%4;;				\n"
    			"[1:]	cmpxchg4.acq %1=[%2],%3,ar.ccv		\n"
    			"	.xdata4 \"__ex_table\", 1b-., 2f-.	\n"
    			"[2:]"
    			: "+r" (r8), "=&r" (prev)
    			: "r" (uaddr), "r" (newval),
    			  "rO" ((long) (unsigned) oldval)
    			: "memory");
    		*uval = prev;
    		return r8;
    	}
    }

    I also initialized the 'r8' var with the C programming language.
    The _asm qualifier on the definition of the 'r8' var forces GCC to use
    the r8 processor register for it.
    I don't believe that we should use inline assembly for zeroing out a
    local variable.
    The constraint is
    "+r" (r8)
    what means that it is both an input register and an output register.
    Note that the page fault handler will modify the r8 register which
    will be the return value of the function.
    The real fix is
    "=&r" (prev)
    The & means that GCC must not use any of the input registers to place
    this output register in.

    Patched the Kernel 3.2.23 and compiled it with GCC4.4:

    0000000000000230 <cmpxchg_futex_value_locked>:
          230:	0b 18 80 1b 18 21 	[MMI]       adds r3=3168,r13;;
          236:	80 40 0d 00 42 00 	            adds r8=40,r3
          23c:	00 00 04 00       	            nop.i 0x0;;
          240:	0b 50 00 10 10 10 	[MMI]       ld4 r10=[r8];;
          246:	90 08 28 00 42 00 	            adds r9=1,r10
          24c:	00 00 04 00       	            nop.i 0x0;;
          250:	09 00 00 00 01 00 	[MMI]       nop.m 0x0
          256:	00 48 20 20 23 00 	            st4 [r8]=r9
          25c:	00 00 04 00       	            nop.i 0x0;;
          260:	08 10 80 06 00 21 	[MMI]       adds r2=32,r3
          266:	20 12 01 10 40 00 	            addp4 r34=r34,r0
          26c:	02 08 f1 52       	            extr.u r16=r33,0,61
          270:	05 40 00 00 00 e1 	[MLX]       mov r8=r0
          276:	ff ff 0f 00 00 e0 	            movl r15=0xfffffffbfff;;
          27c:	f1 f7 ff 65
          280:	09 70 00 04 18 10 	[MMI]       ld8 r14=[r2]
          286:	00 00 00 02 00 c0 	            nop.m 0x0
          28c:	f0 80 1c d0       	            cmp.ltu p6,p7=r15,r16;;
          290:	08 40 fc 1d 09 3b 	[MMI]       cmp.eq p8,p9=-1,r14
          296:	00 00 00 02 00 40 	            nop.m 0x0
          29c:	e1 08 2d d0       	            cmp.ltu p10,p11=r14,r33
          2a0:	56 01 10 00 40 10 	[BBB] (p10) br.cond.spnt.few 2e0
    <cmpxchg_futex_value_locked+0xb0>
          2a6:	02 08 00 80 21 03 	      (p08) br.cond.dpnt.few 2b0
    <cmpxchg_futex_value_locked+0x80>
          2ac:	40 00 00 41       	      (p06) br.cond.spnt.few 2e0
    <cmpxchg_futex_value_locked+0xb0>
          2b0:	0b 00 00 00 22 00 	[MMI]       mf;;
          2b6:	00 10 81 54 08 00 	            mov.m ar.ccv=r34
          2bc:	00 00 04 00       	            nop.i 0x0;;
          2c0:	09 58 8c 42 11 10 	[MMI]       cmpxchg4.acq r11=[r33],r35,ar.ccv
          2c6:	00 00 00 02 00 00 	            nop.m 0x0
          2cc:	00 00 04 00       	            nop.i 0x0;;
          2d0:	10 00 2c 40 90 11 	[MIB]       st4 [r32]=r11
          2d6:	00 00 00 02 00 00 	            nop.i 0x0
          2dc:	20 00 00 40       	            br.few 2f0
    <cmpxchg_futex_value_locked+0xc0>
          2e0:	09 40 c8 f9 ff 27 	[MMI]       mov r8=-14
          2e6:	00 00 00 02 00 00 	            nop.m 0x0
          2ec:	00 00 04 00       	            nop.i 0x0;;
          2f0:	0b 88 20 1a 19 21 	[MMI]       adds r17=3208,r13;;
          2f6:	30 01 44 20 20 00 	            ld4 r19=[r17]
          2fc:	00 00 04 00       	            nop.i 0x0;;
          300:	0b 90 fc 27 3f 23 	[MMI]       adds r18=-1,r19;;
          306:	00 90 44 20 23 00 	            st4 [r17]=r18
          30c:	00 00 04 00       	            nop.i 0x0;;
          310:	11 00 00 00 01 00 	[MIB]       nop.m 0x0
          316:	00 00 00 02 00 80 	            nop.i 0x0
          31c:	08 00 84 00       	            br.ret.sptk.many b0;;

    Much better.
    There is a
          270:	05 40 00 00 00 e1 	[MLX]       mov r8=r0
    which was generated by C code r8 = 0. Below
          2b6:	00 10 81 54 08 00 	            mov.m ar.ccv=r34
    what means that oldval is no longer overwritten.

    This is Debian bug#702641
    (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=702641).

    The patch is applicable on Kernel 3.9-rc1, 3.2.23 and many other versions.

    Signed-off-by: Stephan Schreiber <info@fs-driver.org>
    Signed-off-by: Tony Luck <tony.luck@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3c567a40a1538c96c7cfaa86d944301203e2810d
Author: Yinghai Lu <yinghai@kernel.org>
Date:   Thu Mar 28 04:28:58 2013 +0000

    PCI / ACPI: Don't query OSC support with all possible controls

    commit 545d6e189a41c94c11f55045a771118eccc9d9eb upstream.

    Found problem on system that firmware that could handle pci aer.
    Firmware get error reporting after pci injecting error, before os boots.
    But after os boots, firmware can not get report anymore, even pci=noaer
    is passed.

    Root cause: BIOS _OSC has problem with query bit checking.
    It turns out that BIOS vendor is copying example code from ACPI Spec.
    In ACPI Spec 5.0, page 290:

    	If (Not(And(CDW1,1))) // Query flag clear?
    	{	// Disable GPEs for features granted native control.
    		If (And(CTRL,0x01)) // Hot plug control granted?
    		{
    			Store(0,HPCE) // clear the hot plug SCI enable bit
    			Store(1,HPCS) // clear the hot plug SCI status bit
    		}
    	...
    	}

    When Query flag is set, And(CDW1,1) will be 1, Not(1) will return 0xfffffffe.
    So it will get into code path that should be for control set only.
    BIOS acpi code should be changed to "If (LEqual(And(CDW1,1), 0)))"

    Current kernel code is using _OSC query to notify firmware about support
    from OS and then use _OSC to set control bits.
    During query support, current code is using all possible controls.
    So will execute code that should be only for control set stage.

    That will have problem when pci=noaer or aer firmware_first is used.
    As firmware have that control set for os aer already in query support stage,
    but later will not os aer handling.

    We should avoid passing all possible controls, just use osc_control_set
    instead.
    That should workaround BIOS bugs with affected systems on the field
    as more bios vendors are copying sample code from ACPI spec.

    Signed-off-by: Yinghai Lu <yinghai@kernel.org>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c7baad48c3986e9949a7d42a41dd5081e2177044
Author: Tony Luck <tony.luck@intel.com>
Date:   Wed Mar 20 10:30:15 2013 -0700

    Fix initialization of CMCI/CMCP interrupts

    commit d303e9e98fce56cdb3c6f2ac92f626fc2bd51c77 upstream.

    Back 2010 during a revamp of the irq code some initializations
    were moved from ia64_mca_init() to ia64_mca_late_init() in

    	commit c75f2aa13f5b268aba369b5dc566088b5194377c
    	Cannot use register_percpu_irq() from ia64_mca_init()

    But this was hideously wrong. First of all these initializations
    are now down far too late. Specifically after all the other cpus
    have been brought up and initialized their own CMC vectors from
    smp_callin(). Also ia64_mca_late_init() may be called from any cpu
    so the line:
    	ia64_mca_cmc_vector_setup();       /* Setup vector on BSP */
    is generally not executed on the BSP, and so the CMC vector isn't
    setup at all on that processor.

    Make use of the arch_early_irq_init() hook to get this code executed
    at just the right moment: not too early, not too late.

    Reported-by: Fred Hartnett <fred.hartnett@hp.com>
    Tested-by: Fred Hartnett <fred.hartnett@hp.com>
    Signed-off-by: Tony Luck <tony.luck@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9702319c6eb4ebedc334ea5825ccce3b210c4a32
Author: Steven A. Falco <sfalco@harris.com>
Date:   Mon Apr 22 09:34:39 2013 +0000

    i2c: xiic: must always write 16-bit words to TX_FIFO

    commit c39e8e4354ce4daf23336de5daa28a3b01f00aa6 upstream.

    The TX_FIFO register is 10 bits wide.  The lower 8 bits are the data to be
    written, while the upper two bits are flags to indicate stop/start.

    The driver apparently attempted to optimize write access, by only writing a
    byte in those cases where the stop/start bits are zero.  However, we have
    seen cases where the lower byte is duplicated onto the upper byte by the
    hardware, which causes inadvertent stop/starts.

    This patch changes the write access to the transmit FIFO to always be 16 bits
    wide.

    Signed off by: Steven A. Falco <sfalco@harris.com>
    Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 08181f491cd016e610d072dd42e8d0e7bda4a789
Author: Namhyung Kim <namhyung.kim@lge.com>
Date:   Thu Apr 11 16:01:38 2013 +0900

    tracing: Reset ftrace_graph_filter_enabled if count is zero

    commit 9f50afccfdc15d95d7331acddcb0f7703df089ae upstream.

    The ftrace_graph_count can be decreased with a "!" pattern, so that
    the enabled flag should be updated too.

    Link: http://lkml.kernel.org/r/1365663698-2413-1-git-send-email-namhyung@kernel.org

    Signed-off-by: Namhyung Kim <namhyung@kernel.org>
    Cc: Frederic Weisbecker <fweisbec@gmail.com>
    Cc: Ingo Molnar <mingo@kernel.org>
    Cc: Namhyung Kim <namhyung.kim@lge.com>
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e81e6f4a69ddf39b89e29a4191a23372d4b1007a
Author: Namhyung Kim <namhyung.kim@lge.com>
Date:   Wed Apr 10 09:18:12 2013 +0900

    tracing: Check return value of tracing_init_dentry()

    commit ed6f1c996bfe4b6e520cf7a74b51cd6988d84420 upstream.

    Check return value and bail out if it's NULL.

    Link: http://lkml.kernel.org/r/1365553093-10180-2-git-send-email-namhyung@kernel.org

    Signed-off-by: Namhyung Kim <namhyung@kernel.org>
    Cc: Frederic Weisbecker <fweisbec@gmail.com>
    Cc: Namhyung Kim <namhyung.kim@lge.com>
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 61857764da0a6fa75f3407e06fbaf05f7cac3d84
Author: Namhyung Kim <namhyung.kim@lge.com>
Date:   Mon Apr 1 21:46:24 2013 +0900

    tracing: Fix off-by-one on allocating stat->pages

    commit 39e30cd1537937d3c00ef87e865324e981434e5b upstream.

    The first page was allocated separately, so no need to start from 0.

    Link: http://lkml.kernel.org/r/1364820385-32027-2-git-send-email-namhyung@kernel.org

    Signed-off-by: Namhyung Kim <namhyung@kernel.org>
    Cc: Frederic Weisbecker <fweisbec@gmail.com>
    Cc: Namhyung Kim <namhyung.kim@lge.com>
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 13f475a567de775169fd7e69a5d84fc41c168c3e
Author: Steven Rostedt (Red Hat) <rostedt@goodmis.org>
Date:   Wed Mar 13 23:34:22 2013 -0400

    tracing: Remove most or all of stack tracer stack size from stack_max_size

    commit 4df297129f622bdc18935c856f42b9ddd18f9f28 upstream.

    Currently, the depth reported in the stack tracer stack_trace file
    does not match the stack_max_size file. This is because the stack_max_size
    includes the overhead of stack tracer itself while the depth does not.

    The first time a max is triggered, a calculation is not performed that
    figures out the overhead of the stack tracer and subtracts it from
    the stack_max_size variable. The overhead is stored and is subtracted
    from the reported stack size for comparing for a new max.

    Now the stack_max_size corresponds to the reported depth:

     # cat stack_max_size
    4640

     # cat stack_trace
            Depth    Size   Location    (48 entries)
            -----    ----   --------
      0)     4640      32   _raw_spin_lock+0x18/0x24
      1)     4608     112   ____cache_alloc+0xb7/0x22d
      2)     4496      80   kmem_cache_alloc+0x63/0x12f
      3)     4416      16   mempool_alloc_slab+0x15/0x17
    [...]

    While testing against and older gcc on x86 that uses mcount instead
    of fentry, I found that pasing in ip + MCOUNT_INSN_SIZE let the
    stack trace show one more function deep which was missing before.

    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 53318264d21af2445edd1eb47b4189717d53f288
Author: Steven Rostedt (Red Hat) <rostedt@goodmis.org>
Date:   Wed Mar 13 21:25:35 2013 -0400

    tracing: Fix stack tracer with fentry use

    commit d4ecbfc49b4b1d4b597fb5ba9e4fa25d62f105c5 upstream.

    When gcc 4.6 on x86 is used, the function tracer will use the new
    option -mfentry which does a call to "fentry" at every function
    instead of "mcount". The significance of this is that fentry is
    called as the first operation of the function instead of the mcount
    usage of being called after the stack.

    This causes the stack tracer to show some bogus results for the size
    of the last function traced, as well as showing "ftrace_call" instead
    of the function. This is due to the stack frame not being set up
    by the function that is about to be traced.

     # cat stack_trace
            Depth    Size   Location    (48 entries)
            -----    ----   --------
      0)     4824     216   ftrace_call+0x5/0x2f
      1)     4608     112   ____cache_alloc+0xb7/0x22d
      2)     4496      80   kmem_cache_alloc+0x63/0x12f

    The 216 size for ftrace_call includes both the ftrace_call stack
    (which includes the saving of registers it does), as well as the
    stack size of the parent.

    To fix this, if CC_USING_FENTRY is defined, then the stack_tracer
    will reserve the first item in stack_dump_trace[] array when
    calling save_stack_trace(), and it will fill it in with the parent ip.
    Then the code will look for the parent pointer on the stack and
    give the real size of the parent's stack pointer:

     # cat stack_trace
            Depth    Size   Location    (14 entries)
            -----    ----   --------
      0)     2640      48   update_group_power+0x26/0x187
      1)     2592     224   update_sd_lb_stats+0x2a5/0x4ac
      2)     2368     160   find_busiest_group+0x31/0x1f1
      3)     2208     256   load_balance+0xd9/0x662

    I'm Cc'ing stable, although it's not urgent, as it only shows bogus
    size for item #0, the rest of the trace is legit. It should still be
    corrected in previous stable releases.

    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f42aa66c19796fd453f434be29a039707aec435f
Author: Steven Rostedt (Red Hat) <rostedt@goodmis.org>
Date:   Wed Mar 13 20:43:57 2013 -0400

    tracing: Use stack of calling function for stack tracer

    commit 87889501d0adfae10e3b0f0e6f2d7536eed9ae84 upstream.

    Use the stack of stack_trace_call() instead of check_stack() as
    the test pointer for max stack size. It makes it a bit cleaner
    and a little more accurate.

    Adding stable, as a later fix depends on this patch.

    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 02f1fef6377f64ae0ea5b542a39eddf1424b505d
Author: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Date:   Mon Apr 22 14:19:26 2013 +0300

    fbcon: when font is freed, clear also vc_font.data

    commit e6637d5427d2af9f3f33b95447bfc5347e5ccd85 upstream.

    commit ae1287865f5361fa138d4d3b1b6277908b54eac9
    Author: Dave Airlie <airlied@redhat.com>
    Date:   Thu Jan 24 16:12:41 2013 +1000

        fbcon: don't lose the console font across generic->chip driver switch

    uses a pointer in vc->vc_font.data to load font into the new driver.
    However if the font is actually freed, we need to clear the data
    so that we don't reload font from dangling pointer.

    Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=892340
    Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5022cf90d4bb8bed51c8176ce57ac7ccf87ed3d4
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Wed May 1 07:32:21 2013 -0700

    tty: fix up atime/mtime mess, take three

    commit b0b885657b6c8ef63a46bc9299b2a7715d19acde upstream.

    We first tried to avoid updating atime/mtime entirely (commit
    b0de59b5733d: "TTY: do not update atime/mtime on read/write"), and then
    limited it to only update it occasionally (commit 37b7f3c76595: "TTY:
    fix atime/mtime regression"), but it turns out that this was both
    insufficient and overkill.

    It was insufficient because we let people attach to the shared ptmx node
    to see activity without even reading atime/mtime, and it was overkill
    because the "only once a minute" means that you can't really tell an
    idle person from an active one with 'w'.

    So this tries to fix the problem properly.  It marks the shared ptmx
    node as un-notifiable, and it lowers the "only once a minute" to a few
    seconds instead - still long enough that you can't time individual
    keystrokes, but short enough that you can tell whether somebody is
    active or not.

    Reported-by: Simon Kirby <sim@hostway.ca>
    Acked-by: Jiri Slaby <jslaby@suse.cz>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 70f4184b8eeb04a2b8ad2778a76ffac3a0d4e4d2
Author: Federico Vaga <federico.vaga@gmail.com>
Date:   Mon Apr 15 16:01:07 2013 +0200

    serial_core.c: add put_device() after device_find_child()

    commit 5a65dcc04cda41f4122aacc37a5a348454645399 upstream.

    The serial core uses device_find_child() but does not drop the reference to
    the retrieved child after using it. This patch add the missing put_device().

    What I have done to test this issue.

    I used a machine with an AMBA PL011 serial driver. I tested the patch on
    next-20120408 because the last branch [next-20120415] does not boot on this
    board.

    For test purpose, I added some pr_info() messages to print the refcount
    after device_find_child() (lines: 1937,2009), and after put_device()
    (lines: 1947, 2021).

    Boot the machine *without* put_device(). Then:

    echo reboot > /sys/power/disk
    echo disk > /sys/power/state
    [   87.058575] uart_suspend_port:1937 refcount 4
    [   87.058582] uart_suspend_port:1947 refcount 4
    [   87.098083] uart_resume_port:2009refcount 5
    [   87.098088] uart_resume_port:2021 refcount 5

    echo disk > /sys/power/state
    [  103.055574] uart_suspend_port:1937 refcount 6
    [  103.055580] uart_suspend_port:1947 refcount 6
    [  103.095322] uart_resume_port:2009 refcount 7
    [  103.095327] uart_resume_port:2021 refcount 7

    echo disk > /sys/power/state
    [  252.459580] uart_suspend_port:1937 refcount 8
    [  252.459586] uart_suspend_port:1947 refcount 8
    [  252.499611] uart_resume_port:2009 refcount 9
    [  252.499616] uart_resume_port:2021 refcount 9

    The refcount continuously increased.

    Boot the machine *with* this patch. Then:

    echo reboot > /sys/power/disk
    echo disk > /sys/power/state
    [  159.333559] uart_suspend_port:1937 refcount 4
    [  159.333566] uart_suspend_port:1947 refcount 3
    [  159.372751] uart_resume_port:2009 refcount 4
    [  159.372755] uart_resume_port:2021 refcount 3

    echo disk > /sys/power/state
    [  185.713614] uart_suspend_port:1937 refcount 4
    [  185.713621] uart_suspend_port:1947 refcount 3
    [  185.752935] uart_resume_port:2009 refcount 4
    [  185.752940] uart_resume_port:2021 refcount 3

    echo disk > /sys/power/state
    [  207.458584] uart_suspend_port:1937 refcount 4
    [  207.458591] uart_suspend_port:1947 refcount 3
    [  207.498598] uart_resume_port:2009 refcount 4
    [  207.498605] uart_resume_port:2021 refcount 3

    The refcount correctly handled.

    Signed-off-by: Federico Vaga <federico.vaga@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f7cfcd277732f50bbdaf56880546faddbb2a73ba
Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date:   Tue Apr 16 15:18:00 2013 -0400

    xen/time: Fix kasprintf splat when allocating timer%d IRQ line.

    commit 7918c92ae9638eb8a6ec18e2b4a0de84557cccc8 upstream.

    When we online the CPU, we get this splat:

    smpboot: Booting Node 0 Processor 1 APIC 0x2
    installing Xen timer for CPU 1
    BUG: sleeping function called from invalid context at /home/konrad/ssd/konrad/linux/mm/slab.c:3179
    in_atomic(): 1, irqs_disabled(): 0, pid: 0, name: swapper/1
    Pid: 0, comm: swapper/1 Not tainted 3.9.0-rc6upstream-00001-g3884fad #1
    Call Trace:
     [<ffffffff810c1fea>] __might_sleep+0xda/0x100
     [<ffffffff81194617>] __kmalloc_track_caller+0x1e7/0x2c0
     [<ffffffff81303758>] ? kasprintf+0x38/0x40
     [<ffffffff813036eb>] kvasprintf+0x5b/0x90
     [<ffffffff81303758>] kasprintf+0x38/0x40
     [<ffffffff81044510>] xen_setup_timer+0x30/0xb0
     [<ffffffff810445af>] xen_hvm_setup_cpu_clockevents+0x1f/0x30
     [<ffffffff81666d0a>] start_secondary+0x19c/0x1a8

    The solution to that is use kasprintf in the CPU hotplug path
    that 'online's the CPU. That is, do it in in xen_hvm_cpu_notify,
    and remove the call to in xen_hvm_setup_cpu_clockevents.

    Unfortunatly the later is not a good idea as the bootup path
    does not use xen_hvm_cpu_notify so we would end up never allocating
    timer%d interrupt lines when booting. As such add the check for
    atomic() to continue.

    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d44632e6253a87c8fdad2329b266cfc9c1d5c83c
Author: Heiko Carstens <heiko.carstens@de.ibm.com>
Date:   Thu Apr 25 10:03:15 2013 +0200

    s390/memory hotplug: prevent offline of active memory increments

    commit 94c163663fc1dcfc067a5fb3cc1446b9469975ce upstream.

    In case a machine supports memory hotplug all active memory increments
    present at IPL time have been initialized with a "usecount" of 1.
    This is wrong if the memory increment size is larger than the memory
    section size of the memory hotplug code. If that is the case the
    usecount must be initialized with the number of memory sections that
    fit into one memory increment.
    Otherwise it is possible to put a memory increment into standby state
    even if there are still active sections.
    Afterwards addressing exceptions might happen which cause the kernel
    to panic.
    However even worse, if a memory increment was put into standby state
    and afterwards into active state again, it's contents would have been
    zeroed, leading to memory corruption.

    This was only an issue for machines that support standby memory and
    have at least 256GB memory.

    This is broken since commit fdb1bb15 "[S390] sclp/memory hotplug: fix
    initial usecount of increments".

    Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
    Reviewed-by: Gerald Schaefer <gerald.schaefer@de.ibm.com>
    Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 42753c725c8233d5efbd682e34d0f3215a7c7aaa
Author: Tormod Volden <debian.tormod@gmail.com>
Date:   Sat Apr 20 14:24:04 2013 +0200

    usb-storage: CY7C68300A chips do not support Cypress ATACB

    commit 671b4b2ba9266cbcfe7210a704e9ea487dcaa988 upstream.

    Many cards based on CY7C68300A/B/C use the USB ID 04b4:6830 but only the
    B and C variants (EZ-USB AT2LP) support the ATA Command Block
    functionality, according to the data sheets. The A variant (EZ-USB AT2)
    locks up if ATACB is attempted, until a typical 30 seconds timeout runs
    out and a USB reset is performed.

    https://bugs.launchpad.net/bugs/428469

    It seems that one way to spot a CY7C68300A (at least where the card
    manufacturer left Cypress' EEPROM default vaules, against Cypress'
    recommendations) is to look at the USB string descriptor indices.

    A http://media.digikey.com/pdf/Data%20Sheets/Cypress%20PDFs/CY7C68300A.pdf
    B http://www.farnell.com/datasheets/43456.pdf
    C http://www.cypress.com/?rID=14189

    Note that a CY7C68300B/C chip appears as CY7C68300A if it is running
    in Backward Compatibility Mode, and if ATACB would be supported in this
    case there is anyway no way to tell which chip it really is.

    For 5 years my external USB drive has been locking up for half a minute
    when plugged in and ata_id is run by udev, or anytime hdparm or similar
    is run on it.

    Finally looking at the /correct/ datasheet I think I found the reason. I
    am aware the quirk in this patch is a bit hacky, but the hardware
    manufacturers haven't made it easy for us.

    Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 60306774f3716df189a69d226d2a59fcf57b4aa9
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Tue Apr 16 11:08:33 2013 +0200

    usbfs: Always allow ctrl requests with USB_RECIP_ENDPOINT on the ctrl ep

    commit 1361bf4b9f9ef45e628a5b89e0fd9bedfdcb7104 upstream.

    When usbfs receives a ctrl-request from userspace it calls check_ctrlrecip,
    which for a request with USB_RECIP_ENDPOINT tries to map this to an interface
    to see if this interface is claimed, except for ctrl-requests with a type of
    USB_TYPE_VENDOR.

    When trying to use this device: http://www.akaipro.com/eiepro
    redirected to a Windows vm running on qemu on top of Linux.

    The windows driver makes a ctrl-req with USB_TYPE_CLASS and
    USB_RECIP_ENDPOINT with index 0, and the mapping of the endpoint (0) to
    the interface fails since ep 0 is the ctrl endpoint and thus never is
    part of an interface.

    This patch fixes this ctrl-req failing by skipping the checkintf call for
    USB_RECIP_ENDPOINT ctrl-reqs on the ctrl endpoint.

    Reported-by: Dave Stikkolorum <d.r.stikkolorum@hhs.nl>
    Tested-by: Dave Stikkolorum <d.r.stikkolorum@hhs.nl>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 131541cdce961e10b4a6f10246c19075ed845729
Author: Adrian Thomasset <adrian.thomasset@st.com>
Date:   Tue Apr 23 12:46:29 2013 +0100

    USB: ftdi_sio: correct ST Micro Connect Lite PIDs

    commit 9f06d15f8db6946e41f73196a122b84a37938878 upstream.

    The current ST Micro Connect Lite uses the FT4232H hi-speed quad USB
    UART FTDI chip. It is also possible to drive STM reference targets
    populated with an on-board JTAG debugger based on the FT2232H chip with
    the same STMicroelectronics tools.

    For this reason, the ST Micro Connect Lite PIDs should be
    ST_STMCLT_2232_PID: 0x3746
    ST_STMCLT_4232_PID: 0x3747

    Signed-off-by: Adrian Thomasset <adrian.thomasset@st.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 525df18348e4c2a144b957f3ab6eb02386700f1b
Author: Stefani Seibold <stefani@seibold.net>
Date:   Sun Apr 7 12:08:55 2013 +0200

    USB: add ftdi_sio USB ID for GDM Boost V1.x

    commit 58f8b6c4fa5a13cb2ddb400e26e9e65766d71e38 upstream.

    This patch add a missing usb device id for the GDMBoost V1.x device

    The patch is against 3.9-rc5

    Signed-off-by: Stefani Seibold <stefani@seibold.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6f3894d0531ec8aa8c111919af5f5d5c997d5106
Author: Ben Jencks <ben@bjencks.net>
Date:   Tue Apr 2 00:35:08 2013 -0400

    usb/misc/appledisplay: Add 24" LED Cinema display

    commit e7d3b6e22c871ba36d052ca99bc8ceca4d546a60 upstream.

    Add the Apple 24" LED Cinema display to the supported devices.

    Signed-off-by: Ben Jencks <ben@bjencks.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f4fd63017f8d28fa7719aebf1abca98f31685b2e
Author: Bjørn Mork <bjorn@mork.no>
Date:   Tue Apr 9 11:26:02 2013 +0200

    USB: option: add a D-Link DWM-156 variant

    commit a2a2d6c7f93e160b52a4ad0164db1f43f743ae0f upstream.

    Adding support for a Mediatek based device labelled as
    D-Link Model: DWM-156, H/W Ver: A7

    Also adding two other device IDs found in the Debian(!)
    packages included on the embedded device driver CD.

    This is a composite MBIM + serial ports + card reader device:

    T:  Bus=04 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 14 Spd=480  MxCh= 0
    D:  Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=2001 ProdID=7d01 Rev= 3.00
    S:  Manufacturer=D-Link,Inc
    S:  Product=D-Link DWM-156
    C:* #Ifs= 7 Cfg#= 1 Atr=a0 MxPwr=500mA
    A:  FirstIf#= 0 IfCount= 2 Cls=02(comm.) Sub=0e Prot=00
    I:* If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=0e Prot=00 Driver=cdc_mbim
    E:  Ad=88(I) Atr=03(Int.) MxPS=  64 Ivl=125us
    I:  If#= 1 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
    I:* If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
    E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=02 Prot=01 Driver=option
    E:  Ad=87(I) Atr=03(Int.) MxPS=  64 Ivl=500us
    E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 6 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
    E:  Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms

    Signed-off-by: Bjørn Mork <bjorn@mork.no>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5e0c24d1ff9f94c0c1721b4b00b927aa6ecfe8fc
Author: Filippo Turato <nnj7585@gmail.com>
Date:   Sat Apr 20 15:04:08 2013 +0200

    USB: serial: option: Added support Olivetti Olicard 145

    commit d19bf5cedfd7d53854a3bd699c98b467b139833b upstream.

    This adds PID for Olivetti Olicard 145 in option.c

    Signed-off-by: Filippo Turato <nnj7585@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ea70316c0e035731348f6be194e6332388944029
Author: Michael Ellerman <michael@ellerman.id.au>
Date:   Tue Apr 23 15:13:14 2013 +0000

    powerpc/spufs: Initialise inode->i_ino in spufs_new_inode()

    commit 6747e83235caecd30b186d1282e4eba7679f81b7 upstream.

    In commit 85fe402 (fs: do not assign default i_ino in new_inode), the
    initialisation of i_ino was removed from new_inode() and pushed down
    into the callers. However spufs_new_inode() was not updated.

    This exhibits as no files appearing in /spu, because all our dirents
    have a zero inode, which readdir() seems to dislike.

    Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 74f31cf3c186bc0189ad560fadfc03dd9aa2f806
Author: Michael Neuling <michael.neuling@au1.ibm.com>
Date:   Wed Apr 24 00:30:09 2013 +0000

    powerpc: Add isync to copy_and_flush

    commit 29ce3c5073057991217916abc25628e906911757 upstream.

    In __after_prom_start we copy the kernel down to zero in two calls to
    copy_and_flush.  After the first call (copy from 0 to copy_to_here:)
    we jump to the newly copied code soon after.

    Unfortunately there's no isync between the copy of this code and the
    jump to it.  Hence it's possible that stale instructions could still be
    in the icache or pipeline before we branch to it.

    We've seen this on real machines and it's results in no console output
    after:
      calling quiesce...
      returning from prom_init

    The below adds an isync to ensure that the copy and flushing has
    completed before any branching to the new instructions occurs.

    Signed-off-by: Michael Neuling <mikey@neuling.org>
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Linux 3.0.78

commit ea88a24912c191babee3a3a2658ade2d53b880a9
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Sat May 11 13:38:25 2013 -0700

    Linux 3.0.78

commit 1183e651202ae381263309f6f122e0bf1234b5e2
Author: Andre Przywara <andre.przywara@amd.com>
Date:   Wed Oct 31 17:20:50 2012 +0100

    Revert "x86, amd: Disable way access filter on Piledriver CPUs" it is duplicated

    Revert 5e3fe67e02c53e5a5fcf0e2b0d91dd93f757d50b which is
    commit 2bbf0a1427c377350f001fbc6260995334739ad7 upstream.

    Willy pointed out that I messed up and applied this one twice to the
    3.0-stable tree, so revert the second instance of it.

    Reported by: Willy Tarreau <w@1wt.eu>
    Cc: Andre Przywara <osp@andrep.de>
    Cc: H. Peter Anvin <hpa@linux.intel.com>
    Cc: CAI Qian <caiqian@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

    reverted:

commit dadd72be605e99445bedfacce8d07a85ac84eb41
Author: Jerry Hoemann <jerry.hoemann@hp.com>
Date:   Tue Apr 30 15:15:55 2013 -0600

    x86/mm: account for PGDIR_SIZE alignment

    Patch for -stable.  Function find_early_table_space removed upstream.

    Fixes panic in alloc_low_page due to pgt_buf overflow during
    init_memory_mapping.

    find_early_table_space sizes pgt_buf based upon the size of the
    memory being mapped, but it does not take into account the alignment
    of the memory.  When the region being mapped spans a 512GB (PGDIR_SIZE)
    alignment, a panic from alloc_low_pages occurs.

    kernel_physical_mapping_init takes into account PGDIR_SIZE alignment.
    This causes an extra call to alloc_low_page to be made.  This extra call
    isn't accounted for by find_early_table_space and causes a kernel panic.

    Change is to take into account PGDIR_SIZE alignment in find_early_table_space.

    Signed-off-by: Jerry Hoemann <jerry.hoemann@hp.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d47f90f3cb58908bb6f6720b678e37e57028a590
Author: Chen Gang <gang.chen@asianux.com>
Date:   Mon Apr 29 15:05:19 2013 -0700

    kernel/audit_tree.c: tree will leak memory when failure occurs in audit_trim_trees()

    commit 12b2f117f3bf738c1a00a6f64393f1953a740bd4 upstream.

    audit_trim_trees() calls get_tree().  If a failure occurs we must call
    put_tree().

    [akpm@linux-foundation.org: run put_tree() before mutex_lock() for small scalability improvement]
    Signed-off-by: Chen Gang <gang.chen@asianux.com>
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Cc: Eric Paris <eparis@redhat.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Jonghwan Choi <jhbird.choi@samsung.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 07bdcd24805f6c492c5871dac365f7ce0a331044
Author: Steven Rostedt (Red Hat) <rostedt@goodmis.org>
Date:   Fri Mar 15 13:10:35 2013 -0400

    tracing: Fix ftrace_dump()

    commit 7fe70b579c9e3daba71635e31b6189394e7b79d3 upstream.

    ftrace_dump() had a lot of issues. What ftrace_dump() does, is when
    ftrace_dump_on_oops is set (via a kernel parameter or sysctl), it
    will dump out the ftrace buffers to the console when either a oops,
    panic, or a sysrq-z occurs.

    This was written a long time ago when ftrace was fragile to recursion.
    But it wasn't written well even for that.

    There's a possible deadlock that can occur if a ftrace_dump() is happening
    and an NMI triggers another dump. This is because it grabs a lock
    before checking if the dump ran.

    It also totally disables ftrace, and tracing for no good reasons.

    As the ring_buffer now checks if it is read via a oops or NMI, where
    there's a chance that the buffer gets corrupted, it will disable
    itself. No need to have ftrace_dump() do the same.

    ftrace_dump() is now cleaned up where it uses an atomic counter to
    make sure only one dump happens at a time. A simple atomic_inc_return()
    is enough that is needed for both other CPUs and NMIs. No need for
    a spinlock, as if one CPU is running the dump, no other CPU needs
    to do it too.

    The tracing_on variable is turned off and not turned on. The original
    code did this, but it wasn't pretty. By just disabling this variable
    we get the result of not seeing traces that happen between crashes.

    For sysrq-z, it doesn't get turned on, but the user can always write
    a '1' to the tracing_on file. If they are using sysrq-z, then they should
    know about tracing_on.

    The new code is much easier to read and less error prone. No more
    deadlock possibility when an NMI triggers here.

    Reported-by: zhangwei(Jovi) <jovi.zhangwei@huawei.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Cc: Frederic Weisbecker <fweisbec@gmail.com>
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 82bab2b3b6d6029b06a4e85156ccf99bf95cc2f2
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Thu Apr 25 09:29:17 2013 -0400

    drm/radeon: fix possible segfault when parsing pm tables

    commit f8e6bfc2ce162855fa4f9822a45659f4b542c960 upstream.

    If we have a empty power table, bail early and allocate
    the default power state.

    Should fix:
    https://bugs.freedesktop.org/show_bug.cgi?id=63865

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

commit b085d867934932a43188297161a5fbbe07565b4c
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Wed Apr 24 14:39:31 2013 -0400

    drm/radeon: fix endian bugs in atom_allocate_fb_scratch()

    commit beb71fc61c2cad64e347f164991b8ef476529e64 upstream.

    Reviwed-by: Michel Dänzer <michel.daenzer@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 370112b115a3867b2ebf0ac6a2f44f11425fe818
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Thu Apr 11 12:45:34 2013 -0400

    drm/radeon/evergreen+: don't enable HPD interrupts on eDP/LVDS

    commit 2e97be73e5f74a317232740ae82eb8f95326a660 upstream.

    Avoids potential interrupt storms when the display is disabled.

    May fix:
    https://bugzilla.kernel.org/show_bug.cgi?id=56041

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

commit b1459cd57d01eb554821bf263463ef18bc1f59ef
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Mon Mar 18 17:12:50 2013 -0400

    drm/radeon: don't use get_engine_clock() on APUs

    commit bf05d9985111f85ed6922c134567b96eb789283b upstream.

    It doesn't work reliably.  Just report back the currently
    selected engine clock.

    Partially fixes:
    https://bugs.freedesktop.org/show_bug.cgi?id=62493

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

commit c2fde23d77ebcf4577fdd703af8b1600f3c87f69
Author: David Müller <d.mueller@elsoft.ch>
Date:   Fri Apr 19 10:41:50 2013 +0200

    drm/i915: Fall back to bit banging mode for DVO transmitter detection

    commit e4bfff54ed3f5de88f5358504c78c2cb037813aa upstream.

    As discussed in this thread
    http://lists.freedesktop.org/archives/dri-devel/2013-April/037411.html
    GMBUS based DVO transmitter detection seems to be unreliable which could
    result in an unusable DVO port.

    The attached patch fixes this by falling back to bit banging mode for
    the time DVO transmitter detection is in progress.

    Signed-off-by: David Müller <d.mueller@elsoft.ch>
    Tested-by: David Müller <d.mueller@elsoft.ch>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit df859ddd0675a729e4108da5bd9c3ac9618441f2
Author: Christian Lamparter <chunkeey@googlemail.com>
Date:   Wed Apr 3 14:34:11 2013 +0200

    drm/i915: Add no-lvds quirk for Fujitsu Esprimo Q900

    commit 9e9dd0e889c76c786e8f2e164c825c3c06dea30c upstream.

    The "Mobile Sandy Bridge CPUs" in the Fujitsu Esprimo Q900
    mini desktop PCs are probably misleading the LVDS detection
    code in intel_lvds_supported. Nothing is connected to the
    LVDS ports in these systems.

    Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 332400ff82e7d3ea465bf62d46c87953f59a118b
Author: Hans Schillstrom <hans@schillstrom.com>
Date:   Sat Apr 27 20:06:14 2013 +0200

    ipvs: ip_vs_sip_fill_param() BUG: bad check of return value

    commit f7a1dd6e3ad59f0cfd51da29dfdbfd54122c5916 upstream.

    The reason for this patch is crash in kmemdup
    caused by returning from get_callid with uniialized
    matchoff and matchlen.

    Removing Zero check of matchlen since it's done by ct_sip_get_header()

    BUG: unable to handle kernel paging request at ffff880457b5763f
    IP: [<ffffffff810df7fc>] kmemdup+0x2e/0x35
    PGD 27f6067 PUD 0
    Oops: 0000 [#1] PREEMPT SMP
    Modules linked in: xt_state xt_helper nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_mangle xt_connmark xt_conntrack ip6_tables nf_conntrack_ftp ip_vs_ftp nf_nat xt_tcpudp iptable_mangle xt_mark ip_tables x_tables ip_vs_rr ip_vs_lblcr ip_vs_pe_sip ip_vs nf_conntrack_sip nf_conntrack bonding igb i2c_algo_bit i2c_core
    CPU 5
    Pid: 0, comm: swapper/5 Not tainted 3.9.0-rc5+ #5                  /S1200KP
    RIP: 0010:[<ffffffff810df7fc>]  [<ffffffff810df7fc>] kmemdup+0x2e/0x35
    RSP: 0018:ffff8803fea03648  EFLAGS: 00010282
    RAX: ffff8803d61063e0 RBX: 0000000000000003 RCX: 0000000000000003
    RDX: 0000000000000003 RSI: ffff880457b5763f RDI: ffff8803d61063e0
    RBP: ffff8803fea03658 R08: 0000000000000008 R09: 0000000000000011
    R10: 0000000000000011 R11: 00ffffffff81a8a3 R12: ffff880457b5763f
    R13: ffff8803d67f786a R14: ffff8803fea03730 R15: ffffffffa0098e90
    FS:  0000000000000000(0000) GS:ffff8803fea00000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: ffff880457b5763f CR3: 0000000001a0c000 CR4: 00000000001407e0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
    Process swapper/5 (pid: 0, threadinfo ffff8803ee18c000, task ffff8803ee18a480)
    Stack:
     ffff8803d822a080 000000000000001c ffff8803fea036c8 ffffffffa000937a
     ffffffff81f0d8a0 000000038135fdd5 ffff880300000014 ffff880300110000
     ffffffff150118ac ffff8803d7e8a000 ffff88031e0118ac 0000000000000000
    Call Trace:
     <IRQ>

     [<ffffffffa000937a>] ip_vs_sip_fill_param+0x13a/0x187 [ip_vs_pe_sip]
     [<ffffffffa007b209>] ip_vs_sched_persist+0x2c6/0x9c3 [ip_vs]
     [<ffffffff8107dc53>] ? __lock_acquire+0x677/0x1697
     [<ffffffff8100972e>] ? native_sched_clock+0x3c/0x7d
     [<ffffffff8100972e>] ? native_sched_clock+0x3c/0x7d
     [<ffffffff810649bc>] ? sched_clock_cpu+0x43/0xcf
     [<ffffffffa007bb1e>] ip_vs_schedule+0x181/0x4ba [ip_vs]
    ...

    Signed-off-by: Hans Schillstrom <hans@schillstrom.com>
    Acked-by: Julian Anastasov <ja@ssi.bg>
    Signed-off-by: Simon Horman <horms@verge.net.au>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Cc: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eda948e04f7804886db45005eae5793a6ffb0bbc
Author: David Jeffery <djeffery@redhat.com>
Date:   Mon May 6 13:49:30 2013 +0800

    autofs - remove autofs dentry mount check

    commit ce8a5dbdf9e709bdaf4618d7ef8cceb91e8adc69 upstream.

    When checking if an autofs mount point is busy it isn't sufficient to
    only check if it's a mount point.

    For example, if the mount of an offset mountpoint in a tree is denied
    for this host by its export and the dentry becomes a process working
    directory the check incorrectly returns the mount as not in use at
    expire.

    This can happen since the default when mounting within a tree is
    nostrict, which means ingnore mount fails on mounts within the tree and
    continue.  The nostrict option is meant to allow mounting in this case.

    Signed-off-by: David Jeffery <djeffery@redhat.com>
    Signed-off-by: Ian Kent <raven@themaw.net>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5013bcf5cbd6969b8873b964e0d7aaab430cf643
Author: Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>
Date:   Fri Mar 22 05:49:35 2013 +0000

    powerpc: fix numa distance for form0 device tree

    commit 7122beeee7bc1757682049780179d7c216dd1c83 upstream.

    The following commit breaks numa distance setup for old powerpc
    systems that use form0 encoding in device tree.

    commit 41eab6f88f24124df89e38067b3766b7bef06ddb
    powerpc/numa: Use form 1 affinity to setup node distance

    Device tree node /rtas/ibm,associativity-reference-points would
    index into /cpus/PowerPCxxxx/ibm,associativity based on form0 or
    form1 encoding detected by ibm,architecture-vec-5 property.

    All modern systems use form1 and current kernel code is correct.
    However, on older systems with form0 encoding, the numa distance
    will get hard coded as LOCAL_DISTANCE for all nodes.  This causes
    task scheduling anomaly since scheduler will skip building numa
    level domain (topmost domain with all cpus) if all numa distances
    are same.  (value of 'level' in sched_init_numa() will remain 0)

    Prior to the above commit:
    ((from) == (to) ? LOCAL_DISTANCE : REMOTE_DISTANCE)

    Restoring compatible behavior with this patch for old powerpc systems
    with device tree where numa distance are encoded as form0.

    Signed-off-by: Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>
    Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Linux 3.0.79

commit ae101a35196a14a8388b7db5f7ddd0b3cfdc5f99
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Sun May 19 10:05:47 2013 -0700

    Linux 3.0.79

commit 49432a001824f973ccf8214c7ef9e8e72c974987
Author: Oleg Nesterov <oleg@redhat.com>
Date:   Thu May 16 17:43:55 2013 +0200

    usermodehelper: check subprocess_info->path != NULL

    commit 264b83c07a84223f0efd0d1db9ccc66d6f88288f upstream.

    argv_split(empty_or_all_spaces) happily succeeds, it simply returns
    argc == 0 and argv[0] == NULL. Change call_usermodehelper_exec() to
    check sub_info->path != NULL to avoid the crash.

    This is the minimal fix, todo:

     - perhaps we should change argv_split() to return NULL or change the
       callers.

     - kill or justify ->path[0] check

     - narrow the scope of helper_lock()

    Signed-off-by: Oleg Nesterov <oleg@redhat.com>
    Acked-By: Lucas De Marchi <lucas.demarchi@intel.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ac087d8e21d7722266d913d766b5c8b87772cbb4
Author: Kees Cook <keescook@chromium.org>
Date:   Sun May 12 22:00:51 2013 -0700

    drm/radeon: check incoming cliprects pointer

    commit fefaedcfb82d2e57c2320acf60604ab03b750cc0 upstream.

    The "boxes" parameter points into userspace memory. It should be verified
    like any other operation against user memory.

    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 486684458640fe1e74937b2e0eef41444515caf0
Author: Benjamin LaHaise <bcrl@kvack.org>
Date:   Thu May 16 14:04:27 2013 -0500

    ipmi: ipmi_devintf: compat_ioctl method fails to take ipmi_mutex

    commit 6368087e851e697679af059b4247aca33a69cef3 upstream.

    When a 32 bit version of ipmitool is used on a 64 bit kernel, the
    ipmi_devintf code fails to correctly acquire ipmi_mutex.  This results in
    incomplete data being retrieved in some cases, or other possible failures.
    Add a wrapper around compat_ipmi_ioctl() to take ipmi_mutex to fix this.

    Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
    Signed-off-by: Corey Minyard <cminyard@mvista.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c9e43f309c0a5ecb9467ea826c238fc0febb1e30
Author: Chen Gang <gang.chen@asianux.com>
Date:   Thu May 16 14:04:25 2013 -0500

    drivers/char/ipmi: memcpy, need additional 2 bytes to avoid memory overflow

    commit a5f2b3d6a738e7d4180012fe7b541172f8c8dcea upstream.

    When calling memcpy, read_data and write_data need additional 2 bytes.

      write_data:
        for checking:  "if (size > IPMI_MAX_MSG_LENGTH)"
        for operating: "memcpy(bt->write_data + 3, data + 1, size - 1)"

      read_data:
        for checking:  "if (msg_len < 3 || msg_len > IPMI_MAX_MSG_LENGTH)"
        for operating: "memcpy(data + 2, bt->read_data + 4, msg_len - 2)"

    Signed-off-by: Chen Gang <gang.chen@asianux.com>
    Signed-off-by: Corey Minyard <cminyard@mvista.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9e5124c57d380d616aef157c0f9e05ef0c80d1ca
Author: Lan Tianyu <tianyu.lan@intel.com>
Date:   Mon May 6 03:23:40 2013 +0000

    ACPI / EC: Restart transaction even when the IBF flag set

    commit 28fe5c825f8e15744d04c7c1b8df197950923ecd upstream.

    The EC driver works abnormally with IBF flag always set.
    IBF means "The host has written a byte of data to the command
    or data port, but the embedded controller has not yet read it".
    If IBF is set in the EC status and not cleared, this will cause
    all subsequent EC requests to fail with a timeout error.

    Change the EC driver so that it doesn't refuse to restart a
    transaction if IBF is set in the status.  Also increase the
    number of transaction restarts to 5, as it turns out that 2
    is not sufficient in some cases.

    This bug happens on several different machines (Asus V1S,
    Dell Latitude E6530, Samsung R719, Acer Aspire 5930G,
    Sony Vaio SR19VN and others).

    [rjw: Changelog]
    References: https://bugzilla.kernel.org/show_bug.cgi?id=14733
    References: https://bugzilla.kernel.org/show_bug.cgi?id=15560
    References: https://bugzilla.kernel.org/show_bug.cgi?id=15946
    References: https://bugzilla.kernel.org/show_bug.cgi?id=42945
    References: https://bugzilla.kernel.org/show_bug.cgi?id=48221
    Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5cb2df345fb2b2e119f492d6c36e8d3bad70d8b3
Author: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Date:   Mon Apr 29 16:21:07 2013 -0700

    drivers/rtc/rtc-pcf2123.c: fix error return code in pcf2123_probe()

    commit 35623715818dfa720cccf99cd280dcbb4b78da23 upstream.

    Fix to return -ENODEV in the chip not found error handling
    case instead of 0, as done elsewhere in this function.

    Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
    Cc: Jingoo Han <jg1.han@samsung.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Jonghwan Choi <jhbird.choi@samsung.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d8b1123f949c5463421ec0a66bbca21e0a5feba0
Author: Philipp Reisner <philipp.reisner@linbit.com>
Date:   Wed Mar 27 14:08:47 2013 +0100

    drbd: fix for deadlock when using automatic split-brain-recovery

    commit 7c689e63a847316c1b2500f86891b0a574ce7e69 upstream.

    With an automatic after split-brain recovery policy of
    "after-sb-1pri call-pri-lost-after-sb",
    when trying to drbd_set_role() to R_SECONDARY,
    we run into a deadlock.

    This was first recognized and supposedly fixed by
    2009-06-10 "Fixed a deadlock when using automatic split brain recovery when both nodes are"
    replacing drbd_set_role() with drbd_change_state() in that code-path,
    but the first hunk of that patch forgets to remove the drbd_set_role().

    We apparently only ever tested the "two primaries" case.

    Signed-off-by: Philipp Reisner <philipp.reisner@linbit.com>
    Signed-off-by: Lars Ellenberg <lars.ellenberg@linbit.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Jonghwan Choi <jhbird.choi@samsung.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e81164cfec2f578998670c8f00e5d0c33c06f20f
Author: Francois Romieu <romieu@fr.zoreil.com>
Date:   Fri May 10 00:50:20 2013 +0200

    r8169: fix vlan tag read ordering.

    commit ce11ff5e5963e441feb591e76278528f876c332d upstream.

    Control of receive descriptor must not be returned to ethernet chipset
    before vlan tag processing is done.

    VLAN tag receive word is now reset both in normal and error path.

    Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
    Spotted-by: Timo Teras <timo.teras@iki.fi>
    Cc: Hayes Wang <hayeswang@realtek.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b89396eaa22b921245b4d30f7e26e406e89aa51c
Author: Tomoya MORINAGA <tomoya.rohm@gmail.com>
Date:   Tue Feb 12 11:25:33 2013 +0900

    pch_dma: Use GFP_ATOMIC because called from interrupt context

    commit 5c1ef59168c485318e40ba485c1eba57d81d0faa upstream.

    pdc_desc_get() is called from pd_prep_slave_sg, and the function is
    called from interrupt context(e.g. Uart driver "pch_uart.c").
    In fact, I saw kernel error message.
    So, GFP_ATOMIC must be used not GFP_NOIO.

    Signed-off-by: Tomoya MORINAGA <tomoya.rohm@gmail.com>
    Signed-off-by: Vinod Koul <vinod.koul@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a7e22d0c0e81dde129a51ee413644124f4b59954
Author: Cong Wang <amwang@redhat.com>
Date:   Thu May 9 22:40:00 2013 +0000

    xfrm6: release dev before returning error

    [ Upstream commit 84c4a9dfbf430861e7588d95ae3ff61535dca351 ]

    We forget to call dev_put() on error path in xfrm6_fill_dst(),
    its caller doesn't handle this.

    Signed-off-by: Cong Wang <amwang@redhat.com>
    Cc: Herbert Xu <herbert@gondor.apana.org.au>
    Cc: Steffen Klassert <steffen.klassert@secunet.com>
    Cc: David S. Miller <davem@davemloft.net>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1e74f2ea952f201c5ee5edce74daab21aea89b31
Author: Eric Dumazet <edumazet@google.com>
Date:   Thu May 9 10:28:16 2013 +0000

    ipv6: do not clear pinet6 field

    [ Upstream commit f77d602124d865c38705df7fa25c03de9c284ad2 ]

    We have seen multiple NULL dereferences in __inet6_lookup_established()

    After analysis, I found that inet6_sk() could be NULL while the
    check for sk_family == AF_INET6 was true.

    Bug was added in linux-2.6.29 when RCU lookups were introduced in UDP
    and TCP stacks.

    Once an IPv6 socket, using SLAB_DESTROY_BY_RCU is inserted in a hash
    table, we no longer can clear pinet6 field.

    This patch extends logic used in commit fcbdf09d9652c891
    ("net: fix nulls list corruptions in sk_prot_alloc")

    TCP/UDP/UDPLite IPv6 protocols provide their own .clear_sk() method
    to make sure we do not clear pinet6 field.

    At socket clone phase, we do not really care, as cloning the parent (non
    NULL) pinet6 is not adding a fatal race.

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

commit d5bf240fa193989d605a715bda7cb3283b1abc89
Author: Jiri Pirko <jiri@resnulli.us>
Date:   Thu May 9 04:23:40 2013 +0000

    macvlan: fix passthru mode race between dev removal and rx path

    [ Upstream commit 233c7df0821c4190e2d3f4be0f2ca0ab40a5ed8c, note
      that I had to add list_first_or_null_rcu to rculist.h in order
      to accomodate this fix. ]

    Currently, if macvlan in passthru mode is created and data are rxed and
    you remove this device, following panic happens:

    NULL pointer dereference at 0000000000000198
    IP: [<ffffffffa0196058>] macvlan_handle_frame+0x153/0x1f7 [macvlan]

    I'm using following script to trigger this:
    <script>
    while [ 1 ]
    do
    	ip link add link e1 name macvtap0 type macvtap mode passthru
    	ip link set e1 up
    	ip link set macvtap0 up
    	IFINDEX=`ip link |grep macvtap0 | cut -f 1 -d ':'`
    	cat /dev/tap$IFINDEX  >/dev/null &
    	ip link del dev macvtap0
    done
    </script>

    I run this script while "ping -f" is running on another machine to send
    packets to e1 rx.

    Reason of the panic is that list_first_entry() is blindly called in
    macvlan_handle_frame() even if the list was empty. vlan is set to
    incorrect pointer which leads to the crash.

    I'm fixing this by protecting port->vlans list by rcu and by preventing
    from getting incorrect pointer in case the list is empty.

    Introduced by: commit eb06acdc85585f2 "macvlan: Introduce 'passthru' mode to takeover the underlying device"

    Signed-off-by: Jiri Pirko <jiri@resnulli.us>
    Acked-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1d81283ce68fb5f6841aeea620a133e5f9707e33
Author: Josh Boyer <jwboyer@redhat.com>
Date:   Wed May 8 09:45:47 2013 +0000

    if_cablemodem.h: Add parenthesis around ioctl macros

    [ Upstream commit 4f924b2aa4d3cb30f07e57d6b608838edcbc0d88 ]

    Protect the SIOCGCM* ioctl macros with parenthesis.

    Reported-by: Paul Wouters <pwouters@redhat.com>
    Signed-off-by: Josh Boyer <jwboyer@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cddd4b732be4dd206b99e25ac652db222d0ec2ba
Author: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Date:   Thu May 9 11:14:07 2013 +0000

    3c59x: fix PCI resource management

    [ Upstream commit 4b264a1676e70dc656ba53a8cac690f2d4b65f4e ]

    The driver wrongly claimed I/O ports at an address returned by pci_iomap() --
    even if it was passed an MMIO address.  Fix this by claiming/releasing all PCI
    resources in the PCI driver's probe()/remove() methods instead and get rid of
    'must_free_region' flag weirdness (why would Cardbus claim anything for us?).

    Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 20a7e697adea9e58ce7ad390ba487b995ebcbb1b
Author: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Date:   Thu May 2 11:10:22 2013 +0000

    3c59x: fix freeing nonexistent resource on driver unload

    [ Upstream commit c81400be716aa4c76f6ebf339ba94358dbbf6da6 ]

    When unloading the driver that drives an EISA board, a message similar to the
    following one is displayed:

    Trying to free nonexistent resource <0000000000013000-000000000001301f>

    Then an user is unable to reload the driver because the resource it requested in
    the previous load hasn't been freed. This happens most probably due to a typo in
    vortex_eisa_remove() which calls release_region() with 'dev->base_addr'  instead
    of 'edev->base_addr'...

    Reported-by: Matthew Whitehead <tedheadster@gmail.com>
    Tested-by: Matthew Whitehead <tedheadster@gmail.com>
    Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 577b25f2aaa4b24fcff8457b240fd3442a1dd87b
Author: stephen hemminger <stephen@networkplumber.org>
Date:   Thu May 2 14:23:28 2013 +0000

    bridge: fix race with topology change timer

    [ Upstream commit 83401eb4990ff6af55aeed8f49681558544192e6 ]

    A bridge should only send topology change notice if it is not
    the root bridge. It is possible for message age timer to elect itself
    as a new root bridge, and still have a topology change timer running
    but waiting for bridge lock on other CPU.

    Solve the race by checking if we are root bridge before continuing.
    This was the root cause of the cases where br_send_tcn_bpdu would OOPS.

    Reported-by: JerryKang <jerry.kang@samsung.com>
    Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 368a315a157cda317a468c6d075e7e6ce6920410
Author: Jamal Hadi Salim <jhs@mojatatu.com>
Date:   Sun Apr 28 05:06:38 2013 +0000

    net_sched: act_ipt forward compat with xtables

    [ Upstream commit 0dcffd09641f3abb21ac5cabc61542ab289d1a3c ]

    Deal with changes in newer xtables while maintaining backward
    compatibility. Thanks to Jan Engelhardt for suggestions.

    Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit be8fd5041900f0d8233ca61119477b28ca7df6e0
Author: Matthew Whitehead <tedheadster@gmail.com>
Date:   Mon Apr 29 17:46:53 2013 -0400

    3c509.c: call SET_NETDEV_DEV for all device types (ISA/ISAPnP/EISA)

    [ Upstream commit 3b54912f9cd167641b91d4a697bd742f70e534fe ]

    The venerable 3c509 driver only sets its device parent in one case, the ISAPnP one.
    It does this with the SET_NETDEV_DEV function. It should register with the device
    hierarchy in two additional cases: standard (non-PnP) ISA and EISA.

    - Currently they appear here:
    /sys/devices/virtual/net/eth0 (standard ISA)
    /sys/devices/virtual/net/eth1 (EISA)

    - Rather, they should instead be here:
    /sys/devices/isa/3c509.0/net/eth0 (standard ISA)
    /sys/devices/pci0000:00/0000:00:07.0/00:04/net/eth1 (EISA)

    Tested on ISA and EISA boards.

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

commit a0464b18acc3f17ff86aa25df34c5066a21c8291
Author: Eric Dumazet <edumazet@google.com>
Date:   Wed Apr 24 18:34:55 2013 -0700

    tcp: force a dst refcount when prequeue packet

    [ Upstream commit 093162553c33e9479283e107b4431378271c735d ]

    Before escaping RCU protected section and adding packet into
    prequeue, make sure the dst is refcounted.

    Reported-by: Mike Galbraith <bitbucket@online.de>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 875cfc6271a37f35f6334c26184b16eb70625929
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Sat Apr 20 12:08:11 2013 +0200

    drm/mm: fix dump table BUG

    commit 3a359f0b21ab218c1bf7a6a1b638b6fd143d0b99 upstream.

    In

    commit 9e8944ab564f2e3dde90a518cd32048c58918608
    Author: Chris Wilson <chris@chris-wilson.co.uk>
    Date:   Thu Nov 15 11:32:17 2012 +0000

        drm: Introduce an iterator over holes in the drm_mm range manager

    helpers and iterators for hole handling have been introduced with some
    debug BUG_ONs sprinkled over. Unfortunately this broke the mm dumper
    which unconditionally tried to compute the size of the very first
    hole.

    While at it unify the code a bit with the hole dumping in the loop.

    v2: Extract a hole dump helper.

    Reported-by: Christopher Harvey <charvey@matrox.com>
    Cc: Christopher Harvey <charvey@matrox.com>
    Cc: Dave Airlie <airlied@redhat.com>
    Cc: Chris Wilson <chris@chris-wilson.co.uk>
    Acked-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 483e107f172d8a120579ffe077f834304aa95599
Author: Daniel Drake <dsd@laptop.org>
Date:   Wed May 8 15:37:19 2013 -0400

    mwifiex: fix setting of multicast filter

    commit ccd384b10420ac81ba3fb9b0a7d18272c7173552 upstream.

    A small bug in this code was causing the ALLMULTI filter to be set
    when in fact we were just wanting to program a selective multicast list
    to the hardware.

    Fix that bug and remove a redundant if condition in the code that
    follows.

    This fixes wakeup behaviour when multicast WOL is enabled. Previously,
    all multicast packets would wake up the system. Now, only those that the
    host intended to receive trigger wakeups.

    Signed-off-by: Daniel Drake <dsd@laptop.org>
    Acked-by: Bing Zhao <bzhao@marvell.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a7cacebc8eed5136de20315d0dd8de300e5d18b3
Author: Bing Zhao <bzhao@marvell.com>
Date:   Mon May 6 19:46:53 2013 -0700

    mwifiex: clear is_suspended flag when interrupt is received early

    commit 48795424acff7215d5eac0b52793a2c1eb3a6283 upstream.

    When the XO-4 with 8787 wireless is woken up due to wake-on-WLAN
    mwifiex is often flooded with "not allowed while suspended" messages
    and the interface is unusable.

    [  202.171609] int: sdio_ireg = 0x1
    [  202.180700] info: mwifiex_process_hs_config: auto cancelling host
                   sleep since there is interrupt from the firmware
    [  202.201880] event: wakeup device...
    [  202.211452] event: hs_deactivated
    [  202.514638] info: --- Rx: Data packet ---
    [  202.514753] data: 4294957544 BSS(0-0): Data <= kernel
    [  202.514825] PREP_CMD: device in suspended state
    [  202.514839] data: dequeuing the packet ec7248c0 ec4869c0
    [  202.514886] mwifiex_write_data_sync: not allowed while suspended
    [  202.514886] host_to_card, write iomem (1) failed: -1
    [  202.514917] mwifiex_write_data_sync: not allowed while suspended
    [  202.514936] host_to_card, write iomem (2) failed: -1
    [  202.514949] mwifiex_write_data_sync: not allowed while suspended
    [  202.514965] host_to_card, write iomem (3) failed: -1
    [  202.514976] mwifiex_write_data_async failed: 0xFFFFFFFF

    This can be readily reproduced when putting the XO-4 in a loop where
    it goes to sleep due to inactivity, but then wakes up due to an
    incoming ping. The error is hit within an hour or two.

    This issue happens when an interrupt comes in early while host sleep
    is still activated. Driver handles this case by auto cancelling host
    sleep. However is_suspended flag is still set which prevents any cmd
    or data from being sent to firmware. Fix it by clearing is_suspended
    flag in this path.

    Reported-by: Daniel Drake <dsd@laptop.org>
    Tested-by: Daniel Drake <dsd@laptop.org>
    Signed-off-by: Bing Zhao <bzhao@marvell.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 61ed7336516e074d426f2f7c1e041846d7fa5c12
Author: Felix Fietkau <nbd@openwrt.org>
Date:   Sat Apr 27 11:47:01 2013 +0200

    ath9k: fix key allocation error handling for powersave keys

    commit 4ef69d0394cba8caa9f75d3f2e53429bfb8b3045 upstream.

    If no keycache slots are available, ath_key_config can return -ENOSPC.
    If the key index is not checked for errors, it can lead to logspam that
    looks like this: "ath: wiphy0: keyreset: keycache entry 228 out of range"
    This can cause follow-up errors if the invalid keycache index gets
    used for tx.

    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>

commit 7fb7465071b6f553c5c5cd8aca704cfc6896917c
Author: Lachlan McIlroy <lmcilroy@redhat.com>
Date:   Sun May 5 23:10:00 2013 -0400

    ext4: limit group search loop for non-extent files

    commit e6155736ad76b2070652745f9e54cdea3f0d8567 upstream.

    In the case where we are allocating for a non-extent file,
    we must limit the groups we allocate from to those below
    2^32 blocks, and ext4_mb_regular_allocator() attempts to
    do this initially by putting a cap on ngroups for the
    subsequent search loop.

    However, the initial target group comes in from the
    allocation context (ac), and it may already be beyond
    the artificially limited ngroups.  In this case,
    the limit

    	if (group == ngroups)
    		group = 0;

    at the top of the loop is never true, and the loop will
    run away.

    Catch this case inside the loop and reset the search to
    start at group 0.

    [sandeen@redhat.com: add commit msg & comments]

    Signed-off-by: Lachlan McIlroy <lmcilroy@redhat.com>
    Signed-off-by: Eric Sandeen <sandeen@redhat.com>
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b9cbfd27308999d2ae56d1d341a3a77f91d04a19
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Fri May 3 15:02:50 2013 +0200

    tick: Cleanup NOHZ per cpu data on cpu down

    commit 4b0c0f294f60abcdd20994a8341a95c8ac5eeb96 upstream.

    Prarit reported a crash on CPU offline/online. The reason is that on
    CPU down the NOHZ related per cpu data of the dead cpu is not cleaned
    up. If at cpu online an interrupt happens before the per cpu tick
    device is registered the irq_enter() check potentially sees stale data
    and dereferences a NULL pointer.

    Cleanup the data after the cpu is dead.

    Reported-by: Prarit Bhargava <prarit@redhat.com>
    Cc: Mike Galbraith <bitbucket@online.de>
    Link: http://lkml.kernel.org/r/alpine.LFD.2.02.1305031451561.2886@ionos
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e8934286bc36b73db88a361d31f8eb617ee5cf03
Author: Tirupathi Reddy <tirupath@codeaurora.org>
Date:   Tue May 14 13:59:02 2013 +0530

    timer: Don't reinitialize the cpu base lock during CPU_UP_PREPARE

    commit 42a5cf46cd56f46267d2a9fcf2655f4078cd3042 upstream.

    An inactive timer's base can refer to a offline cpu's base.

    In the current code, cpu_base's lock is blindly reinitialized each
    time a CPU is brought up. If a CPU is brought online during the period
    that another thread is trying to modify an inactive timer on that CPU
    with holding its timer base lock, then the lock will be reinitialized
    under its feet. This leads to following SPIN_BUG().

    <0> BUG: spinlock already unlocked on CPU#3, kworker/u:3/1466
    <0> lock: 0xe3ebe000, .magic: dead4ead, .owner: kworker/u:3/1466, .owner_cpu: 1
    <4> [<c0013dc4>] (unwind_backtrace+0x0/0x11c) from [<c026e794>] (do_raw_spin_unlock+0x40/0xcc)
    <4> [<c026e794>] (do_raw_spin_unlock+0x40/0xcc) from [<c076c160>] (_raw_spin_unlock+0x8/0x30)
    <4> [<c076c160>] (_raw_spin_unlock+0x8/0x30) from [<c009b858>] (mod_timer+0x294/0x310)
    <4> [<c009b858>] (mod_timer+0x294/0x310) from [<c00a5e04>] (queue_delayed_work_on+0x104/0x120)
    <4> [<c00a5e04>] (queue_delayed_work_on+0x104/0x120) from [<c04eae00>] (sdhci_msm_bus_voting+0x88/0x9c)
    <4> [<c04eae00>] (sdhci_msm_bus_voting+0x88/0x9c) from [<c04d8780>] (sdhci_disable+0x40/0x48)
    <4> [<c04d8780>] (sdhci_disable+0x40/0x48) from [<c04bf300>] (mmc_release_host+0x4c/0xb0)
    <4> [<c04bf300>] (mmc_release_host+0x4c/0xb0) from [<c04c7aac>] (mmc_sd_detect+0x90/0xfc)
    <4> [<c04c7aac>] (mmc_sd_detect+0x90/0xfc) from [<c04c2504>] (mmc_rescan+0x7c/0x2c4)
    <4> [<c04c2504>] (mmc_rescan+0x7c/0x2c4) from [<c00a6a7c>] (process_one_work+0x27c/0x484)
    <4> [<c00a6a7c>] (process_one_work+0x27c/0x484) from [<c00a6e94>] (worker_thread+0x210/0x3b0)
    <4> [<c00a6e94>] (worker_thread+0x210/0x3b0) from [<c00aad9c>] (kthread+0x80/0x8c)
    <4> [<c00aad9c>] (kthread+0x80/0x8c) from [<c000ea80>] (kernel_thread_exit+0x0/0x8)

    As an example, this particular crash occurred when CPU #3 is executing
    mod_timer() on an inactive timer whose base is refered to offlined CPU
    #2.  The code locked the timer_base corresponding to CPU #2. Before it
    could proceed, CPU #2 came online and reinitialized the spinlock
    corresponding to its base. Thus now CPU #3 held a lock which was
    reinitialized. When CPU #3 finally ended up unlocking the old cpu_base
    corresponding to CPU #2, we hit the above SPIN_BUG().

    CPU #0		CPU #3				       CPU #2
    ------		-------				       -------
    .....		 ......				      <Offline>
    		mod_timer()
    		 lock_timer_base
    		   spin_lock_irqsave(&base->lock)

    cpu_up(2)	 .....				        ......
    							init_timers_cpu()
    ....		 .....				    	spin_lock_init(&base->lock)
    .....		   spin_unlock_irqrestore(&base->lock)  ......
    		   <spin_bug>

    Allocation of per_cpu timer vector bases is done only once under
    "tvec_base_done[]" check. In the current code, spinlock_initialization
    of base->lock isn't under this check. When a CPU is up each time the
    base lock is reinitialized. Move base spinlock initialization under
    the check.

    Signed-off-by: Tirupathi Reddy <tirupath@codeaurora.org>
    Link: http://lkml.kernel.org/r/1368520142-4136-1-git-send-email-tirupath@codeaurora.org
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8ee29c2d66ae8aab9b28af5e83ec23dd99d8e500
Author: James Bottomley <JBottomley@Parallels.com>
Date:   Wed Apr 24 14:02:53 2013 -0700

    SCSI: sd: fix array cache flushing bug causing performance problems

    commit 39c60a0948cc06139e2fbfe084f83cb7e7deae3b upstream.

    Some arrays synchronize their full non volatile cache when the sd driver sends
    a SYNCHRONIZE CACHE command.  Unfortunately, they can have Terrabytes of this
    and we send a SYNCHRONIZE CACHE for every barrier if an array reports it has a
    writeback cache.  This leads to massive slowdowns on journalled filesystems.

    The fix is to allow userspace to turn off the writeback cache setting as a
    temporary measure (i.e. without doing the MODE SELECT to write it back to the
    device), so even though the device reported it has a writeback cache, the
    user, knowing that the cache is non volatile and all they care about is
    filesystem correctness, can turn that bit off in the kernel and avoid the
    performance ruinous (and safety irrelevant) SYNCHRONIZE CACHE commands.

    The way you do this is add a 'temporary' prefix when performing the usual
    cache setting operations, so

    echo temporary write through > /sys/class/scsi_disk/<disk>/cache_type

    Reported-by: Ric Wheeler <rwheeler@redhat.com>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a3b5b07e0d750c300d771a0a8e5ad24898bcdd9b
Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date:   Sun May 5 09:30:09 2013 -0400

    xen/vcpu/pvhvm: Fix vcpu hotplugging hanging.

    commit 7f1fc268c47491fd5e63548f6415fc8604e13003 upstream.

    If a user did:

    	echo 0 > /sys/devices/system/cpu/cpu1/online
    	echo 1 > /sys/devices/system/cpu/cpu1/online

    we would (this a build with DEBUG enabled) get to:
    smpboot: ++++++++++++++++++++=_---CPU UP  1
    .. snip..
    smpboot: Stack at about ffff880074c0ff44
    smpboot: CPU1: has booted.

    and hang. The RCU mechanism would kick in an try to IPI the CPU1
    but the IPIs (and all other interrupts) would never arrive at the
    CPU1. At first glance at least. A bit digging in the hypervisor
    trace shows that (using xenanalyze):

    [vla] d4v1 vec 243 injecting
       0.043163027 --|x d4v1 intr_window vec 243 src 5(vector) intr f3
    ]  0.043163639 --|x d4v1 vmentry cycles 1468
    ]  0.043164913 --|x d4v1 vmexit exit_reason PENDING_INTERRUPT eip ffffffff81673254
       0.043164913 --|x d4v1 inj_virq vec 243  real
      [vla] d4v1 vec 243 injecting
       0.043164913 --|x d4v1 intr_window vec 243 src 5(vector) intr f3
    ]  0.043165526 --|x d4v1 vmentry cycles 1472
    ]  0.043166800 --|x d4v1 vmexit exit_reason PENDING_INTERRUPT eip ffffffff81673254
       0.043166800 --|x d4v1 inj_virq vec 243  real
      [vla] d4v1 vec 243 injecting

    there is a pending event (subsequent debugging shows it is the IPI
    from the VCPU0 when smpboot.c on VCPU1 has done
    "set_cpu_online(smp_processor_id(), true)") and the guest VCPU1 is
    interrupted with the callback IPI (0xf3 aka 243) which ends up calling
    __xen_evtchn_do_upcall.

    The __xen_evtchn_do_upcall seems to do *something* but not acknowledge
    the pending events. And the moment the guest does a 'cli' (that is the
    ffffffff81673254 in the log above) the hypervisor is invoked again to
    inject the IPI (0xf3) to tell the guest it has pending interrupts.
    This repeats itself forever.

    The culprit was the per_cpu(xen_vcpu, cpu) pointer. At the bootup
    we set each per_cpu(xen_vcpu, cpu) to point to the
    shared_info->vcpu_info[vcpu] but later on use the VCPUOP_register_vcpu_info
    to register per-CPU  structures (xen_vcpu_setup).
    This is used to allow events for more than 32 VCPUs and for performance
    optimizations reasons.

    When the user performs the VCPU hotplug we end up calling the
    the xen_vcpu_setup once more. We make the hypercall which returns
    -EINVAL as it does not allow multiple registration calls (and
    already has re-assigned where the events are being set). We pick
    the fallback case and set per_cpu(xen_vcpu, cpu) to point to the
    shared_info->vcpu_info[vcpu] (which is a good fallback during bootup).
    However the hypervisor is still setting events in the register
    per-cpu structure (per_cpu(xen_vcpu_info, cpu)).

    As such when the events are set by the hypervisor (such as timer one),
    and when we iterate in __xen_evtchn_do_upcall we end up reading stale
    events from the shared_info->vcpu_info[vcpu] instead of the
    per_cpu(xen_vcpu_info, cpu) structures. Hence we never acknowledge the
    events that the hypervisor has set and the hypervisor keeps on reminding
    us to ack the events which we never do.

    The fix is simple. Don't on the second time when xen_vcpu_setup is
    called over-write the per_cpu(xen_vcpu, cpu) if it points to
    per_cpu(xen_vcpu_info).

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

commit 37cc8ba179a6e326d9074b23e8bccdf4cadd6b58
Author: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Date:   Fri May 10 14:37:15 2013 +0100

    dm snapshot: fix error return code in snapshot_ctr

    commit 09e8b813897a0f85bb401435d009228644c81214 upstream.

    Return -ENOMEM instead of success if unable to allocate pending
    exception mempool in snapshot_ctr.

    Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
    Signed-off-by: Alasdair G Kergon <agk@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 94adafe60f4a1ed621da67dde6cc457fd5255e18
Author: Bob Moore <robert.moore@intel.com>
Date:   Wed May 8 04:01:15 2013 +0000

    ACPICA: Fix possible buffer overflow during a field unit read operation

    commit 61388f9e5d93053cf399a356414f31f9b4814c6d upstream.

    Can only happen under these conditions: 1) The DSDT version is 1,
    meaning integers are 32-bits.  2) The field is between 33 and 64
    bits long.

    It applies cleanly back to ACPICA 20100806+ (Linux v2.6.37+).

    Signed-off-by: Bob Moore <robert.moore@intel.com>
    Signed-off-by: Lv Zheng <lv.zheng@intel.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8856cb69e794e8554109aef2568817a304b70ae7
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Tue Apr 30 10:24:41 2013 +0300

    ASoC: wm8994: missing break in wm8994_aif3_hw_params()

    commit 4495e46fe18f198366961bb2b324a694ef8a9b44 upstream.

    The missing break here means that we always return early and the
    function is a no-op.

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

commit f3fb49dfccbf7bb7005bd57bb7385c3ee80d8c52
Author: Aaro Koskinen <aaro.koskinen@iki.fi>
Date:   Wed May 8 16:48:00 2013 -0700

    ARM: OMAP: RX-51: change probe order of touchscreen and panel SPI devices

    commit e65f131a14726e5f1b880a528271a52428e5b3a5 upstream.

    Commit 9fdca9df (spi: omap2-mcspi: convert to module_platform_driver)
    broke the SPI display/panel driver probe on RX-51/N900. The exact cause is
    not fully understood, but it seems to be related to the probe order. SPI
    communication to the panel driver (spi1.2) fails unless the touchscreen
    (spi1.0) has been probed/initialized before. When the omap2-mcspi driver
    was converted to a platform driver, it resulted in that the devices are
    probed immediately after the board registers them in the order they are
    listed in the board file.

    Fix the issue by moving the touchscreen before the panel in the SPI
    device list.

    The patch fixes the following failure:

    [    1.260955] acx565akm spi1.2: invalid display ID
    [    1.265899] panel-acx565akm display0: acx_panel_probe panel detect error
    [    1.273071] omapdss CORE error: driver probe failed: -19

    Tested-by: Sebastian Reichel <sre@debian.org>
    Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi>
    Cc: Pali Rohár <pali.rohar@gmail.com>
    Cc: Joni Lapilainen <joni.lapilainen@gmail.com>
    Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
    Cc: Felipe Balbi <balbi@ti.com>
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e171327c07f33c79dab763e08feb7b0ad24dfe71
Author: Gleb Natapov <gleb@redhat.com>
Date:   Wed May 8 18:38:44 2013 +0300

    KVM: VMX: fix halt emulation while emulating invalid guest sate

    commit 8d76c49e9ffeee839bc0b7a3278a23f99101263e upstream.

    The invalid guest state emulation loop does not check halt_request
    which causes 100% cpu loop while guest is in halt and in invalid
    state, but more serious issue is that this leaves halt_request set, so
    random instruction emulated by vm86 #GP exit can be interpreted
    as halt which causes guest hang. Fix both problems by handling
    halt_request in emulation loop.

    Reported-by: Tomas Papan <tomas.papan@gmail.com>
    Tested-by: Tomas Papan <tomas.papan@gmail.com>
    Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Gleb Natapov <gleb@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Change-Id: If8759cb4ac5539af542c51863497a2bbb56ab81c
Linux 3.0.80

commit f9429439e89dd9e7440de0334f3eefcd3a37adf4
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Fri May 24 11:09:48 2013 -0700

    Linux 3.0.80

commit e51c0ea1c933d98e3f0ea5bf0a8a3149475cf0a1
Author: Alan Cox <alan@linux.intel.com>
Date:   Thu Aug 9 12:33:52 2012 -0300

    media: mantis: fix silly crash case

    commit e1d45ae10aea8e8a403e5d96bf5902ee670007ff upstream.

    If we set mantis->fe to NULL on an error its not a good idea to then try
    passing NULL to the unregister paths and oopsing really.

    Resolves-bug: https://bugzilla.kernel.org/show_bug.cgi?id=16473

    Signed-off-by: Alan Cox <alan@linux.intel.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
    Cc: Bjørn Mork <bjorn@mork.no>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 38180ec039a7589112633b85b2cfab72a76ec9c0
Author: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Date:   Mon May 13 14:01:43 2013 +0800

    hwmon: fix error return code in abituguru_probe()

    commit ecacb0b17c08fae89f65468727f0e4b8e91da4e1 upstream.

    Fix to return a negative error code from the error handling
    case instead of 0, as done elsewhere in this function.

    Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3f9831881378bae530028b35a7a06c811441162d
Author: Gabriel de Perthuis <g2p.code@gmail.com>
Date:   Mon May 6 17:40:18 2013 +0000

    btrfs: don't stop searching after encountering the wrong item

    commit 03b71c6ca6286625d8f1ed44aabab9b5bf5dac10 upstream.

    The search ioctl skips items that are too large for a result buffer, but
    inline items of a certain size occuring before any search result is
    found would trigger an overflow and stop the search entirely.

    Bug: https://bugzilla.kernel.org/show_bug.cgi?id=57641

    Signed-off-by: Gabriel de Perthuis <g2p.code+btrfs@gmail.com>
    Signed-off-by: Josef Bacik <jbacik@fusionio.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Linux 3.0.81

commit 1e18293a23fdc4e28b07302ad6a5ed99f7a26348
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Fri Jun 7 12:46:53 2013 -0700

    Linux 3.0.81

commit 48bcd39b354548d556911373d6c7f3ecfca9d043
Author: Manoj Iyer <manoj.iyer@canonical.com>
Date:   Mon Aug 6 18:15:37 2012 -0500

    thinkpad-acpi: recognize latest V-Series using DMI_BIOS_VENDOR

    commit a4f46bb9fa84642e356898ee44b670989622f8bb upstream.

    In the latest V-series bios DMI_PRODUCT_VERSION does not contain
    the string Lenovo or Thinkpad, but is set to the model number, this
    causes the thinkpad_acpi module to fail to load. Recognize laptop
    as Lenovo using DMI_BIOS_VENDOR instead, which is set to Lenovo.

    Test on V490u
    =============
    == After the patch ==

    [ 1350.295757] thinkpad_acpi: ThinkPad ACPI Extras v0.24
    [ 1350.295760] thinkpad_acpi: http://ibm-acpi.sf.net/
    [ 1350.295761] thinkpad_acpi: ThinkPad BIOS H7ET21WW (1.00 ), EC unknown
    [ 1350.295763] thinkpad_acpi: Lenovo LENOVO, model LV5DXXX
    [ 1350.296086] thinkpad_acpi: detected a 8-level brightness capable ThinkPad
    [ 1350.296694] thinkpad_acpi: radio switch found; radios are enabled
    [ 1350.296703] thinkpad_acpi: possible tablet mode switch found; ThinkPad in laptop mode
    [ 1350.306466] thinkpad_acpi: rfkill switch tpacpi_bluetooth_sw: radio is unblocked
    [ 1350.307082] Registered led device: tpacpi::thinklight
    [ 1350.307215] Registered led device: tpacpi::power
    [ 1350.307255] Registered led device: tpacpi::standby
    [ 1350.307294] Registered led device: tpacpi::thinkvantage
    [ 1350.308160] thinkpad_acpi: Standard ACPI backlight interface available, not loading native one
    [ 1350.308333] thinkpad_acpi: Console audio control enabled, mode: monitor (read only)
    [ 1350.312287] input: ThinkPad Extra Buttons as /devices/platform/thinkpad_acpi/input/input14

    == Before the patch ==
    sudo modprobe thinkpad_acpi
    FATAL: Error inserting thinkpad_acpi (/lib/modules/3.2.0-27-generic/kernel/drivers/platform/x86/thinkpad_acpi.ko): No such device

    Test on B485
    =============
    This patch was also test in a B485 where the thinkpad_acpi module does not
    have any issues loading. But, I tested it to make sure this patch does not
    break on already functioning models of Lenovo products.

    [13486.746359] thinkpad_acpi: ThinkPad ACPI Extras v0.24
    [13486.746364] thinkpad_acpi: http://ibm-acpi.sf.net/
    [13486.746368] thinkpad_acpi: ThinkPad BIOS HJET15WW(1.01), EC unknown
    [13486.746373] thinkpad_acpi: Lenovo Lenovo LB485, model 814TR01
    [13486.747300] thinkpad_acpi: detected a 8-level brightness capable ThinkPad
    [13486.752435] thinkpad_acpi: rfkill switch tpacpi_bluetooth_sw: radio is unblocked
    [13486.752883] Registered led device: tpacpi::thinklight
    [13486.752915] thinkpad_acpi: Standard ACPI backlight interface available, not loading native one
    [13486.753216] thinkpad_acpi: Console audio control enabled, mode: monitor (read only)
    [13486.757147] input: ThinkPad Extra Buttons as /devices/platform/thinkpad_acpi/input/input15

    Signed-off-by: Manoj Iyer <manoj.iyer@canonical.com>
    Signed-off-by: Matthew Garrett <mjg@redhat.com>
    Cc: Shuduo Sang <shuduo.sang@canonical.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2ea00641254d9e6d3e84b6f2f1b295563d3e95e6
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Fri May 24 01:06:09 2013 +0200

    mac80211: close AP_VLAN interfaces before unregistering all

    commit c8aa22db0112f640ac6631347f850879c621840b upstream.

    Since Eric's commit efe117ab8 ("Speedup ieee80211_remove_interfaces")
    there's a bug in mac80211 when it unregisters with AP_VLAN interfaces
    up. If the AP_VLAN interface was registered after the AP it belongs
    to (which is the typical case) and then we get into this code path,
    unregister_netdevice_many() will crash because it isn't prepared to
    deal with interfaces being closed in the middle of it. Exactly this
    happens though, because we iterate the list, find the AP master this
    AP_VLAN belongs to and dev_close() the dependent VLANs. After this,
    unregister_netdevice_many() won't pick up the fact that the AP_VLAN
    is already down and will do it again, causing a crash.

    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Cc: Eric Dumazet <eric.dumazet@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 93a327fcdef0c9e089ba7b347780cf9eaa92677f
Author: Xi Wang <xi.wang@gmail.com>
Date:   Tue Feb 14 05:18:48 2012 -0500

    ALSA: usb-audio: avoid integer overflow in create_fixed_stream_quirk()

    commit 8866f405efd4171f9d9c91901d2dd02f01bacb60 upstream.

    A malicious USB device could feed in a large nr_rates value.  This would
    cause the subsequent call to kmemdup() to allocate a smaller buffer than
    expected, leading to out-of-bounds access.

    This patch validates the nr_rates value and reuses the limit introduced
    in commit 4fa0e81b ("ALSA: usb-audio: fix possible hang and overflow
    in parse_uac2_sample_rate_range()").

    Signed-off-by: Xi Wang <xi.wang@gmail.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Cc: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 44f059fb742aac78cffdab5e0d8fe0c9910c1ded
Author: Xi Wang <xi.wang@gmail.com>
Date:   Sun Jan 8 09:02:52 2012 -0500

    ALSA: usb-audio: fix possible hang and overflow in parse_uac2_sample_rate_range()

    commit 4fa0e81b83503900be277e6273a79651b375e288 upstream.

    A malicious USB device may feed in carefully crafted min/max/res values,
    so that the inner loop in parse_uac2_sample_rate_range() could run for
    a long time or even never terminate, e.g., given max = INT_MAX.

    Also nr_rates could be a large integer, which causes an integer overflow
    in the subsequent call to kmalloc() in parse_audio_format_rates_v2().
    Thus, kmalloc() would allocate a smaller buffer than expected, leading
    to a memory corruption.

    To exploit the two vulnerabilities, an attacker needs physical access
    to the machine to plug in a malicious USB device.

    This patch makes two changes.

    1) The type of "rate" is changed to unsigned int, so that the loop could
       stop once "rate" is larger than INT_MAX.

    2) Limit nr_rates to 1024.

    Suggested-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Xi Wang <xi.wang@gmail.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Cc: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3b1a317977a8d16d743e8f85ed9a5a7f668b61d5
Author: Dave Kleikamp <dave.kleikamp@oracle.com>
Date:   Wed May 1 11:08:38 2013 -0500

    jfs: fix a couple races

    commit 73aaa22d5ffb2630456bac2f9a4ed9b81d0d7271 upstream.

    This patch fixes races uncovered by xfstests testcase 068.

    One race is the result of jfs_sync() trying to write a sync point to the
    journal after it has been frozen (or possibly in the process). Since
    freezing sync's the journal, there is no need to write a sync point so
    we simply want to return.

    The second involves jfs_write_inode() being called on a deleted inode.
    It calls jfs_flush_journal which is held up by the jfs_commit thread
    doing the final iput on the same deleted inode, which itself is
    waiting for the I_SYNC flag to be cleared. jfs_write_inode need not
    do anything when i_nlink is zero, which is the easy fix.

    Reported-by: Michael L. Semon <mlsemon35@gmail.com>
    Signed-off-by: Dave Kleikamp <dave.kleikamp@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3a6b9138a066588649cf0387bf34d7068f0b19a6
Author: Keir Fraser <keir.fraser@citrix.com>
Date:   Thu Mar 28 10:03:36 2013 -0400

    xen/events: Handle VIRQ_TIMER before any other hardirq in event loop.

    commit bee980d9e9642e96351fa3ca9077b853ecf62f57 upstream.

    This avoids any other hardirq handler seeing a very stale jiffies
    value immediately after wakeup from a long idle period. The one
    observable symptom of this was a USB keyboard, with software keyboard
    repeat, which would always repeat a key immediately that it was
    pressed. This is due to the key press waking the guest, the key
    handler immediately runs, sees an old jiffies value, and then that
    jiffies value significantly updated, before the key is unpressed.

    Reviewed-by: David Vrabel <david.vrabel@citrix.com>
    Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cd6b18b0605a8a6355d6b838296926b12d548df3
Author: Vincent Pelletier <plr.vincent@gmail.com>
Date:   Sat May 18 18:44:04 2013 +0200

    libata: make ata_exec_internal_sg honor DMADIR

    commit e771451c0a831d96a7c14b0ca8a8ec671d98567b upstream.

    libata honors DMADIR for regular commands, but not for internal commands
    used (among other) during device initialisation.

    This makes SATA-host-to-PATA-device bridges based on Silicon Image SiL3611
    (such as "Abit Serillel 2") end up disabled when used with an ATAPI device
    after a few tries.

    Log output of the bridge being hot-plugged with an ATAPI drive:

      [ 9631.212901] ata1: exception Emask 0x10 SAct 0x0 SErr 0x40c0000 action 0xe frozen
      [ 9631.212913] ata1: irq_stat 0x00000040, connection status changed
      [ 9631.212923] ata1: SError: { CommWake 10B8B DevExch }
      [ 9631.212939] ata1: hard resetting link
      [ 9632.104962] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
      [ 9632.106393] ata1.00: ATAPI: PIONEER DVD-RW  DVR-115, 1.06, max UDMA/33
      [ 9632.106407] ata1.00: applying bridge limits
      [ 9632.108151] ata1.00: configured for UDMA/33
      [ 9637.105303] ata1.00: qc timeout (cmd 0xa0)
      [ 9637.105324] ata1.00: failed to clear UNIT ATTENTION (err_mask=0x5)
      [ 9637.105335] ata1: hard resetting link
      [ 9638.044599] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
      [ 9638.047878] ata1.00: configured for UDMA/33
      [ 9643.044933] ata1.00: qc timeout (cmd 0xa0)
      [ 9643.044953] ata1.00: failed to clear UNIT ATTENTION (err_mask=0x5)
      [ 9643.044963] ata1: limiting SATA link speed to 1.5 Gbps
      [ 9643.044971] ata1.00: limiting speed to UDMA/33:PIO3
      [ 9643.044979] ata1: hard resetting link
      [ 9643.984225] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
      [ 9643.987471] ata1.00: configured for UDMA/33
      [ 9648.984591] ata1.00: qc timeout (cmd 0xa0)
      [ 9648.984612] ata1.00: failed to clear UNIT ATTENTION (err_mask=0x5)
      [ 9648.984619] ata1.00: disabled
      [ 9649.000593] ata1: hard resetting link
      [ 9649.939902] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
      [ 9649.955864] ata1: EH complete

    With this patch, the drive enumerates correctly when libata is loaded with
    atapi_dmadir=1:

      [ 9891.810863] ata1: exception Emask 0x10 SAct 0x0 SErr 0x40c0000 action 0xe frozen
      [ 9891.810874] ata1: irq_stat 0x00000040, connection status changed
      [ 9891.810884] ata1: SError: { CommWake 10B8B DevExch }
      [ 9891.810900] ata1: hard resetting link
      [ 9892.762105] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
      [ 9892.763544] ata1.00: ATAPI: PIONEER DVD-RW  DVR-115, 1.06, max UDMA/33, DMADIR
      [ 9892.763558] ata1.00: applying bridge limits
      [ 9892.765393] ata1.00: configured for UDMA/33
      [ 9892.786063] ata1: EH complete
      [ 9892.792062] scsi 0:0:0:0: CD-ROM            PIONEER  DVD-RW  DVR-115  1.06 PQ: 0 ANSI: 5
      [ 9892.798455] sr2: scsi3-mmc drive: 12x/12x writer dvd-ram cd/rw xa/form2 cdda tray
      [ 9892.798837] sr 0:0:0:0: Attached scsi CD-ROM sr2
      [ 9892.799109] sr 0:0:0:0: Attached scsi generic sg6 type 5

    Based on a patch by Csaba Halász <csaba.halasz@gmail.com> on linux-ide:
    http://marc.info/?l=linux-ide&m=136121147832295&w=2

    tj: minor formatting changes.

    Signed-off-by: Vincent Pelletier <plr.vincent@gmail.com>
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2af3ee134e1c73c6ab72e958495cee9c238845b0
Author: Wolfgang Frisch <wfpub@roembden.net>
Date:   Thu Jan 17 01:07:02 2013 +0100

    USB: io_ti: Fix NULL dereference in chase_port()

    commit 1ee0a224bc9aad1de496c795f96bc6ba2c394811 upstream.

    The tty is NULL when the port is hanging up.
    chase_port() needs to check for this.

    This patch is intended for stable series.
    The behavior was observed and tested in Linux 3.2 and 3.7.1.

    Johan Hovold submitted a more elaborate patch for the mainline kernel.

    [   56.277883] usb 1-1: edge_bulk_in_callback - nonzero read bulk status received: -84
    [   56.278811] usb 1-1: USB disconnect, device number 3
    [   56.278856] usb 1-1: edge_bulk_in_callback - stopping read!
    [   56.279562] BUG: unable to handle kernel NULL pointer dereference at 00000000000001c8
    [   56.280536] IP: [<ffffffff8144e62a>] _raw_spin_lock_irqsave+0x19/0x35
    [   56.281212] PGD 1dc1b067 PUD 1e0f7067 PMD 0
    [   56.282085] Oops: 0002 [#1] SMP
    [   56.282744] Modules linked in:
    [   56.283512] CPU 1
    [   56.283512] Pid: 25, comm: khubd Not tainted 3.7.1 #1 innotek GmbH VirtualBox/VirtualBox
    [   56.283512] RIP: 0010:[<ffffffff8144e62a>]  [<ffffffff8144e62a>] _raw_spin_lock_irqsave+0x19/0x35
    [   56.283512] RSP: 0018:ffff88001fa99ab0  EFLAGS: 00010046
    [   56.283512] RAX: 0000000000000046 RBX: 00000000000001c8 RCX: 0000000000640064
    [   56.283512] RDX: 0000000000010000 RSI: ffff88001fa99b20 RDI: 00000000000001c8
    [   56.283512] RBP: ffff88001fa99b20 R08: 0000000000000000 R09: 0000000000000000
    [   56.283512] R10: 0000000000000000 R11: ffffffff812fcb4c R12: ffff88001ddf53c0
    [   56.283512] R13: 0000000000000000 R14: 00000000000001c8 R15: ffff88001e19b9f4
    [   56.283512] FS:  0000000000000000(0000) GS:ffff88001fd00000(0000) knlGS:0000000000000000
    [   56.283512] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
    [   56.283512] CR2: 00000000000001c8 CR3: 000000001dc51000 CR4: 00000000000006e0
    [   56.283512] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    [   56.283512] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
    [   56.283512] Process khubd (pid: 25, threadinfo ffff88001fa98000, task ffff88001fa94f80)
    [   56.283512] Stack:
    [   56.283512]  0000000000000046 00000000000001c8 ffffffff810578ec ffffffff812fcb4c
    [   56.283512]  ffff88001e19b980 0000000000002710 ffffffff812ffe81 0000000000000001
    [   56.283512]  ffff88001fa94f80 0000000000000202 ffffffff00000001 0000000000000296
    [   56.283512] Call Trace:
    [   56.283512]  [<ffffffff810578ec>] ? add_wait_queue+0x12/0x3c
    [   56.283512]  [<ffffffff812fcb4c>] ? usb_serial_port_work+0x28/0x28
    [   56.283512]  [<ffffffff812ffe81>] ? chase_port+0x84/0x2d6
    [   56.283512]  [<ffffffff81063f27>] ? try_to_wake_up+0x199/0x199
    [   56.283512]  [<ffffffff81263a5c>] ? tty_ldisc_hangup+0x222/0x298
    [   56.283512]  [<ffffffff81300171>] ? edge_close+0x64/0x129
    [   56.283512]  [<ffffffff810612f7>] ? __wake_up+0x35/0x46
    [   56.283512]  [<ffffffff8106135b>] ? should_resched+0x5/0x23
    [   56.283512]  [<ffffffff81264916>] ? tty_port_shutdown+0x39/0x44
    [   56.283512]  [<ffffffff812fcb4c>] ? usb_serial_port_work+0x28/0x28
    [   56.283512]  [<ffffffff8125d38c>] ? __tty_hangup+0x307/0x351
    [   56.283512]  [<ffffffff812e6ddc>] ? usb_hcd_flush_endpoint+0xde/0xed
    [   56.283512]  [<ffffffff8144e625>] ? _raw_spin_lock_irqsave+0x14/0x35
    [   56.283512]  [<ffffffff812fd361>] ? usb_serial_disconnect+0x57/0xc2
    [   56.283512]  [<ffffffff812ea99b>] ? usb_unbind_interface+0x5c/0x131
    [   56.283512]  [<ffffffff8128d738>] ? __device_release_driver+0x7f/0xd5
    [   56.283512]  [<ffffffff8128d9cd>] ? device_release_driver+0x1a/0x25
    [   56.283512]  [<ffffffff8128d393>] ? bus_remove_device+0xd2/0xe7
    [   56.283512]  [<ffffffff8128b7a3>] ? device_del+0x119/0x167
    [   56.283512]  [<ffffffff812e8d9d>] ? usb_disable_device+0x6a/0x180
    [   56.283512]  [<ffffffff812e2ae0>] ? usb_disconnect+0x81/0xe6
    [   56.283512]  [<ffffffff812e4435>] ? hub_thread+0x577/0xe82
    [   56.283512]  [<ffffffff8144daa7>] ? __schedule+0x490/0x4be
    [   56.283512]  [<ffffffff8105798f>] ? abort_exclusive_wait+0x79/0x79
    [   56.283512]  [<ffffffff812e3ebe>] ? usb_remote_wakeup+0x2f/0x2f
    [   56.283512]  [<ffffffff812e3ebe>] ? usb_remote_wakeup+0x2f/0x2f
    [   56.283512]  [<ffffffff810570b4>] ? kthread+0x81/0x89
    [   56.283512]  [<ffffffff81057033>] ? __kthread_parkme+0x5c/0x5c
    [   56.283512]  [<ffffffff8145387c>] ? ret_from_fork+0x7c/0xb0
    [   56.283512]  [<ffffffff81057033>] ? __kthread_parkme+0x5c/0x5c
    [   56.283512] Code: 8b 7c 24 08 e8 17 0b c3 ff 48 8b 04 24 48 83 c4 10 c3 53 48 89 fb 41 50 e8 e0 0a c3 ff 48 89 04 24 e8 e7 0a c3 ff ba 00 00 01 00
    <f0> 0f c1 13 48 8b 04 24 89 d1 c1 ea 10 66 39 d1 74 07 f3 90 66
    [   56.283512] RIP  [<ffffffff8144e62a>] _raw_spin_lock_irqsave+0x19/0x35
    [   56.283512]  RSP <ffff88001fa99ab0>
    [   56.283512] CR2: 00000000000001c8
    [   56.283512] ---[ end trace 49714df27e1679ce ]---

    Signed-off-by: Wolfgang Frisch <wfpub@roembden.net>
    Cc: Johan Hovold <jhovold@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1b968601f5b7e98cf519684589f853768d377144
Author: Jeff Layton <jlayton@redhat.com>
Date:   Fri May 24 07:40:04 2013 -0400

    cifs: fix potential buffer overrun when composing a new options string

    commit 166faf21bd14bc5c5295a44874bf7f3930c30b20 upstream.

    Consider the case where we have a very short ip= string in the original
    mount options, and when we chase a referral we end up with a very long
    IPv6 address. Be sure to allow for that possibility when estimating the
    size of the string to allocate.

    Signed-off-by: Jeff Layton <jlayton@redhat.com>
    Signed-off-by: Steve French <sfrench@us.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2b23550e4d01f4c0c1560c899db43e1a63f7ccd0
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Wed May 22 11:22:51 2013 -0400

    drm/radeon: fix card_posted check for newer asics

    commit 09fb8bd1a63b0f9f15e655c4fe8d047e5d2bf67a upstream.

    Newer asics have variable numbers of crtcs.  Use that
    rather than the asic family to determine which crtcs
    to check.  This avoids checking non-existent crtcs or
    missing crtcs on certain asics.

    Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9392bf7c8a7fd63c1ff1dbba237d67b95dae5cf9
Author: Richard Weinberger <richard@nod.at>
Date:   Tue Feb 7 01:22:47 2012 +0100

    um: Serve io_remap_pfn_range()

    commit 4d94d6d030adfdea4837694d293ec6918d133ab2 upstream.

    At some places io_remap_pfn_range() is needed.
    UML has to serve it like all other archs do.

    Signed-off-by: Richard Weinberger <richard@nod.at>
    Tested-by: Antoine Martin <antoine@nagafix.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2f28357cd8f0be2c507d3a7d6f79c0cca0d7f9ce
Author: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Date:   Fri May 24 15:55:21 2013 -0700

    mm/THP: use pmd_populate() to update the pmd with pgtable_t pointer

    commit 7c3425123ddfdc5f48e7913ff59d908789712b18 upstream.

    We should not use set_pmd_at to update pmd_t with pgtable_t pointer.
    set_pmd_at is used to set pmd with huge pte entries and architectures
    like ppc64, clear few flags from the pte when saving a new entry.
    Without this change we observe bad pte errors like below on ppc64 with
    THP enabled.

      BUG: Bad page map in process ld mm=0xc000001ee39f4780 pte:7fc3f37848000001 pmd:c000001ec0000000

    Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
    Cc: Hugh Dickins <hughd@google.com>
    Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Reviewed-by: Andrea Arcangeli <aarcange@redhat.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 77809457d14ff89ac8e67f3cdf45a43b2b620f82
Author: Brian Behlendorf <behlendorf1@llnl.gov>
Date:   Fri May 24 15:55:28 2013 -0700

    drivers/block/brd.c: fix brd_lookup_page() race

    commit dfd20b2b174d3a9b258ea3b7a35ead33576587b1 upstream.

    The index on the page must be set before it is inserted in the radix
    tree.  Otherwise there is a small race which can occur during lookup
    where the page can be found with the incorrect index.  This will trigger
    the BUG_ON() in brd_lookup_page().

    Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
    Reported-by: Chris Wedgwood <cw@f00f.org>
    Cc: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 329d6f2ca0653e8a078637ed42ba259f5414e872
Author: Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>
Date:   Fri May 24 15:55:11 2013 -0700

    mm: mmu_notifier: re-fix freed page still mapped in secondary MMU

    commit d34883d4e35c0a994e91dd847a82b4c9e0c31d83 upstream.

    Commit 751efd8610d3 ("mmu_notifier_unregister NULL Pointer deref and
    multiple ->release()") breaks the fix 3ad3d901bbcf ("mm: mmu_notifier:
    fix freed page still mapped in secondary MMU").

    Since hlist_for_each_entry_rcu() is changed now, we can not revert that
    patch directly, so this patch reverts the commit and simply fix the bug
    spotted by that patch

    This bug spotted by commit 751efd8610d3 is:

        There is a race condition between mmu_notifier_unregister() and
        __mmu_notifier_release().

        Assume two tasks, one calling mmu_notifier_unregister() as a result
        of a filp_close() ->flush() callout (task A), and the other calling
        mmu_notifier_release() from an mmput() (task B).

                            A                               B
        t1                                            srcu_read_lock()
        t2            if (!hlist_unhashed())
        t3                                            srcu_read_unlock()
        t4            srcu_read_lock()
        t5                                            hlist_del_init_rcu()
        t6                                            synchronize_srcu()
        t7            srcu_read_unlock()
        t8            hlist_del_rcu()  <--- NULL pointer deref.

    This can be fixed by using hlist_del_init_rcu instead of hlist_del_rcu.

    The another issue spotted in the commit is "multiple ->release()
    callouts", we needn't care it too much because it is really rare (e.g,
    can not happen on kvm since mmu-notify is unregistered after
    exit_mmap()) and the later call of multiple ->release should be fast
    since all the pages have already been released by the first call.
    Anyway, this issue should be fixed in a separate patch.

    -stable suggestions: Any version that has commit 751efd8610d3 need to be
    backported.  I find the oldest version has this commit is 3.0-stable.

    [akpm@linux-foundation.org: tweak comments]
    Signed-off-by: Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>
    Tested-by: Robin Holt <holt@sgi.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ed2bfaffd22f37e669feea0a97ab81d187ccb768
Author: Ryusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>
Date:   Fri May 24 15:55:29 2013 -0700

    nilfs2: fix issue of nilfs_set_page_dirty() for page at EOF boundary

    commit 136e8770cd5d1fe38b3c613100dd6dc4db6d4fa6 upstream.

    nilfs2: fix issue of nilfs_set_page_dirty for page at EOF boundary

    DESCRIPTION:
     There are use-cases when NILFS2 file system (formatted with block size
    lesser than 4 KB) can be remounted in RO mode because of encountering of
    "broken bmap" issue.

    The issue was reported by Anthony Doggett <Anthony2486@interfaces.org.uk>:
     "The machine I've been trialling nilfs on is running Debian Testing,
      Linux version 3.2.0-4-686-pae (debian-kernel@lists.debian.org) (gcc
      version 4.6.3 (Debian 4.6.3-14) ) #1 SMP Debian 3.2.35-2), but I've
      also reproduced it (identically) with Debian Unstable amd64 and Debian
      Experimental (using the 3.8-trunk kernel).  The problematic partitions
      were formatted with "mkfs.nilfs2 -b 1024 -B 8192"."

    SYMPTOMS:
    (1) System log contains error messages likewise:

        [63102.496756] nilfs_direct_assign: invalid pointer: 0
        [63102.496786] NILFS error (device dm-17): nilfs_bmap_assign: broken bmap (inode number=28)
        [63102.496798]
        [63102.524403] Remounting filesystem read-only

    (2) The NILFS2 file system is remounted in RO mode.

    REPRODUSING PATH:
    (1) Create volume group with name "unencrypted" by means of vgcreate utility.
    (2) Run script (prepared by Anthony Doggett <Anthony2486@interfaces.org.uk>):

    ----------------[BEGIN SCRIPT]--------------------

    VG=unencrypted
    lvcreate --size 2G --name ntest $VG
    mkfs.nilfs2 -b 1024 -B 8192 /dev/mapper/$VG-ntest
    mkdir /var/tmp/n
    mkdir /var/tmp/n/ntest
    mount /dev/mapper/$VG-ntest /var/tmp/n/ntest
    mkdir /var/tmp/n/ntest/thedir
    cd /var/tmp/n/ntest/thedir
    sleep 2
    date
    darcs init
    sleep 2
    dmesg|tail -n 5
    date
    darcs whatsnew || true
    date
    sleep 2
    dmesg|tail -n 5
    ----------------[END SCRIPT]--------------------

    REPRODUCIBILITY: 100%

    INVESTIGATION:
    As it was discovered, the issue takes place during segment
    construction after executing such sequence of user-space operations:

      open("_darcs/index", O_RDWR|O_CREAT|O_NOCTTY, 0666) = 7
      fstat(7, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
      ftruncate(7, 60)

    The error message "NILFS error (device dm-17): nilfs_bmap_assign: broken
    bmap (inode number=28)" takes place because of trying to get block
    number for third block of the file with logical offset #3072 bytes.  As
    it is possible to see from above output, the file has 60 bytes of the
    whole size.  So, it is enough one block (1 KB in size) allocation for
    the whole file.  Trying to operate with several blocks instead of one
    takes place because of discovering several dirty buffers for this file
    in nilfs_segctor_scan_file() method.

    The root cause of this issue is in nilfs_set_page_dirty function which
    is called just before writing to an mmapped page.

    When nilfs_page_mkwrite function handles a page at EOF boundary, it
    fills hole blocks only inside EOF through __block_page_mkwrite().

    The __block_page_mkwrite() function calls set_page_dirty() after filling
    hole blocks, thus nilfs_set_page_dirty function (=
    a_ops->set_page_dirty) is called.  However, the current implementation
    of nilfs_set_page_dirty() wrongly marks all buffers dirty even for page
    at EOF boundary.

    As a result, buffers outside EOF are inconsistently marked dirty and
    queued for write even though they are not mapped with nilfs_get_block
    function.

    FIX:
    This modifies nilfs_set_page_dirty() not to mark hole blocks dirty.

    Thanks to Vyacheslav Dubeyko for his effort on analysis and proposals
    for this issue.

    Signed-off-by: Ryusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>
    Reported-by: Anthony Doggett <Anthony2486@interfaces.org.uk>
    Reported-by: Vyacheslav Dubeyko <slava@dubeyko.com>
    Cc: Vyacheslav Dubeyko <slava@dubeyko.com>
    Tested-by: Ryusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 26deb18bd5aa6e3d7099b291038fef47b31cbf69
Author: Imre Deak <imre.deak@intel.com>
Date:   Fri May 24 15:55:09 2013 -0700

    wait: fix false timeouts when using wait_event_timeout()

    commit 4c663cfc523a88d97a8309b04a089c27dc57fd7e upstream.

    Many callers of the wait_event_timeout() and
    wait_event_interruptible_timeout() expect that the return value will be
    positive if the specified condition becomes true before the timeout
    elapses.  However, at the moment this isn't guaranteed.  If the wake-up
    handler is delayed enough, the time remaining until timeout will be
    calculated as 0 - and passed back as a return value - even if the
    condition became true before the timeout has passed.

    Fix this by returning at least 1 if the condition becomes true.  This
    semantic is in line with what wait_for_condition_timeout() does; see
    commit bb10ed09 ("sched: fix wait_for_completion_timeout() spurious
    failure under heavy load").

    Daniel said "We have 3 instances of this bug in drm/i915.  One case even
    where we switch between the interruptible and not interruptible
    wait_event_timeout variants, foolishly presuming they have the same
    semantics.  I very much like this."

    One such bug is reported at
      https://bugs.freedesktop.org/show_bug.cgi?id=64133

    Signed-off-by: Imre Deak <imre.deak@intel.com>
    Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Acked-by: David Howells <dhowells@redhat.com>
    Acked-by: Jens Axboe <axboe@kernel.dk>
    Cc: "Paul E.  McKenney" <paulmck@linux.vnet.ibm.com>
    Cc: Dave Jones <davej@redhat.com>
    Cc: Lukas Czerner <lczerner@redhat.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 929b30b9d3f530900c6e3176b1cf29fbcf307e25
Author: wang, biao <biao.wang@intel.com>
Date:   Thu May 16 09:50:13 2013 +0800

    klist: del waiter from klist_remove_waiters before wakeup waitting process

    commit ac5a2962b02f57dea76d314ef2521a2170b28ab6 upstream.

    There is a race between klist_remove and klist_release. klist_remove
    uses a local var waiter saved on stack. When klist_release calls
    wake_up_process(waiter->process) to wake up the waiter, waiter might run
    immediately and reuse the stack. Then, klist_release calls
    list_del(&waiter->list) to change previous
    wait data and cause prior waiter thread corrupt.

    The patch fixes it against kernel 3.9.

    Signed-off-by: wang, biao <biao.wang@intel.com>
    Acked-by: Peter Zijlstra <peterz@infradead.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c0872911a5926b9c0a3e570cf8bf2a027275a664
Author: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com>
Date:   Fri May 24 15:55:18 2013 -0700

    mm compaction: fix of improper cache flush in migration code

    commit c2cc499c5bcf9040a738f49e8051b42078205748 upstream.

    Page 'new' during MIGRATION can't be flushed with flush_cache_page().
    Using flush_cache_page(vma, addr, pfn) is justified only if the page is
    already placed in process page table, and that is done right after
    flush_cache_page().  But without it the arch function has no knowledge
    of process PTE and does nothing.

    Besides that, flush_cache_page() flushes an application cache page, but
    the kernel has a different page virtual address and dirtied it.

    Replace it with flush_dcache_page(new) which is the proper usage.

    The old page is flushed in try_to_unmap_one() before migration.

    This bug takes place in Sead3 board with M14Kc MIPS CPU without cache
    aliasing (but Harvard arch - separate I and D cache) in tight memory
    environment (128MB) each 1-3days on SOAK test.  It fails in cc1 during
    kernel build (SIGILL, SIGBUS, SIGSEG) if CONFIG_COMPACTION is switched
    ON.

    Signed-off-by: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com>
    Cc: Leonid Yegoshin <yegoshin@mips.com>
    Acked-by: Rik van Riel <riel@redhat.com>
    Cc: Michal Hocko <mhocko@suse.cz>
    Acked-by: Mel Gorman <mgorman@suse.de>
    Cc: Ralf Baechle <ralf@linux-mips.org>
    Cc: Russell King <rmk@arm.linux.org.uk>
    Cc: David Miller <davem@davemloft.net>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 891694374dbdf88b12f41fa412ead40a4d255071
Author: Martin Michlmayr <tbm@cyrius.com>
Date:   Sun Apr 21 17:14:00 2013 +0100

    Kirkwood: Enable PCIe port 1 on QNAP TS-11x/TS-21x

    commit 99e11334dcb846f9b76fb808196c7f47aa83abb3 upstream.

    Enable KW_PCIE1 on QNAP TS-11x/TS-21x devices as newer revisions
    (rev 1.3) have a USB 3.0 chip from Etron on PCIe port 1.  Thanks
    to Marek Vasut for identifying this issue!

    Signed-off-by: Martin Michlmayr <tbm@cyrius.com>
    Tested-by: Marek Vasut <marex@denx.de>
    Acked-by: Andrew Lunn <andrew@lunn.ch>
    Signed-off-by: Jason Cooper <jason@lakedaemon.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 70d53e5acf842b00efe048846aaf49d1f664b23d
Author: Joseph Qi <joseph.qi@huawei.com>
Date:   Fri May 24 15:55:34 2013 -0700

    ocfs2: goto out_unlock if ocfs2_get_clusters_nocache() failed in ocfs2_fiemap()

    commit b4ca2b4b577c3530e34dcfaafccb2cc680ce95d1 upstream.

    Last time we found there is lock/unlock bug in ocfs2_file_aio_write, and
    then we did a thorough search for all lock resources in
    ocfs2_inode_info, including rw, inode and open lockres and found this
    bug.  My kernel version is 3.0.13, and it is also in the lastest version
    3.9.  In ocfs2_fiemap, once ocfs2_get_clusters_nocache failed, it should
    goto out_unlock instead of out, because we need release buffer head, up
    read alloc sem and unlock inode.

    Signed-off-by: Joseph Qi <joseph.qi@huawei.com>
    Reviewed-by: Jie Liu <jeff.liu@oracle.com>
    Cc: Mark Fasheh <mfasheh@suse.com>
    Cc: Joel Becker <jlbec@evilplan.org>
    Acked-by: Sunil Mushran <sunil.mushran@gmail.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2b90057252cfde394556c989a0eb740ed6734389
Author: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
Date:   Fri May 24 15:55:08 2013 -0700

    fat: fix possible overflow for fat_clusters

    commit 7b92d03c3239f43e5b86c9cc9630f026d36ee995 upstream.

    Intermediate value of fat_clusters can be overflowed on 32bits arch.

    Reported-by: Krzysztof Strasburger <strasbur@chkw386.ch.pwr.wroc.pl>
    Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dae84f25ac695ff740ce1ca2226e5451ba296fc3
Author: Jeff Layton <jlayton@redhat.com>
Date:   Tue May 7 11:28:31 2013 -0400

    cifs: only set ops for inodes in I_NEW state

    commit c2b93e0699723700f886ce17bb65ffd771195a6d upstream.

    It's generally not safe to reset the inode ops once they've been set. In
    the case where the inode was originally thought to be a directory and
    then later found to be a DFS referral, this can lead to an oops when we
    try to trigger an inode op on it after changing the ops to the blank
    referral operations.

    Reported-and-Tested-by: Sachin Prabhu <sprabhu@redhat.com>
    Signed-off-by: Jeff Layton <jlayton@redhat.com>
    Signed-off-by: Steve French <smfrench@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c2ecac559adaf4a9413a01d3601006320e345d96
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Tue May 14 13:55:29 2013 -0400

    USB: UHCI: fix for suspend of virtual HP controller

    commit 997ff893603c6455da4c5e26ba1d0f81adfecdfc upstream.

    HP's virtual UHCI host controller takes a long time to suspend
    (several hundred microseconds), even when no devices are attached.
    This provokes a warning message from uhci-hcd in the auto-stop case.

    To prevent this from happening, this patch adds a test to avoid
    performing an auto-stop when the wait_for_hp quirk flag is set.  The
    controller will still suspend through the normal runtime PM mechanism.
    And since that pathway includes a 1-ms delay, the slowness of the
    virtual hardware won't matter.

    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Reported-and-tested-by: ZhenHua <zhen-hual@hp.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ea4950c9faa2a5d1019d74ff559374a56fdad8a2
Author: Oliver Neukum <oliver@neukum.org>
Date:   Tue Apr 30 10:18:04 2013 +0200

    USB: reset resume quirk needed by a hub

    commit bac6b03275184c912ad0818c9a0a736847804dca upstream.

    Werner Fink has reported problems with this hub.

    Signed-off-by: Oliver Neukum <oliver@neukum.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bf968788053dca71a4cb6f798ac19d9f4312648c
Author: Schemmel Hans-Christoph <Hans-Christoph.Schemmel@gemalto.com>
Date:   Mon May 6 11:05:12 2013 +0200

    USB: Blacklisted Cinterion's PLxx WWAN Interface

    commit 8ff10bdb14a52e3f25d4ce09e0582a8684c1a6db upstream.

    /drivers/usb/serial/option.c: Blacklisted Cinterion's PLxx WWAN
    Interface (USB Interface 4), because it will be handled by QMI WWAN
    driver. Product IDs renamed.

    Signed-off-by: Hans-Christoph Schemmel <hans-christoph.schemmel@gemalto.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3bf001a01656e1fa0dc34e3c0043801575fdb6bb
Author: Wang YanQing <udknight@gmail.com>
Date:   Thu May 9 14:16:47 2013 +0800

    TTY: Fix tty miss restart after we turn off flow-control

    commit dab73b4eb9ef924a2b90dab84e539076d82b256f upstream.

    I meet emacs hang in start if I do the operation below:
      1: echo 3 > /proc/sys/vm/drop_caches
      2: emacs BigFile
      3: Press CTRL-S follow 2 immediately

    Then emacs hang on, CTRL-Q can't resume, the terminal
    hang on, you can do nothing with this terminal except
    close it.

    The reason is before emacs takeover control the tty,
    we use CTRL-S to XOFF it. Then when emacs takeover the
    control, it may don't use the flow-control, so emacs hang.
    This patch fix it.

    This patch will fix a kind of strange tty relation hang problem,
    I believe I meet it with vim in ssh, and also see below bug report:
    http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=465823

    Signed-off-by: Wang YanQing <udknight@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2d722d28a3614fcd7959adc6e7debf9959b4bb8c
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Sun May 19 21:52:20 2013 +0300

    USB: cxacru: potential underflow in cxacru_cm_get_array()

    commit 2a0ebf80aa95cc758d4725f74a7016e992606a39 upstream.

    The value of "offd" comes off the instance->rcv_buf[] and we used it as
    the offset into an array.  The problem is that we check the upper bound
    but not for negative values.

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

commit e50d48c8f67b2b96797bc5d66eb3c717d24744ff
Author: Gomella, Andrew (NIH/NHLBI) [F] <andrew.gomella@nih.gov>
Date:   Fri May 17 17:39:46 2013 +0000

    USB: ftdi_sio: Add support for Newport CONEX motor drivers

    commit 7138143972b7c293267c783fc99a194f0ceff7f2 upstream.

    Here are two more devices that use FTDI USB-to-serial chips with new product ID's.

    The devices are the Newport Conex-AGP and Conex-CC motor controllers.
    (http://www.newport.com/CONEX-AGP-Integrated-Piezo-Motor-Rotation-Stages-/987623/1033/info.aspx)
    (http://www.newport.com/CONEX-CC-DC-Servo-Controller-Actuators/934114/1033/info.aspx)

    usb-devices command yields:

    P:  Vendor=104d ProdID=3002 Rev=06.00
    S:  Manufacturer=Newport
    S:  Product=CONEX-CC

    as well as

    P:  Vendor=104d ProdID=3006 Rev=06.00
    S:  Manufacturer=Newport
    S:  Product=CONEX-AGP

    Signed-off-by: Andrew Gomella <andrew.gomella@nih.gov>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ef98b82a7c1671d08802574131c2c9b73e6b96fe
Author: Dan Williams <dcbw@redhat.com>
Date:   Mon May 6 16:16:44 2013 -0500

    USB: option: add device IDs for Dell 5804 (Novatel E371) WWAN card

    commit 49c6e370dd6400b84897c4100095089b5c13a061 upstream.

    A rebranded Novatel E371 for AT&T's LTE bands.

    Signed-off-by: Dan Williams <dcbw@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4c540276d44f2fc29c82338bc15b9d3a335d82f8
Author: Teppo Kotilainen <qubit303@gmail.com>
Date:   Fri May 3 10:28:12 2013 +0300

    usb: option: Add Telewell TW-LTE 4G

    commit 73c042df6e1bc50544842a04b777b36bbe3630e6 upstream.

    Information from driver description files:

      diag:  VID_19D2&PID_0412&MI_00
      nmea:  VID_19D2&PID_0412&MI_01
      at:    VID_19D2&PID_0412&MI_02
      modem: VID_19D2&PID_0412&MI_03
      net:   VID_19D2&PID_0412&MI_04

    Signed-off-by: Teppo Kotilainen <qubit303@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bbb17fe79731a9d580ab2338fe001b900fc29311
Author: Hema Prathaban <hemaklnce@gmail.com>
Date:   Sat May 11 22:39:47 2013 +0530

    staging: vt6656: use free_netdev instead of kfree

    commit 0a438d5b381e2bdfd5e02d653bf46fcc878356e3 upstream.

    use free_netdev() instead of kfree(pDevice->apdev)

    Signed-off-by: Hema Prathaban <hemaklnce@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8a3e6d89936003e13011ab01dacdf96c66a0e465
Author: Gregory CLEMENT <gregory.clement@free-electrons.com>
Date:   Sun May 19 22:12:43 2013 +0200

    ARM: plat-orion: Fix num_resources and id for ge10 and ge11

    commit 2b8b2797142c7951e635c6eec5d1705ee9bc45c5 upstream.

    When platform data were moved from arch/arm/mach-mv78xx0/common.c to
    arch/arm/plat-orion/common.c with the commit "7e3819d ARM: orion:
    Consolidate ethernet platform data", there were few typo made on
    gigabit Ethernet interface ge10 and ge11. This commit writes back
    their initial value, which allows to use this interfaces again.

    Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
    Acked-by: Andrew Lunn <andrew@lunn.ch>
    Signed-off-by: Jason Cooper <jason@lakedaemon.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e9a91cb47886388540eaf68f981e7a3d4b04a27c
Author: Hans-Christian Egtvedt <egtvedt@samfundet.no>
Date:   Mon May 13 22:22:10 2013 +0200

    avr32: fix relocation check for signed 18-bit offset

    commit e68c636d88db3fda74e664ecb1a213ae0d50a7d8 upstream.

    Caught by static code analysis by David.

    Reported-by: David Binderman <dcb314@hotmail.com>
    Signed-off-by: Hans-Christian Egtvedt <egtvedt@samfundet.no>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Linux 3.0.82

commit ae02c5a7cd1ed15da0976a44b8d0da4ad5c0975d
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Thu Jun 13 09:27:00 2013 -0700

    Linux 3.0.82

commit 103128b4b48010bed60d220d3eb46ceab9c021b5
Author: Steven Rostedt <rostedt@goodmis.org>
Date:   Fri Jun 7 17:01:04 2013 +0800

    ftrace: Move ftrace_filter_lseek out of CONFIG_DYNAMIC_FTRACE section

    commit 7f49ef69db6bbf756c0abca7e9b65b32e999eec8 upstream.

    As ftrace_filter_lseek is now used with ftrace_pid_fops, it needs to
    be moved out of the #ifdef CONFIG_DYNAMIC_FTRACE section as the
    ftrace_pid_fops is defined when DYNAMIC_FTRACE is not.

    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Cc: Namhyung Kim <namhyung@kernel.org>
    [ lizf: adjust context ]
    Signed-off-by: Li Zefan <lizefan@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c45fe24c84eb35565a252c4fe2dd851cee22cb3e
Author: Namhyung Kim <namhyung.kim@lge.com>
Date:   Fri Jun 7 17:00:33 2013 +0800

    tracing: Fix possible NULL pointer dereferences

    commit 6a76f8c0ab19f215af2a3442870eeb5f0e81998d upstream.

    Currently set_ftrace_pid and set_graph_function files use seq_lseek
    for their fops.  However seq_open() is called only for FMODE_READ in
    the fops->open() so that if an user tries to seek one of those file
    when she open it for writing, it sees NULL seq_file and then panic.

    It can be easily reproduced with following command:

      $ cd /sys/kernel/debug/tracing
      $ echo 1234 | sudo tee -a set_ftrace_pid

    In this example, GNU coreutils' tee opens the file with fopen(, "a")
    and then the fopen() internally calls lseek().

    Link:
    http://lkml.kernel.org/r/1365663302-2170-1-git-send-email-namhyung@kernel.org

    Signed-off-by: Namhyung Kim <namhyung@kernel.org>
    Cc: Frederic Weisbecker <fweisbec@gmail.com>
    Cc: Ingo Molnar <mingo@kernel.org>
    Cc: Namhyung Kim <namhyung.kim@lge.com>
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    [ lizf: adjust context ]
    Signed-off-by: Li Zefan <lizefan@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 24d54932440284584060455a81156f7ca4edff0e
Author: Ying Xue <ying.xue@windriver.com>
Date:   Mon Aug 6 17:46:37 2012 +0800

    USB: ftdi_sio: Quiet sparse noise about using plain integer was NULL pointer

    commit a816e3113b63753c330ca4751ea1d208e93e3015 upstream.

    Pointers should not be compared to plain integers.
    Quiets the sparse warning:
    warning: Using plain integer as NULL pointer

    Signed-off-by: Ying Xue <ying.xue@windriver.com>
    Cc: Lotfi Manseur <lotfi.manseur@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9c9d7bf530c4d01e695fd9e8ba69006177d36a14
Author: Andrew Worsley <amworsley@gmail.com>
Date:   Tue Nov 22 20:00:19 2011 +1100

    USB: serial: ftdi_sio: Handle the old_termios == 0 case e.g. uart_resume_port()

    commit c515598e0f5769916c31c00392cc2bfe6af74e55 upstream.

      Handle null old_termios in ftdi_set_termios() calls from uart_resume_port().

    Signed-off-by: Andrew Worsley <amworsley@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Cc: Lotfi Manseur <lotfi.manseur@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c4c2a7db886d6a7bb562fe5eebbb74ba043745b2
Author: Egbert Eich <eich@suse.de>
Date:   Tue Jun 4 17:13:21 2013 +0200

    drm/i915/sdvo: Use &intel_sdvo->ddc instead of intel_sdvo->i2c for DDC.

    commit 53d3b4d7778daf15900867336c85d3f8dd70600c upstream.

    In intel_sdvo_get_lvds_modes() the wrong i2c adapter record is used
    for DDC. Thus the code will always have to rely on a LVDS panel
    mode supplied by VBT.
    In most cases this succeeds, so this didn't get detected for quite
    a while.

    This regression seems to have been introduced in

    commit f899fc64cda8569d0529452aafc0da31c042df2e
    Author: Chris Wilson <chris@chris-wilson.co.uk>
    Date:   Tue Jul 20 15:44:45 2010 -0700

        drm/i915: use GMBUS to manage i2c links

    Signed-off-by: Egbert Eich <eich@suse.de>
    Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
    [danvet: Add note about which commit likely introduced this issue.]
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ad712863393b6d3b772529c1726b3aa3375e3fc1
Author: Huacai Chen <chenhc@lemote.com>
Date:   Tue May 21 06:23:43 2013 +0000

    drm: fix a use-after-free when GPU acceleration disabled

    commit b7ea85a4fed37835eec78a7be3039c8dc22b8178 upstream.

    When GPU acceleration is disabled, drm_vblank_cleanup() will free the
    vblank-related data, such as vblank_refcount, vblank_inmodeset, etc.
    But we found that drm_vblank_post_modeset() may be called after the
    cleanup, which use vblank_refcount and vblank_inmodeset. And this will
    cause a kernel panic.

    Fix this by return immediately if dev->num_crtcs is zero. This is the
    same thing that drm_vblank_pre_modeset() does.

    Call trace of a drm_vblank_post_modeset() after drm_vblank_cleanup():
    [   62.628906] [<ffffffff804868d0>] drm_vblank_post_modeset+0x34/0xb4
    [   62.628906] [<ffffffff804c7008>] atombios_crtc_dpms+0xb4/0x174
    [   62.628906] [<ffffffff804c70e0>] atombios_crtc_commit+0x18/0x38
    [   62.628906] [<ffffffff8047f038>] drm_crtc_helper_set_mode+0x304/0x3cc
    [   62.628906] [<ffffffff8047f92c>] drm_crtc_helper_set_config+0x6d8/0x988
    [   62.628906] [<ffffffff8047dd40>] drm_fb_helper_set_par+0x94/0x104
    [   62.628906] [<ffffffff80439d14>] fbcon_init+0x424/0x57c
    [   62.628906] [<ffffffff8046a638>] visual_init+0xb8/0x118
    [   62.628906] [<ffffffff8046b9f8>] take_over_console+0x238/0x384
    [   62.628906] [<ffffffff80436df8>] fbcon_takeover+0x7c/0xdc
    [   62.628906] [<ffffffff8024fa20>] notifier_call_chain+0x44/0x94
    [   62.628906] [<ffffffff8024fcbc>] __blocking_notifier_call_chain+0x48/0x68
    [   62.628906] [<ffffffff8042d990>] register_framebuffer+0x228/0x260
    [   62.628906] [<ffffffff8047e010>] drm_fb_helper_single_fb_probe+0x260/0x314
    [   62.628906] [<ffffffff8047e2c4>] drm_fb_helper_initial_config+0x200/0x234
    [   62.628906] [<ffffffff804e5560>] radeon_fbdev_init+0xd4/0xf4
    [   62.628906] [<ffffffff804e0e08>] radeon_modeset_init+0x9bc/0xa18
    [   62.628906] [<ffffffff804bfc14>] radeon_driver_load_kms+0xdc/0x12c
    [   62.628906] [<ffffffff8048b548>] drm_get_pci_dev+0x148/0x238
    [   62.628906] [<ffffffff80423564>] local_pci_probe+0x5c/0xd0
    [   62.628906] [<ffffffff80241ac4>] work_for_cpu_fn+0x1c/0x30
    [   62.628906] [<ffffffff802427c8>] process_one_work+0x274/0x3bc
    [   62.628906] [<ffffffff80242934>] process_scheduled_works+0x24/0x44
    [   62.628906] [<ffffffff8024515c>] worker_thread+0x31c/0x3f4
    [   62.628906] [<ffffffff802497a8>] kthread+0x88/0x90
    [   62.628906] [<ffffffff80206794>] kernel_thread_helper+0x10/0x18

    Signed-off-by: Huacai Chen <chenhc@lemote.com>
    Signed-off-by: Binbin Zhou <zhoubb@lemote.com>
    Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
    Acked-by: Paul Menzel <paulepanter@users.sourceforge.net>
    Signed-off-by: Dave Airlie <airlied@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bf204ada5b969c9f33b903795b5b0e530d389350
Author: Guenter Roeck <linux@roeck-us.net>
Date:   Wed Jun 5 14:09:30 2013 -0700

    hwmon: (adm1021) Strengthen chip detection for ADM1021, LM84 and MAX1617

    commit 591bfcfc334a003ba31c0deff03b22e73349939b upstream.

    On a system with both MAX1617 and JC42 sensors, JC42 sensors can be misdetected
    as LM84. Strengthen detection sufficiently enough to avoid this misdetection.
    Also improve detection for ADM1021.

    Modeled after chip detection code in sensors-detect command.

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

commit 87646a0da17e5368db84a14c506e9df588051acf
Author: Ash Willis <ashwillis.kernel@gmail.com>
Date:   Wed May 29 01:27:59 2013 +0000

    ACPI / video: ignore BIOS initial backlight value for HP Pavilion g6

    commit 780a6ec640a3fed671fc2c40e4dd30c03eca3ac3 upstream.

    This patch addresses kernel bug 56661. BIOS reports an incorrect
    backlight value, causing the driver to switch off the backlight
    completely during startup. This patch ignores the incorrect value from
    BIOS.

    References: https://bugzilla.kernel.org/show_bug.cgi?id=56661
    Signed-off-by: Ash Willis <ashwillis@programmer.net>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d117eaaa99ceedbf4c73a6dabf2f92d330c3b71b
Author: Alex Hung <alex.hung@canonical.com>
Date:   Tue May 28 02:05:09 2013 +0000

    ACPI / video: ignore BIOS initial backlight value for HP m4

    commit fedbe9bc6fd3e14b1ffbb3dac407777ac4a3650c upstream.

    On HP m4 lapops, BIOS reports minimum backlight on boot and
    causes backlight to dim completely. This ignores the initial backlight
    values and set to max brightness.

    References: https://bugs.launchpad.net/bugs/1184501
    Signed-off-by: Alex Hung <alex.hung@canonical.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 078da62e2285732cda0863cca0da10f5b69bf552
Author: Johan Hovold <jhovold@gmail.com>
Date:   Tue Jun 4 18:50:31 2013 +0200

    USB: mos7720: fix hardware flow control

    commit a26f009a070e840fadacb91013b2391ba7ab6cc2 upstream.

    The register access to enable hardware flow control depends on the
    device port number and not the port minor number.

    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 061a4524510c25c2e594aaa86f6100bf82b20c5f
Author: Johan Hovold <jhovold@gmail.com>
Date:   Mon May 27 14:44:43 2013 +0200

    USB: mos7720: fix message timeouts

    commit 849513a7809175420d353625b6f651d961e99d49 upstream.

    The control and bulk-message timeouts are specified in milliseconds and
    should not depend on HZ.

    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e9ab9a9031d6224f01577a8fdfe8d380882b8b25
Author: Johan Hovold <jhovold@gmail.com>
Date:   Mon May 27 14:44:39 2013 +0200

    USB: mos7720: fix DMA to stack

    commit 72ea18a558ed7a63a50bb121ba60d73b5b38ae30 upstream.

    The read_mos_reg function is called with stack-allocated buffers, which
    must not be used for control messages.

    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9afcad40de6d98484d3d12305830656b882f76f1
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Tue May 28 14:03:10 2013 -0400

    USB: revert periodic scheduling bugfix

    commit fdc03438f53a00294ed9939eb3a1f6db6f3d8963 upstream.

    This patch reverts commit 3e619d04159be54b3daa0b7036b0ce9e067f4b5d
    (USB: EHCI: fix bug in scheduling periodic split transfers).  The
    commit was valid -- it fixed a real bug -- but the periodic scheduler
    in ehci-hcd is in such bad shape (especially the part that handles
    split transactions) that fixing one bug is very likely to cause
    another to surface.  That's what happened in this case; the result was
    choppy and noisy playback on certain 24-bit audio devices.

    The only real fix will be to rewrite this entire section of code.  My
    next project...

    This fixes https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1136110.

    Thanks to Tim Richardson for extra testing and feedback, and to Joseph
    Salisbury and Tyson Tan for tracking down the original source of the
    problem.

    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    CC: Joseph Salisbury <joseph.salisbury@canonical.com>
    CC: Tim Richardson <tim@tim-richardson.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e1742ba57d747024a4f0c01c88a212b7e4d5e898
Author: Johan Hovold <jhovold@gmail.com>
Date:   Mon May 27 14:44:37 2013 +0200

    USB: serial: fix Treo/Kyocera interrrupt-in urb context

    commit 5f8e2c07d75967ee49a5da1d21ddf5f50d48cda0 upstream.

    The first and second interrupt-in urbs are swapped for some Treo/Kyocera
    devices, but the urb context was never updated with the new port.

    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0317720b2f8c9d7c1b085a039b9a25cfad09a417
Author: Johan Hovold <jhovold@gmail.com>
Date:   Thu Jun 6 13:32:47 2013 +0200

    USB: whiteheat: fix broken port configuration

    commit 9eecf22d2b375b9064a20421c6c307b760b03d46 upstream.

    When configuring the port (e.g. set_termios) the port minor number
    rather than the port number was used in the request (and they only
    coincide for minor number 0).

    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1450a25582a8fab2c19d87182c98505173ec6bfa
Author: Robert Butora <robert.butora.fi@gmail.com>
Date:   Fri May 31 18:09:51 2013 +0300

    USB: Serial: cypress_M8: Enable FRWD Dongle hidcom device

    commit 6529591e3eef65f0f528a81ac169f6e294b947a7 upstream.

    The patch adds a new HIDCOM device and does not affect other devices
    driven by the cypress_M8 module. Changes are:
    - add VendorID ProductID to device tables
    - skip unstable speed check because FRWD uses 115200bps
    - skip reset at probe which is an issue workaround for this
    particular device.

    Signed-off-by: Robert Butora <robert.butora.fi@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b40e7b1ead426706d4ca3193b484cec5df215106
Author: Johan Hovold <jhovold@gmail.com>
Date:   Mon May 27 14:44:41 2013 +0200

    USB: ark3116: fix control-message timeout

    commit 634371911730a462626071065b64cd6e1fe213e0 upstream.

    The control-message timeout is specified in milliseconds and should not
    depend on HZ.

    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eedbcc70f665c043b7094b17092f6fc99c084c7f
Author: Johan Hovold <jhovold@gmail.com>
Date:   Tue Jun 4 18:50:29 2013 +0200

    USB: keyspan: fix bogus array index

    commit a07088098a650267b2eda689538133a324b9523f upstream.

    The outcont_endpoints array was indexed using the port minor number
    (which can be greater than the array size) rather than the device port
    number.

    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c4e994727232f6106df6b21f96d3bfd4c04b3ed1
Author: Johan Hovold <jhovold@gmail.com>
Date:   Mon May 27 14:44:42 2013 +0200

    USB: iuu_phoenix: fix bulk-message timeout

    commit 6c13ff68a7ce01da7a51b44241a7aad8eaaedde7 upstream.

    The bulk-message timeout is specified in milliseconds and should not
    depend on HZ.

    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 01fcf83196be95454880a729cb6c483a7d9cef4b
Author: Takashi Iwai <tiwai@suse.de>
Date:   Tue Jun 4 16:02:54 2013 +0200

    ALSA: usb-audio - Apply Logitech QuickCam Pro 9000 quirk only to audio iface

    commit 8eafc0a161123d90617c9ca2eddfe87b382b1b89 upstream.

    ... instead of applying to all interfaces.

    Reference: http://forums.gentoo.org/viewtopic-p-6886404.html

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

commit 3af312d74eeea767598d0b4f9e909e098599f4d3
Author: Bjørn Mork <bjorn@mork.no>
Date:   Thu Jun 6 12:57:24 2013 +0200

    USB: option: blacklist network interface on Huawei E1820

    commit b8a24e6281d37243c06b9497dcbfaa98c1e2ad35 upstream.

    The mode used by Windows for the Huawei E1820 will use the
    same ff/ff/ff class codes for both serial and network
    functions.

    Reported-by: Graham Inggs <graham.inggs@uct.ac.za>
    Signed-off-by: Bjørn Mork <bjorn@mork.no>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Linux 3.0.83

commit 937d4f9ee2fe18a6ab012a343fc3b620756b954e
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Thu Jun 20 11:28:30 2013 -0700

    Linux 3.0.83

commit 088d9d4d782d66941fc9e29ff4eb0dd72f84493b
Author: Sage Weil <sage@inktank.com>
Date:   Fri Feb 22 15:31:00 2013 -0800

    ceph: fix statvfs fr_size

    commit 92a49fb0f79f3300e6e50ddf56238e70678e4202 upstream.

    Different versions of glibc are broken in different ways, but the short of
    it is that for the time being, frsize should == bsize, and be used as the
    multiple for the blocks, free, and available fields.  This mirrors what is
    done for NFS.  The previous reporting of the page size for frsize meant
    that newer glibc and df would report a very small value for the fs size.

    Fixes http://tracker.ceph.com/issues/3793.

    Signed-off-by: Sage Weil <sage@inktank.com>
    Reviewed-by: Greg Farnum <greg@inktank.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0ffdfdbe55c84906dd65627f069619bec54e5422
Author: Kees Cook <keescook@chromium.org>
Date:   Wed Jun 5 11:47:18 2013 -0700

    x86: Fix typo in kexec register clearing

    commit c8a22d19dd238ede87aa0ac4f7dbea8da039b9c1 upstream.

    Fixes a typo in register clearing code. Thanks to PaX Team for fixing
    this originally, and James Troup for pointing it out.

    Signed-off-by: Kees Cook <keescook@chromium.org>
    Link: http://lkml.kernel.org/r/20130605184718.GA8396@www.outflux.net
    Cc: PaX Team <pageexec@freemail.hu>
    Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 79848ba66d91e0c171ff203363e0c96629279c15
Author: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Date:   Wed Jun 12 14:05:04 2013 -0700

    mm: migration: add migrate_entry_wait_huge()

    commit 30dad30922ccc733cfdbfe232090cf674dc374dc upstream.

    When we have a page fault for the address which is backed by a hugepage
    under migration, the kernel can't wait correctly and do busy looping on
    hugepage fault until the migration finishes.  As a result, users who try
    to kick hugepage migration (via soft offlining, for example) occasionally
    experience long delay or soft lockup.

    This is because pte_offset_map_lock() can't get a correct migration entry
    or a correct page table lock for hugepage.  This patch introduces
    migration_entry_wait_huge() to solve this.

    Signed-off-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
    Reviewed-by: Rik van Riel <riel@redhat.com>
    Reviewed-by: Wanpeng Li <liwanp@linux.vnet.ibm.com>
    Reviewed-by: Michal Hocko <mhocko@suse.cz>
    Cc: Mel Gorman <mgorman@suse.de>
    Cc: Andi Kleen <andi@firstfloor.org>
    Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 78ef884ebb6c02d45abefc95350f428be7390a26
Author: Rafael Aquini <aquini@redhat.com>
Date:   Wed Jun 12 14:04:49 2013 -0700

    swap: avoid read_swap_cache_async() race to deadlock while waiting on discard I/O completion

    commit cbab0e4eec299e9059199ebe6daf48730be46d2b upstream.

    read_swap_cache_async() can race against get_swap_page(), and stumble
    across a SWAP_HAS_CACHE entry in the swap map whose page wasn't brought
    into the swapcache yet.

    This transient swap_map state is expected to be transitory, but the
    actual placement of discard at scan_swap_map() inserts a wait for I/O
    completion thus making the thread at read_swap_cache_async() to loop
    around its -EEXIST case, while the other end at get_swap_page() is
    scheduled away at scan_swap_map().  This can leave the system deadlocked
    if the I/O completion happens to be waiting on the CPU waitqueue where
    read_swap_cache_async() is busy looping and !CONFIG_PREEMPT.

    This patch introduces a cond_resched() call to make the aforementioned
    read_swap_cache_async() busy loop condition to bail out when necessary,
    thus avoiding the subtle race window.

    Signed-off-by: Rafael Aquini <aquini@redhat.com>
    Acked-by: Johannes Weiner <hannes@cmpxchg.org>
    Acked-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
    Acked-by: Hugh Dickins <hughd@google.com>
    Cc: Shaohua Li <shli@kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bac5719cdfb081dd68b0eeef7d9796c15fc29811
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Mon Jun 10 09:47:58 2013 +0200

    drm/i915: prefer VBT modes for SVDO-LVDS over EDID

    commit c3456fb3e4712d0448592af3c5d644c9472cd3c1 upstream.

    In

    commit 53d3b4d7778daf15900867336c85d3f8dd70600c
    Author: Egbert Eich <eich@suse.de>
    Date:   Tue Jun 4 17:13:21 2013 +0200

        drm/i915/sdvo: Use &intel_sdvo->ddc instead of intel_sdvo->i2c for DDC

    Egbert Eich fixed a long-standing bug where we simply used a
    non-working i2c controller to read the EDID for SDVO-LVDS panels.
    Unfortunately some machines seem to not be able to cope with the mode
    provided in the EDID. Specifically they seem to not be able to cope
    with a 4x pixel mutliplier instead of a 2x one, which seems to have
    been worked around by slightly changing the panels native mode in the
    VBT so that the dotclock is just barely above 50MHz.

    Since it took forever to notice the breakage it's fairly safe to
    assume that at least for SDVO-LVDS panels the VBT contains fairly sane
    data. So just switch around the order and use VBT modes first.

    v2: Also add EDID modes just in case, and spell Egbert correctly.

    v3: Elaborate a bit more about what's going on on Chris' machine.

    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65524
    Reported-and-tested-by: Chris Wilson <chris@chris-wilson.co.uk>
    Cc: Egbert Eich <eich@suse.de>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 319d630e7f0778c8999f6ef503998a4d99cee5f1
Author: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Date:   Sat Jun 1 07:08:09 2013 +0530

    ath9k: Disable PowerSave by default

    commit 531671cb17af07281e6f28c1425f754346e65c41 upstream.

    Almost all the DMA issues which have plagued ath9k (in station mode)
    for years are related to PS. Disabling PS usually "fixes" the user's
    connection stablility. Reports of DMA problems are still trickling in
    and are sitting in the kernel bugzilla. Until the PS code in ath9k is
    given a thorough review, disbale it by default. The slight increase
    in chip power consumption is a small price to pay for improved link
    stability.

    Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 720083f1dc15ac6b6fb85b323d0eae1a151e20ce
Author: Kees Cook <keescook@chromium.org>
Date:   Fri May 10 14:48:21 2013 -0700

    b43: stop format string leaking into error msgs

    commit e0e29b683d6784ef59bbc914eac85a04b650e63c upstream.

    The module parameter "fwpostfix" is userspace controllable, unfiltered,
    and is used to define the firmware filename. b43_do_request_fw() populates
    ctx->errors[] on error, containing the firmware filename. b43err()
    parses its arguments as a format string. For systems with b43 hardware,
    this could lead to a uid-0 to ring-0 escalation.

    CVE-2013-2852

    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Linux 3.0.84

commit 863c94fa3948619d3e425f9a3c61e6baf72ee666
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Thu Jun 27 10:35:30 2013 -0700

    Linux 3.0.84

commit c77a0bc75e37339dcbd4caf20d5ce2a4e7070740
Author: Anders Hammarquist <iko@iko.pp.se>
Date:   Wed Jun 19 01:45:48 2013 +0200

    USB: serial: ti_usb_3410_5052: new device id for Abbot strip port cable

    commit 35a2fbc941accd0e9f1bfadd669311786118d874 upstream.

    Add product id for Abbott strip port cable for Precision meter which
    uses the TI 3410 chip.

    Signed-off-by: Anders Hammarquist <iko@iko.pp.se>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 60ab7833a93b180b420a18e24e88e3a9528a7038
Author: Guillaume Nault <g.nault@alphalink.fr>
Date:   Wed Jun 12 16:07:36 2013 +0200

    l2tp: Fix sendmsg() return value

    [ Upstream commit a6f79d0f26704214b5b702bbac525cb72997f984 ]

    PPPoL2TP sockets should comply with the standard send*() return values
    (i.e. return number of bytes sent instead of 0 upon success).

    Signed-off-by: Guillaume Nault <g.nault@alphalink.fr>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6e092615d27d7036832c18f1c14b691c6c1cbb1d
Author: Guillaume Nault <g.nault@alphalink.fr>
Date:   Wed Jun 12 16:07:23 2013 +0200

    l2tp: Fix PPP header erasure and memory leak

    [ Upstream commit 55b92b7a11690bc377b5d373872a6b650ae88e64 ]

    Copy user data after PPP framing header. This prevents erasure of the
    added PPP header and avoids leaking two bytes of uninitialised memory
    at the end of skb's data buffer.

    Signed-off-by: Guillaume Nault <g.nault@alphalink.fr>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b4d45a2af9c9ca5c14e00375366125e7c31d5293
Author: Daniel Borkmann <dborkman@redhat.com>
Date:   Wed Jun 12 16:02:27 2013 +0200

    packet: packet_getname_spkt: make sure string is always 0-terminated

    [ Upstream commit 2dc85bf323515e59e15dfa858d1472bb25cad0fe ]

    uaddr->sa_data is exactly of size 14, which is hard-coded here and
    passed as a size argument to strncpy(). A device name can be of size
    IFNAMSIZ (== 16), meaning we might leave the destination string
    unterminated. Thus, use strlcpy() and also sizeof() while we're
    at it. We need to memset the data area beforehand, since strlcpy
    does not padd the remaining buffer with zeroes for user space, so
    that we do not possibly leak anything.

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

commit bba0c7f5421c40314ef48be4a7540efa76166dcd
Author: Daniel Borkmann <dborkman@redhat.com>
Date:   Thu Jun 6 15:53:47 2013 +0200

    net: sctp: fix NULL pointer dereference in socket destruction

    [ Upstream commit 1abd165ed757db1afdefaac0a4bc8a70f97d258c ]

    While stress testing sctp sockets, I hit the following panic:

    BUG: unable to handle kernel NULL pointer dereference at 0000000000000020
    IP: [<ffffffffa0490c4e>] sctp_endpoint_free+0xe/0x40 [sctp]
    PGD 7cead067 PUD 7ce76067 PMD 0
    Oops: 0000 [#1] SMP
    Modules linked in: sctp(F) libcrc32c(F) [...]
    CPU: 7 PID: 2950 Comm: acc Tainted: GF            3.10.0-rc2+ #1
    Hardware name: Dell Inc. PowerEdge T410/0H19HD, BIOS 1.6.3 02/01/2011
    task: ffff88007ce0e0c0 ti: ffff88007b568000 task.ti: ffff88007b568000
    RIP: 0010:[<ffffffffa0490c4e>]  [<ffffffffa0490c4e>] sctp_endpoint_free+0xe/0x40 [sctp]
    RSP: 0018:ffff88007b569e08  EFLAGS: 00010292
    RAX: 0000000000000000 RBX: ffff88007db78a00 RCX: dead000000200200
    RDX: ffffffffa049fdb0 RSI: ffff8800379baf38 RDI: 0000000000000000
    RBP: ffff88007b569e18 R08: ffff88007c230da0 R09: 0000000000000001
    R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
    R13: ffff880077990d00 R14: 0000000000000084 R15: ffff88007db78a00
    FS:  00007fc18ab61700(0000) GS:ffff88007fc60000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
    CR2: 0000000000000020 CR3: 000000007cf9d000 CR4: 00000000000007e0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
    Stack:
     ffff88007b569e38 ffff88007db78a00 ffff88007b569e38 ffffffffa049fded
     ffffffff81abf0c0 ffff88007db78a00 ffff88007b569e58 ffffffff8145b60e
     0000000000000000 0000000000000000 ffff88007b569eb8 ffffffff814df36e
    Call Trace:
     [<ffffffffa049fded>] sctp_destroy_sock+0x3d/0x80 [sctp]
     [<ffffffff8145b60e>] sk_common_release+0x1e/0xf0
     [<ffffffff814df36e>] inet_create+0x2ae/0x350
     [<ffffffff81455a6f>] __sock_create+0x11f/0x240
     [<ffffffff81455bf0>] sock_create+0x30/0x40
     [<ffffffff8145696c>] SyS_socket+0x4c/0xc0
     [<ffffffff815403be>] ? do_page_fault+0xe/0x10
     [<ffffffff8153cb32>] ? page_fault+0x22/0x30
     [<ffffffff81544e02>] system_call_fastpath+0x16/0x1b
    Code: 0c c9 c3 66 2e 0f 1f 84 00 00 00 00 00 e8 fb fe ff ff c9 c3 66 0f
          1f 84 00 00 00 00 00 55 48 89 e5 53 48 83 ec 08 66 66 66 66 90 <48>
          8b 47 20 48 89 fb c6 47 1c 01 c6 40 12 07 e8 9e 68 01 00 48
    RIP  [<ffffffffa0490c4e>] sctp_endpoint_free+0xe/0x40 [sctp]
     RSP <ffff88007b569e08>
    CR2: 0000000000000020
    ---[ end trace e0d71ec1108c1dd9 ]---

    I did not hit this with the lksctp-tools functional tests, but with a
    small, multi-threaded test program, that heavily allocates, binds,
    listens and waits in accept on sctp sockets, and then randomly kills
    some of them (no need for an actual client in this case to hit this).
    Then, again, allocating, binding, etc, and then killing child processes.

    This panic then only occurs when ``echo 1 > /proc/sys/net/sctp/auth_enable''
    is set. The cause for that is actually very simple: in sctp_endpoint_init()
    we enter the path of sctp_auth_init_hmacs(). There, we try to allocate
    our crypto transforms through crypto_alloc_hash(). In our scenario,
    it then can happen that crypto_alloc_hash() fails with -EINTR from
    crypto_larval_wait(), thus we bail out and release the socket via
    sk_common_release(), sctp_destroy_sock() and hit the NULL pointer
    dereference as soon as we try to access members in the endpoint during
    sctp_endpoint_free(), since endpoint at that time is still NULL. Now,
    if we have that case, we do not need to do any cleanup work and just
    leave the destruction handler.

    Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
    Acked-by: Neil Horman <nhorman@tuxdriver.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 0e7d0e50a7502671ff7deed63595ed2d20ac1e8c
Author: Gao feng <gaofeng@cn.fujitsu.com>
Date:   Sun Jun 2 22:16:21 2013 +0000

    ipv6: assign rt6_info to inet6_ifaddr in init_loopback

    [ Upstream commit 534c877928a16ae5f9776436a497109639bf67dc ]

    Commit 25fb6ca4ed9cad72f14f61629b68dc03c0d9713f
    "net IPv6 : Fix broken IPv6 routing table after loopback down-up"
    forgot to assign rt6_info to the inet6_ifaddr.
    When disable the net device, the rt6_info which allocated
    in init_loopback will not be destroied in __ipv6_ifa_notify.

    This will trigger the waring message below
    [23527.916091] unregister_netdevice: waiting for tap0 to become free. Usage count = 1

    Reported-by: Arkadiusz Miskiewicz <a.miskiewicz@gmail.com>
    Signed-off-by: Gao feng <gaofeng@cn.fujitsu.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 64274c35beebe1be22650a9353c0c33a7b8b723c
Author: Eric Dumazet <eric.dumazet@gmail.com>
Date:   Wed May 29 09:06:27 2013 +0000

    net: force a reload of first item in hlist_nulls_for_each_entry_rcu

    [ Upstream commit c87a124a5d5e8cf8e21c4363c3372bcaf53ea190 ]

    Roman Gushchin discovered that udp4_lib_lookup2() was not reloading
    first item in the rcu protected list, in case the loop was restarted.

    This produced soft lockups as in https://lkml.org/lkml/2013/4/16/37

    rcu_dereference(X)/ACCESS_ONCE(X) seem to not work as intended if X is
    ptr->field :

    In some cases, gcc caches the value or ptr->field in a register.

    Use a barrier() to disallow such caching, as documented in
    Documentation/atomic_ops.txt line 114

    Thanks a lot to Roman for providing analysis and numerous patches.

    Diagnosed-by: Roman Gushchin <klamm@yandex-team.ru>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: Boris Zhmurov <zhmurov@yandex-team.ru>
    Signed-off-by: Roman Gushchin <klamm@yandex-team.ru>
    Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e1b796f9408a33d18709e9fdbf18ce91dfede962
Author: Andy Lutomirski <luto@amacapital.net>
Date:   Wed May 22 14:07:44 2013 -0700

    net: Block MSG_CMSG_COMPAT in send(m)msg and recv(m)msg

    [ Upstream commits 1be374a0518a288147c6a7398792583200a67261 and
      a7526eb5d06b0084ef12d7b168d008fcf516caab ]

    MSG_CMSG_COMPAT is (AFAIK) not intended to be part of the API --
    it's a hack that steals a bit to indicate to other networking code
    that a compat entry was used.  So don't allow it from a non-compat
    syscall.

    This prevents an oops when running this code:

    int main()
    {
        int s;
        struct sockaddr_in addr;
        struct msghdr *hdr;

        char *highpage = mmap((void*)(TASK_SIZE_MAX - 4096), 4096,
                              PROT_READ | PROT_WRITE,
                              MAP_PRIVATE | MAP_ANONYMOUS | MAP_FIXED, -1, 0);
        if (highpage == MAP_FAILED)
            err(1, "mmap");

        s = socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP);
        if (s == -1)
            err(1, "socket");

            addr.sin_family = AF_INET;
            addr.sin_port = htons(1);
            addr.sin_addr.s_addr = htonl(INADDR_LOOPBACK);
        if (connect(s, (struct sockaddr*)&addr, sizeof(addr)) != 0)
            err(1, "connect");

        void *evil = highpage + 4096 - COMPAT_MSGHDR_SIZE;
        printf("Evil address is %p\n", evil);

        if (syscall(__NR_sendmmsg, s, evil, 1, MSG_CMSG_COMPAT) < 0)
            err(1, "sendmmsg");

        return 0;
    }

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

commit 34e4c0aed353934a72809784999900fc7b5653ef
Author: Eric Dumazet <edumazet@google.com>
Date:   Fri May 24 05:49:58 2013 +0000

    ip_tunnel: fix kernel panic with icmp_dest_unreach

    [ Upstream commit a622260254ee481747cceaaa8609985b29a31565 ]

    Daniel Petre reported crashes in icmp_dst_unreach() with following call
    graph:

    Daniel found a similar problem mentioned in
     http://lkml.indiana.edu/hypermail/linux/kernel/1007.0/00961.html

    And indeed this is the root cause : skb->cb[] contains data fooling IP
    stack.

    We must clear IPCB in ip_tunnel_xmit() sooner in case dst_link_failure()
    is called. Or else skb->cb[] might contain garbage from GSO segmentation
    layer.

    A similar fix was tested on linux-3.9, but gre code was refactored in
    linux-3.10. I'll send patches for stable kernels as well.

    Many thanks to Daniel for providing reports, patches and testing !

    Reported-by: Daniel Petre <daniel.petre@rcs-rds.ro>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 04e093d128963bfe46f50dbcff4c70147464fd0a
Author: Eric Dumazet <edumazet@google.com>
Date:   Thu May 23 07:44:20 2013 +0000

    tcp: xps: fix reordering issues

    [ Upstream commit 547669d483e5783d722772af1483fa474da7caf9 ]

    commit 3853b5841c01a ("xps: Improvements in TX queue selection")
    introduced ooo_okay flag, but the condition to set it is slightly wrong.

    In our traces, we have seen ACK packets being received out of order,
    and RST packets sent in response.

    We should test if we have any packets still in host queue.

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

commit 54ba13b9018c810664923626be5b22d220a955e8
Author: Paul Moore <pmoore@redhat.com>
Date:   Fri May 17 09:08:50 2013 +0000

    netlabel: improve domain mapping validation

    [ Upstream commit 6b21e1b77d1a3d58ebfd513264c885695e8a0ba5 ]

    The net/netlabel/netlabel_domainhash.c:netlbl_domhsh_add() function
    does not properly validate new domain hash entries resulting in
    potential problems when an administrator attempts to add an invalid
    entry.  One such problem, as reported by Vlad Halilov, is a kernel
    BUG (found in netlabel_domainhash.c:netlbl_domhsh_audit_add()) when
    adding an IPv6 outbound mapping with a CIPSO configuration.

    This patch corrects this problem by adding the necessary validation
    code to netlbl_domhsh_add() via the newly created
    netlbl_domhsh_validate() function.

    Ideally this patch should also be pushed to the currently active
    -stable trees.

    Reported-by: Vlad Halilov <vlad.halilov@gmail.com>
    Signed-off-by: Paul Moore <pmoore@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8410e49bf36d9adf4aba8a5cb8e1540da6aec862
Author: Eric Dumazet <edumazet@google.com>
Date:   Fri May 17 04:53:13 2013 +0000

    ipv6: fix possible crashes in ip6_cork_release()

    [ Upstream commit 284041ef21fdf2e0d216ab6b787bc9072b4eb58a ]

    commit 0178b695fd6b4 ("ipv6: Copy cork options in ip6_append_data")
    added some code duplication and bad error recovery, leading to potential
    crash in ip6_cork_release() as kfree() could be called with garbage.

    use kzalloc() to make sure this wont happen.

    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Cc: Herbert Xu <herbert@gondor.apana.org.au>
    Cc: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
    Cc: Neal Cardwell <ncardwell@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cc56da01f9325fd72ebf4d759b8333020bdc5f6c
Author: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Date:   Thu May 16 22:25:34 2013 +0000

    gianfar: add missing iounmap() on error in gianfar_ptp_probe()

    [ Upstream commit e5f5e380e0f3bb11f04ca5bc66a551e58e0ad26e ]

    Add the missing iounmap() before return from gianfar_ptp_probe()
    in the error handling case.

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

commit 41a187532a9458873a603aee48f017c0288d03fe
Author: Eric Dumazet <edumazet@google.com>
Date:   Mon May 13 21:25:52 2013 +0000

    tcp: fix tcp_md5_hash_skb_data()

    [ Upstream commit 54d27fcb338bd9c42d1dfc5a39e18f6f9d373c2e ]

    TCP md5 communications fail [1] for some devices, because sg/crypto code
    assume page offsets are below PAGE_SIZE.

    This was discovered using mlx4 driver [2], but I suspect loopback
    might trigger the same bug now we use order-3 pages in tcp_sendmsg()

    [1] Failure is giving following messages.

    huh, entered softirq 3 NET_RX ffffffff806ad230 preempt_count 00000100,
    exited with 00000101?

    [2] mlx4 driver uses order-2 pages to allocate RX frags

    Reported-by: Matt Schnall <mischnal@google.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Bernhard Beck <bbeck@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1819a873d94cd7abeb94f235175052f72fe6fa2c
Author: Zhanghaoyu (A) <haoyu.zhang@huawei.com>
Date:   Fri Jun 14 07:36:13 2013 +0000

    KVM: x86: remove vcpu's CPL check in host-invoked XCR set

    commit 764bcbc5a6d7a2f3e75c9f0e4caa984e2926e346 upstream.

    __kvm_set_xcr function does the CPL check when set xcr. __kvm_set_xcr is
    called in two flows, one is invoked by guest, call stack shown as below,

      handle_xsetbv(or xsetbv_interception)
        kvm_set_xcr
          __kvm_set_xcr

    the other one is invoked by host, for example during system reset:

      kvm_arch_vcpu_ioctl
        kvm_vcpu_ioctl_x86_set_xcrs
          __kvm_set_xcr

    The former does need the CPL check, but the latter does not.

    Signed-off-by: Zhang Haoyu <haoyu.zhang@huawei.com>
    [Tweaks to commit message. - Paolo]
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a0631b300bac987a591ae485d8a19a08aa57b4d2
Author: Chris Metcalf <cmetcalf@tilera.com>
Date:   Sat Jun 15 16:47:47 2013 -0400

    tilepro: work around module link error with gcc 4.7

    commit 3cb3f839d306443f3d1e79b0bde1a2ad2c12b555 upstream.

    gcc 4.7.x is emitting calls to __ffsdi2 where previously
    it used to inline the appropriate ctz instructions.
    While this needs to be fixed in gcc, it's also easy to avoid
    having it cause build failures when building with those
    compilers by exporting __ffsdi2 to modules.

    Signed-off-by: Chris Metcalf <cmetcalf@tilera.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 68af5a0e5cdb5e5c9ae53af4eb6e5ab8dbdd9cb4
Author: Clemens Ladisch <clemens@ladisch.de>
Date:   Sat Jun 15 11:21:09 2013 +0200

    ALSA: usb-audio: work around Android accessory firmware bug

    commit 342cda29343a6272c630f94ed56810a76740251b upstream.

    When the Android firmware enables the audio interfaces in accessory
    mode, it always declares in the control interface's baInterfaceNr array
    that interfaces 0 and 1 belong to the audio function.  However, the
    accessory interface itself, if also enabled, already is at index 0 and
    shifts the actual audio interface numbers to 1 and 2, which prevents the
    PCM streaming interface from being seen by the host driver.

    To get the PCM interface interface to work, detect when the descriptors
    point to the (for this driver useless) accessory interface, and redirect
    to the correct one.

    Reported-by: Jeremy Rosen <jeremy.rosen@openwide.fr>
    Tested-by: Jeremy Rosen <jeremy.rosen@openwide.fr>
    Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Linux 3.0.85

commit 2d0ed86595ca3a101c710efaec7aab0ca69c76da
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Wed Jul 3 11:03:56 2013 -0700

    Linux 3.0.85

commit db61e4ec623437237d05b5ab8ce97d9377682de2
Author: Liang Li <liang.li@windriver.com>
Date:   Sat Jan 19 17:52:10 2013 +0800

    pch_uart: fix a deadlock when pch_uart as console

    commit 384e301e3519599b000c1a2ecd938b533fc15d85 upstream.

    When we use pch_uart as system console like 'console=ttyPCH0,115200',
    then 'send break' to it. We'll encounter the deadlock on a cpu/core,
    with interrupts disabled on the core. When we happen to have all irqs
    affinity to cpu0 then the deadlock on cpu0 actually deadlock whole
    system.

    In pch_uart_interrupt, we have spin_lock_irqsave(&priv->lock, flags)
    then call pch_uart_err_ir when break is received. Then the call to
    dev_err would actually call to pch_console_write then we'll run into
    another spin_lock(&priv->lock), with interrupts disabled.

    So in the call sequence lead by pch_uart_interrupt, we should be
    carefully to call functions that will 'print message to console' only
    in case the uart port is not being used as serial console.

    Signed-off-by: Liang Li <liang.li@windriver.com>
    Cc: Yijing Wang <wangyijing@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c6c46477761504a89d5c68331f3b86fe31b51338
Author: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Date:   Fri Jun 28 14:15:15 2013 +0300

    UBIFS: fix a horrid bug

    commit 605c912bb843c024b1ed173dc427cd5c08e5d54d upstream.

    Al Viro pointed me to the fact that '->readdir()' and '->llseek()' have no
    mutual exclusion, which means the 'ubifs_dir_llseek()' can be run while we are
    in the middle of 'ubifs_readdir()'.

    This means that 'file->private_data' can be freed while 'ubifs_readdir()' uses
    it, and this is a very bad bug: not only 'ubifs_readdir()' can return garbage,
    but this may corrupt memory and lead to all kinds of problems like crashes an
    security holes.

    This patch fixes the problem by using the 'file->f_version' field, which
    '->llseek()' always unconditionally sets to zero. We set it to 1 in
    'ubifs_readdir()' and whenever we detect that it became 0, we know there was a
    seek and it is time to clear the state saved in 'file->private_data'.

    I tested this patch by writing a user-space program which runds readdir and
    seek in parallell. I could easily crash the kernel without these patches, but
    could not crash it with these patches.

    Reported-by: Al Viro <viro@zeniv.linux.org.uk>
    Tested-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
    Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1f4f917e5e882de1e701d7b26955884ed16604d5
Author: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Date:   Fri Jun 28 14:15:14 2013 +0300

    UBIFS: prepare to fix a horrid bug

    commit 33f1a63ae84dfd9ad298cf275b8f1887043ced36 upstream.

    Al Viro pointed me to the fact that '->readdir()' and '->llseek()' have no
    mutual exclusion, which means the 'ubifs_dir_llseek()' can be run while we are
    in the middle of 'ubifs_readdir()'.

    First of all, this means that 'file->private_data' can be freed while
    'ubifs_readdir()' uses it.  But this particular patch does not fix the problem.
    This patch is only a preparation, and the fix will follow next.

    In this patch we make 'ubifs_readdir()' stop using 'file->f_pos' directly,
    because 'file->f_pos' can be changed by '->llseek()' at any point. This may
    lead 'ubifs_readdir()' to returning inconsistent data: directory entry names
    may correspond to incorrect file positions.

    So here we introduce a local variable 'pos', read 'file->f_pose' once at very
    the beginning, and then stick to 'pos'. The result of this is that when
    'ubifs_dir_llseek()' changes 'file->f_pos' while we are in the middle of
    'ubifs_readdir()', the latter "wins".

    Reported-by: Al Viro <viro@zeniv.linux.org.uk>
    Tested-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
    Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5d28835c59b02d4389003bbfa7c4276375f39ed6
Author: Stephane Eranian <eranian@google.com>
Date:   Thu Jun 20 11:36:28 2013 +0200

    perf: Disable monitoring on setuid processes for regular users

    commit 2976b10f05bd7f6dab9f9e7524451ddfed656a89 upstream.

    There was a a bug in setup_new_exec(), whereby
    the test to disabled perf monitoring was not
    correct because the new credentials for the
    process were not yet committed and therefore
    the get_dumpable() test was never firing.

    The patch fixes the problem by moving the
    perf_event test until after the credentials
    are committed.

    Signed-off-by: Stephane Eranian <eranian@google.com>
    Tested-by: Jiri Olsa <jolsa@redhat.com>
    Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 806f529730af538c2edbb805589c48cc19ad169b
Author: Zefan Li <lizefan@huawei.com>
Date:   Wed Jun 26 15:31:58 2013 +0800

    dlci: validate the net device in dlci_del()

    commit 578a1310f2592ba90c5674bca21c1dbd1adf3f0a upstream.

    We triggered an oops while running trinity with 3.4 kernel:

    BUG: unable to handle kernel paging request at 0000000100000d07
    IP: [<ffffffffa0109738>] dlci_ioctl+0xd8/0x2d4 [dlci]
    PGD 640c0d067 PUD 0
    Oops: 0000 [#1] PREEMPT SMP
    CPU 3
    ...
    Pid: 7302, comm: trinity-child3 Not tainted 3.4.24.09+ 40 Huawei Technologies Co., Ltd. Tecal RH2285          /BC11BTSA
    RIP: 0010:[<ffffffffa0109738>]  [<ffffffffa0109738>] dlci_ioctl+0xd8/0x2d4 [dlci]
    ...
    Call Trace:
      [<ffffffff8137c5c3>] sock_ioctl+0x153/0x280
      [<ffffffff81195494>] do_vfs_ioctl+0xa4/0x5e0
      [<ffffffff8118354a>] ? fget_light+0x3ea/0x490
      [<ffffffff81195a1f>] sys_ioctl+0x4f/0x80
      [<ffffffff81478b69>] system_call_fastpath+0x16/0x1b
    ...

    It's because the net device is not a dlci device.

    Reported-by: Li Jinyue <lijinyue@huawei.com>
    Signed-off-by: Li Zefan <lizefan@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 72ad35befc4715ebb0d715b90f27572ef11a15e2
Author: Zefan Li <lizefan@huawei.com>
Date:   Wed Jun 26 15:29:54 2013 +0800

    dlci: acquire rtnl_lock before calling __dev_get_by_name()

    commit 11eb2645cbf38a08ae491bf6c602eea900ec0bb5 upstream.

    Otherwise the net device returned can be freed at anytime.

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

commit e2652ea43028e5409c2fd2b585dc8388a6e75bd0
Author: Oleg Nesterov <oleg@redhat.com>
Date:   Thu Jun 20 17:50:09 2013 +0200

    hw_breakpoint: Use cpu_possible_mask in {reserve,release}_bp_slot()

    commit c790b0ad23f427c7522ffed264706238c57c007e upstream.

    fetch_bp_busy_slots() and toggle_bp_slot() use
    for_each_online_cpu(), this is obviously wrong wrt cpu_up() or
    cpu_down(), we can over/under account the per-cpu numbers.

    For example:

        # echo 0 >> /sys/devices/system/cpu/cpu1/online
        # perf record -e mem:0x10 -p 1 &
        # echo 1 >> /sys/devices/system/cpu/cpu1/online
        # perf record -e mem:0x10,mem:0x10,mem:0x10,mem:0x10 -C1 -a &
        # taskset -p 0x2 1

    triggers the same WARN_ONCE("Can't find any breakpoint slot") in
    arch_install_hw_breakpoint().

    Reported-by: Vince Weaver <vincent.weaver@maine.edu>
    Signed-off-by: Oleg Nesterov <oleg@redhat.com>
    Acked-by: Frederic Weisbecker <fweisbec@gmail.com>
    Link: http://lkml.kernel.org/r/20130620155009.GA6327@redhat.com
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3ddc55287a4505a5634643fec8e02f887498ffc8
Author: Anderson Lizardo <anderson.lizardo@openbossa.org>
Date:   Sun Jun 2 16:30:40 2013 -0400

    Bluetooth: Fix crash in l2cap_build_cmd() with small MTU

    commit 300b962e5244a1ea010df7e88595faa0085b461d upstream.

    If a too small MTU value is set with ioctl(HCISETACLMTU) or by a bogus
    controller, memory corruption happens due to a memcpy() call with
    negative length.

    Fix this crash on either incoming or outgoing connections with a MTU
    smaller than L2CAP_HDR_SIZE + L2CAP_CMD_HDR_SIZE:

    [   46.885433] BUG: unable to handle kernel paging request at f56ad000
    [   46.888037] IP: [<c03d94cd>] memcpy+0x1d/0x40
    [   46.888037] *pdpt = 0000000000ac3001 *pde = 00000000373f8067 *pte = 80000000356ad060
    [   46.888037] Oops: 0002 [#1] SMP DEBUG_PAGEALLOC
    [   46.888037] Modules linked in: hci_vhci bluetooth virtio_balloon i2c_piix4 uhci_hcd usbcore usb_common
    [   46.888037] CPU: 0 PID: 1044 Comm: kworker/u3:0 Not tainted 3.10.0-rc1+ #12
    [   46.888037] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007
    [   46.888037] Workqueue: hci0 hci_rx_work [bluetooth]
    [   46.888037] task: f59b15b0 ti: f55c4000 task.ti: f55c4000
    [   46.888037] EIP: 0060:[<c03d94cd>] EFLAGS: 00010212 CPU: 0
    [   46.888037] EIP is at memcpy+0x1d/0x40
    [   46.888037] EAX: f56ac1c0 EBX: fffffff8 ECX: 3ffffc6e EDX: f55c5cf2
    [   46.888037] ESI: f55c6b32 EDI: f56ad000 EBP: f55c5c68 ESP: f55c5c5c
    [   46.888037]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
    [   46.888037] CR0: 8005003b CR2: f56ad000 CR3: 3557d000 CR4: 000006f0
    [   46.888037] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
    [   46.888037] DR6: ffff0ff0 DR7: 00000400
    [   46.888037] Stack:
    [   46.888037]  fffffff8 00000010 00000003 f55c5cac f8c6a54c ffffffff f8c69eb2 00000000
    [   46.888037]  f4783cdc f57f0070 f759c590 1001c580 00000003 0200000a 00000000 f5a88560
    [   46.888037]  f5ba2600 f5a88560 00000041 00000000 f55c5d90 f8c6f4c7 00000008 f55c5cf2
    [   46.888037] Call Trace:
    [   46.888037]  [<f8c6a54c>] l2cap_send_cmd+0x1cc/0x230 [bluetooth]
    [   46.888037]  [<f8c69eb2>] ? l2cap_global_chan_by_psm+0x152/0x1a0 [bluetooth]
    [   46.888037]  [<f8c6f4c7>] l2cap_connect+0x3f7/0x540 [bluetooth]
    [   46.888037]  [<c019b37b>] ? trace_hardirqs_off+0xb/0x10
    [   46.888037]  [<c01a0ff8>] ? mark_held_locks+0x68/0x110
    [   46.888037]  [<c064ad20>] ? mutex_lock_nested+0x280/0x360
    [   46.888037]  [<c064b9d9>] ? __mutex_unlock_slowpath+0xa9/0x150
    [   46.888037]  [<c01a118c>] ? trace_hardirqs_on_caller+0xec/0x1b0
    [   46.888037]  [<c064ad08>] ? mutex_lock_nested+0x268/0x360
    [   46.888037]  [<c01a125b>] ? trace_hardirqs_on+0xb/0x10
    [   46.888037]  [<f8c72f8d>] l2cap_recv_frame+0xb2d/0x1d30 [bluetooth]
    [   46.888037]  [<c01a0ff8>] ? mark_held_locks+0x68/0x110
    [   46.888037]  [<c064b9d9>] ? __mutex_unlock_slowpath+0xa9/0x150
    [   46.888037]  [<c01a118c>] ? trace_hardirqs_on_caller+0xec/0x1b0
    [   46.888037]  [<f8c754f1>] l2cap_recv_acldata+0x2a1/0x320 [bluetooth]
    [   46.888037]  [<f8c491d8>] hci_rx_work+0x518/0x810 [bluetooth]
    [   46.888037]  [<f8c48df2>] ? hci_rx_work+0x132/0x810 [bluetooth]
    [   46.888037]  [<c0158979>] process_one_work+0x1a9/0x600
    [   46.888037]  [<c01588fb>] ? process_one_work+0x12b/0x600
    [   46.888037]  [<c015922e>] ? worker_thread+0x19e/0x320
    [   46.888037]  [<c015922e>] ? worker_thread+0x19e/0x320
    [   46.888037]  [<c0159187>] worker_thread+0xf7/0x320
    [   46.888037]  [<c0159090>] ? rescuer_thread+0x290/0x290
    [   46.888037]  [<c01602f8>] kthread+0xa8/0xb0
    [   46.888037]  [<c0656777>] ret_from_kernel_thread+0x1b/0x28
    [   46.888037]  [<c0160250>] ? flush_kthread_worker+0x120/0x120
    [   46.888037] Code: c3 90 8d 74 26 00 e8 63 fc ff ff eb e8 90 55 89 e5 83 ec 0c 89 5d f4 89 75 f8 89 7d fc 3e 8d 74 26 00 89 cb 89 c7 c1 e9 02 89 d6 <f3> a5 89 d9 83 e1 03 74 02 f3 a4 8b 5d f4 8b 75 f8 8b 7d fc 89
    [   46.888037] EIP: [<c03d94cd>] memcpy+0x1d/0x40 SS:ESP 0068:f55c5c5c
    [   46.888037] CR2: 00000000f56ad000
    [   46.888037] ---[ end trace 0217c1f4d78714a9 ]---

    Signed-off-by: Anderson Lizardo <anderson.lizardo@openbossa.org>
    Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Linux 3.0.86

commit a62a87169d61229a5e55364cf80d168860298ad2
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Sat Jul 13 10:34:59 2013 -0700

    Linux 3.0.86

commit 3bb0ab9e10eecc932df94807cacb90ca30010cb7
Author: Ben Hutchings <ben@decadent.org.uk>
Date:   Mon May 27 19:07:19 2013 +0100

    SCSI: sd: Fix parsing of 'temporary ' cache mode prefix

    commit 2ee3e26c673e75c05ef8b914f54fadee3d7b9c88 upstream.

    Commit 39c60a0948cc '[SCSI] sd: fix array cache flushing bug causing
    performance problems' added temp as a pointer to "temporary " and used
    sizeof(temp) - 1 as its length.  But sizeof(temp) is the size of the
    pointer, not the size of the string constant.  Change temp to a static
    array so that sizeof() does what was intended.

    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5583db3830ede897a8e4709452bcf0bc5266bdd9
Author: J. Bruce Fields <bfields@redhat.com>
Date:   Fri Jun 21 11:48:11 2013 -0400

    nfsd4: fix decoding of compounds across page boundaries

    commit 247500820ebd02ad87525db5d9b199e5b66f6636 upstream.

    A freebsd NFSv4.0 client was getting rare IO errors expanding a tarball.
    A network trace showed the server returning BAD_XDR on the final getattr
    of a getattr+write+getattr compound.  The final getattr started on a
    page boundary.

    I believe the Linux client ignores errors on the post-write getattr, and
    that that's why we haven't seen this before.

    Reported-by: Rick Macklem <rmacklem@uoguelph.ca>
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d16bc599dea23cb3414b64323f2051093f8bee14
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Tue Jun 18 12:58:12 2013 -0700

    MAINTAINERS: add stable_kernel_rules.txt to stable maintainer information

    commit 7b175c46720f8e6b92801bb634c93d1016f80c62 upstream.

    This hopefully will help point developers to the proper way that patches
    should be submitted for inclusion in the stable kernel releases.

    Reported-by: David Howells <dhowells@redhat.com>
    Acked-by: David Howells <dhowells@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ef68389b70f111c1be62eb084071ed2770bde981
Author: Kees Cook <keescook@chromium.org>
Date:   Wed Jul 3 15:01:15 2013 -0700

    crypto: sanitize argument for format string

    commit 1c8fca1d92e14859159a82b8a380d220139b7344 upstream.

    The template lookup interface does not provide a way to use format
    strings, so make sure that the interface cannot be abused accidentally.

    Signed-off-by: Kees Cook <keescook@chromium.org>
    Cc: Herbert Xu <herbert@gondor.apana.org.au>
    Cc: "David S. Miller" <davem@davemloft.net>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cb065a908d47441cfc660d1cc0a50fceefa0cda0
Author: Kees Cook <keescook@chromium.org>
Date:   Wed Jul 3 15:01:14 2013 -0700

    block: do not pass disk names as format strings

    commit ffc8b30866879ed9ba62bd0a86fecdbd51cd3d19 upstream.

    Disk names may contain arbitrary strings, so they must not be
    interpreted as format strings.  It seems that only md allows arbitrary
    strings to be used for disk names, but this could allow for a local
    memory corruption from uid 0 into ring 0.

    CVE-2013-2851

    Signed-off-by: Kees Cook <keescook@chromium.org>
    Cc: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c55035cb085d79311a429129183f43b85bac3994
Author: Mikulas Patocka <mikulas@artax.karlin.mff.cuni.cz>
Date:   Thu Jul 4 18:42:29 2013 +0200

    hpfs: better test for errors

    commit 3ebacb05044f82c5f0bb456a894eb9dc57d0ed90 upstream.

    The test if bitmap access is out of bound could errorneously pass if the
    device size is divisible by 16384 sectors and we are asking for one bitmap
    after the end.

    Check for invalid size in the superblock. Invalid size could cause integer
    overflows in the rest of the code.

    Signed-off-by: Mikulas Patocka <mpatocka@artax.karlin.mff.cuni.cz>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a6ca6dff63f92efa17810ac0a4d33e3b63670482
Author: Jonathan Salwan <jonathan.salwan@gmail.com>
Date:   Wed Jul 3 15:01:13 2013 -0700

    drivers/cdrom/cdrom.c: use kzalloc() for failing hardware

    commit 542db01579fbb7ea7d1f7bb9ddcef1559df660b2 upstream.

    In drivers/cdrom/cdrom.c mmc_ioctl_cdrom_read_data() allocates a memory
    area with kmalloc in line 2885.

      2885         cgc->buffer = kmalloc(blocksize, GFP_KERNEL);
      2886         if (cgc->buffer == NULL)
      2887                 return -ENOMEM;

    In line 2908 we can find the copy_to_user function:

      2908         if (!ret && copy_to_user(arg, cgc->buffer, blocksize))

    The cgc->buffer is never cleaned and initialized before this function.
    If ret = 0 with the previous basic block, it's possible to display some
    memory bytes in kernel space from userspace.

    When we read a block from the disk it normally fills the ->buffer but if
    the drive is malfunctioning there is a chance that it would only be
    partially filled.  The result is an leak information to userspace.

    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Cc: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Jonathan Salwan <jonathan.salwan@gmail.com>
    Cc: Luis Henriques <luis.henriques@canonical.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 314d3e7c43ea9125ef257dad74f494c0c82b7fe3
Author: Tyler Hicks <tyhicks@canonical.com>
Date:   Thu Jun 20 13:13:59 2013 -0700

    libceph: Fix NULL pointer dereference in auth client code

    commit 2cb33cac622afde897aa02d3dcd9fbba8bae839e upstream.

    A malicious monitor can craft an auth reply message that could cause a
    NULL function pointer dereference in the client's kernel.

    To prevent this, the auth_none protocol handler needs an empty
    ceph_auth_client_ops->build_request() function.

    CVE-2013-1059

    Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
    Reported-by: Chanam Park <chanam.park@hkpco.kr>
    Reviewed-by: Seth Arnold <seth.arnold@canonical.com>
    Reviewed-by: Sage Weil <sage@inktank.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Conflicts:
	drivers/scsi/sd.c

Conflicts:
	drivers/scsi/sd.c
Make smartassv2 & sio defaults in spade- & spade-perf_defconfigs
Enable CONFIG_CC_OPTIMIZE_FOR_SIZE=y