commit 0c468cadbbc7a65c11042113b63838b16affa5d0
Author: Sabrina Dubroca <sd@queasysnail.net>
Date:   Wed Nov 4 14:47:53 2015 +0100

    ipv6: clean up dev_snmp6 proc entry when we fail to initialize inet6_dev

    [ Upstream commit 2a189f9e57650e9f310ddf4aad75d66c1233a064 ]

    In ipv6_add_dev, when addrconf_sysctl_register fails, we do not clean up
    the dev_snmp6 entry that we have already registered for this device.
    Call snmp6_unregister_dev in this case.

    Fixes: a317a2f19da7d ("ipv6: fail early when creating netdev named all or default")
    Reported-by: Dmitry Vyukov <dvyukov@google.com>
    Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit b724151849d9b60289ff4f829a544defc5e31881
Author: Martin Habets <mhabets@solarflare.com>
Date:   Mon Nov 2 12:51:31 2015 +0000

    sfc: push partner queue for skb->xmit_more

    [ Upstream commit b2663a4f30e85ec606b806f5135413e6d5c78d1e ]

    When the IP stack passes SKBs the sfc driver puts them in 2 different TX
    queues (called partners), one for checksummed and one for not checksummed.
    If the SKB has xmit_more set the driver will delay pushing the work to the
    NIC.

    When later it does decide to push the buffers this patch ensures it also
    pushes the partner queue, if that also has any delayed work. Before this
    fix the work in the partner queue would be left for a long time and cause
    a netdev watchdog.

    Fixes: 70b33fb ("sfc: add support for skb->xmit_more")
    Reported-by: Jianlin Shi <jishi@redhat.com>
    Signed-off-by: Martin Habets <mhabets@solarflare.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 5a38002ee58d2ac061b289fc4f34c4da72598583
Author: Eric Dumazet <edumazet@google.com>
Date:   Mon Nov 2 17:08:19 2015 -0800

    sit: fix sit0 percpu double allocations

    [ Upstream commit 4ece9009774596ee3df0acba65a324b7ea79387c ]

    sit0 device allocates its percpu storage twice :
    - One time in ipip6_tunnel_init()
    - One time in ipip6_fb_tunnel_init()

    Thus we leak 48 bytes per possible cpu per network namespace dismantle.

    ipip6_fb_tunnel_init() can be much simpler and does not
    return an error, and should be called after register_netdev()

    Note that ipip6_tunnel_clone_6rd() also needs to be called
    after register_netdev() (calling ipip6_tunnel_init())

    Fixes: ebe084aafb7e ("sit: Use ipip6_tunnel_init as the ndo_init function.")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: Dmitry Vyukov <dvyukov@google.com>
    Cc: Steffen Klassert <steffen.klassert@secunet.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit c48cc8bb582a83b2c64044abb73ad43900b13ef4
Author: Eric Dumazet <edumazet@google.com>
Date:   Sat Oct 24 05:47:44 2015 -0700

    ipv6: gre: support SIT encapsulation

    [ Upstream commit 7e3b6e7423d5f994257c1de88e06b509673fdbcf ]

    gre_gso_segment() chokes if SIT frames were aggregated by GRO engine.

    Fixes: 61c1db7fae21e ("ipv6: sit: add GSO/TSO support")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit a83ab982ddbf61296f323c709ba7c0a3622a16a6
Author: Bjørn Mork <bjorn@mork.no>
Date:   Thu Oct 22 14:15:58 2015 +0200

    qmi_wwan: add Sierra Wireless MC74xx/EM74xx

    [ Upstream commit 0db65fcfcded76fe4f74e3ca9f4e2baf67b683ef ]

    New device IDs shamelessly lifted from the vendor driver.

    Signed-off-by: Bjørn Mork <bjorn@mork.no>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit f20b58288d77730caa69f8767977f7fc25d10f95
Author: Jason Wang <jasowang@redhat.com>
Date:   Wed Aug 5 10:34:04 2015 +0800

    virtio-net: drop NETIF_F_FRAGLIST

    [ Upstream commit 48900cb6af4282fa0fb6ff4d72a81aa3dadb5c39 ]

    virtio declares support for NETIF_F_FRAGLIST, but assumes
    that there are at most MAX_SKB_FRAGS + 2 fragments which isn't
    always true with a fraglist.

    A longer fraglist in the skb will make the call to skb_to_sgvec overflow
    the sg array, leading to memory corruption.

    Drop NETIF_F_FRAGLIST so we only get what we can handle.

    Cc: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: Jason Wang <jasowang@redhat.com>
    Acked-by: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 65dcc613f928ec6ed8f7bfbce217720a7f6c0ebc
Author: Eric Dumazet <edumazet@google.com>
Date:   Mon Nov 9 17:51:23 2015 -0800

    net: fix a race in dst_release()

    [ Upstream commit d69bbf88c8d0b367cf3e3a052f6daadf630ee566 ]

    Only cpu seeing dst refcount going to 0 can safely
    dereference dst->flags.

    Otherwise an other cpu might already have freed the dst.

    Fixes: 27b75c95f10d ("net: avoid RCU for NOCACHE dst")
    Reported-by: Greg Thelen <gthelen@google.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 59c3d7e9dadeb4960db61fc97239beb5d12a5773
Author: Eric Dumazet <edumazet@google.com>
Date:   Fri Oct 2 16:54:31 2015 -0700

    net: avoid NULL deref in inet_ctl_sock_destroy()

    [ Upstream commit 8fa677d2706d325d71dab91bf6e6512c05214e37 ]

    Under low memory conditions, tcp_sk_init() and icmp_sk_init()
    can both iterate on all possible cpus and call inet_ctl_sock_destroy(),
    with eventual NULL pointer.

    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: Dmitry Vyukov <dvyukov@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 66858ce4963d3b5ea33920f104cdd7919554ce81
Author: Bjørn Mork <bjorn@mork.no>
Date:   Thu Oct 1 16:54:31 2015 -0700

    qmi_wwan: fix entry for HP lt4112 LTE/HSPA+ Gobi 4G Module

    [ Upstream commit 70910791731b5956171e1bfcad707766b8e18fee ]

    The lt4112 is a HP branded Huawei me906e modem. Like other Huawei
    modems, it does not have a fixed interface to function mapping.
    Instead it uses a Huawei specific scheme: functions are mapped by
    subclass and protocol.

    However, the HP vendor ID is used for modems from many different
    manufacturers using different schemes, so we cannot apply a generic
    vendor rule like we do for the Huawei vendor ID.

    Replace the previous lt4112 entry pointing to an arbitrary interface
    number with a device specific subclass + protocol match.

    Reported-and-tested-by: Muri Nicanor <muri+libqmi@immerda.ch>
    Tested-by: Martin Hauke <mardnh@gmx.de>
    Fixes: bb2bdeb83fb1 ("qmi_wwan: Add support for HP lt4112 LTE/HSPA+ Gobi 4G Modem")
    Signed-off-by: Bjørn Mork <bjorn@mork.no>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit ecc599de1f4b9db6f71025c8ad24b0bf682a8bfc
Author: Ani Sinha <ani@arista.com>
Date:   Fri Oct 30 16:54:31 2015 -0700

    ipmr: fix possible race resulting from improper usage of IP_INC_STATS_BH() in preemptible context.

    [ Upstream commit 44f49dd8b5a606870a1f21101522a0f9c4414784 ]

    Fixes the following kernel BUG :

    BUG: using __this_cpu_add() in preemptible [00000000] code: bash/2758
    caller is __this_cpu_preempt_check+0x13/0x15
    CPU: 0 PID: 2758 Comm: bash Tainted: P           O   3.18.19 #2
     ffffffff8170eaca ffff880110d1b788 ffffffff81482b2a 0000000000000000
     0000000000000000 ffff880110d1b7b8 ffffffff812010ae ffff880007cab800
     ffff88001a060800 ffff88013a899108 ffff880108b84240 ffff880110d1b7c8
    Call Trace:
    [<ffffffff81482b2a>] dump_stack+0x52/0x80
    [<ffffffff812010ae>] check_preemption_disabled+0xce/0xe1
    [<ffffffff812010d4>] __this_cpu_preempt_check+0x13/0x15
    [<ffffffff81419d60>] ipmr_queue_xmit+0x647/0x70c
    [<ffffffff8141a154>] ip_mr_forward+0x32f/0x34e
    [<ffffffff8141af76>] ip_mroute_setsockopt+0xe03/0x108c
    [<ffffffff810553fc>] ? get_parent_ip+0x11/0x42
    [<ffffffff810e6974>] ? pollwake+0x4d/0x51
    [<ffffffff81058ac0>] ? default_wake_function+0x0/0xf
    [<ffffffff810553fc>] ? get_parent_ip+0x11/0x42
    [<ffffffff810613d9>] ? __wake_up_common+0x45/0x77
    [<ffffffff81486ea9>] ? _raw_spin_unlock_irqrestore+0x1d/0x32
    [<ffffffff810618bc>] ? __wake_up_sync_key+0x4a/0x53
    [<ffffffff8139a519>] ? sock_def_readable+0x71/0x75
    [<ffffffff813dd226>] do_ip_setsockopt+0x9d/0xb55
    [<ffffffff81429818>] ? unix_seqpacket_sendmsg+0x3f/0x41
    [<ffffffff813963fe>] ? sock_sendmsg+0x6d/0x86
    [<ffffffff813959d4>] ? sockfd_lookup_light+0x12/0x5d
    [<ffffffff8139650a>] ? SyS_sendto+0xf3/0x11b
    [<ffffffff810d5738>] ? new_sync_read+0x82/0xaa
    [<ffffffff813ddd19>] compat_ip_setsockopt+0x3b/0x99
    [<ffffffff813fb24a>] compat_raw_setsockopt+0x11/0x32
    [<ffffffff81399052>] compat_sock_common_setsockopt+0x18/0x1f
    [<ffffffff813c4d05>] compat_SyS_setsockopt+0x1a9/0x1cf
    [<ffffffff813c4149>] compat_SyS_socketcall+0x180/0x1e3
    [<ffffffff81488ea1>] cstar_dispatch+0x7/0x1e

    Signed-off-by: Ani Sinha <ani@arista.com>
    Acked-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 468880892e5f3dfac1176c01dccdffb9551cf45e
Author: Phil Reid <preid@electromag.com.au>
Date:   Fri Oct 30 16:43:55 2015 +0800

    stmmac: Correctly report PTP capabilities.

    [ Upstream commit e6dbe1eb2db0d7a14991c06278dd3030c45fb825 ]

    priv->hwts_*_en indicate if timestamping is enabled/disabled at run
    time. But  priv->dma_cap.time_stamp  and priv->dma_cap.atime_stamp
    indicates HW is support for PTPv1/PTPv2.

    Signed-off-by: Phil Reid <preid@electromag.com.au>
    Acked-by: Richard Cochran <richardcochran@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit b9eb1e61a9a96922a67c10822751ec5eeb5cc45f
Author: Carol L Soto <clsoto@linux.vnet.ibm.com>
Date:   Tue Oct 27 17:36:20 2015 +0200

    net/mlx4: Copy/set only sizeof struct mlx4_eqe bytes

    [ Upstream commit c02b05011fadf8e409e41910217ca689f2fc9d91 ]

    When doing memcpy/memset of EQEs, we should use sizeof struct
    mlx4_eqe as the base size and not caps.eqe_size which could be bigger.

    If caps.eqe_size is bigger than the struct mlx4_eqe then we corrupt
    data in the master context.

    When using a 64 byte stride, the memcpy copied over 63 bytes to the
    slave_eq structure.  This resulted in copying over the entire eqe of
    interest, including its ownership bit -- and also 31 bytes of garbage
    into the next WQE in the slave EQ -- which did NOT include the ownership
    bit (and therefore had no impact).

    However, once the stride is increased to 128, we are overwriting the
    ownership bits of *three* eqes in the slave_eq struct.  This results
    in an incorrect ownership bit for those eqes, which causes the eq to
    seem to be full. The issue therefore surfaced only once 128-byte EQEs
    started being used in SRIOV and (overarchitectures that have 128/256
    byte cache-lines such as PPC) - e.g after commit 77507aa249ae
    "net/mlx4_core: Enable CQE/EQE stride support".

    Fixes: 08ff32352d6f ('mlx4: 64-byte CQE/EQE support')
    Signed-off-by: Carol L Soto <clsoto@linux.vnet.ibm.com>
    Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
    Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit fe9583e4721327a089e841713baa63b4fa27c07d
Author: Sowmini Varadhan <sowmini.varadhan@oracle.com>
Date:   Mon Oct 26 12:46:37 2015 -0400

    RDS-TCP: Recover correctly from pskb_pull()/pksb_trim() failure in rds_tcp_data_recv

    [ Upstream commit 8ce675ff39b9958d1c10f86cf58e357efaafc856 ]

    Either of pskb_pull() or pskb_trim() may fail under low memory conditions.
    If rds_tcp_data_recv() ignores such failures, the application will
    receive corrupted data because the skb has not been correctly
    carved to the RDS datagram size.

    Avoid this by handling pskb_pull/pskb_trim failure in the same
    manner as the skb_clone failure: bail out of rds_tcp_data_recv(), and
    retry via the deferred call to rds_send_worker() that gets set up on
    ENOMEM from rds_tcp_read_sock()

    Signed-off-by: Sowmini Varadhan <sowmini.varadhan@oracle.com>
    Acked-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit b7491ba5218ead37c335f6457848c8e93c655055
Author: Guillaume Nault <g.nault@alphalink.fr>
Date:   Thu Oct 22 16:57:10 2015 +0200

    ppp: fix pppoe_dev deletion condition in pppoe_release()

    [ Upstream commit 1acea4f6ce1b1c0941438aca75dd2e5c6b09db60 ]

    We can't rely on PPPOX_ZOMBIE to decide whether to clear po->pppoe_dev.
    PPPOX_ZOMBIE can be set by pppoe_disc_rcv() even when po->pppoe_dev is
    NULL. So we have no guarantee that (sk->sk_state & PPPOX_ZOMBIE) implies
    (po->pppoe_dev != NULL).
    Since we're releasing a PPPoE socket, we want to release the pppoe_dev
    if it exists and reset sk_state to PPPOX_DEAD, no matter the previous
    value of sk_state. So we can just check for po->pppoe_dev and avoid any
    assumption on sk->sk_state.

    Fixes: 2b018d57ff18 ("pppoe: drop PPPOX_ZOMBIEs in pppoe_release")
    Signed-off-by: Guillaume Nault <g.nault@alphalink.fr>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 08b66c123bd04c501b3f2299c4dd885aca9160c5
Author: Jason Wang <jasowang@redhat.com>
Date:   Fri Oct 23 00:57:05 2015 -0400

    macvtap: unbreak receiving of gro skb with frag list

    [ Upstream commit f23d538bc24a83c16127c2eb82c9cf1adc2b5149 ]

    We don't have fraglist support in TAP_FEATURES. This will lead
    software segmentation of gro skb with frag list. Fixes by having
    frag list support in TAP_FEATURES.

    With this patch single session of netperf receiving were restored from
    about 5Gb/s to about 12Gb/s on mlx4.

    Fixes a567dd6252 ("macvtap: simplify usage of tap_features")
    Cc: Vlad Yasevich <vyasevic@redhat.com>
    Cc: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: Jason Wang <jasowang@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 7d2c8abc68d63e287fe36a9df9bc59e5a47719ba
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Mon Oct 19 13:16:49 2015 +0300

    irda: precedence bug in irlmp_seq_hb_idx()

    [ Upstream commit 50010c20597d14667eff0fdb628309986f195230 ]

    This is decrementing the pointer, instead of the value stored in the
    pointer.  KASan detects it as an out of bounds reference.

    Reported-by: "Berry Cheng 程君(成淼)" <chengmiao.cj@alibaba-inc.com>
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit b32d475dbf53b9be47ea1092539012dad1f7932b
Author: Paul Moore <pmoore@redhat.com>
Date:   Tue Dec 30 09:26:21 2014 -0500

    audit: create private file name copies when auditing inodes

    [ Upstream commit fcf22d8267ad2601fe9b6c549d1be96401c23e0b ]

    Unfortunately, while commit 4a928436 ("audit: correctly record file
    names with different path name types") fixed a problem where we were
    not recording filenames, it created a new problem by attempting to use
    these file names after they had been freed.  This patch resolves the
    issue by creating a copy of the filename which the audit subsystem
    frees after it is done with the string.

    At some point it would be nice to resolve this issue with refcounts,
    or something similar, instead of having to allocate/copy strings, but
    that is almost surely beyond the scope of a -rcX patch so we'll defer
    that for later.  On the plus side, only audit users should be impacted
    by the string copying.

    Reported-by: Toralf Foerster <toralf.foerster@gmx.de>
    Signed-off-by: Paul Moore <pmoore@redhat.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 2f1d09037eeab4f3c89465fcb876a76ff651e12a
Author: Paul Moore <pmoore@redhat.com>
Date:   Mon Dec 22 12:27:39 2014 -0500

    audit: correctly record file names with different path name types

    [ Upstream commit 4a92843601ad0f5067f441d2f0dca55bbe18c076 ]

    There is a problem with the audit system when multiple audit records
    are created for the same path, each with a different path name type.
    The root cause of the problem is in __audit_inode() when an exact
    match (both the path name and path name type) is not found for a
    path name record; the existing code creates a new path name record,
    but it never sets the path name in this record, leaving it NULL.
    This patch corrects this problem by assigning the path name to these
    newly created records.

    There are many ways to reproduce this problem, but one of the
    easiest is the following (assuming auditd is running):

      # mkdir /root/tmp/test
      # touch /root/tmp/test/567
      # auditctl -a always,exit -F dir=/root/tmp/test
      # touch /root/tmp/test/567

    Afterwards, or while the commands above are running, check the audit
    log and pay special attention to the PATH records.  A faulty kernel
    will display something like the following for the file creation:

      type=SYSCALL msg=audit(1416957442.025:93): arch=c000003e syscall=2
        success=yes exit=3 ... comm="touch" exe="/usr/bin/touch"
      type=CWD msg=audit(1416957442.025:93):  cwd="/root/tmp"
      type=PATH msg=audit(1416957442.025:93): item=0 name="test/"
        inode=401409 ... nametype=PARENT
      type=PATH msg=audit(1416957442.025:93): item=1 name=(null)
        inode=393804 ... nametype=NORMAL
      type=PATH msg=audit(1416957442.025:93): item=2 name=(null)
        inode=393804 ... nametype=NORMAL

    While a patched kernel will show the following:

      type=SYSCALL msg=audit(1416955786.566:89): arch=c000003e syscall=2
        success=yes exit=3 ... comm="touch" exe="/usr/bin/touch"
      type=CWD msg=audit(1416955786.566:89):  cwd="/root/tmp"
      type=PATH msg=audit(1416955786.566:89): item=0 name="test/"
        inode=401409 ... nametype=PARENT
      type=PATH msg=audit(1416955786.566:89): item=1 name="test/567"
        inode=393804 ... nametype=NORMAL

    This issue was brought up by a number of people, but special credit
    should go to hujianyang@huawei.com for reporting the problem along
    with an explanation of the problem and a patch.  While the original
    patch did have some problems (see the archive link below), it did
    demonstrate the problem and helped kickstart the fix presented here.

      * https://lkml.org/lkml/2014/9/5/66

    Reported-by: hujianyang <hujianyang@huawei.com>
    Signed-off-by: Paul Moore <pmoore@redhat.com>
    Acked-by: Richard Guy Briggs <rgb@redhat.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit f0146c7ff3129ad8137ade130c0a804e63d1579d
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Fri Jul 3 11:53:03 2015 +0300

    mptfusion: prevent some memory corruption

    [ Upstream commit e819cdb198319cccf4af4fc12ac4d796109d8c23 ]

    These are signed values the come from the user, we put a cap on the
    upper bounds but not on the lower bounds.

    We use "karg.dataSgeOffset" to calculate "sz".  We verify "sz" and
    proceed as if that means that "karg.dataSgeOffset" is correct but this
    fails to consider that the "sz" calculations can have integer overflows.

    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
    Signed-off-by: James Bottomley <JBottomley@Odin.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit fd9ffdd1f79f1fd442b186c6fd702b4d71459c3c
Author: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Date:   Tue Jul 7 15:28:13 2015 +0100

    mfd: wm5110: Add register patch for rev E and above

    [ Upstream commit 81207880cef207cd89db863f9aa1d65f22b4f2a2 ]

    Add a register patch for rev E and above that configures the location of
    some write sequences to assist with the headphone enables.

    Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
    Acked-by: Lee Jones <lee.jones@linaro.org>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 1da953c20a7eca9d2dfe9c260c3f1a61ed44969e
Author: Nicholas Mc Guire <hofrat@osadl.org>
Date:   Sun Jun 7 11:34:40 2015 -0300

    [media] gscpa_m5602: use msecs_to_jiffies for conversions

    [ Upstream commit 63f2f417526fc54191f2b813f72dc1d5322bede8 ]

    API compliance scanning with coccinelle flagged:
    ./drivers/media/usb/gspca/m5602/m5602_s5k83a.c:180:9-25:
             WARNING: timeout (100) seems HZ dependent

    Numeric constants passed to schedule_timeout() make the effective
    timeout HZ dependent which makes little sense in a polling loop for
    the cameras rotation state.
    Fixed up by converting the constant to jiffies with msecs_to_jiffies()

    Signed-off-by: Nicholas Mc Guire <hofrat@osadl.org>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 52d42a7c1aac255fa0699497b5adeebe921da9bf
Author: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
Date:   Wed Jan 28 22:53:53 2015 -0200

    [media] v4l: vsp1: Fix VI6_WPF_SZCLIP_SIZE_MASK macro

    [ Upstream commit 03b36e4dcf422a10da8b67bce2ed00b34ec58aac ]

    Clipping size bit of VI6_WPFn _HSZCLIP and VI6_WPFn _VSZCLIP register are from
    0 bit to 11 bit. But VI6_WPF_SZCLIP_SIZE_MASK is set to 0x1FFF, this will mask
    until the reserve bits. This fixes size for VI6_WPF_SZCLIP_SIZE_MASK.

    Signed-off-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
    Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 8a6f1ccc84f161442f80fc8a6dfe7eebcac18d0e
Author: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
Date:   Wed Jan 28 22:53:54 2015 -0200

    [media] v4l: vsp1: Fix VI6_DPR_ROUTE_FP_MASK macro

    [ Upstream commit 1aa7890324b497f96f07c20673fae58f26fabfe7 ]

    FP bit of VI6_DPR_mod_ROUTE register is 6bit. But VI6_DPR_ROUTE_FP_MASK is set
    to 0xFF, this will mask until the reserve bit.
    This fixes size for VI6_DPR_ROUTE_FP_MASK.

    Signed-off-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
    Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 0d4bca31e2974e42e6df0519b8a0b8bad1d463a8
Author: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
Date:   Wed Jan 28 22:53:55 2015 -0200

    [media] v4l: vsp1: Fix VI6_DPR_ROUTE_FXA_MASK macro

    [ Upstream commit 45008ee9295b3ae96d7413ab91871907a671ca82 ]

    FXA bit of VI6_DPR_mod_ROUTE register starts from 16bit. But VI6_DPR_ROUTE_FXA_MASK
    is set to become start from 8bit. This fixes shift size for VI6_DPR_ROUTE_FXA_MASK.

    Signed-off-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
    Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 23e0e849bb6f3a6ea2f58c779a3876de012da152
Author: Hans Verkuil <hans.verkuil@cisco.com>
Date:   Mon Jul 20 09:59:35 2015 -0300

    [media] usbvision: fix locking error

    [ Upstream commit e2c84ccb0fbe5e524d15bb09c042a6ca634adaed ]

    If remove_pending is non-zero, then the v4l2_lock is never unlocked.

    Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit ccee6c265e76bdc9f7ea4a42c0db27e28b39dcbf
Author: Andrew Morton <akpm@linux-foundation.org>
Date:   Mon Sep 28 16:38:07 2015 -0700

    Input: zhenhua - ensure we have BITREVERSE

    [ Upstream commit d3b367bc26ea2e07a83fe73f0ccbddd729cb1f9a ]

    It uses bitrev8(), so it must ensure that lib/bitrev.o gets included in
    vmlinux.

    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit c9366743e025947f8ec2e0b9fb2dca60bed947db
Author: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
Date:   Mon Sep 28 15:59:22 2015 -0700

    Input: omap4-keypad - fix memory leak

    [ Upstream commit d79bdc7f004404204a6ac07785f8d6717070ecdb ]

    If omap4_keypad_parse_dt() fails we returned the error code but we
    missed releasing keypad_data.

    Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit e6004b4d70df3607e2c258e69d2ada8234f9c7cb
Author: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
Date:   Sun Sep 27 17:13:55 2015 -0700

    Input: serio - fix blocking of parport

    [ Upstream commit 1a5e251996e1b602f2ddc9261ee9de0ca1875bfa ]

    If parkbd_allocate_serio() fails to allocate memory we are releasing the
    parport but we missed unregistering the device. As a result this device
    with exclusive access to that parport remains registered. And no other
    device will be able to use that parport even though this driver has
    failed to load.

    Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 7c4e78f59a93be4b62c7eee2aa7e14b92d38270c
Author: Stefan Assmann <sassmann@kpanic.de>
Date:   Wed Aug 26 13:11:49 2015 -0700

    Input: psmouse - add small delay for IBM trackpoint pass-through mode

    [ Upstream commit 66bc2f51ef7deabc8b8f3baa98ae64b65e5e973a ]

    There are trackpoint devices that fail to respond to the PS2 command
    PSMOUSE_CMD_GETID if immediately queried after the parent device is
    deactivated. Add a small delay for the hardware to get in a sane state
    before sending any PS2 commands.

    One example of such a system is:
    Lenovo ThinkPad X120e, model 30515QG
    synaptics: Touchpad model: 1, fw: 8.0, id: 0x1e2b1, caps: 0xd001a3/0x940300/0x121c00, board id: 1811, fw id: 797391

    Signed-off-by: Stefan Assmann <sassmann@kpanic.de>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 4af4b38c1078c66b4d55a55a60393c414eb03602
Author: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Date:   Fri Aug 21 10:18:08 2015 -0400

    HID: quirks: add QUIRK_NOGET for an other TPV touchscreen

    [ Upstream commit c9b57724b38d4c1555ee49418be3d76801e3327c ]

    Looks like 0x8882 needs the same quirk than 0x8883.
    Given that both devices claim they are "TPV OpticalTouchScreen" rename
    the 0x8883 to add its PID in the #define.

    Reported-by: Blaine Lee <blaine.j.lee@medtronic.com>
    Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 850ab913a9af3d87c7b5e240e1004e480691fee9
Author: Henrik Rydberg <rydberg@bitmath.org>
Date:   Fri Jul 24 14:45:05 2015 -0700

    HID: apple: Add support for the 2015 Macbook Pro

    [ Upstream commit a4a2c54560f2c57b88ba0283f141b44f594c2337 ]

    This patch adds keyboard support for MacbookPro12,1 as WELLSPRING9
    (0x0272, 0x0273, 0x0274). The touchpad is handled in a separate
    bcm5974 patch, as usual.

    Tested-by: John Horan <knasher@gmail.com>
    Tested-by: Jochen Radmacher <jradmacher@gmx.de>
    Tested-by: Yang Hongyang <burnef@gmail.com>
    Tested-by: Yen-Chin, Lee <coldnew.tw@gmail.com>
    Tested-by: George Hilios <ghilios@gmail.com>
    Tested-by: Janez Urevc <janez@janezurevc.name>
    Signed-off-by: Henrik Rydberg <rydberg@bitmath.org>
    Acked-by: Jiri Kosina <jkosina@suse.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 9f5c910b9c85796629adfc35fab903cb90b9b97a
Author: Bin Liu <b-liu@ti.com>
Date:   Mon Aug 24 15:28:37 2015 -0500

    usb: musb: fix cppi channel teardown for isoch transfer

    [ Upstream commit b431ba8803666e56c1d178a421b3cbc36e8d3d33 ]

    After a few iterations of start/stop UVC camera streaming, the streaming
    stops.

    This patch adds 250us delay in the cppi channel abort path to let cppi
    drain properly.

    Using 50us delay seems to be too aggressive, some webcams are still
    broken. 250us is the original value used in TI 3.2 kernel.

    Signed-off-by: Bin Liu <b-liu@ti.com>
    Signed-off-by: Felipe Balbi <balbi@ti.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 9a032d2a1f8a7453dd47cb0e3870ad02590499cd
Author: Bin Liu <b-liu@ti.com>
Date:   Mon Jan 26 16:22:07 2015 -0600

    usb: musb: cppi41: improve rx channel abort routine

    [ Upstream commit cb83df77f3ec151d68a1b6be957207e6fc7b7f50 ]

    1. set AUTOREQ to NONE at the beginning of teardown;

    2. add delay for dma pipeline to drain;

    3. Do not set USB_TDOWN bit for RX teardown.

      The CPPI hw has an issue that when tearing down a RX channel, if
      another RX channel is receiving data, the CPPI will lockup.

      To workaround the issue, do not set the CPPI TD bit. The steps before
      this point ensures the CPPI channel will be torn down properly.

    Signed-off-by: Bin Liu <b-liu@ti.com>
    Signed-off-by: Felipe Balbi <balbi@ti.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 039a1e26d6f0fb392ae4ca82e91dc78228b024f9
Author: Philipp Hachtmann <hachti@hachti.de>
Date:   Mon Aug 17 17:31:47 2015 +0200

    USB: symbolserial: Correct transferred data size

    [ Upstream commit 8ae25a355b5969e12f3185e8cb8eb08b871c9084 ]

    The scanner (here DS3508) always returns 64 bytes per urb buffer. The first
    byte indicates the data length used in the current buffer. There even was
    a comment describing this. But the comment also said that we'll send
    everything in the buffer to the tty layer. That means sending the actual
    barcode data and lots of trailing zeroes. This patch lets the driver only
    send the real data.

    Signed-off-by: Philipp Hachtmann <hachti@hachti.de>
    Acked-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit c357a87557409fe0c9a0b21ccfd85edf4f7eb948
Author: Li Jun <jun.li@freescale.com>
Date:   Wed Jul 29 13:11:11 2015 +0800

    usb: chipidea: debug: add runtime pm for register access

    [ Upstream commit bc24937943d9f71a1e32b5dc4e2f0ef8fcc07b64 ]

    Add runtime pm operations for registers access to avoid system hang.

    Signed-off-by: Li Jun <jun.li@freescale.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 448753c5cc07b5fade57b8ebbaf14ea25b652950
Author: Martin Schwidefsky <schwidefsky@de.ibm.com>
Date:   Wed Aug 19 16:50:10 2015 +0200

    s390/3270: redraw screen on unsolicited device end

    [ Upstream commit 05bfd70bcdd3cd12c061cb77b73a11ba6f87379d ]

    If a 3270 terminal is disconnected and later reconnected again,
    it gets an unsolicited device end. This is currently ignored and
    you have to hit the clear key to get the screen redrawn.
    Add an automatic full redraw of the screen for this case.

    Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit df3a9927e47952b55a1695c0cb583530f98c9ce1
Author: Joerg Roedel <jroedel@suse.de>
Date:   Wed May 27 09:26:09 2015 +0200

    iommu/amd: Handle integer overflow in dma_ops_area_alloc

    [ Upstream commit e6aabee05f41c9d18e0b92194819edd84f352ac9 ]

    Handle this case to make sure boundary_size does not become
    0 and trigger a BUG_ON later.

    Signed-off-by: Joerg Roedel <jroedel@suse.de>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit fa52a8d9469cc7e46acdbe92b6568f7216ac9cb6
Author: Noel Power <noel.power@suse.com>
Date:   Wed May 27 09:22:10 2015 +0100

    client MUST ignore EncryptionKeyLength if CAP_EXTENDED_SECURITY is set

    [ Upstream commit f291095f340db986271e951e3891bb95624a93ea ]

    [MS-SMB] 2.2.4.5.2.1 states:

    "ChallengeLength (1 byte): When the CAP_EXTENDED_SECURITY bit is set,
     the server MUST set this value to zero and clients MUST ignore this
     value."

    Signed-off-by: Noel Power <noel.power@suse.com>
    Signed-off-by: Steve French <smfrench@gmail.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit e59fd940129c83888ec2605b065c116cd21643d1
Author: Teunis van Beelen <teuniz@gmail.com>
Date:   Sun May 31 09:36:22 2015 +0200

    USB: usbtmc: add device quirk for Rigol DS6104

    [ Upstream commit f50420223071b6ff4b586308f5c27eec54694a81 ]

    Recently we purchased the Rigol DS6104 and when I try to operate it from
    my Linux pc, everything works well with the default usbtmc driver,
    except when I want to download a big datachunk like a screenshot. This
    bitmapfile has a size of 1152054 bytes but I receive a smaller file and
    no new packets can be read.

    When I took a look at the driver source, I found this "Rigol quirk" and
    I added the id of the new DS series oscilloscopes to this list. I
    compiled it and loaded the new driver and now everything seems to work
    fine.

    Signed-off-by: Teunis van Beelen <teuniz@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 3bb4005ca26162ab0c64d8901b7b323904bbb890
Author: Jan H. Schönherr <jschoenh@amazon.de>
Date:   Wed Aug 12 21:35:56 2015 +0200

    sched: Fix cpu_active_mask/cpu_online_mask race

    [ Upstream commit dd9d3843755da95f63dd3a376f62b3e45c011210 ]

    There is a race condition in SMP bootup code, which may result
    in

        WARNING: CPU: 0 PID: 1 at kernel/workqueue.c:4418
        workqueue_cpu_up_callback()
    or
        kernel BUG at kernel/smpboot.c:135!

    It can be triggered with a bit of luck in Linux guests running
    on busy hosts.

            CPU0                        CPUn
            ====                        ====

            _cpu_up()
              __cpu_up()
                                        start_secondary()
                                          set_cpu_online()
                                            cpumask_set_cpu(cpu,
                                                       to_cpumask(cpu_online_bits));
              cpu_notify(CPU_ONLINE)
                <do stuff, see below>
                                            cpumask_set_cpu(cpu,
                                                       to_cpumask(cpu_active_bits));

    During the various CPU_ONLINE callbacks CPUn is online but not
    active. Several things can go wrong at that point, depending on
    the scheduling of tasks on CPU0.

    Variant 1:

      cpu_notify(CPU_ONLINE)
        workqueue_cpu_up_callback()
          rebind_workers()
            set_cpus_allowed_ptr()

      This call fails because it requires an active CPU; rebind_workers()
      ends with a warning:

        WARNING: CPU: 0 PID: 1 at kernel/workqueue.c:4418
        workqueue_cpu_up_callback()

    Variant 2:

      cpu_notify(CPU_ONLINE)
        smpboot_thread_call()
          smpboot_unpark_threads()
           ..
            __kthread_unpark()
              __kthread_bind()
              wake_up_state()
               ..
                select_task_rq()
                  select_fallback_rq()

      The ->wake_cpu of the unparked thread is not allowed, making a call
      to select_fallback_rq() necessary. Then, select_fallback_rq() cannot
      find an allowed, active CPU and promptly resets the allowed CPUs, so
      that the task in question ends up on CPU0.

      When those unparked tasks are eventually executed, they run
      immediately into a BUG:

        kernel BUG at kernel/smpboot.c:135!

    Just changing the order in which the online/active bits are set
    (and adding some memory barriers), would solve the two issues
    above. However, it would change the order of operations back to
    the one before commit 6acbfb96976f ("sched: Fix hotplug vs.
    set_cpus_allowed_ptr()"), thus, reintroducing that particular
    problem.

    Going further back into history, we have at least the following
    commits touching this topic:
    - commit 2baab4e90495 ("sched: Fix select_fallback_rq() vs cpu_active/cpu_online")
    - commit 5fbd036b552f ("sched: Cleanup cpu_active madness")

    Together, these give us the following non-working solutions:

      - secondary CPU sets active before online, because active is assumed to
        be a subset of online;

      - secondary CPU sets online before active, because the primary CPU
        assumes that an online CPU is also active;

      - secondary CPU sets online and waits for primary CPU to set active,
        because it might deadlock.

    Commit 875ebe940d77 ("powerpc/smp: Wait until secondaries are
    active & online") introduces an arch-specific solution to this
    arch-independent problem.

    Now, go for a more general solution without explicit waiting and
    simply set active twice: once on the secondary CPU after online
    was set and once on the primary CPU after online was seen.

    set_cpus_allowed_ptr()")

    Signed-off-by: Jan H. Schönherr <jschoenh@amazon.de>
    Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Cc: <stable@vger.kernel.org>
    Cc: Anton Blanchard <anton@samba.org>
    Cc: Borislav Petkov <bp@alien8.de>
    Cc: Joerg Roedel <jroedel@suse.de>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Matt Wilson <msw@amazon.com>
    Cc: Michael Ellerman <mpe@ellerman.id.au>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Fixes: 6acbfb96976f ("sched: Fix hotplug vs. set_cpus_allowed_ptr()")
    Link: http://lkml.kernel.org/r/1439408156-18840-1-git-send-email-jschoenh@amazon.de
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 9caa36f324a300c0a35929e79a3e4ecb5442b955
Author: Mark Rustad <mark.d.rustad@intel.com>
Date:   Mon Jul 13 11:40:07 2015 -0700

    PCI: Add VPD function 0 quirk for Intel Ethernet devices

    [ Upstream commit 7aa6ca4d39edf01f997b9e02cf6d2fdeb224f351 ]

    Set the PCI_DEV_FLAGS_VPD_REF_F0 flag on all Intel Ethernet device
    functions other than function 0, so that on multi-function devices, we will
    always read VPD from function 0 instead of from the other functions.

    [bhelgaas: changelog]
    Signed-off-by: Mark Rustad <mark.d.rustad@intel.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Acked-by: Alexander Duyck <alexander.h.duyck@redhat.com>
    CC: stable@vger.kernel.org

    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit e4ef8c343517e5ba5a42d3372e2dc655efde8f36
Author: Mark Rustad <mark.d.rustad@intel.com>
Date:   Mon Jul 13 11:40:02 2015 -0700

    PCI: Add dev_flags bit to access VPD through function 0

    [ Upstream commit 91a37c794cf2cf7ec1f9afc4cbf4a118df7e085e ]

    commit 932c435caba8a2ce473a91753bad0173269ef334 upstream.

    Add a dev_flags bit, PCI_DEV_FLAGS_VPD_REF_F0, to access VPD through
    function 0 to provide VPD access on other functions.  This is for hardware
    devices that provide copies of the same VPD capability registers in
    multiple functions.  Because the kernel expects that each function has its
    own registers, both the locking and the state tracking are affected by VPD
    accesses to different functions.

    On such devices for example, if a VPD write is performed on function 0,
    *any* later attempt to read VPD from any other function of that device will
    hang.  This has to do with how the kernel tracks the expected value of the
    F bit per function.

    Concurrent accesses to different functions of the same device can not only
    hang but also corrupt both read and write VPD data.

    When hangs occur, typically the error message:

      vpd r/w failed.  This is likely a firmware bug on this device.

    will be seen.

    Never set this bit on function 0 or there will be an infinite recursion.

    Signed-off-by: Mark Rustad <mark.d.rustad@intel.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Acked-by: Alexander Duyck <alexander.h.duyck@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit a0e38ca669beedd225ecddda70db61aad3da1694
Author: Alex Williamson <alex.williamson@redhat.com>
Date:   Fri Nov 21 11:24:08 2014 -0700

    PCI: Add flag for devices that don't reset on D3hot->D0 transition

    [ Upstream commit 51e537387990dc1f00752103f314fd135cb94bc6 ]

    Per the PCI Power Management spec r1.2, sec 3.2.4, a device that advertises
    No_Soft_Reset == 0 in the PMCSR register (reported by lspci as "NoSoftRst-")
    should perform an internal reset when transitioning from D3hot to D0 via
    software control.  Configuration context is lost and the device requires a
    full reinitialization sequence.

    Unfortunately the definition of "internal reset", beyond the application of
    the configuration context, is largely left to the interpretation of the
    specific device.  Some devices don't seem to perform an "internal reset"
    even if they report No_Soft_Reset == 0.

    We still need to honor the PCI specification and restore PCI config context
    in the event that we do a PM reset, so we don't cache and modify the
    PCI_PM_CTRL_NO_SOFT_RESET bit for the device, but for interfaces where the
    intention is to reset the device, like pci_reset_function(), we need a
    mechanism to flag that PM reset (a D3hot->D0 transition) doesn't perform
    any significant "internal reset" of the device.

    Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit ec4d789161f852d8131df242b97c84331d1f09f0
Author: David Howells <dhowells@redhat.com>
Date:   Thu Oct 15 17:21:37 2015 +0100

    KEYS: Fix crash when attempt to garbage collect an uninstantiated keyring

    [ Upstream commit f05819df10d7b09f6d1eb6f8534a8f68e5a4fe61 ]

    The following sequence of commands:

        i=`keyctl add user a a @s`
        keyctl request2 keyring foo bar @t
        keyctl unlink $i @s

    tries to invoke an upcall to instantiate a keyring if one doesn't already
    exist by that name within the user's keyring set.  However, if the upcall
    fails, the code sets keyring->type_data.reject_error to -ENOKEY or some
    other error code.  When the key is garbage collected, the key destroy
    function is called unconditionally and keyring_destroy() uses list_empty()
    on keyring->type_data.link - which is in a union with reject_error.
    Subsequently, the kernel tries to unlink the keyring from the keyring names
    list - which oopses like this:

            BUG: unable to handle kernel paging request at 00000000ffffff8a
            IP: [<ffffffff8126e051>] keyring_destroy+0x3d/0x88
            ...
            Workqueue: events key_garbage_collector
            ...
            RIP: 0010:[<ffffffff8126e051>] keyring_destroy+0x3d/0x88
            RSP: 0018:ffff88003e2f3d30  EFLAGS: 00010203
            RAX: 00000000ffffff82 RBX: ffff88003bf1a900 RCX: 0000000000000000
            RDX: 0000000000000000 RSI: 000000003bfc6901 RDI: ffffffff81a73a40
            RBP: ffff88003e2f3d38 R08: 0000000000000152 R09: 0000000000000000
            R10: ffff88003e2f3c18 R11: 000000000000865b R12: ffff88003bf1a900
            R13: 0000000000000000 R14: ffff88003bf1a908 R15: ffff88003e2f4000
            ...
            CR2: 00000000ffffff8a CR3: 000000003e3ec000 CR4: 00000000000006f0
            ...
            Call Trace:
             [<ffffffff8126c756>] key_gc_unused_keys.constprop.1+0x5d/0x10f
             [<ffffffff8126ca71>] key_garbage_collector+0x1fa/0x351
             [<ffffffff8105ec9b>] process_one_work+0x28e/0x547
             [<ffffffff8105fd17>] worker_thread+0x26e/0x361
             [<ffffffff8105faa9>] ? rescuer_thread+0x2a8/0x2a8
             [<ffffffff810648ad>] kthread+0xf3/0xfb
             [<ffffffff810647ba>] ? kthread_create_on_node+0x1c2/0x1c2
             [<ffffffff815f2ccf>] ret_from_fork+0x3f/0x70
             [<ffffffff810647ba>] ? kthread_create_on_node+0x1c2/0x1c2

    Note the value in RAX.  This is a 32-bit representation of -ENOKEY.

    The solution is to only call ->destroy() if the key was successfully
    instantiated.

    Reported-by: Dmitry Vyukov <dvyukov@google.com>
    Signed-off-by: David Howells <dhowells@redhat.com>
    Tested-by: Dmitry Vyukov <dvyukov@google.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 9485c5aa5bfbbcbd656afdd06df905614ba2946a
Author: David Howells <dhowells@redhat.com>
Date:   Fri Sep 25 16:30:08 2015 +0100

    KEYS: Fix race between key destruction and finding a keyring by name

    [ Upstream commit 94c4554ba07adbdde396748ee7ae01e86cf2d8d7 ]

    There appears to be a race between:

     (1) key_gc_unused_keys() which frees key->security and then calls
         keyring_destroy() to unlink the name from the name list

     (2) find_keyring_by_name() which calls key_permission(), thus accessing
         key->security, on a key before checking to see whether the key usage is 0
         (ie. the key is dead and might be cleaned up).

    Fix this by calling ->destroy() before cleaning up the core key data -
    including key->security.

    Reported-by: Petr Matousek <pmatouse@redhat.com>
    Signed-off-by: David Howells <dhowells@redhat.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 4a72f9130bb9afc3d18f5a2c0a8c3856c430080c
Author: Eric Whitney <enwlinux@gmail.com>
Date:   Fri Apr 3 00:13:42 2015 -0400

    ext4: fix loss of delalloc extent info in ext4_zero_range()

    [ Upstream commit 94426f4b9648154dc5a6760b59e6953e640ab3b1 ]

    In ext4_zero_range(), removing a file's entire block range from the
    extent status tree removes all records of that file's delalloc extents.
    The delalloc accounting code uses this information, and its loss can
    then lead to accounting errors and kernel warnings at writeback time and
    subsequent file system damage.  This is most noticeable on bigalloc
    file systems where code in ext4_ext_map_blocks() handles cases where
    delalloc extents share clusters with a newly allocated extent.

    Because we're not deleting a block range and are correctly updating the
    status of its associated extent, there is no need to remove anything
    from the extent status tree.

    When this patch is combined with an unrelated bug fix for
    ext4_zero_range(), kernel warnings and e2fsck errors reported during
    xfstests runs on bigalloc filesystems are greatly reduced without
    introducing regressions on other xfstests-bld test scenarios.

    Signed-off-by: Eric Whitney <enwlinux@gmail.com>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit ecca2fb1f47b4cc4267de9d76d16c356a65601b3
Author: Lukas Czerner <lczerner@redhat.com>
Date:   Fri Apr 3 00:09:13 2015 -0400

    ext4: allocate entire range in zero range

    [ Upstream commit 0f2af21aae11972fa924374ddcf52e88347cf5a8 ]

    Currently there is a bug in zero range code which causes zero range
    calls to only allocate block aligned portion of the range, while
    ignoring the rest in some cases.

    In some cases, namely if the end of the range is past i_size, we do
    attempt to preallocate the last nonaligned block. However this might
    cause kernel to BUG() in some carefully designed zero range requests
    on setups where page size > block size.

    Fix this problem by first preallocating the entire range, including
    the nonaligned edges and converting the written extents to unwritten
    in the next step. This approach will also give us the advantage of
    having the range to be as linearly contiguous as possible.

    Signed-off-by: Lukas Czerner <lczerner@redhat.com>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 6169a11a8fa06796cf15d64cd79c4dd4cccd651c
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Thu Feb 5 10:37:33 2015 +0300

    vhost/scsi: potential memory corruption

    [ Upstream commit 59c816c1f24df0204e01851431d3bab3eb76719c ]

    This code in vhost_scsi_make_tpg() is confusing because we limit "tpgt"
    to UINT_MAX but the data type of "tpg->tport_tpgt" and that is a u16.

    I looked at the context and it turns out that in
    vhost_scsi_set_endpoint(), "tpg->tport_tpgt" is used as an offset into
    the vs_tpg[] array which has VHOST_SCSI_MAX_TARGET (256) elements so
    anything higher than 255 then it is invalid.  I have made that the limit
    now.

    In vhost_scsi_send_evt() we mask away values higher than 255, but now
    that the limit has changed, we don't need the mask.

    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 9b85836ec94666957c2a1ae1adfd6da4a2b8d078
Author: Soeren Grunewald <soeren.grunewald@desy.de>
Date:   Thu Jun 11 09:25:04 2015 +0200

    serial: 8250_pci: Add support for 12 port Exar boards

    [ Upstream commit be32c0cf0462c36f482b5ddcff1d8371be1e183c ]

    The Exar XR17V358 can also be combined with a XR17V354 chip to act as a
    single 12 port chip. This works the same way as the combining two XR17V358
    chips. But the reported device id then is 0x4358.

    Signed-off-by: Soeren Grunewald <soeren.grunewald@desy.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit e7509898c3936faf643dba8e105dfdf90f23b0a9
Author: Soeren Grunewald <soeren.grunewald@desy.de>
Date:   Tue Apr 28 16:29:49 2015 +0200

    serial: 8250_pci: Add support for 16 port Exar boards

    [ Upstream commit 96a5d18bc1338786fecac73599f1681f59a59a8e ]

    The Exar XR17V358 chip usually provides only 8 ports. But two chips can be
    combined to act as a single 16 port chip. Therefor one chip is configured
    as master the second as slave by connecting the mode pin to VCC (master)
    or GND (slave).

    Then the master chip is reporting a different device-id depending on
    whether a slave is detected or not. The UARTs 8-15 are addressed from
    0x2000-0x3fff. So the offset of 0x400 from UART to UART can be used to
    address all 16 ports as before.

    See: https://www.exar.com/common/content/document.ashx?id=1587 page 11

    Signed-off-by: Soeren Grunewald <soeren.grunewald@desy.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit cc908bc41a0ecc4be8db97521362e608f80a3077
Author: Roman Gushchin <klamm@yandex-team.ru>
Date:   Sat Oct 31 10:53:50 2015 +1100

    md/raid5: fix locking in handle_stripe_clean_event()

    [ Upstream commit b8a9d66d043ffac116100775a469f05f5158c16f ]

    After commit 566c09c53455 ("raid5: relieve lock contention in get_active_stripe()")
    __find_stripe() is called under conf->hash_locks + hash.
    But handle_stripe_clean_event() calls remove_hash() under
    conf->device_lock.

    Under some cirscumstances the hash chain can be circuited,
    and we get an infinite loop with disabled interrupts and locked hash
    lock in __find_stripe(). This leads to hard lockup on multiple CPUs
    and following system crash.

    I was able to reproduce this behavior on raid6 over 6 ssd disks.
    The devices_handle_discard_safely option should be set to enable trim
    support. The following script was used:

    for i in `seq 1 32`; do
        dd if=/dev/zero of=large$i bs=10M count=100 &
    done

    neilb: original was against a 3.x kernel.  I forward-ported
      to 4.3-rc.  This verison is suitable for any kernel since
      Commit: 59fc630b8b5f ("RAID5: batch adjacent full stripe write")
      (v4.1+).  I'll post a version for earlier kernels to stable.

    Signed-off-by: Roman Gushchin <klamm@yandex-team.ru>
    Fixes: 566c09c53455 ("raid5: relieve lock contention in get_active_stripe()")
    Signed-off-by: NeilBrown <neilb@suse.com>
    Cc: Shaohua Li <shli@kernel.org>
    Cc: <stable@vger.kernel.org> # 3.13 - 4.2
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 53d59e5595f3d3c91a5668866a981037a319bc82
Author: Doron Tsur <doront@mellanox.com>
Date:   Sun Oct 11 15:58:17 2015 +0300

    IB/cm: Fix rb-tree duplicate free and use-after-free

    [ Upstream commit 0ca81a2840f77855bbad1b9f172c545c4dc9e6a4 ]

    ib_send_cm_sidr_rep could sometimes erase the node from the sidr
    (depending on errors in the process). Since ib_send_cm_sidr_rep is
    called both from cm_sidr_req_handler and cm_destroy_id, cm_id_priv
    could be either erased from the rb_tree twice or not erased at all.
    Fixing that by making sure it's erased only once before freeing
    cm_id_priv.

    Fixes: a977049dacde ('[PATCH] IB: Add the kernel CM implementation')
    Signed-off-by: Doron Tsur <doront@mellanox.com>
    Signed-off-by: Matan Barak <matanb@mellanox.com>
    Signed-off-by: Doug Ledford <dledford@redhat.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 37dfbd826b48df45b5e2bf7aecb3036450a66ecc
Author: Dāvis Mosāns <davispuh@gmail.com>
Date:   Fri Aug 21 07:29:22 2015 +0300

    mvsas: Fix NULL pointer dereference in mvs_slot_task_free

    [ Upstream commit 2280521719e81919283b82902ac24058f87dfc1b ]

    When pci_pool_alloc fails in mvs_task_prep then task->lldd_task stays
    NULL but it's later used in mvs_abort_task as slot which is passed
    to mvs_slot_task_free causing NULL pointer dereference.

    Just return from mvs_slot_task_free when passed with NULL slot.

    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=101891
    Signed-off-by: Dāvis Mosāns <davispuh@gmail.com>
    Reviewed-by: Tomas Henzl <thenzl@redhat.com>
    Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
    Cc: stable@vger.kernel.org
    Signed-off-by: James Bottomley <JBottomley@Odin.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit e456c19869192bc51aa098f510f1df3e913c2a1d
Author: NeilBrown <neilb@suse.com>
Date:   Sat Oct 31 11:00:56 2015 +1100

    Revert "md: allow a partially recovered device to be hot-added to an array."

    [ Upstream commit d01552a76d71f9879af448e9142389ee9be6e95b ]

    This reverts commit 7eb418851f3278de67126ea0c427641ab4792c57.

    This commit is poorly justified, I can find not discusison in email,
    and it clearly causes a problem.

    If a device which is being recovered fails and is subsequently
    re-added to an array, there could easily have been changes to the
    array *before* the point where the recovery was up to.  So the
    recovery must start again from the beginning.

    If a spare is being recovered and fails, then when it is re-added we
    really should do a bitmap-based recovery up to the recovery-offset,
    and then a full recovery from there.  Before this reversion, we only
    did the "full recovery from there" which is not corect.  After this
    reversion with will do a full recovery from the start, which is safer
    but not ideal.

    It will be left to a future patch to arrange the two different styles
    of recovery.

    Reported-and-tested-by: Nate Dailey <nate.dailey@stratus.com>
    Signed-off-by: NeilBrown <neilb@suse.com>
    Cc: stable@vger.kernel.org (3.14+)
    Fixes: 7eb418851f32 ("md: allow a partially recovered device to be hot-added to an array.")
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit aab9369e905c132ceeb03924e6ecfd73cea9c3dd
Author: Jes Sorensen <Jes.Sorensen@redhat.com>
Date:   Tue Oct 20 12:09:13 2015 -0400

    md/raid10: submit_bio_wait() returns 0 on success

    [ Upstream commit 681ab4696062f5aa939c9e04d058732306a97176 ]

    This was introduced with 9e882242c6193ae6f416f2d8d8db0d9126bd996b
    which changed the return value of submit_bio_wait() to return != 0 on
    error, but didn't update the caller accordingly.

    Fixes: 9e882242c6 ("block: Add submit_bio_wait(), remove from md")
    Cc: stable@vger.kernel.org (v3.10)
    Reported-by: Bill Kuzeja <William.Kuzeja@stratus.com>
    Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com>
    Signed-off-by: NeilBrown <neilb@suse.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 3ae3d7f7d36d7776a8284024374c11879b3577fb
Author: Jes Sorensen <Jes.Sorensen@redhat.com>
Date:   Tue Oct 20 12:09:12 2015 -0400

    md/raid1: submit_bio_wait() returns 0 on success

    [ Upstream commit 203d27b0226a05202438ddb39ef0ef1acb14a759 ]

    This was introduced with 9e882242c6193ae6f416f2d8d8db0d9126bd996b
    which changed the return value of submit_bio_wait() to return != 0 on
    error, but didn't update the caller accordingly.

    Fixes: 9e882242c6 ("block: Add submit_bio_wait(), remove from md")
    Cc: stable@vger.kernel.org (v3.10)
    Reported-by: Bill Kuzeja <William.Kuzeja@stratus.com>
    Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com>
    Signed-off-by: NeilBrown <neilb@suse.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 287819b75d1b56163ac9cc2ee6c8b3cca7483650
Author: Herbert Xu <herbert@gondor.apana.org.au>
Date:   Mon Oct 19 18:23:57 2015 +0800

    crypto: api - Only abort operations on fatal signal

    [ Upstream commit 3fc89adb9fa4beff31374a4bf50b3d099d88ae83 ]

    Currently a number of Crypto API operations may fail when a signal
    occurs.  This causes nasty problems as the caller of those operations
    are often not in a good position to restart the operation.

    In fact there is currently no need for those operations to be
    interrupted by user signals at all.  All we need is for them to
    be killable.

    This patch replaces the relevant calls of signal_pending with
    fatal_signal_pending, and wait_for_completion_interruptible with
    wait_for_completion_killable, respectively.

    Cc: stable@vger.kernel.org
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 2b23192757b42e2774516e170712aac0759038e1
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Thu Aug 20 10:34:59 2015 +0930

    module: Fix locking in symbol_put_addr()

    [ Upstream commit 275d7d44d802ef271a42dc87ac091a495ba72fc5 ]

    Poma (on the way to another bug) reported an assertion triggering:

      [<ffffffff81150529>] module_assert_mutex_or_preempt+0x49/0x90
      [<ffffffff81150822>] __module_address+0x32/0x150
      [<ffffffff81150956>] __module_text_address+0x16/0x70
      [<ffffffff81150f19>] symbol_put_addr+0x29/0x40
      [<ffffffffa04b77ad>] dvb_frontend_detach+0x7d/0x90 [dvb_core]

    Laura Abbott <labbott@redhat.com> produced a patch which lead us to
    inspect symbol_put_addr(). This function has a comment claiming it
    doesn't need to disable preemption around the module lookup
    because it holds a reference to the module it wants to find, which
    therefore cannot go away.

    This is wrong (and a false optimization too, preempt_disable() is really
    rather cheap, and I doubt any of this is on uber critical paths,
    otherwise it would've retained a pointer to the actual module anyway and
    avoided the second lookup).

    While its true that the module cannot go away while we hold a reference
    on it, the data structure we do the lookup in very much _CAN_ change
    while we do the lookup. Therefore fix the comment and add the
    required preempt_disable().

    Reported-by: poma <pomidorabelisima@gmail.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
    Fixes: a6e6abd575fc ("module: remove module_text_address()")
    Cc: stable@kernel.org
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 01d978039a585c712e51cccf3e8c30b24c5e0215
Author: Cathy Avery <cathy.avery@oracle.com>
Date:   Fri Oct 2 09:35:01 2015 -0400

    xen-blkfront: check for null drvdata in blkback_changed (XenbusStateClosing)

    [ Upstream commit a54c8f0f2d7df525ff997e2afe71866a1a013064 ]

    xen-blkfront will crash if the check to talk_to_blkback()
    in blkback_changed()(XenbusStateInitWait) returns an error.
    The driver data is freed and info is set to NULL. Later during
    the close process via talk_to_blkback's call to xenbus_dev_fatal()
    the null pointer is passed to and dereference in blkfront_closing.

    CC: stable@vger.kernel.org
    Signed-off-by: Cathy Avery <cathy.avery@oracle.com>
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 244cebd7d0c7cf5a9d807449622b98d444b292b8
Author: Laura Abbott <labbott@fedoraproject.org>
Date:   Mon Oct 12 11:30:13 2015 +0300

    xhci: Add spurious wakeup quirk for LynxPoint-LP controllers

    [ Upstream commit fd7cd061adcf5f7503515ba52b6a724642a839c8 ]

    We received several reports of systems rebooting and powering on
    after an attempted shutdown. Testing showed that setting
    XHCI_SPURIOUS_WAKEUP quirk in addition to the XHCI_SPURIOUS_REBOOT
    quirk allowed the system to shutdown as expected for LynxPoint-LP
    xHCI controllers. Set the quirk back.

    Note that the quirk was originally introduced for LynxPoint and
    LynxPoint-LP just for this same reason. See:

    commit 638298dc66ea ("xhci: Fix spurious wakeups after S5 on Haswell")

    It was later limited to only concern HP machines as it caused
    regression on some machines, see both bug and commit:

    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=66171
    commit 6962d914f317 ("xhci: Limit the spurious wakeup fix only to HP machines")

    Later it was discovered that the powering on after shutdown
    was limited to LynxPoint-LP (Haswell-ULT) and that some non-LP HP
    machine suffered from spontaneous resume from S3 (which should
    not be related to the SPURIOUS_WAKEUP quirk at all). An attempt
    to fix this then removed the SPURIOUS_WAKEUP flag usage completely.

    commit b45abacde3d5 ("xhci: no switching back on non-ULT Haswell")

    Current understanding is that LynxPoint-LP (Haswell ULT) machines
    need the SPURIOUS_WAKEUP quirk, otherwise they will restart, and
    plain Lynxpoint (Haswell) machines may _not_ have the quirk
    set otherwise they again will restart.

    Signed-off-by: Laura Abbott <labbott@fedoraproject.org>
    Cc: Takashi Iwai <tiwai@suse.de>
    Cc: Oliver Neukum <oneukum@suse.com>
    [Added more history to commit message -Mathias]
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 24cd9f6f26d25f9ca1939abaeab327c483b9a742
Author: Mathias Nyman <mathias.nyman@linux.intel.com>
Date:   Mon Oct 12 11:30:12 2015 +0300

    xhci: handle no ping response error properly

    [ Upstream commit 3b4739b8951d650becbcd855d7d6f18ac98a9a85 ]

    If a host fails to wake up a isochronous SuperSpeed device from U1/U2
    in time for a isoch transfer it will generate a "No ping response error"
    Host will then move to the next transfer descriptor.

    Handle this case in the same way as missed service errors, tag the
    current TD as skipped and handle it on the next transfer event.

    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit c74505b714a06ca639dbfdf07349f67009508326
Author: Mike Snitzer <snitzer@redhat.com>
Date:   Thu Oct 22 10:56:40 2015 -0400

    dm btree: fix leak of bufio-backed block in btree_split_beneath error path

    [ Upstream commit 4dcb8b57df3593dcb20481d9d6cf79d1dc1534be ]

    btree_split_beneath()'s error path had an outstanding FIXME that speaks
    directly to the potential for _not_ cleaning up a previously allocated
    bufio-backed block.

    Fix this by releasing the previously allocated bufio block using
    unlock_block().

    Reported-by: Mikulas Patocka <mpatocka@redhat.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Acked-by: Joe Thornber <thornber@redhat.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 297ce6f9c494be69cc3106c7be437038ee842344
Author: Joe Thornber <ejt@redhat.com>
Date:   Wed Oct 21 18:36:49 2015 +0100

    dm btree remove: fix a bug when rebalancing nodes after removal

    [ Upstream commit 2871c69e025e8bc507651d5a9cf81a8a7da9d24b ]

    Commit 4c7e309340ff ("dm btree remove: fix bug in redistribute3") wasn't
    a complete fix for redistribute3().

    The redistribute3 function takes 3 btree nodes and shares out the entries
    evenly between them.  If the three nodes in total contained
    (MAX_ENTRIES * 3) - 1 entries between them then this was erroneously getting
    rebalanced as (MAX_ENTRIES - 1) on the left and right, and (MAX_ENTRIES + 1) in
    the center.

    Fix this issue by being more careful about calculating the target number
    of entries for the left and right nodes.

    Unit tested in userspace using this program:
    https://github.com/jthornber/redistribute3-test/blob/master/redistribute3_t.c

    Signed-off-by: Joe Thornber <ejt@redhat.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 1895f1b79e22b18b1b46b845572b9bd36a4ebd20
Author: Will Deacon <will.deacon@arm.com>
Date:   Wed Oct 28 16:56:13 2015 +0000

    Revert "ARM64: unwind: Fix PC calculation"

    [ Upstream commit 9702970c7bd3e2d6fecb642a190269131d4ac16c ]

    This reverts commit e306dfd06fcb44d21c80acb8e5a88d55f3d1cf63.

    With this patch applied, we were the only architecture making this sort
    of adjustment to the PC calculation in the unwinder. This causes
    problems for ftrace, where the PC values are matched against the
    contents of the stack frames in the callchain and fail to match any
    records after the address adjustment.

    Whilst there has been some effort to change ftrace to workaround this,
    those patches are not yet ready for mainline and, since we're the odd
    architecture in this regard, let's just step in line with other
    architectures (like arch/arm/) for now.

    Cc: <stable@vger.kernel.org>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 51c083f34d4545f49749327242e69475187a2b98
Author: Ronny Hegewald <ronny.hegewald@online.de>
Date:   Thu Oct 15 18:50:46 2015 +0000

    rbd: require stable pages if message data CRCs are enabled

    [ Upstream commit bae818ee1577c27356093901a0ea48f672eda514 ]

    rbd requires stable pages, as it performs a crc of the page data before
    they are send to the OSDs.

    But since kernel 3.9 (patch 1d1d1a767206fbe5d4c69493b7e6d2a8d08cc0a0
    "mm: only enforce stable page writes if the backing device requires
    it") it is not assumed anymore that block devices require stable pages.

    This patch sets the necessary flag to get stable pages back for rbd.

    In a ceph installation that provides multiple ext4 formatted rbd
    devices "bad crc" messages appeared regularly (ca 1 message every 1-2
    minutes on every OSD that provided the data for the rbd) in the
    OSD-logs before this patch. After this patch this messages are pretty
    much gone (only ca 1-2 / month / OSD).

    Cc: stable@vger.kernel.org # 3.9+, needs backporting
    Signed-off-by: Ronny Hegewald <Ronny.Hegewald@online.de>
    [idryomov@gmail.com: require stable pages only in crc case, changelog]
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>

    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit a1c0361f5dad79729ec1dcb503d773e11f801b8c
Author: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Date:   Wed Oct 7 13:10:54 2015 +0200

    iio: mxs-lradc: Fix temperature offset

    [ Upstream commit b94e22805a2224061bb263a82b72e09544a5fbb3 ]

    0° Kelvin is actually −273.15°C, not -272.15°C. Fix the temperature offset.
    Also improve the comment explaining the calculation.

    Reported-by: Janusz Użycki <j.uzycki@elpromaelectronics.com>
    Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
    Acked-by: Stefan Wahren <stefan.wahren@i2se.com>
    Acked-by: Marek Vasut <marex@denx.de>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Jonathan Cameron <jic23@kernel.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit cb6e0c1eda88038175cd848f10ae330744067558
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Fri Oct 23 10:38:52 2015 -0400

    drm/radeon: don't try to recreate sysfs entries on resume

    [ Upstream commit 49abb26651167c892393cd9f2ad23df429645ed9 ]

    Fixes a harmless error message caused by:
    51a4726b04e880fdd9b4e0e58b13f70b0a68a7f5

    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit a83d675ed2f83b40e539e859f8d624f2ac1b4404
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Wed Oct 7 22:08:24 2015 +0300

    drm/i915: Restore lost DPLL register write on gen2-4

    [ Upstream commit 8e7a65aa70bcc1235a44e40ae0da5056525fe081 ]

    We accidentally lost the initial DPLL register write in
    1c4e02746147 drm/i915: Fix DVO 2x clock enable on 830M

    The "three times for luck" hack probably saved us from a total
    disaster. But anyway, bring the initial write back so that the
    code actually makes some sense.

    Reported-and-tested-by: Nick Bowler <nbowler@draconx.ca>
    References: http://mid.gmane.org/CAN_QmVyMaArxYgEcVVsGvsMo7-6ohZr8HmF5VhkkL4i9KOmrhw@mail.gmail.com
    Cc: stable@vger.kernel.org
    Cc: Nick Bowler <nbowler@draconx.ca>
    Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 239030251b6e6187f55831aa44e2aee415dabed4
Author: Ilia Mirkin <imirkin@alum.mit.edu>
Date:   Tue Oct 20 01:15:39 2015 -0400

    drm/nouveau/gem: return only valid domain when there's only one

    [ Upstream commit 2a6c521bb41ce862e43db46f52e7681d33e8d771 ]

    On nv50+, we restrict the valid domains to just the one where the buffer
    was originally created. However after the buffer is evicted to system
    memory, we might move it back to a different domain that was not
    originally valid. When sharing the buffer and retrieving its GEM_INFO
    data, we still want the domain that will be valid for this buffer in a
    pushbuf, not the one where it currently happens to be.

    This resolves fdo#92504 and several others. These are due to suspend
    evicting all buffers, making it more likely that they temporarily end up
    in the wrong place.

    Cc: stable@vger.kernel.org
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92504
    Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
    Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 499cf5fb763ce3271b5190ef1a00c5404c7f43b9
Author: Lad, Prabhakar <prabhakar.csengg@gmail.com>
Date:   Thu Dec 4 14:56:04 2014 +0000

    power: bq24190_charger: suppress build warning

    [ Upstream commit 31f50e48e3e4ea9d503285a389d6a1b5349d66c0 ]

    This patch fixes following build warning:

    In file included from include/linux/printk.h:261:0,
                     from include/linux/kernel.h:13,
                     from include/linux/list.h:8,
                     from include/linux/module.h:9,
                     from drivers/power/bq24190_charger.c:11:
    drivers/power/bq24190_charger.c: In function ‘bq24190_irq_handler_thread’:
    include/linux/dynamic_debug.h:86:20: warning: ‘ss_reg’ may be used uninitialized in this function [-Wmaybe-uninitialized]
       __dynamic_dev_dbg(&descriptor, dev, fmt, \
                        ^
    drivers/power/bq24190_charger.c:1211:5: note: ‘ss_reg’ was declared here
      u8 ss_reg, f_reg;
         ^
    In file included from include/linux/printk.h:261:0,
                     from include/linux/kernel.h:13,
                     from include/linux/list.h:8,
                     from include/linux/module.h:9,
                     from drivers/power/bq24190_charger.c:11:
    include/linux/dynamic_debug.h:86:20: warning: ‘f_reg’ may be used uninitialized in this function [-Wmaybe-uninitialized]
       __dynamic_dev_dbg(&descriptor, dev, fmt, \
                        ^
    drivers/power/bq24190_charger.c:1211:13: note: ‘f_reg’ was declared here
      u8 ss_reg, f_reg;

    Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
    Signed-off-by: Sebastian Reichel <sre@kernel.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit a6a0076803a901f499bc60ce379807cf4eda8aaa
Author: David S. Miller <davem@davemloft.net>
Date:   Fri Apr 17 15:15:40 2015 -0400

    sfc: Fix memcpy() with const destination compiler warning.

    [ Upstream commit 1d20a16062e771b6e26b843c0cde3b17c1146e00 ]

    drivers/net/ethernet/sfc/selftest.c: In function ‘efx_iterate_state’:
    drivers/net/ethernet/sfc/selftest.c:388:9: warning: passing argument 1 of ‘memcpy’ discards ‘const’ qualifier from pointer target type [-Wdiscarded-array-qualifiers]

    This is because the msg[] member of struct efx_loopback_payload
    is marked as 'const'.  Remove that.

    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 4084246db34ccb9c58cd6b5a85bfe74af0d4620a
Author: Jan Kara <jack@suse.com>
Date:   Thu Oct 22 13:32:21 2015 -0700

    mm: make sendfile(2) killable

    [ Upstream commit 296291cdd1629c308114504b850dc343eabc2782 ]

    Currently a simple program below issues a sendfile(2) system call which
    takes about 62 days to complete in my test KVM instance.

            int fd;
            off_t off = 0;

            fd = open("file", O_RDWR | O_TRUNC | O_SYNC | O_CREAT, 0644);
            ftruncate(fd, 2);
            lseek(fd, 0, SEEK_END);
            sendfile(fd, fd, &off, 0xfffffff);

    Now you should not ask kernel to do a stupid stuff like copying 256MB in
    2-byte chunks and call fsync(2) after each chunk but if you do, sysadmin
    should have a way to stop you.

    We actually do have a check for fatal_signal_pending() in
    generic_perform_write() which triggers in this path however because we
    always succeed in writing something before the check is done, we return
    value > 0 from generic_perform_write() and thus the information about
    signal gets lost.

    Fix the problem by doing the signal check before writing anything.  That
    way generic_perform_write() returns -EINTR, the error gets propagated up
    and the sendfile loop terminates early.

    Signed-off-by: Jan Kara <jack@suse.com>
    Reported-by: Dmitry Vyukov <dvyukov@google.com>
    Cc: Al Viro <viro@ZenIV.linux.org.uk>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 7b516b5f395b0610008c7d2638fd293440ab2f8a
Author: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Date:   Tue Oct 20 10:25:58 2015 +0100

    ASoC: wm8904: Correct number of EQ registers

    [ Upstream commit 97aff2c03a1e4d343266adadb52313613efb027f ]

    There are 24 EQ registers not 25, I suspect this bug came about because
    the registers start at EQ1 not zero. The bug is relatively harmless as
    the extra register written is an unused one.

    Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Cc: stable@vger.kernel.org
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 074ea6f13f7617cccf074ba8401bfb83dc0b4420
Author: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Date:   Fri Oct 16 15:53:29 2015 +0530

    powerpc/rtas: Validate rtas.entry before calling enter_rtas()

    [ Upstream commit 8832317f662c06f5c06e638f57bfe89a71c9b266 ]

    Currently we do not validate rtas.entry before calling enter_rtas(). This
    leads to a kernel oops when user space calls rtas system call on a powernv
    platform (see below). This patch adds code to validate rtas.entry before
    making enter_rtas() call.

      Oops: Exception in kernel mode, sig: 4 [#1]
      SMP NR_CPUS=1024 NUMA PowerNV
      task: c000000004294b80 ti: c0000007e1a78000 task.ti: c0000007e1a78000
      NIP: 0000000000000000 LR: 0000000000009c14 CTR: c000000000423140
      REGS: c0000007e1a7b920 TRAP: 0e40   Not tainted  (3.18.17-340.el7_1.pkvm3_1_0.2400.1.ppc64le)
      MSR: 1000000000081000 <HV,ME>  CR: 00000000  XER: 00000000
      CFAR: c000000000009c0c SOFTE: 0
      NIP [0000000000000000]           (null)
      LR [0000000000009c14] 0x9c14
      Call Trace:
      [c0000007e1a7bba0] [c00000000041a7f4] avc_has_perm_noaudit+0x54/0x110 (unreliable)
      [c0000007e1a7bd80] [c00000000002ddc0] ppc_rtas+0x150/0x2d0
      [c0000007e1a7be30] [c000000000009358] syscall_exit+0x0/0x98

    Cc: stable@vger.kernel.org # v3.2+
    Fixes: 55190f88789a ("powerpc: Add skeleton PowerNV platform")
    Reported-by: NAGESWARA R. SASTRY <nasastry@in.ibm.com>
    Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
    [mpe: Reword change log, trim oops, and add stable + fixes]
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>

    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit b6a84ee5b14652021a9d34c43206eb36a081a2d7
Author: Joerg Roedel <jroedel@suse.de>
Date:   Tue Oct 20 14:59:36 2015 +0200

    iommu/amd: Don't clear DTE flags when modifying it

    [ Upstream commit cbf3ccd09d683abf1cacd36e3640872ee912d99b ]

    During device assignment/deassignment the flags in the DTE
    get lost, which might cause spurious faults, for example
    when the device tries to access the system management range.
    Fix this by not clearing the flags with the rest of the DTE.

    Reported-by: G. Richard Bellamy <rbellamy@pteradigm.com>
    Tested-by: G. Richard Bellamy <rbellamy@pteradigm.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Joerg Roedel <jroedel@suse.de>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 09d7738b387bc229eda6df0a705ec8f09d9ff75f
Author: Luca Coelho <luciano.coelho@intel.com>
Date:   Tue Sep 22 09:44:39 2015 +0300

    iwlwifi: pci: add a few more PCI subvendor IDs for the 7265 series

    [ Upstream commit f08f625876476b6c4a87834dc86e3b927f4697d2 ]

    Add 3 new subdevice IDs for the 0x095A device ID and 2 for the 0x095B
    device ID.

    Cc: <stable@vger.kernerl.org> [3.13+]
    Reported-by: Jeremy <jeremy.bomkamp@gmail.com>
    Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit e9bdf3b3913dd77c463c6e01c2901a232ead7289
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Tue Sep 15 14:36:09 2015 +0200

    iwlwifi: mvm: fix D3 firmware PN programming

    [ Upstream commit 2cf5eb3ab7bb7f2e3a70edcef236cd62c87db030 ]

    The code to send the RX PN data (for each TID) to the firmware
    has a devastating bug: it overwrites the data for TID 0 with
    all the TID data, leaving the remaining TIDs zeroed. This will
    allow replays to actually be accepted by the firmware, which
    could allow waking up the system.

    Cc: <stable@vger.kernel.org> [3.1+]
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 1b0151756149d603927e1a590429d8ae4ee51876
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Tue Nov 18 15:39:51 2014 +0100

    iwlwifi: pcie: support 7265-D devices

    [ Upstream commit 3fd0d3c170ad6ba8b64e16938f699d0b43cc782e ]

    Identify 7265-D devices using the hardware revision (they have the
    same PCI IDs as 7265) and change the configuration for them taking
    the differences (currently only the firmware image) into account.

    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit b2845e18999b1f9e51eefadd0b9e64a62bfcff90
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Tue Sep 22 10:47:27 2015 +0200

    iwlwifi: fix firmware filename for 3160

    [ Upstream commit b5a48134f8af08f5243328f8a0b05fc5ae7cf343 ]

    The MODULE_FIRMWARE() for 3160 should be using the 7260 version as
    it's done in the device configuration struct instead of referencing
    IWL3160_UCODE_API_OK which doesn't even exist.

    Cc: <stable@vger.kernel.org> [3.8+]
    Reported-by: Hauke Mehrtens <hauke@hauke-m.de>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit ae9b626a28912f18a61b8963da60deef0609a93d
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Tue Sep 15 14:36:09 2015 +0200

    iwlwifi: dvm: fix D3 firmware PN programming

    [ Upstream commit 5bd166872d8f99f156fac191299d24f828bb2348 ]

    The code to send the RX PN data (for each TID) to the firmware
    has a devastating bug: it overwrites the data for TID 0 with
    all the TID data, leaving the remaining TIDs zeroed. This will
    allow replays to actually be accepted by the firmware, which
    could allow waking up the system.

    Cc: <stable@vger.kernel.org> [3.1+]
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit c66c8ccae54d30a47a1a9d793a1790fc612d3842
Author: Felix Fietkau <nbd@openwrt.org>
Date:   Thu Sep 24 16:59:46 2015 +0200

    ath9k: declare required extra tx headroom

    [ Upstream commit 029cd0370241641eb70235d205aa0b90c84dce44 ]

    ath9k inserts padding between the 802.11 header and the data area (to
    align it). Since it didn't declare this extra required headroom, this
    led to some nasty issues like randomly dropped packets in some setups.

    Cc: stable@vger.kernel.org
    Signed-off-by: Felix Fietkau <nbd@openwrt.org>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit ca7c3488286856a30fdd8c376360ebc7b687518b
Author: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Date:   Thu Feb 12 15:03:05 2015 -0800

    lib/radix-tree.c: change to simpler include

    [ Upstream commit 886d3dfa85d5aa6f11813c319e50f5402c7cf4e4 ]

    The comment helpfully explains why hardirq.h is included, but since
    commit 2d4b84739f0a ("hardirq: Split preempt count mask definitions")
    in_interrupt() has been provided by preempt_mask.h.  Use that instead,
    saving around 40 lines in the generated dependency file.

    Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit f5c09209ca16bd7329e4255aca7ad6bca31cfaff
Author: Ilya Dryomov <idryomov@gmail.com>
Date:   Mon Aug 31 15:21:39 2015 +0300

    rbd: fix double free on rbd_dev->header_name

    [ Upstream commit 3ebe138ac642a195c7f2efdb918f464734421fd6 ]

    If rbd_dev_image_probe() in rbd_dev_probe_parent() fails, header_name
    is freed twice: once in rbd_dev_probe_parent() and then in its caller
    rbd_dev_image_probe() (rbd_dev_image_probe() is called recursively to
    handle parent images).

    rbd_dev_probe_parent() is responsible for probing the parent, so it
    shouldn't muck with clone's fields.

    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
    Reviewed-by: Alex Elder <elder@linaro.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 21f6ebb8ddf3d7940bc6a752df0ddc62667915c1
Author: Mike Snitzer <snitzer@redhat.com>
Date:   Tue Oct 13 12:04:28 2015 -0400

    dm thin: fix missing pool reference count decrement in pool_ctr error path

    [ Upstream commit ba30670f4d5292c4e7f7980bbd5071f7c4794cdd ]

    Fixes: ac8c3f3df ("dm thin: generate event when metadata threshold passed")
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Cc: stable@vger.kernel.org # 3.10+
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 5ab6262ccf4d1a622ab8fb63636a24a1028ffd92
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Wed Sep 30 16:45:52 2015 -0400

    drm/radeon: add pm sysfs files late

    [ Upstream commit 51a4726b04e880fdd9b4e0e58b13f70b0a68a7f5 ]

    They were added relatively early in the driver init process
    which meant that in some cases the driver was not finished
    initializing before external tools tried to use them which
    could result in a crash depending on the timing.

    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit a7138587d56380902237cec784fbc09048a17003
Author: Ben Skeggs <bskeggs@redhat.com>
Date:   Fri Oct 2 14:03:19 2015 +1000

    drm/nouveau/fbcon: take runpm reference when userspace has an open fd

    [ Upstream commit f231976c2e8964ceaa9250e57d27c35ff03825c2 ]

    We need to do this in order to prevent accesses to the device while it's
    powered down.  Userspace may have an mmap of the fb, and there's no good
    way (that I know of) to prevent it from touching the device otherwise.

    This fixes some nasty races between runpm and plymouth on some systems,
    which result in the GPU getting very upset and hanging the boot.

    Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 43ac913d76a9ae3894337654effc3ff2f931e106
Author: Shaohua Li <shli@fb.com>
Date:   Wed Sep 30 09:05:30 2015 -0700

    workqueue: make sure delayed work run in local cpu

    [ Upstream commit 874bbfe600a660cba9c776b3957b1ce393151b76 ]

    My system keeps crashing with below message. vmstat_update() schedules a delayed
    work in current cpu and expects the work runs in the cpu.
    schedule_delayed_work() is expected to make delayed work run in local cpu. The
    problem is timer can be migrated with NO_HZ. __queue_work() queues work in
    timer handler, which could run in a different cpu other than where the delayed
    work is scheduled. The end result is the delayed work runs in different cpu.
    The patch makes __queue_delayed_work records local cpu earlier. Where the timer
    runs doesn't change where the work runs with the change.

    [   28.010131] ------------[ cut here ]------------
    [   28.010609] kernel BUG at ../mm/vmstat.c:1392!
    [   28.011099] invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC KASAN
    [   28.011860] Modules linked in:
    [   28.012245] CPU: 0 PID: 289 Comm: kworker/0:3 Tainted: G        W4.3.0-rc3+ #634
    [   28.013065] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20140709_153802- 04/01/2014
    [   28.014160] Workqueue: events vmstat_update
    [   28.014571] task: ffff880117682580 ti: ffff8800ba428000 task.ti: ffff8800ba428000
    [   28.015445] RIP: 0010:[<ffffffff8115f921>]  [<ffffffff8115f921>]vmstat_update+0x31/0x80
    [   28.016282] RSP: 0018:ffff8800ba42fd80  EFLAGS: 00010297
    [   28.016812] RAX: 0000000000000000 RBX: ffff88011a858dc0 RCX:0000000000000000
    [   28.017585] RDX: ffff880117682580 RSI: ffffffff81f14d8c RDI:ffffffff81f4df8d
    [   28.018366] RBP: ffff8800ba42fd90 R08: 0000000000000001 R09:0000000000000000
    [   28.019169] R10: 0000000000000000 R11: 0000000000000121 R12:ffff8800baa9f640
    [   28.019947] R13: ffff88011a81e340 R14: ffff88011a823700 R15:0000000000000000
    [   28.020071] FS:  0000000000000000(0000) GS:ffff88011a800000(0000)knlGS:0000000000000000
    [   28.020071] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
    [   28.020071] CR2: 00007ff6144b01d0 CR3: 00000000b8e93000 CR4:00000000000006f0
    [   28.020071] Stack:
    [   28.020071]  ffff88011a858dc0 ffff8800baa9f640 ffff8800ba42fe00ffffffff8106bd88
    [   28.020071]  ffffffff8106bd0b 0000000000000096 0000000000000000ffffffff82f9b1e8
    [   28.020071]  ffffffff829f0b10 0000000000000000 ffffffff81f18460ffff88011a81e340
    [   28.020071] Call Trace:
    [   28.020071]  [<ffffffff8106bd88>] process_one_work+0x1c8/0x540
    [   28.020071]  [<ffffffff8106bd0b>] ? process_one_work+0x14b/0x540
    [   28.020071]  [<ffffffff8106c214>] worker_thread+0x114/0x460
    [   28.020071]  [<ffffffff8106c100>] ? process_one_work+0x540/0x540
    [   28.020071]  [<ffffffff81071bf8>] kthread+0xf8/0x110
    [   28.020071]  [<ffffffff81071b00>] ?kthread_create_on_node+0x200/0x200
    [   28.020071]  [<ffffffff81a6522f>] ret_from_fork+0x3f/0x70
    [   28.020071]  [<ffffffff81071b00>] ?kthread_create_on_node+0x200/0x200

    Signed-off-by: Shaohua Li <shli@fb.com>
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Cc: stable@vger.kernel.org # v2.6.31+
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit cd351c29c369fc45102590d60a136436360f8e11
Author: Mika Westerberg <mika.westerberg@linux.intel.com>
Date:   Thu Sep 24 12:06:54 2015 +0300

    i2c: designware: Do not use parameters from ACPI on Dell Inspiron 7348

    [ Upstream commit 56d4b8a24cef5d66f0d10ac778a520d3c2c68a48 ]

    ACPI SSCN/FMCN methods were originally added because then the platform can
    provide the most accurate HCNT/LCNT values to the driver. However, this
    seems not to be true for Dell Inspiron 7348 where using these causes the
    touchpad to fail in boot:

      i2c_hid i2c-DLL0675:00: failed to retrieve report from device.
      i2c_designware INT3433:00: i2c_dw_handle_tx_abort: lost arbitration
      i2c_hid i2c-DLL0675:00: failed to retrieve report from device.
      i2c_designware INT3433:00: controller timed out

    The values received from ACPI are (in fast mode):

      HCNT: 72
      LCNT: 160

    this translates to following timings (input clock is 100MHz on Broadwell):

      tHIGH: 720 ns (spec min 600 ns)
      tLOW: 1600 ns (spec min 1300 ns)
      Bus period: 2920 ns (assuming 300 ns tf and tr)
      Bus speed: 342.5 kHz

    Both tHIGH and tLOW are within the I2C specification.

    The calculated values when ACPI parameters are not used are (in fast mode):

      HCNT: 87
      LCNT: 159

    which translates to:

      tHIGH: 870 ns (spec min 600 ns)
      tLOW: 1590 ns (spec min 1300 ns)
      Bus period 3060 ns (assuming 300 ns tf and tr)
      Bus speed 326.8 kHz

    These values are also within the I2C specification.

    Since both ACPI and calculated values meet the I2C specification timing
    requirements it is hard to say why the touchpad does not function properly
    with the ACPI values except that the bus speed is higher in this case (but
    still well below the max 400kHz).

    Solve this by adding DMI quirk to the driver that disables using ACPI
    parameters on this particulare machine.

    Reported-by: Pavel Roskin <plroskin@gmail.com>
    Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
    Tested-by: Pavel Roskin <plroskin@gmail.com>
    Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
    Cc: stable@kernel.org
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit d8b06f6fe0481d5bb79994b31f284a6609c46286
Author: Wolfram Sang <wsa+renesas@sang-engineering.com>
Date:   Sat Oct 10 08:24:23 2015 +0100

    i2c: s3c2410: enable RuntimePM before registering to the core

    [ Upstream commit eadd709f5d2e8aebb1b7bf49460e97a68d81a9b0 ]

    The core may register clients attached to this master which may use
    funtionality from the master. So, RuntimePM must be enabled before, otherwise
    this will fail. While here, move drvdata, too.

    Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
    Tested-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
    Acked-by: Kukjin Kim <kgene@kernel.org>
    Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
    Cc: stable@kernel.org
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit d1edec87b14e67ff76d97eb8d6434270d8286efc
Author: Wolfram Sang <wsa+renesas@sang-engineering.com>
Date:   Fri Oct 9 10:39:25 2015 +0100

    i2c: rcar: enable RuntimePM before registering to the core

    [ Upstream commit 4f7effddf4549d57114289f273710f077c4c330a ]

    The core may register clients attached to this master which may use
    funtionality from the master. So, RuntimePM must be enabled before, otherwise
    this will fail. While here, move drvdata, too.

    Reported-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
    Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
    Cc: stable@kernel.org
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit b2a40bdea04d1b212e4c26e68953ec5d8151d218
Author: Will Deacon <will.deacon@arm.com>
Date:   Thu Oct 8 11:11:17 2015 +0100

    arm64: errata: use KBUILD_CFLAGS_MODULE for erratum #843419

    [ Upstream commit b6dd8e0719c0d2d01429639a11b7bc2677de240c ]

    Commit df057cc7b4fa ("arm64: errata: add module build workaround for
    erratum #843419") sets CFLAGS_MODULE to ensure that the large memory
    model is used by the compiler when building kernel modules.

    However, CFLAGS_MODULE is an environment variable and intended to be
    overridden on the command line, which appears to be the case with the
    Ubuntu kernel packaging system, so use KBUILD_CFLAGS_MODULE instead.

    Cc: <stable@vger.kernel.org>
    Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Fixes: df057cc7b4fa ("arm64: errata: add module build workaround for erratum #843419")
    Reported-by: Dann Frazier <dann.frazier@canonical.com>
    Tested-by: Dann Frazier <dann.frazier@canonical.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 431baf4cb7d25cd47bb9c81c08eff0a835f6536e
Author: Chris Mason <clm@fb.com>
Date:   Tue Oct 13 14:06:48 2015 -0400

    btrfs: fix use after free iterating extrefs

    [ Upstream commit dc6c5fb3b514221f2e9d21ee626a9d95d3418dff ]

    The code for btrfs inode-resolve has never worked properly for
    files with enough hard links to trigger extrefs.  It was trying to
    get the leaf out of a path after freeing the path:

            btrfs_release_path(path);
            leaf = path->nodes[0];
            item_size = btrfs_item_size_nr(leaf, slot);

    The fix here is to use the extent buffer we cloned just a little higher
    up to avoid deadlocks caused by using the leaf in the path.

    Signed-off-by: Chris Mason <clm@fb.com>
    cc: stable@vger.kernel.org # v3.7+
    cc: Mark Fasheh <mfasheh@suse.de>
    Reviewed-by: Filipe Manana <fdmanana@suse.com>
    Reviewed-by: Mark Fasheh <mfasheh@suse.de>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 0202b0dfe93fe7d0179b80013dbac5c15f2c81c3
Author: Russell King <rmk+kernel@arm.linux.org.uk>
Date:   Fri Oct 9 20:43:33 2015 +0100

    crypto: ahash - ensure statesize is non-zero

    [ Upstream commit 8996eafdcbad149ac0f772fb1649fbb75c482a6a ]

    Unlike shash algorithms, ahash drivers must implement export
    and import as their descriptors may contain hardware state and
    cannot be exported as is.  Unfortunately some ahash drivers did
    not provide them and end up causing crashes with algif_hash.

    This patch adds a check to prevent these drivers from registering
    ahash algorithms until they are fixed.

    Cc: stable@vger.kernel.org
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 27874987e9b9eba00c17aa5590befe3ebe8723ba
Author: Dave Kleikamp <dave.kleikamp@oracle.com>
Date:   Mon Oct 5 10:08:51 2015 -0500

    crypto: sparc - initialize blkcipher.ivsize

    [ Upstream commit a66d7f724a96d6fd279bfbd2ee488def6b081bea ]

    Some of the crypto algorithms write to the initialization vector,
    but no space has been allocated for it. This clobbers adjacent memory.

    Cc: stable@vger.kernel.org
    Signed-off-by: Dave Kleikamp <dave.kleikamp@oracle.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit f5f7e02d8bd8f173aa74bfa006d696c83cc39119
Author: Joe Perches <joe@perches.com>
Date:   Wed Oct 14 01:09:40 2015 -0700

    ethtool: Use kcalloc instead of kmalloc for ethtool_get_strings

    [ Upstream commit 077cb37fcf6f00a45f375161200b5ee0cd4e937b ]

    It seems that kernel memory can leak into userspace by a
    kmalloc, ethtool_get_strings, then copy_to_user sequence.

    Avoid this by using kcalloc to zero fill the copied buffer.

    Signed-off-by: Joe Perches <joe@perches.com>
    Acked-by: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 2191851fa6974677c5cbb0c4b131cd768c18c4ec
Author: Guillaume Nault <g.nault@alphalink.fr>
Date:   Wed Sep 30 11:45:33 2015 +0200

    ppp: don't override sk->sk_state in pppoe_flush_dev()

    [ Upstream commit e6740165b8f7f06d8caee0fceab3fb9d790a6fed ]

    Since commit 2b018d57ff18 ("pppoe: drop PPPOX_ZOMBIEs in pppoe_release"),
    pppoe_release() calls dev_put(po->pppoe_dev) if sk is in the
    PPPOX_ZOMBIE state. But pppoe_flush_dev() can set sk->sk_state to
    PPPOX_ZOMBIE _and_ reset po->pppoe_dev to NULL. This leads to the
    following oops:

    [  570.140800] BUG: unable to handle kernel NULL pointer dereference at 00000000000004e0
    [  570.142931] IP: [<ffffffffa018c701>] pppoe_release+0x50/0x101 [pppoe]
    [  570.144601] PGD 3d119067 PUD 3dbc1067 PMD 0
    [  570.144601] Oops: 0000 [#1] SMP
    [  570.144601] Modules linked in: l2tp_ppp l2tp_netlink l2tp_core ip6_udp_tunnel udp_tunnel pppoe pppox ppp_generic slhc loop crc32c_intel ghash_clmulni_intel jitterentropy_rng sha256_generic hmac drbg ansi_cprng aesni_intel aes_x86_64 ablk_helper cryptd lrw gf128mul glue_helper acpi_cpufreq evdev serio_raw processor button ext4 crc16 mbcache jbd2 virtio_net virtio_blk virtio_pci virtio_ring virtio
    [  570.144601] CPU: 1 PID: 15738 Comm: ppp-apitest Not tainted 4.2.0 #1
    [  570.144601] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Debian-1.8.2-1 04/01/2014
    [  570.144601] task: ffff88003d30d600 ti: ffff880036b60000 task.ti: ffff880036b60000
    [  570.144601] RIP: 0010:[<ffffffffa018c701>]  [<ffffffffa018c701>] pppoe_release+0x50/0x101 [pppoe]
    [  570.144601] RSP: 0018:ffff880036b63e08  EFLAGS: 00010202
    [  570.144601] RAX: 0000000000000000 RBX: ffff880034340000 RCX: 0000000000000206
    [  570.144601] RDX: 0000000000000006 RSI: ffff88003d30dd20 RDI: ffff88003d30dd20
    [  570.144601] RBP: ffff880036b63e28 R08: 0000000000000001 R09: 0000000000000000
    [  570.144601] R10: 00007ffee9b50420 R11: ffff880034340078 R12: ffff8800387ec780
    [  570.144601] R13: ffff8800387ec7b0 R14: ffff88003e222aa0 R15: ffff8800387ec7b0
    [  570.144601] FS:  00007f5672f48700(0000) GS:ffff88003fc80000(0000) knlGS:0000000000000000
    [  570.144601] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [  570.144601] CR2: 00000000000004e0 CR3: 0000000037f7e000 CR4: 00000000000406a0
    [  570.144601] Stack:
    [  570.144601]  ffffffffa018f240 ffff8800387ec780 ffffffffa018f240 ffff8800387ec7b0
    [  570.144601]  ffff880036b63e48 ffffffff812caabe ffff880039e4e000 0000000000000008
    [  570.144601]  ffff880036b63e58 ffffffff812cabad ffff880036b63ea8 ffffffff811347f5
    [  570.144601] Call Trace:
    [  570.144601]  [<ffffffff812caabe>] sock_release+0x1a/0x75
    [  570.144601]  [<ffffffff812cabad>] sock_close+0xd/0x11
    [  570.144601]  [<ffffffff811347f5>] __fput+0xff/0x1a5
    [  570.144601]  [<ffffffff811348cb>] ____fput+0x9/0xb
    [  570.144601]  [<ffffffff81056682>] task_work_run+0x66/0x90
    [  570.144601]  [<ffffffff8100189e>] prepare_exit_to_usermode+0x8c/0xa7
    [  570.144601]  [<ffffffff81001a26>] syscall_return_slowpath+0x16d/0x19b
    [  570.144601]  [<ffffffff813babb1>] int_ret_from_sys_call+0x25/0x9f
    [  570.144601] Code: 48 8b 83 c8 01 00 00 a8 01 74 12 48 89 df e8 8b 27 14 e1 b8 f7 ff ff ff e9 b7 00 00 00 8a 43 12 a8 0b 74 1c 48 8b 83 a8 04 00 00 <48> 8b 80 e0 04 00 00 65 ff 08 48 c7 83 a8 04 00 00 00 00 00 00
    [  570.144601] RIP  [<ffffffffa018c701>] pppoe_release+0x50/0x101 [pppoe]
    [  570.144601]  RSP <ffff880036b63e08>
    [  570.144601] CR2: 00000000000004e0
    [  570.200518] ---[ end trace 46956baf17349563 ]---

    pppoe_flush_dev() has no reason to override sk->sk_state with
    PPPOX_ZOMBIE. pppox_unbind_sock() already sets sk->sk_state to
    PPPOX_DEAD, which is the correct state given that sk is unbound and
    po->pppoe_dev is NULL.

    Fixes: 2b018d57ff18 ("pppoe: drop PPPOX_ZOMBIEs in pppoe_release")
    Tested-by: Oleksii Berezhniak <core@irc.lg.ua>
    Signed-off-by: Guillaume Nault <g.nault@alphalink.fr>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 5ca907c8d1e928e88f6a3cf877a8d39c5193de64
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Sep 29 18:52:25 2015 -0700

    net: add pfmemalloc check in sk_add_backlog()

    [ Upstream commit c7c49b8fde26b74277188bdc6c9dca38db6fa35b ]

    Greg reported crashes hitting the following check in __sk_backlog_rcv()

            BUG_ON(!sock_flag(sk, SOCK_MEMALLOC));

    The pfmemalloc bit is currently checked in sk_filter().

    This works correctly for TCP, because sk_filter() is ran in
    tcp_v[46]_rcv() before hitting the prequeue or backlog checks.

    For UDP or other protocols, this does not work, because the sk_filter()
    is ran from sock_queue_rcv_skb(), which might be called _after_ backlog
    queuing if socket is owned by user by the time packet is processed by
    softirq handler.

    Fixes: b4b9e35585089 ("netvm: set PF_MEMALLOC as appropriate during SKB processing")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: Greg Thelen <gthelen@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 22f7f93333ef1dd1466cc205e8644c025da65c3e
Author: Pravin B Shelar <pshelar@nicira.com>
Date:   Mon Sep 28 17:24:25 2015 -0700

    skbuff: Fix skb checksum partial check.

    [ Upstream commit 31b33dfb0a144469dd805514c9e63f4993729a48 ]

    Earlier patch 6ae459bda tried to detect void ckecksum partial
    skb by comparing pull length to checksum offset. But it does
    not work for all cases since checksum-offset depends on
    updates to skb->data.

    Following patch fixes it by validating checksum start offset
    after skb-data pointer is updated. Negative value of checksum
    offset start means there is no need to checksum.

    Fixes: 6ae459bda ("skbuff: Fix skb checksum flag on skb pull")
    Reported-by: Andrew Vagin <avagin@odin.com>
    Signed-off-by: Pravin B Shelar <pshelar@nicira.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 97582070de7ca5d50db3e2659b55906d73ab908d
Author: Pravin B Shelar <pshelar@nicira.com>
Date:   Tue Sep 22 12:57:53 2015 -0700

    skbuff: Fix skb checksum flag on skb pull

    [ Upstream commit 6ae459bdaaeebc632b16e54dcbabb490c6931d61 ]

    VXLAN device can receive skb with checksum partial. But the checksum
    offset could be in outer header which is pulled on receive. This results
    in negative checksum offset for the skb. Such skb can cause the assert
    failure in skb_checksum_help(). Following patch fixes the bug by setting
    checksum-none while pulling outer header.

    Following is the kernel panic msg from old kernel hitting the bug.

    ------------[ cut here ]------------
    kernel BUG at net/core/dev.c:1906!
    RIP: 0010:[<ffffffff81518034>] skb_checksum_help+0x144/0x150
    Call Trace:
    <IRQ>
    [<ffffffffa0164c28>] queue_userspace_packet+0x408/0x470 [openvswitch]
    [<ffffffffa016614d>] ovs_dp_upcall+0x5d/0x60 [openvswitch]
    [<ffffffffa0166236>] ovs_dp_process_packet_with_key+0xe6/0x100 [openvswitch]
    [<ffffffffa016629b>] ovs_dp_process_received_packet+0x4b/0x80 [openvswitch]
    [<ffffffffa016c51a>] ovs_vport_receive+0x2a/0x30 [openvswitch]
    [<ffffffffa0171383>] vxlan_rcv+0x53/0x60 [openvswitch]
    [<ffffffffa01734cb>] vxlan_udp_encap_recv+0x8b/0xf0 [openvswitch]
    [<ffffffff8157addc>] udp_queue_rcv_skb+0x2dc/0x3b0
    [<ffffffff8157b56f>] __udp4_lib_rcv+0x1cf/0x6c0
    [<ffffffff8157ba7a>] udp_rcv+0x1a/0x20
    [<ffffffff8154fdbd>] ip_local_deliver_finish+0xdd/0x280
    [<ffffffff81550128>] ip_local_deliver+0x88/0x90
    [<ffffffff8154fa7d>] ip_rcv_finish+0x10d/0x370
    [<ffffffff81550365>] ip_rcv+0x235/0x300
    [<ffffffff8151ba1d>] __netif_receive_skb+0x55d/0x620
    [<ffffffff8151c360>] netif_receive_skb+0x80/0x90
    [<ffffffff81459935>] virtnet_poll+0x555/0x6f0
    [<ffffffff8151cd04>] net_rx_action+0x134/0x290
    [<ffffffff810683d8>] __do_softirq+0xa8/0x210
    [<ffffffff8162fe6c>] call_softirq+0x1c/0x30
    [<ffffffff810161a5>] do_softirq+0x65/0xa0
    [<ffffffff810687be>] irq_exit+0x8e/0xb0
    [<ffffffff81630733>] do_IRQ+0x63/0xe0
    [<ffffffff81625f2e>] common_interrupt+0x6e/0x6e

    Reported-by: Anupam Chanda <achanda@vmware.com>
    Signed-off-by: Pravin B Shelar <pshelar@nicira.com>
    Acked-by: Tom Herbert <tom@herbertland.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 9afa56cff10e209bb9910ef5460f87c0e8f89d3a
Author: Andrey Vagin <avagin@openvz.org>
Date:   Fri Oct 2 00:05:36 2015 +0300

    net/unix: fix logic about sk_peek_offset

    [ Upstream commit e9193d60d363e4dff75ff6d43a48f22be26d59c7 ]

    Now send with MSG_PEEK can return data from multiple SKBs.

    Unfortunately we take into account the peek offset for each skb,
    that is wrong. We need to apply the peek offset only once.

    In addition, the peek offset should be used only if MSG_PEEK is set.

    Cc: "David S. Miller" <davem@davemloft.net> (maintainer:NETWORKING
    Cc: Eric Dumazet <edumazet@google.com> (commit_signer:1/14=7%)
    Cc: Aaron Conole <aconole@bytheb.org>
    Fixes: 9f389e35674f ("af_unix: return data from multiple SKBs on recv() with MSG_PEEK flag")
    Signed-off-by: Andrey Vagin <avagin@openvz.org>
    Tested-by: Aaron Conole <aconole@bytheb.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit aa7940ce4d64d03444e093d4b15a66b8a63e9626
Author: Aaron Conole <aconole@bytheb.org>
Date:   Sat Sep 26 18:50:43 2015 -0400

    af_unix: return data from multiple SKBs on recv() with MSG_PEEK flag

    [ Upstream commit 9f389e35674f5b086edd70ed524ca0f287259725 ]

    AF_UNIX sockets now return multiple skbs from recv() when MSG_PEEK flag
    is set.

    This is referenced in kernel bugzilla #12323 @
    https://bugzilla.kernel.org/show_bug.cgi?id=12323

    As described both in the BZ and lkml thread @
    http://lkml.org/lkml/2008/1/8/444 calling recv() with MSG_PEEK on an
    AF_UNIX socket only reads a single skb, where the desired effect is
    to return as much skb data has been queued, until hitting the recv
    buffer size (whichever comes first).

    The modified MSG_PEEK path will now move to the next skb in the tree
    and jump to the again: label, rather than following the natural loop
    structure. This requires duplicating some of the loop head actions.

    This was tested using the python socketpair python code attached to
    the bugzilla issue.

    Signed-off-by: Aaron Conole <aconole@bytheb.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 38bd9af57d22d9de63c8a8ebb647fbea1f55d887
Author: Aaron Conole <aconole@bytheb.org>
Date:   Sat Sep 26 18:50:42 2015 -0400

    af_unix: Convert the unix_sk macro to an inline function for type safety

    [ Upstream commit 4613012db1d911f80897f9446a49de817b2c4c47 ]

    As suggested by Eric Dumazet this change replaces the
    #define with a static inline function to enjoy
    complaints by the compiler when misusing the API.

    Signed-off-by: Aaron Conole <aconole@bytheb.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit c859b74e5a49244ddf6734ef42f365f3814f3227
Author: Alexander Couzens <lynxis@fe80.eu>
Date:   Mon Sep 28 11:32:42 2015 +0200

    l2tp: protect tunnel->del_work by ref_count

    [ Upstream commit 06a15f51cf3618e32a73871ee6a547ef7fd902b5 ]

    There is a small chance that tunnel_free() is called before tunnel->del_work scheduled
    resulting in a zero pointer dereference.

    Signed-off-by: Alexander Couzens <lynxis@fe80.eu>
    Acked-by: James Chapman <jchapman@katalix.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 645d5160d3e33b256e897b26270f8c944eec67d8
Author: Jan Kara <jack@suse.com>
Date:   Tue Jul 28 14:57:14 2015 -0400

    jbd2: avoid infinite loop when destroying aborted journal

    [ Upstream commit 841df7df196237ea63233f0f9eaa41db53afd70f ]

    Commit 6f6a6fda2945 "jbd2: fix ocfs2 corrupt when updating journal
    superblock fails" changed jbd2_cleanup_journal_tail() to return EIO
    when the journal is aborted. That makes logic in
    jbd2_log_do_checkpoint() bail out which is fine, except that
    jbd2_journal_destroy() expects jbd2_log_do_checkpoint() to always make
    a progress in cleaning the journal. Without it jbd2_journal_destroy()
    just loops in an infinite loop.

    Fix jbd2_journal_destroy() to cleanup journal checkpoint lists of
    jbd2_log_do_checkpoint() fails with error.

    Reported-by: Eryu Guan <guaneryu@gmail.com>
    Tested-by: Eryu Guan <guaneryu@gmail.com>
    Fixes: 6f6a6fda294506dfe0e3e0a253bb2d2923f28f0a
    Signed-off-by: Jan Kara <jack@suse.com>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 6df34de6c5d05d6fa7d99d000a18b84a446095e8
Author: Sasha Levin <sasha.levin@oracle.com>
Date:   Sat Oct 31 16:39:51 2015 -0400

    Linux 3.18.24

    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 5f8c7ff19975a9d78d07265a00d79bff3e168a78
Author: Kosuke Tatsukawa <tatsu@ab.jp.nec.com>
Date:   Fri Oct 2 08:27:05 2015 +0000

    tty: fix stall caused by missing memory barrier in drivers/tty/n_tty.c

    [ Upstream commit e81107d4c6bd098878af9796b24edc8d4a9524fd ]

    My colleague ran into a program stall on a x86_64 server, where
    n_tty_read() was waiting for data even if there was data in the buffer
    in the pty.  kernel stack for the stuck process looks like below.
     #0 [ffff88303d107b58] __schedule at ffffffff815c4b20
     #1 [ffff88303d107bd0] schedule at ffffffff815c513e
     #2 [ffff88303d107bf0] schedule_timeout at ffffffff815c7818
     #3 [ffff88303d107ca0] wait_woken at ffffffff81096bd2
     #4 [ffff88303d107ce0] n_tty_read at ffffffff8136fa23
     #5 [ffff88303d107dd0] tty_read at ffffffff81368013
     #6 [ffff88303d107e20] __vfs_read at ffffffff811a3704
     #7 [ffff88303d107ec0] vfs_read at ffffffff811a3a57
     #8 [ffff88303d107f00] sys_read at ffffffff811a4306
     #9 [ffff88303d107f50] entry_SYSCALL_64_fastpath at ffffffff815c86d7

    There seems to be two problems causing this issue.

    First, in drivers/tty/n_tty.c, __receive_buf() stores the data and
    updates ldata->commit_head using smp_store_release() and then checks
    the wait queue using waitqueue_active().  However, since there is no
    memory barrier, __receive_buf() could return without calling
    wake_up_interactive_poll(), and at the same time, n_tty_read() could
    start to wait in wait_woken() as in the following chart.

            __receive_buf()                         n_tty_read()
    ------------------------------------------------------------------------
    if (waitqueue_active(&tty->read_wait))
    /* Memory operations issued after the
       RELEASE may be completed before the
       RELEASE operation has completed */
                                            add_wait_queue(&tty->read_wait, &wait);
                                            ...
                                            if (!input_available_p(tty, 0)) {
    smp_store_release(&ldata->commit_head,
                      ldata->read_head);
                                            ...
                                            timeout = wait_woken(&wait,
                                              TASK_INTERRUPTIBLE, timeout);
    ------------------------------------------------------------------------

    The second problem is that n_tty_read() also lacks a memory barrier
    call and could also cause __receive_buf() to return without calling
    wake_up_interactive_poll(), and n_tty_read() to wait in wait_woken()
    as in the chart below.

            __receive_buf()                         n_tty_read()
    ------------------------------------------------------------------------
                                            spin_lock_irqsave(&q->lock, flags);
                                            /* from add_wait_queue() */
                                            ...
                                            if (!input_available_p(tty, 0)) {
                                            /* Memory operations issued after the
                                               RELEASE may be completed before the
                                               RELEASE operation has completed */
    smp_store_release(&ldata->commit_head,
                      ldata->read_head);
    if (waitqueue_active(&tty->read_wait))
                                            __add_wait_queue(q, wait);
                                            spin_unlock_irqrestore(&q->lock,flags);
                                            /* from add_wait_queue() */
                                            ...
                                            timeout = wait_woken(&wait,
                                              TASK_INTERRUPTIBLE, timeout);
    ------------------------------------------------------------------------

    There are also other places in drivers/tty/n_tty.c which have similar
    calls to waitqueue_active(), so instead of adding many memory barrier
    calls, this patch simply removes the call to waitqueue_active(),
    leaving just wake_up*() behind.

    This fixes both problems because, even though the memory access before
    or after the spinlocks in both wake_up*() and add_wait_queue() can
    sneak into the critical section, it cannot go past it and the critical
    section assures that they will be serialized (please see "INTER-CPU
    ACQUIRING BARRIER EFFECTS" in Documentation/memory-barriers.txt for a
    better explanation).  Moreover, the resulting code is much simpler.

    Latency measurement using a ping-pong test over a pty doesn't show any
    visible performance drop.

    Signed-off-by: Kosuke Tatsukawa <tatsu@ab.jp.nec.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit cfe6deeecd4098b743a4d50825a112893465738e
Author: Sasha Levin <sasha.levin@oracle.com>
Date:   Sat Oct 31 08:54:32 2015 -0400

    Revert "tty: fix stall caused by missing memory barrier in drivers/tty/n_tty.c"

    This reverts commit af32cc7bde6304dac92e6a74fe4b2cc8120cb29a.

    The commit was incorrectly backported and was causing hangs.

    Reported-by: Corey Wright <undefined@pobox.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 343f9bd48a7d3b6399542bf50762371ee44ed70f
Author: Sasha Levin <sasha.levin@oracle.com>
Date:   Wed Oct 28 22:49:46 2015 -0400

    Linux 3.18.23

    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 5ef609bbdc4845085488543b1c67d550f705e090
Author: Steven Rostedt <rostedt@goodmis.org>
Date:   Fri Feb 27 14:50:19 2015 -0500

    x86: Init per-cpu shadow copy of CR4 on 32-bit CPUs too

    [ Upstream commit 5b2bdbc84556774afbe11bcfd24c2f6411cfa92b ]

    Commit:

       1e02ce4cccdc ("x86: Store a per-cpu shadow copy of CR4")

    added a shadow CR4 such that reads and writes that do not
    modify the CR4 execute much faster than always reading the
    register itself.

    The change modified cpu_init() in common.c, so that the
    shadow CR4 gets initialized before anything uses it.

    Unfortunately, there's two cpu_init()s in common.c. There's
    one for 64-bit and one for 32-bit. The commit only added
    the shadow init to the 64-bit path, but the 32-bit path
    needs the init too.

    Link: http://lkml.kernel.org/r/20150227125208.71c36402@gandalf.local.home Fixes: 1e02ce4cccdc "x86: Store a per-cpu shadow copy of CR4"
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Acked-by: Andy Lutomirski <luto@amacapital.net>
    Cc: Peter Zijlstra (Intel) <peterz@infradead.org>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Link: http://lkml.kernel.org/r/20150227145019.2bdd4354@gandalf.local.home
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 12b34f06d178859239282182dc2951873ec8818f
Author: Christoph Hellwig <hch@lst.de>
Date:   Sat Oct 3 19:16:07 2015 +0200

    3w-9xxx: don't unmap bounce buffered commands

    [ Upstream commit 15e3d5a285ab9283136dba34bbf72886d9146706 ]

    3w controller don't dma map small single SGL entry commands but instead
    bounce buffer them.  Add a helper to identify these commands and don't
    call scsi_dma_unmap for them.

    Based on an earlier patch from James Bottomley.

    Fixes: 118c85 ("3w-9xxx: fix command completion race")
    Reported-by: Tóth Attila <atoth@atoth.sote.hu>
    Tested-by: Tóth Attila <atoth@atoth.sote.hu>
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Acked-by: Adam Radford <aradford@gmail.com>
    Signed-off-by: James Bottomley <JBottomley@Odin.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 2c74d22246d30a2c6205e30d8b52b93870586200
Author: Roland Dreier <roland@purestorage.com>
Date:   Mon Oct 5 10:29:28 2015 -0700

    fib_rules: Fix dump_rules() not to exit early

    [ Upstream commit 8ea4b34355189e1f1eacaf2d825f2dce776b3b9c ]

    Backports of 41fc014332d9 ("fib_rules: fix fib rule dumps across
    multiple skbs") introduced a regression in "ip rule show" - it ends up
    dumping the first rule over and over and never exiting, because 3.19
    and earlier are missing commit 053c095a82cf ("netlink: make
    nlmsg_end() and genlmsg_end() void"), so fib_nl_fill_rule() ends up
    returning skb->len (i.e. > 0) in the success case.

    Fix this by checking the return code for < 0 instead of != 0.

    Signed-off-by: Roland Dreier <roland@purestorage.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 36afb7233c204099f1f81395e72d0aa2ec3230ac
Author: Eric W. Biederman <ebiederm@xmission.com>
Date:   Sat Aug 15 20:27:13 2015 -0500

    vfs: Test for and handle paths that are unreachable from their mnt_root

    [ Upstream commit 397d425dc26da728396e66d392d5dcb8dac30c37 ]

    In rare cases a directory can be renamed out from under a bind mount.
    In those cases without special handling it becomes possible to walk up
    the directory tree to the root dentry of the filesystem and down
    from the root dentry to every other file or directory on the filesystem.

    Like division by zero .. from an unconnected path can not be given
    a useful semantic as there is no predicting at which path component
    the code will realize it is unconnected.  We certainly can not match
    the current behavior as the current behavior is a security hole.

    Therefore when encounting .. when following an unconnected path
    return -ENOENT.

    - Add a function path_connected to verify path->dentry is reachable
      from path->mnt.mnt_root.  AKA to validate that rename did not do
      something nasty to the bind mount.

      To avoid races path_connected must be called after following a path
      component to it's next path component.

    Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 846a6c3fdedbea41f9787f6dbc9f1b0b081fb518
Author: NeilBrown <neilb@suse.com>
Date:   Wed Jul 22 10:20:07 2015 +1000

    md: flush ->event_work before stopping array.

    [ Upstream commit ee5d004fd0591536a061451eba2b187092e9127c ]

    The 'event_work' worker used by dm-raid may still be running
    when the array is stopped.  This can result in an oops.

    So flush the workqueue on which it is run after detaching
    and before destroying the device.

    Reported-by: Heinz Mauelshagen <heinzm@redhat.com>
    Signed-off-by: NeilBrown <neilb@suse.com>
    Cc: stable@vger.kernel.org (2.6.38+ please delay 2 weeks after -final release)
    Fixes: 9d09e663d550 ("dm: raid456 basic support")
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 307a1c1213513f41dd39b40aae0291f16adc6b7b
Author: Andy Lutomirski <luto@kernel.org>
Date:   Sun Sep 20 16:32:05 2015 -0700

    x86/nmi/64: Fix a paravirt stack-clobbering bug in the NMI code

    [ Upstream commit 83c133cf11fb0e68a51681447e372489f052d40e ]

    The NMI entry code that switches to the normal kernel stack needs to
    be very careful not to clobber any extra stack slots on the NMI
    stack.  The code is fine under the assumption that SWAPGS is just a
    normal instruction, but that assumption isn't really true.  Use
    SWAPGS_UNSAFE_STACK instead.

    This is part of a fix for some random crashes that Sasha saw.

    Fixes: 9b6e6a8334d5 ("x86/nmi/64: Switch stacks on userspace NMI entry")
    Reported-and-tested-by: Sasha Levin <sasha.levin@oracle.com>
    Signed-off-by: Andy Lutomirski <luto@kernel.org>
    Cc: stable@vger.kernel.org
    Link: http://lkml.kernel.org/r/974bc40edffdb5c2950a5c4977f821a446b76178.1442791737.git.luto@kernel.org
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit c93f6e1ee3a8db372b6527030f6bd2eb97474476
Author: Markus Pargmann <mpa@pengutronix.de>
Date:   Wed Jul 29 15:46:03 2015 +0200

    Revert "iio: bmg160: IIO_BUFFER and IIO_TRIGGERED_BUFFER are required"

    [ Upstream commit HEAD ]

    This reverts commit 279c039ca63acbd69e69d6d7ddfed50346fb2185 which was
    commit 06d2f6ca5a38abe92f1f3a132b331eee773868c3 upstream as it should
    not have been applied.

    Reported-by: Luis Henriques <luis.henriques@canonical.com>
    Cc: Markus Pargmann <mpa@pengutronix.de>
    Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
    Cc: Jonathan Cameron <jic23@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

    (cherry picked from commit 934d9b907aeec5f344ca801ed7361551199dfc69)
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit c1b3815f362ef76e27553e70d4ec54ce8951aeac
Author: Herbert Xu <herbert@gondor.apana.org.au>
Date:   Mon Jul 13 16:04:13 2015 +0800

    net: Fix skb_set_peeked use-after-free bug

    [ Upstream commit a0a2a6602496a45ae838a96db8b8173794b5d398 ]

    The commit 738ac1ebb96d02e0d23bc320302a6ea94c612dec ("net: Clone
    skb before setting peeked flag") introduced a use-after-free bug
    in skb_recv_datagram.  This is because skb_set_peeked may create
    a new skb and free the existing one.  As it stands the caller will
    continue to use the old freed skb.

    This patch fixes it by making skb_set_peeked return the new skb
    (or the old one if unchanged).

    Fixes: 738ac1ebb96d ("net: Clone skb before setting peeked flag")
    Reported-by: Brenden Blanco <bblanco@plumgrid.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Tested-by: Brenden Blanco <bblanco@plumgrid.com>
    Reviewed-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 6402732251519e7cc44949e7621cb24c8a3dd5dc
Author: Yinghai Lu <yinghai@kernel.org>
Date:   Fri Sep 4 15:42:39 2015 -0700

    mm: check if section present during memory block registering

    [ Upstream commit 04697858d89e4bf2650364f8d6956e2554e8ef88 ]

    Tony Luck found on his setup, if memory block size 512M will cause crash
    during booting.

      BUG: unable to handle kernel paging request at ffffea0074000020
      IP: get_nid_for_pfn+0x17/0x40
      PGD 128ffcb067 PUD 128ffc9067 PMD 0
      Oops: 0000 [#1] SMP
      Modules linked in:
      CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.2.0-rc8 #1
      ...
      Call Trace:
         ? register_mem_sect_under_node+0x66/0xe0
         register_one_node+0x17b/0x240
         ? pci_iommu_alloc+0x6e/0x6e
         topology_init+0x3c/0x95
         do_one_initcall+0xcd/0x1f0

    The system has non continuous RAM address:
     BIOS-e820: [mem 0x0000001300000000-0x0000001cffffffff] usable
     BIOS-e820: [mem 0x0000001d70000000-0x0000001ec7ffefff] usable
     BIOS-e820: [mem 0x0000001f00000000-0x0000002bffffffff] usable
     BIOS-e820: [mem 0x0000002c18000000-0x0000002d6fffefff] usable
     BIOS-e820: [mem 0x0000002e00000000-0x00000039ffffffff] usable

    So there are start sections in memory block not present.  For example:

        memory block : [0x2c18000000, 0x2c20000000) 512M

    first three sections are not present.

    The current register_mem_sect_under_node() assume first section is
    present, but memory block section number range [start_section_nr,
    end_section_nr] would include not present section.

    For arch that support vmemmap, we don't setup memmap for struct page
    area within not present sections area.

    So skip the pfn range that belong to absent section.

    [akpm@linux-foundation.org: simplification]
    [rientjes@google.com: more simplification]
    Fixes: bdee237c0343 ("x86: mm: Use 2GB memory block size on large memory x86-64 systems")
    Fixes: 982792c782ef ("x86, mm: probe memory block size for generic x86 64bit")
    Signed-off-by: Yinghai Lu <yinghai@kernel.org>
    Signed-off-by: David Rientjes <rientjes@google.com>
    Reported-by: Tony Luck <tony.luck@intel.com>
    Tested-by: Tony Luck <tony.luck@intel.com>
    Cc: Greg KH <greg@kroah.com>
    Cc: Ingo Molnar <mingo@elte.hu>
    Tested-by: David Rientjes <rientjes@google.com>
    Cc: <stable@vger.kernel.org>    [3.15+]
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 49577c854b5dbf004acb57037596ab5b39c800aa
Author: Mikulas Patocka <mikulas@twibright.com>
Date:   Wed Sep 2 22:51:53 2015 +0200

    hpfs: update ctime and mtime on directory modification

    [ Upstream commit f49a26e7718dd30b49e3541e3e25aecf5e7294e2 ]

    Update ctime and mtime when a directory is modified. (though OS/2 doesn't
    update them anyway)

    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Cc: stable@kernel.org   # v3.3+
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 84d2f08ca422687a306f31388c3cfda000eae355
Author: Grant Likely <grant.likely@linaro.org>
Date:   Sun Jun 7 15:20:11 2015 +0100

    drivercore: Fix unregistration path of platform devices

    [ Upstream commit 7f5dcaf1fdf289767a126a0a5cc3ef39b5254b06 ]

    The unregister path of platform_device is broken. On registration, it
    will register all resources with either a parent already set, or
    type==IORESOURCE_{IO,MEM}. However, on unregister it will release
    everything with type==IORESOURCE_{IO,MEM}, but ignore the others. There
    are also cases where resources don't get registered in the first place,
    like with devices created by of_platform_populate()*.

    Fix the unregister path to be symmetrical with the register path by
    checking the parent pointer instead of the type field to decide which
    resources to unregister. This is safe because the upshot of the
    registration path algorithm is that registered resources have a parent
    pointer, and non-registered resources do not.

    * It can be argued that of_platform_populate() should be registering
      it's resources, and they argument has some merit. However, there are
      quite a few platforms that end up broken if we try to do that due to
      overlapping resources in the device tree. Until that is fixed, we need
      to solve the immediate problem.

    Cc: Pantelis Antoniou <pantelis.antoniou@konsulko.com>
    Cc: Wolfram Sang <wsa@the-dreams.de>
    Cc: Rob Herring <robh@kernel.org>
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Cc: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
    Signed-off-by: Grant Likely <grant.likely@linaro.org>
    Tested-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
    Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Rob Herring <robh@kernel.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit ee491c0c341c43a9aac4a44255e8a801e8233955
Author: Vignesh R <vigneshr@ti.com>
Date:   Wed Jun 3 17:21:20 2015 +0530

    ARM: OMAP2+: DRA7: clockdomain: change l4per2_7xx_clkdm to SW_WKUP

    [ Upstream commit b9e23f321940d2db2c9def8ff723b8464fb86343 ]

    Legacy IPs like PWMSS, present under l4per2_7xx_clkdm, cannot support
    smart-idle when its clock domain is in HW_AUTO on DRA7 SoCs. Hence,
    program clock domain to SW_WKUP.

    Signed-off-by: Vignesh R <vigneshr@ti.com>
    Acked-by: Tero Kristo <t-kristo@ti.com>
    Reviewed-by: Paul Walmsley <paul@pwsan.com>
    Signed-off-by: Paul Walmsley <paul@pwsan.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 6e95689dd460d525a65be7158f31f52323812654
Author: David Daney <david.daney@cavium.com>
Date:   Wed Aug 19 13:17:47 2015 -0700

    of/address: Don't loop forever in of_find_matching_node_by_address().

    [ Upstream commit 3a496b00b6f90c41bd21a410871dfc97d4f3c7ab ]

    If the internal call to of_address_to_resource() fails, we end up
    looping forever in of_find_matching_node_by_address().  This can be
    caused by a defective device tree, or calling with an incorrect
    matches argument.

    Fix by calling of_find_matching_node() unconditionally at the end of
    the loop.

    Signed-off-by: David Daney <david.daney@cavium.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Rob Herring <robh@kernel.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit e5c96a79865c62e593b41eb69153be15cc66b41e
Author: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
Date:   Mon Jul 20 17:27:21 2015 +0530

    auxdisplay: ks0108: fix refcount

    [ Upstream commit bab383de3b84e584b0f09227151020b2a43dc34c ]

    parport_find_base() will implicitly do parport_get_port() which
    increases the refcount. Then parport_register_device() will again
    increment the refcount. But while unloading the module we are only
    doing parport_unregister_device() decrementing the refcount only once.
    We add an parport_put_port() to neutralize the effect of
    parport_get_port().

    Cc: <stable@vger.kernel.org> # 2.6.32+
    Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit e451bf46db1a1fda75428c29de0137b20946580f
Author: Peter Chen <peter.chen@freescale.com>
Date:   Fri Jul 31 16:36:29 2015 +0800

    Doc: ABI: testing: configfs-usb-gadget-sourcesink

    [ Upstream commit 4bc58eb16bb2352854b9c664cc36c1c68d2bfbb7 ]

    Fix the name of attribute

    Cc: <stable@vger.kernel.org>
    Signed-off-by: Peter Chen <peter.chen@freescale.com>
    Signed-off-by: Felipe Balbi <balbi@ti.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 930acc5024169d705c7debdf5fa30a8e8ae84788
Author: Peter Chen <peter.chen@freescale.com>
Date:   Fri Jul 31 16:36:28 2015 +0800

    Doc: ABI: testing: configfs-usb-gadget-loopback

    [ Upstream commit 8cd50626823c00ca7472b2f61cb8c0eb9798ddc0 ]

    Fix the name of attribute

    Cc: <stable@vger.kernel.org>
    Signed-off-by: Peter Chen <peter.chen@freescale.com>
    Signed-off-by: Felipe Balbi <balbi@ti.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 5062f6012e4022cde01727b831454e981a070306
Author: Masahiro Yamada <yamada.masahiro@socionext.com>
Date:   Wed Jul 15 10:29:00 2015 +0900

    devres: fix devres_get()

    [ Upstream commit 64526370d11ce8868ca495723d595b61e8697fbf ]

    Currently, devres_get() passes devres_free() the pointer to devres,
    but devres_free() should be given with the pointer to resource data.

    Fixes: 9ac7849e35f7 ("devres: device resource management")
    Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
    Acked-by: Tejun Heo <tj@kernel.org>
    Cc: stable <stable@vger.kernel.org> # 2.6.21+
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 75f411869a2a2b72cadc077e1bf44338bb869d82
Author: Max Filippov <jcmvbkbc@gmail.com>
Date:   Thu Jul 16 10:41:02 2015 +0300

    xtensa: fix kernel register spilling

    [ Upstream commit 77d6273e79e3a86552fcf10cdd31a69b46ed2ce6 ]

    call12 can't be safely used as the first call in the inline function,
    because the compiler does not extend the stack frame of the bounding
    function accordingly, which may result in corruption of local variables.

    If a call needs to be done, do call8 first followed by call12.

    For pure assembly code in _switch_to increase stack frame size of the
    bounding function.

    Cc: stable@vger.kernel.org
    Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 493c0e290d349e4821558a575061d98193ba5115
Author: Max Filippov <jcmvbkbc@gmail.com>
Date:   Sat Jul 4 15:27:39 2015 +0300

    xtensa: fix threadptr reload on return to userspace

    [ Upstream commit 4229fb12a03e5da5882b420b0aa4a02e77447b86 ]

    Userspace return code may skip restoring THREADPTR register if there are
    no registers that need to be zeroed. This leads to spurious failures in
    libc NPTL tests.

    Always restore THREADPTR on return to userspace.

    Cc: stable@vger.kernel.org
    Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 3d5f09649ae556201f93c1e4be967aaf2b920744
Author: Xiao Guangrong <guangrong.xiao@linux.intel.com>
Date:   Wed Aug 5 12:04:19 2015 +0800

    KVM: MMU: fix validation of mmio page fault

    [ Upstream commit 6f691251c0350ac52a007c54bf3ef62e9d8cdc5e ]

    We got the bug that qemu complained with "KVM: unknown exit, hardware
    reason 31" and KVM shown these info:
    [84245.284948] EPT: Misconfiguration.
    [84245.285056] EPT: GPA: 0xfeda848
    [84245.285154] ept_misconfig_inspect_spte: spte 0x5eaef50107 level 4
    [84245.285344] ept_misconfig_inspect_spte: spte 0x5f5fadc107 level 3
    [84245.285532] ept_misconfig_inspect_spte: spte 0x5141d18107 level 2
    [84245.285723] ept_misconfig_inspect_spte: spte 0x52e40dad77 level 1

    This is because we got a mmio #PF and the handler see the mmio spte becomes
    normal (points to the ram page)

    However, this is valid after introducing fast mmio spte invalidation which
    increases the generation-number instead of zapping mmio sptes, a example
    is as follows:
    1. QEMU drops mmio region by adding a new memslot
    2. invalidate all mmio sptes
    3.

            VCPU 0                        VCPU 1
        access the invalid mmio spte
                                access the region originally was MMIO before
                                set the spte to the normal ram map

        mmio #PF
        check the spte and see it becomes normal ram mapping !!!

    This patch fixes the bug just by dropping the check in mmio handler, it's
    good for backport. Full check will be introduced in later patches

    Reported-by: Pavel Shirshov <ru.pchel@gmail.com>
    Tested-by: Pavel Shirshov <ru.pchel@gmail.com>
    Signed-off-by: Xiao Guangrong <guangrong.xiao@linux.intel.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 06cab2593619a6ed6fee26dbdd55fa521f14f9f0
Author: Don Zickus <dzickus@redhat.com>
Date:   Mon Aug 10 12:06:53 2015 -0400

    HID: usbhid: Fix the check for HID_RESET_PENDING in hid_io_error

    [ Upstream commit 3af4e5a95184d6d3c1c6a065f163faa174a96a1d ]

    It was reported that after 10-20 reboots, a usb keyboard plugged
    into a docking station would not work unless it was replugged in.

    Using usbmon, it turns out the interrupt URBs were streaming with
    callback errors of -71 for some reason.  The hid-core.c::hid_io_error was
    supposed to retry and then reset, but the reset wasn't really happening.

    The check for HID_NO_BANDWIDTH was inverted.  Fix was simple.

    Tested by reporter and locally by me by unplugging a keyboard halfway until I
    could recreate a stream of errors but no disconnect.

    Signed-off-by: Don Zickus <dzickus@redhat.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit d72174a6d7cbdf965458c586eb736e40bd81f215
Author: Andrey Ryabinin <aryabinin@odin.com>
Date:   Thu Sep 3 14:32:01 2015 +0300

    crypto: ghash-clmulni: specify context size for ghash async algorithm

    [ Upstream commit 71c6da846be478a61556717ef1ee1cea91f5d6a8 ]

    Currently context size (cra_ctxsize) doesn't specified for
    ghash_async_alg. Which means it's zero. Thus crypto_create_tfm()
    doesn't allocate needed space for ghash_async_ctx, so any
    read/write to ctx (e.g. in ghash_async_init_tfm()) is not valid.

    Cc: stable@vger.kernel.org
    Signed-off-by: Andrey Ryabinin <aryabinin@odin.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 0df02ec634dc9ace6854b1e11c692c116aaf35fe
Author: Maciej S. Szmigiero <mail@maciej.szmigiero.name>
Date:   Sun Aug 2 23:11:52 2015 +0200

    serial: 8250: don't bind to SMSC IrCC IR port

    [ Upstream commit ffa34de03bcfbfa88d8352942bc238bb48e94e2d ]

    SMSC IrCC SIR/FIR port should not be bound to by
    (legacy) serial driver so its own driver (smsc-ircc2)
    can bind to it.

    Signed-off-by: Maciej Szmigiero <mail@maciej.szmigiero.name>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 63bdd88aebe05c01c64bfce68ffeaf2697c7007d
Author: Peter Chen <peter.chen@freescale.com>
Date:   Mon Aug 17 10:23:03 2015 +0800

    usb: host: ehci-sys: delete useless bus_to_hcd conversion

    [ Upstream commit 0521cfd06e1ebcd575e7ae36aab068b38df23850 ]

    The ehci platform device's drvdata is the pointer of struct usb_hcd
    already, so we doesn't need to call bus_to_hcd conversion again.

    Cc: <stable@vger.kernel.org>
    Signed-off-by: Peter Chen <peter.chen@freescale.com>
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 2c9fef0a33b224c6e3b9083d6b3ac1966f5e5df2
Author: Kishon Vijay Abraham I <kishon@ti.com>
Date:   Mon Jul 27 12:25:27 2015 +0530

    usb: dwc3: ep0: Fix mem corruption on OUT transfers of more than 512 bytes

    [ Upstream commit b2fb5b1a0f50d3ebc12342c8d8dead245e9c9d4e ]

    DWC3 uses bounce buffer to handle non max packet aligned OUT transfers and
    the size of bounce buffer is 512 bytes. However if the host initiates OUT
    transfers of size more than 512 bytes (and non max packet aligned), the
    driver throws a WARN dump but still programs the TRB to receive more than
    512 bytes. This will cause bounce buffer to overflow and corrupt the
    adjacent memory locations which can be fatal.

    Fix it by programming the TRB to receive a maximum of DWC3_EP0_BOUNCE_SIZE
    (512) bytes.

    Cc: <stable@vger.kernel.org> # 3.4+
    Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
    Signed-off-by: Felipe Balbi <balbi@ti.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit a3c1260650e176f211f9cbc1cfc8cbad570784dd
Author: Matthijs Kooijman <matthijs@stdin.nl>
Date:   Tue Aug 18 10:33:56 2015 +0200

    USB: ftdi_sio: Added custom PID for CustomWare products

    [ Upstream commit 1fb8dc36384ae1140ee6ccc470de74397606a9d5 ]

    CustomWare uses the FTDI VID with custom PIDs for their ShipModul MiniPlex
    products.

    Signed-off-by: Matthijs Kooijman <matthijs@stdin.nl>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 2d2438f4ad4f57732fc2c44380c95ad5955984d2
Author: Philipp Hachtmann <hachti@hachti.de>
Date:   Mon Aug 17 17:31:46 2015 +0200

    USB: symbolserial: Use usb_get_serial_port_data

    [ Upstream commit 951d3793bbfc0a441d791d820183aa3085c83ea9 ]

    The driver used usb_get_serial_data(port->serial) which compiled but resulted
    in a NULL pointer being returned (and subsequently used). I did not go deeper
    into this but I guess this is a regression.

    Signed-off-by: Philipp Hachtmann <hachti@hachti.de>
    Fixes: a85796ee5149 ("USB: symbolserial: move private-data allocation to
    port_probe")
    Cc: stable <stable@vger.kernel.org>     # v3.10
    Acked-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 28fe0e4f55fd669f5f629bc763d3b8cf399e2467
Author: Bjorn Helgaas <bhelgaas@google.com>
Date:   Fri Jun 19 15:58:24 2015 -0500

    PCI: Fix TI816X class code quirk

    [ Upstream commit d1541dc977d376406f4584d8eb055488655c98ec ]

    In fixup_ti816x_class(), we assigned "class = PCI_CLASS_MULTIMEDIA_VIDEO".
    But PCI_CLASS_MULTIMEDIA_VIDEO is only the two-byte base class/sub-class
    and needs to be shifted to make space for the low-order interface byte.

    Shift PCI_CLASS_MULTIMEDIA_VIDEO to set the correct class code.

    Fixes: 63c4408074cb ("PCI: Add quirk for setting valid class for TI816X Endpoint")
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    CC: Hemant Pedanekar <hemantp@ti.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 63f29ebd76d06f0eadd2de6987b94bfb86ca7dab
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Wed Jul 29 13:17:06 2015 +0300

    clk: versatile: off by one in clk_sp810_timerclken_of_get()

    [ Upstream commit 3294bee87091be5f179474f6c39d1d87769635e2 ]

    The ">" should be ">=" or we end up reading beyond the end of the array.

    Fixes: 6e973d2c4385 ('clk: vexpress: Add separate SP810 driver')
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Acked-by: Pawel Moll <pawel.moll@arm.com>
    Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 25eabc9328cbd27e52d20010682151f0493cd0c8
Author: Ian Abbott <abbotti@mev.co.uk>
Date:   Tue Aug 11 13:05:10 2015 +0100

    staging: comedi: adl_pci7x3x: fix digital output on PCI-7230

    [ Upstream commit ad83dbd974feb2e2a8cc071a1d28782bd4d2c70e ]

    The "adl_pci7x3x" driver replaced the "adl_pci7230" and "adl_pci7432"
    drivers in commits 8f567c373c4b ("staging: comedi: new adl_pci7x3x
    driver") and 657f77d173d3 ("staging: comedi: remove adl_pci7230 and
    adl_pci7432 drivers").  Although the new driver code agrees with the
    user manuals for the respective boards, digital outputs stopped working
    on the PCI-7230.  This has 16 digital output channels and the previous
    adl_pci7230 driver shifted the 16 bit output state left by 16 bits
    before writing to the hardware register.  The new adl_pci7x3x driver
    doesn't do that.  Fix it in `adl_pci7x3x_do_insn_bits()` by checking
    for the special case of the subdevice having only 16 channels and
    duplicating the 16 bit output state into both halves of the 32-bit
    register.  That should work both for what the board actually does and
    for what the user manual says it should do.

    Fixes: 8f567c373c4b ("staging: comedi: new adl_pci7x3x driver")
    Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
    Cc: <stable@vger.kernel.org> # 3.13+, needs backporting for 3.7 to 3.12
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit f452eb1887c18b83ea991781c413cf9e88a86863
Author: Lars-Peter Clausen <lars@metafoo.de>
Date:   Wed Aug 5 15:38:15 2015 +0200

    iio: adis16480: Fix scale factors

    [ Upstream commit 7abad1063deb0f77d275c61f58863ec319c58c5c ]

    The different devices support by the adis16480 driver have slightly
    different scales for the gyroscope and accelerometer channels.

    Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
    Cc: <Stable@vger.kernel.org>
    Signed-off-by: Jonathan Cameron <jic23@kernel.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 12958c6062a0075074e16131ef4837cfecc3b8de
Author: Lars-Peter Clausen <lars@metafoo.de>
Date:   Wed Aug 5 15:38:14 2015 +0200

    iio: Add inverse unit conversion macros

    [ Upstream commit c689a923c867eac40ed3826c1d9328edea8b6bc7 ]

    Add inverse unit conversion macro to convert from standard IIO units to
    units that might be used by some devices.

    Those are useful in combination with scale factors that are specified as
    IIO_VAL_FRACTIONAL. Typically the denominator for those specifications will
    contain the maximum raw value the sensor will generate and the numerator
    the value it maps to in a specific unit. Sometimes datasheets specify those
    in different units than the standard IIO units (e.g. degree/s instead of
    rad/s) and so we need to do a unit conversion.

    From a mathematical point of view it does not make a difference whether we
    apply the unit conversion to the numerator or the inverse unit conversion
    to the denominator since (x / y) / z = x / (y * z). But as the denominator
    is typically a larger value and we are rounding both the numerator and
    denominator to integer values using the later method gives us a better
    precision (E.g. the relative error is smaller if we round 8000.3 to 8000
    rather than rounding 8.3 to 8).

    This is where in inverse unit conversion macros will be used.

    Marked for stable as used by some upcoming fixes.

    Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
    Cc: <Stable@vger.kernel.org>
    Signed-off-by: Jonathan Cameron <jic23@kernel.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 32163777a11a84449114c304848a884f3f5ed887
Author: Cristina Opriceana <cristina.opriceana@gmail.com>
Date:   Mon Aug 3 13:37:40 2015 +0300

    iio: industrialio-buffer: Fix iio_buffer_poll return value

    [ Upstream commit 1bdc0293901cbea23c6dc29432e81919d4719844 ]

    Change return value to 0 if no device is bound since
    unsigned int cannot support negative error codes.

    Fixes: f18e7a068 ("iio: Return -ENODEV for file operations if the
    device has been unregistered")

    Signed-off-by: Cristina Opriceana <cristina.opriceana@gmail.com>
    Cc: <Stable@vger.kernel.org>
    Signed-off-by: Jonathan Cameron <jic23@kernel.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 1c979a10452b6bb7b22a3756fa0b374720179543
Author: Cristina Opriceana <cristina.opriceana@gmail.com>
Date:   Mon Aug 3 13:00:47 2015 +0300

    iio: event: Remove negative error code from iio_event_poll

    [ Upstream commit 41d903c00051d8f31c98a8136edbac67e6f8688f ]

    Negative return values are not supported by iio_event_poll since
    its return type is unsigned int.

    Fixes: f18e7a068a0a3 ("iio: Return -ENODEV for file operations if the device has been unregistered")

    Signed-off-by: Cristina Opriceana <cristina.opriceana@gmail.com>
    Cc: <Stable@vger.kernel.org>
    Signed-off-by: Jonathan Cameron <jic23@kernel.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 0b7a7c0416bd481cb4c9e10cca496f3b1dc56c35
Author: Markus Pargmann <mpa@pengutronix.de>
Date:   Wed Jul 29 15:46:03 2015 +0200

    iio: bmg160: IIO_BUFFER and IIO_TRIGGERED_BUFFER are required

    [ Upstream commit 06d2f6ca5a38abe92f1f3a132b331eee773868c3 ]

    This patch adds selects for IIO_BUFFER and IIO_TRIGGERED_BUFFER. Without
    IIO_BUFFER, the driver does not compile.

    Signed-off-by: Markus Pargmann <mpa@pengutronix.de>
    Reviewed-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
    Cc: <Stable@vger.kernel.org>
    Signed-off-by: Jonathan Cameron <jic23@kernel.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit a03140d0a726899c457fe95b81dfd2bd49d967f4
Author: Sebastian Ott <sebott@linux.vnet.ibm.com>
Date:   Thu Jun 25 09:32:22 2015 +0200

    s390/sclp: fix compile error

    [ Upstream commit a313bdc5310dd807655d3ca3eb2219cd65dfe45a ]

    Fix this error when compiling with CONFIG_SMP=n and
    CONFIG_DYNAMIC_DEBUG=y:

    drivers/s390/char/sclp_early.c: In function 'sclp_read_info_early':
    drivers/s390/char/sclp_early.c:87:19: error: 'EBUSY' undeclared (first use in this function)
       } while (rc == -EBUSY);
                       ^

    Signed-off-by: Sebastian Ott <sebott@linux.vnet.ibm.com>
    Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 510b6c73f2ba293b6c69af9353f6989bbd213e19
Author: Jonathon Jongsma <jjongsma@redhat.com>
Date:   Thu Aug 20 14:04:32 2015 -0500

    drm/qxl: validate monitors config modes

    [ Upstream commit bd3e1c7c6de9f5f70d97cdb6c817151c0477c5e3 ]

    Due to some recent changes in
    drm_helper_probe_single_connector_modes_merge_bits(), old custom modes
    were not being pruned properly. In current kernels,
    drm_mode_validate_basic() is called to sanity-check each mode in the
    list. If the sanity-check passes, the mode's status gets set to to
    MODE_OK. In older kernels this check was not done, so old custom modes
    would still have a status of MODE_UNVERIFIED at this point, and would
    therefore be pruned later in the function.

    As a result of this new behavior, the list of modes for a device always
    includes every custom mode ever configured for the device, with the
    largest one listed first. Since desktop environments usually choose the
    first preferred mode when a hotplug event is emitted, this had the
    result of making it very difficult for the user to reduce the size of
    the display.

    The qxl driver did implement the mode_valid connector function, but it
    was empty. In order to restore the old behavior where old custom modes
    are pruned, we implement a proper mode_valid function for the qxl
    driver. This function now checks each mode against the last configured
    custom mode and the list of standard modes. If the mode doesn't match
    any of these, its status is set to MODE_BAD so that it will be pruned as
    expected.

    Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 97c4f73e690d584945ace96f2dc10ebae63a2180
Author: Stephen Chandler Paul <cpaul@redhat.com>
Date:   Fri Aug 21 14:16:12 2015 -0400

    drm/amdgpu: Don't link train DisplayPort on HPD until we get the dpcd

    [ Upstream commit a887adadb7b9ef9eb4ee48e4ad575aefcfd1db14 ]

    This is a port of:
    DRM - radeon: Don't link train DisplayPort on HPD until we get the dpcd
    to amdgpu.

    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 2c8818052d31bdc57b78ccbdbc1298479bc80d51
Author: Joonsoo Kim <js1304@gmail.com>
Date:   Thu Oct 1 15:36:54 2015 -0700

    mm/slab: fix unexpected index mapping result of kmalloc_size(INDEX_NODE+1)

    [ Upstream commit 03a2d2a3eafe4015412cf4e9675ca0e2d9204074 ]

    Commit description is copied from the original post of this bug:

      http://comments.gmane.org/gmane.linux.kernel.mm/135349

    Kernels after v3.9 use kmalloc_size(INDEX_NODE + 1) to get the next
    larger cache size than the size index INDEX_NODE mapping.  In kernels
    3.9 and earlier we used malloc_sizes[INDEX_L3 + 1].cs_size.

    However, sometimes we can't get the right output we expected via
    kmalloc_size(INDEX_NODE + 1), causing a BUG().

    The mapping table in the latest kernel is like:
        index = {0,   1,  2 ,  3,  4,   5,   6,   n}
         size = {0,   96, 192, 8, 16,  32,  64,   2^n}
    The mapping table before 3.10 is like this:
        index = {0 , 1 , 2,   3,  4 ,  5 ,  6,   n}
        size  = {32, 64, 96, 128, 192, 256, 512, 2^(n+3)}

    The problem on my mips64 machine is as follows:

    (1) When configured DEBUG_SLAB && DEBUG_PAGEALLOC && DEBUG_LOCK_ALLOC
        && DEBUG_SPINLOCK, the sizeof(struct kmem_cache_node) will be "150",
        and the macro INDEX_NODE turns out to be "2": #define INDEX_NODE
        kmalloc_index(sizeof(struct kmem_cache_node))

    (2) Then the result of kmalloc_size(INDEX_NODE + 1) is 8.

    (3) Then "if(size >= kmalloc_size(INDEX_NODE + 1)" will lead to "size
        = PAGE_SIZE".

    (4) Then "if ((size >= (PAGE_SIZE >> 3))" test will be satisfied and
        "flags |= CFLGS_OFF_SLAB" will be covered.

    (5) if (flags & CFLGS_OFF_SLAB)" test will be satisfied and will go to
        "cachep->slabp_cache = kmalloc_slab(slab_size, 0u)", and the result
        here may be NULL while kernel bootup.

    (6) Finally,"BUG_ON(ZERO_OR_NULL_PTR(cachep->slabp_cache));" causes the
        BUG info as the following shows (may be only mips64 has this problem):

    This patch fixes the problem of kmalloc_size(INDEX_NODE + 1) and removes
    the BUG by adding 'size >= 256' check to guarantee that all necessary
    small sized slabs are initialized regardless sequence of slab size in
    mapping table.

    Fixes: e33660165c90 ("slab: Use common kmalloc_index/kmalloc_size...")
    Signed-off-by: Joonsoo Kim <iamjoonsoo.kim@lge.com>
    Reported-by: Liuhailong <liu.hailong6@zte.com.cn>
    Acked-by: Christoph Lameter <cl@linux.com>
    Cc: Pekka Enberg <penberg@kernel.org>
    Cc: David Rientjes <rientjes@google.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit e3c2669ff76d4636d41907f08a31129cb2e02eac
Author: Prarit Bhargava <prarit@redhat.com>
Date:   Mon Jun 15 13:43:29 2015 -0400

    intel_pstate: Fix overflow in busy_scaled due to long delay

    [ Upstream commit 7180dddf7c32c49975c7e7babf2b60ed450cb760 ]

    The kernel may delay interrupts for a long time which can result in timers
    being delayed. If this occurs the intel_pstate driver will crash with a
    divide by zero error:

    divide error: 0000 [#1] SMP
    Modules linked in: btrfs zlib_deflate raid6_pq xor msdos ext4 mbcache jbd2 binfmt_misc arc4 md4 nls_utf8 cifs dns_resolver tcp_lp bnep bluetooth rfkill fuse dm_service_time iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi nf_conntrack_netbios_ns nf_conntrack_broadcast nf_conntrack_ftp ip6t_rpfilter ip6t_REJECT ipt_REJECT xt_conntrack ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw ip6table_filter ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw iptable_filter ip_tables intel_powerclamp coretemp vfat fat kvm_intel iTCO_wdt iTCO_vendor_support ipmi_devintf sr_mod kvm crct10dif_pclmul
     crc32_pclmul crc32c_intel ghash_clmulni_intel aesni_intel cdc_ether lrw usbnet cdrom mii gf128mul glue_helper ablk_helper cryptd lpc_ich mfd_core pcspkr sb_edac edac_core ipmi_si ipmi_msghandler ioatdma wmi shpchp acpi_pad nfsd auth_rpcgss nfs_acl lockd uinput dm_multipath sunrpc xfs libcrc32c usb_storage sd_mod crc_t10dif crct10dif_common ixgbe mgag200 syscopyarea sysfillrect sysimgblt mdio drm_kms_helper ttm igb drm ptp pps_core dca i2c_algo_bit megaraid_sas i2c_core dm_mirror dm_region_hash dm_log dm_mod
    CPU: 113 PID: 0 Comm: swapper/113 Tainted: G        W   --------------   3.10.0-229.1.2.el7.x86_64 #1
    Hardware name: IBM x3950 X6 -[3837AC2]-/00FN827, BIOS -[A8E112BUS-1.00]- 08/27/2014
    task: ffff880fe8abe660 ti: ffff880fe8ae4000 task.ti: ffff880fe8ae4000
    RIP: 0010:[<ffffffff814a9279>]  [<ffffffff814a9279>] intel_pstate_timer_func+0x179/0x3d0
    RSP: 0018:ffff883fff4e3db8  EFLAGS: 00010206
    RAX: 0000000027100000 RBX: ffff883fe6965100 RCX: 0000000000000000
    RDX: 0000000000000000 RSI: 0000000000000010 RDI: 000000002e53632d
    RBP: ffff883fff4e3e20 R08: 000e6f69a5a125c0 R09: ffff883fe84ec001
    R10: 0000000000000002 R11: 0000000000000005 R12: 00000000000049f5
    R13: 0000000000271000 R14: 00000000000049f5 R15: 0000000000000246
    FS:  0000000000000000(0000) GS:ffff883fff4e0000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00007f7668601000 CR3: 000000000190a000 CR4: 00000000001407e0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
    Stack:
     ffff883fff4e3e58 ffffffff81099dc1 0000000000000086 0000000000000071
     ffff883fff4f3680 0000000000000071 fbdc8a965e33afee ffffffff810b69dd
     ffff883fe84ec000 ffff883fe6965108 0000000000000100 ffffffff814a9100
    Call Trace:
     <IRQ>

     [<ffffffff81099dc1>] ? run_posix_cpu_timers+0x51/0x840
     [<ffffffff810b69dd>] ? trigger_load_balance+0x5d/0x200
     [<ffffffff814a9100>] ? pid_param_set+0x130/0x130
     [<ffffffff8107df56>] call_timer_fn+0x36/0x110
     [<ffffffff814a9100>] ? pid_param_set+0x130/0x130
     [<ffffffff8107fdcf>] run_timer_softirq+0x21f/0x320
     [<ffffffff81077b2f>] __do_softirq+0xef/0x280
     [<ffffffff816156dc>] call_softirq+0x1c/0x30
     [<ffffffff81015d95>] do_softirq+0x65/0xa0
     [<ffffffff81077ec5>] irq_exit+0x115/0x120
     [<ffffffff81616355>] smp_apic_timer_interrupt+0x45/0x60
     [<ffffffff81614a1d>] apic_timer_interrupt+0x6d/0x80
     <EOI>

     [<ffffffff814a9c32>] ? cpuidle_enter_state+0x52/0xc0
     [<ffffffff814a9c28>] ? cpuidle_enter_state+0x48/0xc0
     [<ffffffff814a9d65>] cpuidle_idle_call+0xc5/0x200
     [<ffffffff8101d14e>] arch_cpu_idle+0xe/0x30
     [<ffffffff810c67c1>] cpu_startup_entry+0xf1/0x290
     [<ffffffff8104228a>] start_secondary+0x1ba/0x230
    Code: 42 0f 00 45 89 e6 48 01 c2 43 8d 44 6d 00 39 d0 73 26 49 c1 e5 08 89 d2 4d 63 f4 49 63 c5 48 c1 e2 08 48 c1 e0 08 48 63 ca 48 99 <48> f7 f9 48 98 4c 0f af f0 49 c1 ee 08 8b 43 78 c1 e0 08 44 29
    RIP  [<ffffffff814a9279>] intel_pstate_timer_func+0x179/0x3d0
     RSP <ffff883fff4e3db8>

    The kernel values for cpudata for CPU 113 were:

    struct cpudata {
      cpu = 113,
      timer = {
        entry = {
          next = 0x0,
          prev = 0xdead000000200200
        },
        expires = 8357799745,
        base = 0xffff883fe84ec001,
        function = 0xffffffff814a9100 <intel_pstate_timer_func>,
        data = 18446612406765768960,
    <snip>
        i_gain = 0,
        d_gain = 0,
        deadband = 0,
        last_err = 22489
      },
      last_sample_time = {
        tv64 = 4063132438017305
      },
      prev_aperf = 287326796397463,
      prev_mperf = 251427432090198,
      sample = {
        core_pct_busy = 23081,
        aperf = 2937407,
        mperf = 3257884,
        freq = 2524484,
        time = {
          tv64 = 4063149215234118
        }
      }
    }

    which results in the time between samples = last_sample_time - sample.time
    = 4063149215234118 - 4063132438017305 = 16777216813 which is 16.777 seconds.

    The duration between reads of the APERF and MPERF registers overflowed a s32
    sized integer in intel_pstate_get_scaled_busy()'s call to div_fp().  The result
    is that int_tofp(duration_us) == 0, and the kernel attempts to divide by 0.

    While the kernel shouldn't be delaying for a long time, it can and does
    happen and the intel_pstate driver should not panic in this situation.  This
    patch changes the div_fp() function to use div64_s64() to allow for "long"
    division.  This will avoid the overflow condition on long delays.

    [v2]: use div64_s64() in div_fp()

    Signed-off-by: Prarit Bhargava <prarit@redhat.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit e892880767a6dacbbc53841bfe4b7c38b90f3a52
Author: Kosuke Tatsukawa <tatsu@ab.jp.nec.com>
Date:   Fri Oct 2 08:27:05 2015 +0000

    tty: fix stall caused by missing memory barrier in drivers/tty/n_tty.c

    [ Upstream commit e81107d4c6bd098878af9796b24edc8d4a9524fd ]

    My colleague ran into a program stall on a x86_64 server, where
    n_tty_read() was waiting for data even if there was data in the buffer
    in the pty.  kernel stack for the stuck process looks like below.
     #0 [ffff88303d107b58] __schedule at ffffffff815c4b20
     #1 [ffff88303d107bd0] schedule at ffffffff815c513e
     #2 [ffff88303d107bf0] schedule_timeout at ffffffff815c7818
     #3 [ffff88303d107ca0] wait_woken at ffffffff81096bd2
     #4 [ffff88303d107ce0] n_tty_read at ffffffff8136fa23
     #5 [ffff88303d107dd0] tty_read at ffffffff81368013
     #6 [ffff88303d107e20] __vfs_read at ffffffff811a3704
     #7 [ffff88303d107ec0] vfs_read at ffffffff811a3a57
     #8 [ffff88303d107f00] sys_read at ffffffff811a4306
     #9 [ffff88303d107f50] entry_SYSCALL_64_fastpath at ffffffff815c86d7

    There seems to be two problems causing this issue.

    First, in drivers/tty/n_tty.c, __receive_buf() stores the data and
    updates ldata->commit_head using smp_store_release() and then checks
    the wait queue using waitqueue_active().  However, since there is no
    memory barrier, __receive_buf() could return without calling
    wake_up_interactive_poll(), and at the same time, n_tty_read() could
    start to wait in wait_woken() as in the following chart.

            __receive_buf()                         n_tty_read()
    ------------------------------------------------------------------------
    if (waitqueue_active(&tty->read_wait))
    /* Memory operations issued after the
       RELEASE may be completed before the
       RELEASE operation has completed */
                                            add_wait_queue(&tty->read_wait, &wait);
                                            ...
                                            if (!input_available_p(tty, 0)) {
    smp_store_release(&ldata->commit_head,
                      ldata->read_head);
                                            ...
                                            timeout = wait_woken(&wait,
                                              TASK_INTERRUPTIBLE, timeout);
    ------------------------------------------------------------------------

    The second problem is that n_tty_read() also lacks a memory barrier
    call and could also cause __receive_buf() to return without calling
    wake_up_interactive_poll(), and n_tty_read() to wait in wait_woken()
    as in the chart below.

            __receive_buf()                         n_tty_read()
    ------------------------------------------------------------------------
                                            spin_lock_irqsave(&q->lock, flags);
                                            /* from add_wait_queue() */
                                            ...
                                            if (!input_available_p(tty, 0)) {
                                            /* Memory operations issued after the
                                               RELEASE may be completed before the
                                               RELEASE operation has completed */
    smp_store_release(&ldata->commit_head,
                      ldata->read_head);
    if (waitqueue_active(&tty->read_wait))
                                            __add_wait_queue(q, wait);
                                            spin_unlock_irqrestore(&q->lock,flags);
                                            /* from add_wait_queue() */
                                            ...
                                            timeout = wait_woken(&wait,
                                              TASK_INTERRUPTIBLE, timeout);
    ------------------------------------------------------------------------

    There are also other places in drivers/tty/n_tty.c which have similar
    calls to waitqueue_active(), so instead of adding many memory barrier
    calls, this patch simply removes the call to waitqueue_active(),
    leaving just wake_up*() behind.

    This fixes both problems because, even though the memory access before
    or after the spinlocks in both wake_up*() and add_wait_queue() can
    sneak into the critical section, it cannot go past it and the critical
    section assures that they will be serialized (please see "INTER-CPU
    ACQUIRING BARRIER EFFECTS" in Documentation/memory-barriers.txt for a
    better explanation).  Moreover, the resulting code is much simpler.

    Latency measurement using a ping-pong test over a pty doesn't show any
    visible performance drop.

    Signed-off-by: Kosuke Tatsukawa <tatsu@ab.jp.nec.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit ae7799addbd7e6830e613e252009bb07a43ec52d
Author: covici@ccs.covici.com <covici@ccs.covici.com>
Date:   Wed May 20 05:44:11 2015 -0400

    staging: speakup: fix speakup-r regression

    [ Upstream commit b1d562acc78f0af46de0dfe447410bc40bdb7ece ]

    Here is a patch to make speakup-r work again.

    It broke in 3.6 due to commit 4369c64c79a22b98d3b7eff9d089196cd878a10a
    "Input: Send events one packet at a time)

    The problem was that the fakekey.c routine to fake a down arrow no
    longer functioned properly and putting the input_sync fixed it.

    Fixes: 4369c64c79a22b98d3b7eff9d089196cd878a10a
    Cc: stable <stable@vger.kernel.org>
    Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
    Signed-off-by: John Covici <covici@ccs.covici.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 5db13a87a598b3b8045a11658686feb3f689826a
Author: Joe Thornber <ejt@redhat.com>
Date:   Fri Oct 9 14:03:38 2015 +0100

    dm cache: fix NULL pointer when switching from cleaner policy

    [ Upstream commit 2bffa1503c5c06192eb1459180fac4416575a966 ]

    The cleaner policy doesn't make use of the per cache block hint space in
    the metadata (unlike the other policies).  When switching from the
    cleaner policy to mq or smq a NULL pointer crash (in dm_tm_new_block)
    was observed.  The crash was caused by bugs in dm-cache-metadata.c
    when trying to skip creation of the hint btree.

    The minimal fix is to change hint size for the cleaner policy to 4 bytes
    (only hint size supported).

    Signed-off-by: Joe Thornber <ejt@redhat.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 4af768733ce0fb8f8a6788791471375c0ac3aba7
Author: Ben Dooks <ben.dooks@codethink.co.uk>
Date:   Tue Sep 29 15:01:08 2015 +0100

    clk: ti: fix dual-registration of uart4_ick

    [ Upstream commit 19e79687de22f23bcfb5e79cce3daba20af228d1 ]

    On the OMAP AM3517 platform the uart4_ick gets registered
    twice, causing any power management to /dev/ttyO3 to fail
    when trying to wake the device up.

    This solves the following oops:

    [] Unhandled fault: external abort on non-linefetch (0x1028) at 0xfa09e008
    [] PC is at serial_omap_pm+0x48/0x15c
    [] LR is at _raw_spin_unlock_irqrestore+0x30/0x5c

    Fixes: aafd900cab87 ("CLK: TI: add omap3 clock init file")
    Cc: stable@vger.kernel.org
    Cc: mturquette@baylibre.com
    Cc: sboyd@codeaurora.org
    Cc: linux-clk@vger.kernel.org
    Cc: linux-omap@vger.kernel.org
    Cc: linux-kernel@lists.codethink.co.uk
    Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
    Signed-off-by: Tero Kristo <t-kristo@ti.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 9d8248b629a7f2fb16802b09fb6dfb6bc862e460
Author: Kinglong Mee <kinglongmee@gmail.com>
Date:   Mon Sep 14 20:12:21 2015 +0800

    nfs/filelayout: Fix NULL reference caused by double freeing of fh_array

    [ Upstream commit 3ec0c97959abff33a42db9081c22132bcff5b4f2 ]

    If filelayout_decode_layout fail, _filelayout_free_lseg will causes
    a double freeing of fh_array.

    [ 1179.279800] BUG: unable to handle kernel NULL pointer dereference at           (null)
    [ 1179.280198] IP: [<ffffffffa027222d>] filelayout_free_fh_array.isra.11+0x1d/0x70 [nfs_layout_nfsv41_files]
    [ 1179.281010] PGD 0
    [ 1179.281443] Oops: 0000 [#1]
    [ 1179.281831] Modules linked in: nfs_layout_nfsv41_files(OE) nfsv4(OE) nfs(OE) fscache(E) xfs libcrc32c coretemp nfsd crct10dif_pclmul ppdev crc32_pclmul crc32c_intel auth_rpcgss ghash_clmulni_intel nfs_acl lockd vmw_balloon grace sunrpc parport_pc vmw_vmci parport shpchp i2c_piix4 vmwgfx drm_kms_helper ttm drm serio_raw mptspi scsi_transport_spi mptscsih e1000 mptbase ata_generic pata_acpi [last unloaded: fscache]
    [ 1179.283891] CPU: 0 PID: 13336 Comm: cat Tainted: G           OE   4.3.0-rc1-pnfs+ #244
    [ 1179.284323] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 05/20/2014
    [ 1179.285206] task: ffff8800501d48c0 ti: ffff88003e3c4000 task.ti: ffff88003e3c4000
    [ 1179.285668] RIP: 0010:[<ffffffffa027222d>]  [<ffffffffa027222d>] filelayout_free_fh_array.isra.11+0x1d/0x70 [nfs_layout_nfsv41_files]
    [ 1179.286612] RSP: 0018:ffff88003e3c77f8  EFLAGS: 00010202
    [ 1179.287092] RAX: 0000000000000000 RBX: ffff88001fe78900 RCX: 0000000000000000
    [ 1179.287731] RDX: ffffea0000f40760 RSI: ffff88001fe789c8 RDI: ffff88001fe789c0
    [ 1179.288383] RBP: ffff88003e3c7810 R08: ffffea0000f40760 R09: 0000000000000000
    [ 1179.289170] R10: 0000000000000000 R11: 0000000000000001 R12: ffff88001fe789c8
    [ 1179.289959] R13: ffff88001fe789c0 R14: ffff88004ec05a80 R15: ffff88004f935b88
    [ 1179.290791] FS:  00007f4e66bb5700(0000) GS:ffffffff81c29000(0000) knlGS:0000000000000000
    [ 1179.291580] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [ 1179.292209] CR2: 0000000000000000 CR3: 00000000203f8000 CR4: 00000000001406f0
    [ 1179.292731] Stack:
    [ 1179.293195]  ffff88001fe78900 00000000000000d0 ffff88001fe78178 ffff88003e3c7868
    [ 1179.293676]  ffffffffa0272737 0000000000000001 0000000000000001 ffff88001fe78800
    [ 1179.294151]  00000000614fffce ffffffff81727671 ffff88001fe78100 ffff88001fe78100
    [ 1179.294623] Call Trace:
    [ 1179.295092]  [<ffffffffa0272737>] filelayout_alloc_lseg+0xa7/0x2d0 [nfs_layout_nfsv41_files]
    [ 1179.295625]  [<ffffffff81727671>] ? out_of_line_wait_on_bit+0x81/0xb0
    [ 1179.296133]  [<ffffffffa040407e>] pnfs_layout_process+0xae/0x320 [nfsv4]
    [ 1179.296632]  [<ffffffffa03e0a01>] nfs4_proc_layoutget+0x2b1/0x360 [nfsv4]
    [ 1179.297134]  [<ffffffffa0402983>] pnfs_update_layout+0x853/0xb30 [nfsv4]
    [ 1179.297632]  [<ffffffffa039db24>] ? nfs_get_lock_context+0x74/0x170 [nfs]
    [ 1179.298158]  [<ffffffffa0271807>] filelayout_pg_init_read+0x37/0x50 [nfs_layout_nfsv41_files]
    [ 1179.298834]  [<ffffffffa03a72d9>] __nfs_pageio_add_request+0x119/0x460 [nfs]
    [ 1179.299385]  [<ffffffffa03a6bd7>] ? nfs_create_request.part.9+0x37/0x2e0 [nfs]
    [ 1179.299872]  [<ffffffffa03a7cc3>] nfs_pageio_add_request+0xa3/0x1b0 [nfs]
    [ 1179.300362]  [<ffffffffa03a8635>] readpage_async_filler+0x85/0x260 [nfs]
    [ 1179.300907]  [<ffffffff81180cb1>] read_cache_pages+0x91/0xd0
    [ 1179.301391]  [<ffffffffa03a85b0>] ? nfs_read_completion+0x220/0x220 [nfs]
    [ 1179.301867]  [<ffffffffa03a8dc8>] nfs_readpages+0x128/0x200 [nfs]
    [ 1179.302330]  [<ffffffff81180ef3>] __do_page_cache_readahead+0x203/0x280
    [ 1179.302784]  [<ffffffff81180dc8>] ? __do_page_cache_readahead+0xd8/0x280
    [ 1179.303413]  [<ffffffff81181116>] ondemand_readahead+0x1a6/0x2f0
    [ 1179.303855]  [<ffffffff81181371>] page_cache_sync_readahead+0x31/0x50
    [ 1179.304286]  [<ffffffff811750a6>] generic_file_read_iter+0x4a6/0x5c0
    [ 1179.304711]  [<ffffffffa03a0316>] ? __nfs_revalidate_mapping+0x1f6/0x240 [nfs]
    [ 1179.305132]  [<ffffffffa039ccf2>] nfs_file_read+0x52/0xa0 [nfs]
    [ 1179.305540]  [<ffffffff811e343c>] __vfs_read+0xcc/0x100
    [ 1179.305936]  [<ffffffff811e3d15>] vfs_read+0x85/0x130
    [ 1179.306326]  [<ffffffff811e4a98>] SyS_read+0x58/0xd0
    [ 1179.306708]  [<ffffffff8172caaf>] entry_SYSCALL_64_fastpath+0x12/0x76
    [ 1179.307094] Code: c4 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 48 89 e5 41 55 41 54 53 8b 07 49 89 f4 85 c0 74 47 48 8b 06 49 89 fd <48> 8b 38 48 85 ff 74 22 31 db eb 0c 48 63 d3 48 8b 3c d0 48 85
    [ 1179.308357] RIP  [<ffffffffa027222d>] filelayout_free_fh_array.isra.11+0x1d/0x70 [nfs_layout_nfsv41_files]
    [ 1179.309177]  RSP <ffff88003e3c77f8>
    [ 1179.309582] CR2: 0000000000000000

    Signed-off-by: Kinglong Mee <kinglongmee@gmail.com>
    Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 184f42a146a071392aae4fa2eeefdf87886db1d1
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Sun Jul 12 10:39:45 2015 -0400

    fix a braino in ovl_d_select_inode()

    [ Upstream commit 9391dd00d13c853ab4f2a85435288ae2202e0e43 ]

    when opening a directory we want the overlayfs inode, not one from
    the topmost layer.

    Reported-By: Andrey Jr. Melnikov <temnota.am@gmail.com>
    Tested-By: Andrey Jr. Melnikov <temnota.am@gmail.com>
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 687fad0d4610e4211ede26c6785a738c44e9db29
Author: David Howells <dhowells@redhat.com>
Date:   Thu Jun 18 14:32:31 2015 +0100

    overlayfs: Make f_path always point to the overlay and f_inode to the underlay

    [ Upstream commit 4bacc9c9234c7c8eec44f5ed4e960d9f96fa0f01 ]

    Make file->f_path always point to the overlay dentry so that the path in
    /proc/pid/fd is correct and to ensure that label-based LSMs have access to the
    overlay as well as the underlay (path-based LSMs probably don't need it).

    Using my union testsuite to set things up, before the patch I see:

            [root@andromeda union-testsuite]# bash 5</mnt/a/foo107
            [root@andromeda union-testsuite]# ls -l /proc/$$/fd/
            ...
            lr-x------. 1 root root 64 Jun  5 14:38 5 -> /a/foo107
            [root@andromeda union-testsuite]# stat /mnt/a/foo107
            ...
            Device: 23h/35d Inode: 13381       Links: 1
            ...
            [root@andromeda union-testsuite]# stat -L /proc/$$/fd/5
            ...
            Device: 23h/35d Inode: 13381       Links: 1
            ...

    After the patch:

            [root@andromeda union-testsuite]# bash 5</mnt/a/foo107
            [root@andromeda union-testsuite]# ls -l /proc/$$/fd/
            ...
            lr-x------. 1 root root 64 Jun  5 14:22 5 -> /mnt/a/foo107
            [root@andromeda union-testsuite]# stat /mnt/a/foo107
            ...
            Device: 23h/35d Inode: 40346       Links: 1
            ...
            [root@andromeda union-testsuite]# stat -L /proc/$$/fd/5
            ...
            Device: 23h/35d Inode: 40346       Links: 1
            ...

    Note the change in where /proc/$$/fd/5 points to in the ls command.  It was
    pointing to /a/foo107 (which doesn't exist) and now points to /mnt/a/foo107
    (which is correct).

    The inode accessed, however, is the lower layer.  The union layer is on device
    25h/37d and the upper layer on 24h/36d.

    Signed-off-by: David Howells <dhowells@redhat.com>
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 3ed7df6411ed4038c9962bfef9725e79396e581b
Author: David Howells <dhowells@redhat.com>
Date:   Thu Jan 29 12:02:27 2015 +0000

    VFS: Introduce inode-getting helpers for layered/unioned fs environments

    [ Upstream commit 155e35d4daa804582f75acaa2c74ec797a89c615 ]

    Introduce some function for getting the inode (and also the dentry) in an
    environment where layered/unioned filesystems are in operation.

    The problem is that we have places where we need *both* the union dentry and
    the lower source or workspace inode or dentry available, but we can only have
    a handle on one of them.  Therefore we need to derive the handle to the other
    from that.

    The idea is to introduce an extra field in struct dentry that allows the union
    dentry to refer to and pin the lower dentry.

    Signed-off-by: David Howells <dhowells@redhat.com>
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit c098c356cb19574036c82652d978ba319f1693ea
Author: David Howells <dhowells@redhat.com>
Date:   Thu Jun 18 14:32:23 2015 +0100

    overlay: Call ovl_drop_write() earlier in ovl_dentry_open()

    [ Upstream commit f25801ee4680ef1db21e15c112e6e5fe3ffe8da5 ]

    Call ovl_drop_write() earlier in ovl_dentry_open() before we call vfs_open()
    as we've done the copy up for which we needed the freeze-write lock by that
    point.

    Signed-off-by: David Howells <dhowells@redhat.com>
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 7750e25bbf2b4c9dafe9777e11c2ac8355d777ba
Author: Ben Hutchings <ben@decadent.org.uk>
Date:   Sat Sep 26 12:23:56 2015 +0100

    genirq: Fix race in register_irq_proc()

    [ Upstream commit 95c2b17534654829db428f11bcf4297c059a2a7e ]

    Per-IRQ directories in procfs are created only when a handler is first
    added to the irqdesc, not when the irqdesc is created.  In the case of
    a shared IRQ, multiple tasks can race to create a directory.  This
    race condition seems to have been present forever, but is easier to
    hit with async probing.

    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Link: http://lkml.kernel.org/r/1443266636.2004.2.camel@decadent.org.uk
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: stable@vger.kernel.org
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 1ace5c6e26cdb135f9fc5ca36e020400ca5e4fb8
Author: Stefan Assmann <sassmann@kpanic.de>
Date:   Fri Jul 10 15:01:12 2015 +0200

    igb: do not re-init SR-IOV during probe

    [ Upstream commit 6423fc34160939142d72ffeaa2db6408317f54df ]

    During driver probing the following code path is triggered.
    igb_probe
    ->igb_sw_init
      ->igb_probe_vfs
        ->igb_pci_enable_sriov
          ->igb_sriov_reinit

    Doing the SR-IOV re-init is not necessary during probing since we're
    starting from scratch. Here we can call igb_enable_sriov() right away.

    Running igb_sriov_reinit() during igb_probe() also seems to cause
    occasional packet loss on some onboard 82576 NICs. Reproduced on
    Dell and HP servers with onboard 82576 NICs.
    Example:
    Intel Corporation 82576 Gigabit Network Connection [8086:10c9] (rev 01)
    Subsystem: Dell Device [1028:0481]

    Signed-off-by: Stefan Assmann <sassmann@kpanic.de>
    Tested-by: Aaron Brown <aaron.f.brown@intel.com>
    Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 382aec5dbe7315540ae37a797e344f8f2a316393
Author: Chas Williams <3chas3@gmail.com>
Date:   Thu Aug 27 12:28:46 2015 -0400

    net/xen-netfront: only napi_synchronize() if running

    [ Upstream commit 274b045509175db0405c784be85e8cce116e6f7d ]

    If an interface isn't running napi_synchronize() will hang forever.

    [  392.248403] rmmod           R  running task        0   359    343 0x00000000
    [  392.257671]  ffff88003760fc88 ffff880037193b40 ffff880037193160 ffff88003760fc88
    [  392.267644]  ffff880037610000 ffff88003760fcd8 0000000100014c22 ffffffff81f75c40
    [  392.277524]  0000000000bc7010 ffff88003760fca8 ffffffff81796927 ffffffff81f75c40
    [  392.287323] Call Trace:
    [  392.291599]  [<ffffffff81796927>] schedule+0x37/0x90
    [  392.298553]  [<ffffffff8179985b>] schedule_timeout+0x14b/0x280
    [  392.306421]  [<ffffffff810f91b9>] ? irq_free_descs+0x69/0x80
    [  392.314006]  [<ffffffff811084d0>] ? internal_add_timer+0xb0/0xb0
    [  392.322125]  [<ffffffff81109d07>] msleep+0x37/0x50
    [  392.329037]  [<ffffffffa00ec79a>] xennet_disconnect_backend.isra.24+0xda/0x390 [xen_netfront]
    [  392.339658]  [<ffffffffa00ecadc>] xennet_remove+0x2c/0x80 [xen_netfront]
    [  392.348516]  [<ffffffff81481c69>] xenbus_dev_remove+0x59/0xc0
    [  392.356257]  [<ffffffff814e7217>] __device_release_driver+0x87/0x120
    [  392.364645]  [<ffffffff814e7cf8>] driver_detach+0xb8/0xc0
    [  392.371989]  [<ffffffff814e6e69>] bus_remove_driver+0x59/0xe0
    [  392.379883]  [<ffffffff814e84f0>] driver_unregister+0x30/0x70
    [  392.387495]  [<ffffffff814814b2>] xenbus_unregister_driver+0x12/0x20
    [  392.395908]  [<ffffffffa00ed89b>] netif_exit+0x10/0x775 [xen_netfront]
    [  392.404877]  [<ffffffff81124e08>] SyS_delete_module+0x1d8/0x230
    [  392.412804]  [<ffffffff8179a8ee>] system_call_fastpath+0x12/0x71

    Signed-off-by: Chas Williams <3chas3@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 51302cb3b7c918b7d58c7a9004c48b80646da332
Author: Andreas Schwab <schwab@linux-m68k.org>
Date:   Wed Sep 23 23:12:09 2015 +0200

    m68k: Define asmlinkage_protect

    [ Upstream commit 8474ba74193d302e8340dddd1e16c85cc4b98caf ]

    Make sure the compiler does not modify arguments of syscall functions.
    This can happen if the compiler generates a tailcall to another
    function.  For example, without asmlinkage_protect sys_openat is compiled
    into this function:

    sys_openat:
            clr.l %d0
            move.w 18(%sp),%d0
            move.l %d0,16(%sp)
            jbra do_sys_open

    Note how the fourth argument is modified in place, modifying the register
    %d4 that gets restored from this stack slot when the function returns to
    user-space.  The caller may expect the register to be unmodified across
    system calls.

    Signed-off-by: Andreas Schwab <schwab@linux-m68k.org>
    Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Cc: stable@vger.kernel.org
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 36c8fcc207bfb55731e1f8a454d6ab2fab20f0d1
Author: Li Bin <huawei.libin@huawei.com>
Date:   Wed Sep 30 10:49:55 2015 +0800

    arm64: ftrace: fix function_graph tracer panic

    [ Upstream commit ee556d00cf20012e889344a0adbbf809ab5015a3 ]

    When function graph tracer is enabled, the following operation
    will trigger panic:

    mount -t debugfs nodev /sys/kernel
    echo next_tgid > /sys/kernel/tracing/set_ftrace_filter
    echo function_graph > /sys/kernel/tracing/current_tracer
    ls /proc/

    ------------[ cut here ]------------
    [  198.501417] Unable to handle kernel paging request at virtual address cb88537fdc8ba316
    [  198.506126] pgd = ffffffc008f79000
    [  198.509363] [cb88537fdc8ba316] *pgd=00000000488c6003, *pud=00000000488c6003, *pmd=0000000000000000
    [  198.517726] Internal error: Oops: 94000005 [#1] SMP
    [  198.518798] Modules linked in:
    [  198.520582] CPU: 1 PID: 1388 Comm: ls Tainted: G
    [  198.521800] Hardware name: linux,dummy-virt (DT)
    [  198.522852] task: ffffffc0fa9e8000 ti: ffffffc0f9ab0000 task.ti: ffffffc0f9ab0000
    [  198.524306] PC is at next_tgid+0x30/0x100
    [  198.525205] LR is at return_to_handler+0x0/0x20
    [  198.526090] pc : [<ffffffc0002a1070>] lr : [<ffffffc0000907c0>] pstate: 60000145
    [  198.527392] sp : ffffffc0f9ab3d40
    [  198.528084] x29: ffffffc0f9ab3d40 x28: ffffffc0f9ab0000
    [  198.529406] x27: ffffffc000d6a000 x26: ffffffc000b786e8
    [  198.530659] x25: ffffffc0002a1900 x24: ffffffc0faf16c00
    [  198.531942] x23: ffffffc0f9ab3ea0 x22: 0000000000000002
    [  198.533202] x21: ffffffc000d85050 x20: 0000000000000002
    [  198.534446] x19: 0000000000000002 x18: 0000000000000000
    [  198.535719] x17: 000000000049fa08 x16: ffffffc000242efc
    [  198.537030] x15: 0000007fa472b54c x14: ffffffffff000000
    [  198.538347] x13: ffffffc0fada84a0 x12: 0000000000000001
    [  198.539634] x11: ffffffc0f9ab3d70 x10: ffffffc0f9ab3d70
    [  198.540915] x9 : ffffffc0000907c0 x8 : ffffffc0f9ab3d40
    [  198.542215] x7 : 0000002e330f08f0 x6 : 0000000000000015
    [  198.543508] x5 : 0000000000000f08 x4 : ffffffc0f9835ec0
    [  198.544792] x3 : cb88537fdc8ba316 x2 : cb88537fdc8ba306
    [  198.546108] x1 : 0000000000000002 x0 : ffffffc000d85050
    [  198.547432]
    [  198.547920] Process ls (pid: 1388, stack limit = 0xffffffc0f9ab0020)
    [  198.549170] Stack: (0xffffffc0f9ab3d40 to 0xffffffc0f9ab4000)
    [  198.582568] Call trace:
    [  198.583313] [<ffffffc0002a1070>] next_tgid+0x30/0x100
    [  198.584359] [<ffffffc0000907bc>] ftrace_graph_caller+0x6c/0x70
    [  198.585503] [<ffffffc0000907bc>] ftrace_graph_caller+0x6c/0x70
    [  198.586574] [<ffffffc0000907bc>] ftrace_graph_caller+0x6c/0x70
    [  198.587660] [<ffffffc0000907bc>] ftrace_graph_caller+0x6c/0x70
    [  198.588896] Code: aa0003f5 2a0103f4 b4000102 91004043 (885f7c60)
    [  198.591092] ---[ end trace 6a346f8f20949ac8 ]---

    This is because when using function graph tracer, if the traced
    function return value is in multi regs ([x0-x7]), return_to_handler
    may corrupt them. So in return_to_handler, the parameter regs should
    be protected properly.

    Cc: <stable@vger.kernel.org> # 3.18+
    Signed-off-by: Li Bin <huawei.libin@huawei.com>
    Acked-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit b94ee9f4e5475b89378dce8c923705f204a474dd
Author: Eric W. Biederman <ebiederm@xmission.com>
Date:   Sat Aug 15 13:36:12 2015 -0500

    dcache: Handle escaped paths in prepend_path

    [ Upstream commit cde93be45a8a90d8c264c776fab63487b5038a65 ]

    A rename can result in a dentry that by walking up d_parent
    will never reach it's mnt_root.  For lack of a better term
    I call this an escaped path.

    prepend_path is called by four different functions __d_path,
    d_absolute_path, d_path, and getcwd.

    __d_path only wants to see paths are connected to the root it passes
    in.  So __d_path needs prepend_path to return an error.

    d_absolute_path similarly wants to see paths that are connected to
    some root.  Escaped paths are not connected to any mnt_root so
    d_absolute_path needs prepend_path to return an error greater
    than 1.  So escaped paths will be treated like paths on lazily
    unmounted mounts.

    getcwd needs to prepend "(unreachable)" so getcwd also needs
    prepend_path to return an error.

    d_path is the interesting hold out.  d_path just wants to print
    something, and does not care about the weird cases.  Which raises
    the question what should be printed?

    Given that <escaped_path>/<anything> should result in -ENOENT I
    believe it is desirable for escaped paths to be printed as empty
    paths.  As there are not really any meaninful path components when
    considered from the perspective of a mount tree.

    So tweak prepend_path to return an empty path with an new error
    code of 3 when it encounters an escaped path.

    Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 683846ae9c03e7c1a8c7a0588a222b1b35075b4f
Author: shengyong <shengyong1@huawei.com>
Date:   Mon Sep 28 17:57:19 2015 +0000

    UBI: return ENOSPC if no enough space available

    [ Upstream commit 7c7feb2ebfc9c0552c51f0c050db1d1a004faac5 ]

    UBI: attaching mtd1 to ubi0
    UBI: scanning is finished
    UBI error: init_volumes: not enough PEBs, required 706, available 686
    UBI error: ubi_wl_init: no enough physical eraseblocks (-20, need 1)
    UBI error: ubi_attach_mtd_dev: failed to attach mtd1, error -12 <= NOT ENOMEM
    UBI error: ubi_init: cannot attach mtd1

    If available PEBs are not enough when initializing volumes, return -ENOSPC
    directly. If available PEBs are not enough when initializing WL, return
    -ENOSPC instead of -ENOMEM.

    Cc: stable@vger.kernel.org
    Signed-off-by: Sheng Yong <shengyong1@huawei.com>
    Signed-off-by: Richard Weinberger <richard@nod.at>
    Reviewed-by: David Gstir <david@sigma-star.at>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 65521fa80cfaa5d19dd4f5d1171fe295169709ac
Author: Richard Weinberger <richard@nod.at>
Date:   Tue Sep 22 23:58:07 2015 +0200

    UBI: Validate data_size

    [ Upstream commit 281fda27673f833a01d516658a64d22a32c8e072 ]

    Make sure that data_size is less than LEB size.
    Otherwise a handcrafted UBI image is able to trigger
    an out of bounds memory access in ubi_compare_lebs().

    Cc: stable@vger.kernel.org
    Signed-off-by: Richard Weinberger <richard@nod.at>
    Reviewed-by: David Gstir <david@sigma-star.at>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 751a99634e13731cc0d9f95425de36c902a058f9
Author: Paul Mackerras <paulus@ozlabs.org>
Date:   Thu Sep 10 14:36:21 2015 +1000

    powerpc/MSI: Fix race condition in tearing down MSI interrupts

    [ Upstream commit e297c939b745e420ef0b9dc989cb87bda617b399 ]

    This fixes a race which can result in the same virtual IRQ number
    being assigned to two different MSI interrupts.  The most visible
    consequence of that is usually a warning and stack trace from the
    sysfs code about an attempt to create a duplicate entry in sysfs.

    The race happens when one CPU (say CPU 0) is disposing of an MSI
    while another CPU (say CPU 1) is setting up an MSI.  CPU 0 calls
    (for example) pnv_teardown_msi_irqs(), which calls
    msi_bitmap_free_hwirqs() to indicate that the MSI (i.e. its
    hardware IRQ number) is no longer in use.  Then, before CPU 0 gets
    to calling irq_dispose_mapping() to free up the virtal IRQ number,
    CPU 1 comes in and calls msi_bitmap_alloc_hwirqs() to allocate an
    MSI, and gets the same hardware IRQ number that CPU 0 just freed.
    CPU 1 then calls irq_create_mapping() to get a virtual IRQ number,
    which sees that there is currently a mapping for that hardware IRQ
    number and returns the corresponding virtual IRQ number (which is
    the same virtual IRQ number that CPU 0 was using).  CPU 0 then
    calls irq_dispose_mapping() and frees that virtual IRQ number.
    Now, if another CPU comes along and calls irq_create_mapping(), it
    is likely to get the virtual IRQ number that was just freed,
    resulting in the same virtual IRQ number apparently being used for
    two different hardware interrupts.

    To fix this race, we just move the call to msi_bitmap_free_hwirqs()
    to after the call to irq_dispose_mapping().  Since virq_to_hw()
    doesn't work for the virtual IRQ number after irq_dispose_mapping()
    has been called, we need to call it before irq_dispose_mapping() and
    remember the result for the msi_bitmap_free_hwirqs() call.

    The pattern of calling msi_bitmap_free_hwirqs() before
    irq_dispose_mapping() appears in 5 places under arch/powerpc, and
    appears to have originated in commit 05af7bd2d75e ("[POWERPC] MPIC
    U3/U4 MSI backend") from 2007.

    Fixes: 05af7bd2d75e ("[POWERPC] MPIC U3/U4 MSI backend")
    Cc: stable@vger.kernel.org # v2.6.22+
    Reported-by: Alexey Kardashevskiy <aik@ozlabs.ru>
    Signed-off-by: Paul Mackerras <paulus@samba.org>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit c49426e98f62651d79eca5f0bc0bcbfd5f7eb36d
Author: Kapileshwar Singh <kapileshwar.singh@arm.com>
Date:   Tue Sep 22 14:22:03 2015 +0100

    tools lib traceevent: Fix string handling in heterogeneous arch environments

    [ Upstream commit c2e4b24ff848bb180f9b9cd873a38327cd219ad2 ]

    When a trace recorded on a 32-bit device is processed with a 64-bit
    binary, the higher 32-bits of the address need to ignored.

    The lack of this results in the output of the 64-bit pointer
    value to the trace as the 32-bit address lookup fails in find_printk().

    Before:

      burn-1778  [003]   548.600305: bputs:   0xc0046db2s: 2cec5c058d98c

    After:

      burn-1778  [003]   548.600305: bputs:   0xc0046db2s: RT throttling activated

    The problem occurs in PRINT_FIELD when the field is recognized as a
    pointer to a string (of the type const char *)

    Heterogeneous architectures cases below can arise and should be handled:

    * Traces recorded using 32-bit addresses processed on a 64-bit machine
    * Traces recorded using 64-bit addresses processed on a 32-bit machine

    Reported-by: Juri Lelli <juri.lelli@arm.com>
    Signed-off-by: Kapileshwar Singh <kapileshwar.singh@arm.com>
    Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
    Cc: David Ahern <dsahern@gmail.com>
    Cc: Javi Merino <javi.merino@arm.com>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: stable@vger.kernel.org
    Link: http://lkml.kernel.org/r/1442928123-13824-1-git-send-email-kapileshwar.singh@arm.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 32435867973da5100ee4ecb3aee0db664af61379
Author: Linus Lüssing <linus.luessing@c0d3.blue>
Date:   Tue Jun 30 23:45:26 2015 +0200

    batman-adv: Fix potentially broken skb network header access

    [ Upstream commit 53cf037bf846417fd92dc92ddf97267f69b110f4 ]

    The two commits noted below added calls to ip_hdr() and ipv6_hdr(). They
    need a correctly set skb network header.

    Unfortunately we cannot rely on the device drivers to set it for us.
    Therefore setting it in the beginning of the according ndo_start_xmit
    handler.

    Fixes: 1d8ab8d3c176 ("batman-adv: Modified forwarding behaviour for multicast packets")
    Fixes: ab49886e3da7 ("batman-adv: Add IPv4 link-local/IPv6-ll-all-nodes multicast support")
    Signed-off-by: Linus Lüssing <linus.luessing@c0d3.blue>
    Signed-off-by: Marek Lindner <mareklindner@neomailbox.ch>
    Signed-off-by: Antonio Quartulli <antonio@meshcoding.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit a5516389f7813170c593bc8106bcc20c1a086cb8
Author: Linus Lüssing <linus.luessing@c0d3.blue>
Date:   Tue Jun 16 17:10:24 2015 +0200

    batman-adv: Make TT capability changes atomic

    [ Upstream commit ac4eebd48461ec993e7cb614d5afe7df8c72e6b7 ]

    Bitwise OR/AND assignments in C aren't guaranteed to be atomic. One
    OGM handler might undo the set/clear of a specific bit from another
    handler run in between.

    Fix this by using the atomic set_bit()/clear_bit()/test_bit() functions.

    Fixes: e17931d1a61d ("batman-adv: introduce capability initialization bitfield")
    Signed-off-by: Linus Lüssing <linus.luessing@c0d3.blue>
    Signed-off-by: Marek Lindner <mareklindner@neomailbox.ch>
    Signed-off-by: Antonio Quartulli <antonio@meshcoding.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 9a1f325d7c9f0a56af6b5111f4c8514422f4b02d
Author: Linus Lüssing <linus.luessing@c0d3.blue>
Date:   Tue Jun 16 17:10:23 2015 +0200

    batman-adv: Make NC capability changes atomic

    [ Upstream commit 4635469f5c617282f18c69643af36cd8c0acf707 ]

    Bitwise OR/AND assignments in C aren't guaranteed to be atomic. One
    OGM handler might undo the set/clear of a specific bit from another
    handler run in between.

    Fix this by using the atomic set_bit()/clear_bit()/test_bit() functions.

    Fixes: 3f4841ffb336 ("batman-adv: tvlv - add network coding container")
    Signed-off-by: Linus Lüssing <linus.luessing@c0d3.blue>
    Signed-off-by: Marek Lindner <mareklindner@neomailbox.ch>
    Signed-off-by: Antonio Quartulli <antonio@meshcoding.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 993b87dfa9ba01cdfc7026bbb8d6365f892dcb33
Author: James Hogan <james.hogan@imgtec.com>
Date:   Fri Mar 27 08:33:43 2015 +0000

    MIPS: dma-default: Fix 32-bit fall back to GFP_DMA

    [ Upstream commit 53960059d56ecef67d4ddd546731623641a3d2d1 ]

    If there is a DMA zone (usually 24bit = 16MB I believe), but no DMA32
    zone, as is the case for some 32-bit kernels, then massage_gfp_flags()
    will cause DMA memory allocated for devices with a 32..63-bit
    coherent_dma_mask to fall back to using __GFP_DMA, even though there may
    only be 32-bits of physical address available anyway.

    Correct that case to compare against a mask the size of phys_addr_t
    instead of always using a 64-bit mask.

    Signed-off-by: James Hogan <james.hogan@imgtec.com>
    Fixes: a2e715a86c6d ("MIPS: DMA: Fix computation of DMA flags from device's coherent_dma_mask.")
    Cc: Ralf Baechle <ralf@linux-mips.org>
    Cc: linux-mips@linux-mips.org
    Cc: <stable@vger.kernel.org> # 2.6.36+
    Patchwork: https://patchwork.linux-mips.org/patch/9610/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 178adb782b60a76981bf041736c27c06bedb20f2
Author: Viresh Kumar <viresh.kumar@linaro.org>
Date:   Wed Sep 2 14:36:50 2015 +0530

    cpufreq: dt: Tolerance applies on both sides of target voltage

    [ Upstream commit a2022001cebd0825b96aa0f3345ea3ad44ae79d4 ]

    Tolerance applies on both sides of the target voltage, i.e. both min and
    max sides. But while checking if a voltage is supported by the regulator
    or not, we haven't taken care of tolerance on the lower side. Fix that.

    Cc: Lucas Stach <l.stach@pengutronix.de>
    Fixes: 045ee45c4ff2 ("cpufreq: cpufreq-dt: disable unsupported OPPs")
    Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
    Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 317a43bb95155b991644de5c8f152a3c2586fecb
Author: Yao-Wen Mao <yaowen@google.com>
Date:   Mon Aug 31 14:24:09 2015 +0800

    USB: Add reset-resume quirk for two Plantronics usb headphones.

    [ Upstream commit 8484bf2981b3d006426ac052a3642c9ce1d8d980 ]

    These two headphones need a reset-resume quirk to properly resume to
    original volume level.

    Signed-off-by: Yao-Wen Mao <yaowen@google.com>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit d9345b0c2b7b828b8208f2a2a064cdc76293e1dc
Author: Vincent Palatin <vpalatin@chromium.org>
Date:   Thu Oct 1 14:10:22 2015 -0700

    usb: Add device quirk for Logitech PTZ cameras

    [ Upstream commit 72194739f54607bbf8cfded159627a2015381557 ]

    Add a device quirk for the Logitech PTZ Pro Camera and its sibling the
    ConferenceCam CC3000e Camera.
    This fixes the failed camera enumeration on some boot, particularly on
    machines with fast CPU.

    Tested by connecting a Logitech PTZ Pro Camera to a machine with a
    Haswell Core i7-4600U CPU @ 2.10GHz, and doing thousands of reboot cycles
    while recording the kernel logs and taking camera picture after each boot.
    Before the patch, more than 7% of the boots show some enumeration transfer
    failures and in a few of them, the kernel is giving up before actually
    enumerating the webcam. After the patch, the enumeration has been correct
    on every reboot.

    Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 9ea9f8ee0be93e9b90a64616391a32e461660d3a
Author: Felipe Balbi <balbi@ti.com>
Date:   Thu Aug 6 10:51:29 2015 -0500

    usb: musb: cppi41: allow it to work again

    [ Upstream commit b0a688ddcc5015eb26000c63841db7c46cfb380a ]

    since commit 33c300cb90a6 ("usb: musb: dsps:
    don't fake of_node to musb core") we have been
    preventing CPPI 4.1 from probing due to NULL
    of_node. We can't revert said commit otherwise
    a different regression would show up, so the fix
    is to look for the parent device's (glue layer's)
    of_node instead, since that's the thing which
    is actually described in DTS.

    Signed-off-by: Felipe Balbi <balbi@ti.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 2180f6799fe3594149ec4d7e185cc694f37ca055
Author: Mathias Nyman <mathias.nyman@linux.intel.com>
Date:   Mon Sep 21 17:46:09 2015 +0300

    usb: Use the USB_SS_MULT() macro to get the burst multiplier.

    [ Upstream commit ff30cbc8da425754e8ab96904db1d295bd034f27 ]

    Bits 1:0 of the bmAttributes are used for the burst multiplier.
    The rest of the bits used to be reserved (zero), but USB3.1 takes bit 7
    into use.

    Use the existing USB_SS_MULT() macro instead to make sure the mult value
    and hence max packet calculations are correct for USB3.1 devices.

    Note that burst multiplier in bmAttributes is zero based and that
    the USB_SS_MULT() macro adds one.

    Cc: <stable@vger.kernel.org>
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 110fda8090a2f3131c8e2035b4ca3ffef0dc9cdd
Author: Peter Chen <peter.chen@freescale.com>
Date:   Mon Aug 24 14:10:07 2015 +0800

    usb: chipidea: udc: using the correct stall implementation

    [ Upstream commit 56ffa1d154c7e12af16273f0cdc42690dd05caf5 ]

    According to spec, there are functional and protocol stalls.

    For functional stall, it is for bulk and interrupt endpoints,
    below are cases for it:
    - Host sends SET_FEATURE request for Set-Halt, the udc driver
    needs to set stall, and return true unconditionally.
    - The gadget driver may call usb_ep_set_halt to stall certain
    endpoints, if there is a transfer in pending, the udc driver
    should not set stall, and return -EAGAIN accordingly.
    These two kinds of stall need to be cleared by host using CLEAR_FEATURE
    request (Clear-Halt).

    For protocol stall, it is for control endpoint, this stall will
    be set if the control request has failed. This stall will be
    cleared by next setup request (hardware will do it).

    It fixed usbtest (drivers/usb/misc/usbtest.c) Test 13 "set/clear halt"
    test failure, meanwhile, this change has been verified by
    USB2 CV Compliance Test and MSC Tests.

    Cc: <stable@vger.kernel.org> #3.10+
    Cc: Alan Stern <stern@rowland.harvard.edu>
    Cc: Felipe Balbi <balbi@ti.com>
    Signed-off-by: Peter Chen <peter.chen@freescale.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 37371a15850eafb5f7dc831a6cf76e80a727d16f
Author: Jann Horn <jann@thejh.net>
Date:   Fri Sep 18 23:41:23 2015 +0200

    security: fix typo in security_task_prctl

    [ Upstream commit b7f76ea2ef6739ee484a165ffbac98deb855d3d3 ]

    Signed-off-by: Jann Horn <jann@thejh.net>
    Reviewed-by: Andy Lutomirski <luto@kernel.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit afeda4748db04805d0fe7905fc93518118e65251
Author: Mark Brown <broonie@kernel.org>
Date:   Sat Sep 19 07:12:34 2015 -0700

    regmap: debugfs: Don't bother actually printing when calculating max length

    [ Upstream commit 176fc2d5770a0990eebff903ba680d2edd32e718 ]

    The in kernel snprintf() will conveniently return the actual length of
    the printed string even if not given an output beffer at all so just do
    that rather than relying on the user to pass in a suitable buffer,
    ensuring that we don't need to worry if the buffer was truncated due to
    the size of the buffer passed in.

    Reported-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Cc: stable@vger.kernel.org
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit c53a219f7f9b7462fdf4a8fd2d20fadad811e97f
Author: Mark Brown <broonie@kernel.org>
Date:   Sat Sep 19 07:00:18 2015 -0700

    regmap: debugfs: Ensure we don't underflow when printing access masks

    [ Upstream commit b763ec17ac762470eec5be8ebcc43e4f8b2c2b82 ]

    If a read is attempted which is smaller than the line length then we may
    underflow the subtraction we're doing with the unsigned size_t type so
    move some of the calculation to be additions on the right hand side
    instead in order to avoid this.

    Reported-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Cc: stable@vger.kernel.org
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit df1dc5e8cb68325743fda1c745b2f9cb6901cf9e
Author: Heiko Stuebner <heiko@sntech.de>
Date:   Tue Aug 4 21:36:12 2015 +0200

    PM / AVS: rockchip-io: depend on CONFIG_POWER_AVS

    [ Upstream commit 28c1f1628ee4b163e615eefe1b6463e3d229a873 ]

    The rockchip io-domain driver currently only depends on ARCH_ROCKCHIP
    itself. This makes it possible to select the power-domain driver, but
    not the POWER_AVS class and results in the iodomain-driver not getting
    build in this case.

    So add the additional dependency, which also results in the driver
    config option now being placed nicely into the AVS submenu.

    Fixes: 662a958638bd ("PM / AVS: rockchip-io: add driver handling Rockchip io domains")
    Signed-off-by: Heiko Stuebner <heiko@sntech.de>
    Acked-by: Kevin Hilman <khilman@linaro.org>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 101755ff61aa274657aba98670282b185144dcd9
Author: Antoine Ténart <antoine.tenart@free-electrons.com>
Date:   Tue Aug 18 10:59:10 2015 +0200

    mtd: pxa3xx_nand: add a default chunk size

    [ Upstream commit bc3e00f04cc1fe033a289c2fc2e5c73c0168d360 ]

    When keeping the configuration set by the bootloader (by using
    the marvell,nand-keep-config property), the pxa3xx_nand_detect_config()
    function is called and set the chunk size to 512 as a default value if
    NDCR_PAGE_SZ is not set.

    In the other case, when not keeping the bootloader configuration, no
    chunk size is set. Fix this by adding a default chunk size of 512.

    Fixes: 70ed85232a93 ("mtd: nand: pxa3xx: Introduce multiple page I/O
    support")

    Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
    Acked-by: Robert Jarzmik <robert.jarzmik@free>
    Signed-off-by: Brian Norris <computersforpeace@gmail.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 7a41fbe7baec500e8a94fe76a09fb9d3370c07ec
Author: Mario Carrillo <mario.alfredo.c.arevalo@intel.com>
Date:   Mon Aug 24 09:33:09 2015 -0500

    docs: update HOWTO for 3.x -> 4.x versioning

    [ Upstream commit e4144fe5d47c91c92d36cdbd5f31ed8d6e3a57ab ]

    The HOWTO document needed updating for the new kernel versioning.

    Signed-off-by: Mario Carrillo <mario.alfredo.c.arevalo@intel.com>
    Signed-off-by: Jonathan Corbet <corbet@lwn.net>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit ec30985f6dfadd1b5e3d9a833fd872b01ab28058
Author: Peter Seiderer <ps.report@gmx.net>
Date:   Thu Sep 17 21:40:12 2015 +0200

    cifs: use server timestamp for ntlmv2 authentication

    [ Upstream commit 98ce94c8df762d413b3ecb849e2b966b21606d04 ]

    Linux cifs mount with ntlmssp against an Mac OS X (Yosemite
    10.10.5) share fails in case the clocks differ more than +/-2h:

    digest-service: digest-request: od failed with 2 proto=ntlmv2
    digest-service: digest-request: kdc failed with -1561745592 proto=ntlmv2

    Fix this by (re-)using the given server timestamp for the
    ntlmv2 authentication (as Windows 7 does).

    A related problem was also reported earlier by Namjae Jaen (see below):

    Windows machine has extended security feature which refuse to allow
    authentication when there is time difference between server time and
    client time when ntlmv2 negotiation is used. This problem is prevalent
    in embedded enviornment where system time is set to default 1970.

    Modern servers send the server timestamp in the TargetInfo Av_Pair
    structure in the challenge message [see MS-NLMP 2.2.2.1]
    In [MS-NLMP 3.1.5.1.2] it is explicitly mentioned that the client must
    use the server provided timestamp if present OR current time if it is
    not

    Reported-by: Namjae Jeon <namjae.jeon@samsung.com>
    Signed-off-by: Peter Seiderer <ps.report@gmx.net>
    Signed-off-by: Steve French <smfrench@gmail.com>
    CC: Stable <stable@vger.kernel.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 56b4f4e1e72aaaebab94c0fdddb132a5f4cbfab6
Author: Dong Aisheng <aisheng.dong@freescale.com>
Date:   Wed Jul 22 20:53:03 2015 +0800

    dts: imx25: fix sd card gpio polarity specified in device tree

    [ Upstream commit cf75eb15be2bdd054a76aeef6458beaa4a6ab770 ]

    cd-gpios polarity should be changed to GPIO_ACTIVE_LOW and wp-gpios
    should be changed to GPIO_ACTIVE_HIGH.
    Otherwise, the SD may not work properly due to wrong polarity inversion
    specified in DT after switch to common parsing function mmc_of_parse().

    Signed-off-by: Dong Aisheng <aisheng.dong@freescale.com>
    Acked-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 776aefbd399915fd4ddd6c9de4a12f989a62699e
Author: Dong Aisheng <aisheng.dong@freescale.com>
Date:   Wed Jul 22 20:53:01 2015 +0800

    dts: imx53: fix sd card gpio polarity specified in device tree

    [ Upstream commit 94d76946859b4bcfa0da373357f14feda2af0622 ]

    cd-gpios polarity should be changed to GPIO_ACTIVE_LOW and wp-gpios
    should be changed to GPIO_ACTIVE_HIGH.
    Otherwise, the SD may not work properly due to wrong polarity inversion
    specified in DT after switch to common parsing function mmc_of_parse().

    Signed-off-by: Dong Aisheng <aisheng.dong@freescale.com>
    Acked-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit ea16b55dc40e466bd18f3f42a97625614f5d2c95
Author: Dong Aisheng <aisheng.dong@freescale.com>
Date:   Wed Jul 22 20:53:00 2015 +0800

    dts: imx51: fix sd card gpio polarity specified in device tree

    [ Upstream commit aca45c0e95dad1c4ba4d38da192756b0e10cbbbd ]

    cd-gpios polarity should be changed to GPIO_ACTIVE_LOW and wp-gpios
    should be changed to GPIO_ACTIVE_HIGH.
    Otherwise, the SD may not work properly due to wrong polarity inversion
    specified in DT after switch to common parsing function mmc_of_parse().

    Signed-off-by: Dong Aisheng <aisheng.dong@freescale.com>
    Acked-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit f4896bf8e3783a0358de738739881b6142c12ea2
Author: Linus Lüssing <linus.luessing@c0d3.blue>
Date:   Tue Jun 16 17:10:22 2015 +0200

    batman-adv: Make DAT capability changes atomic

    [ Upstream commit 65d7d46050704bcdb8121ddbf4110bfbf2b38baa ]

    Bitwise OR/AND assignments in C aren't guaranteed to be atomic. One
    OGM handler might undo the set/clear of a specific bit from another
    handler run in between.

    Fix this by using the atomic set_bit()/clear_bit()/test_bit() functions.

    Fixes: 17cf0ea455f1 ("batman-adv: tvlv - add distributed arp table container")
    Signed-off-by: Linus Lüssing <linus.luessing@c0d3.blue>
    Signed-off-by: Marek Lindner <mareklindner@neomailbox.ch>
    Signed-off-by: Antonio Quartulli <antonio@meshcoding.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit cd7d25e2e12f9e3aef73417f0937276ca5b5c451
Author: Marek Lindner <mareklindner@neomailbox.ch>
Date:   Wed Jun 17 20:01:36 2015 +0800

    batman-adv: protect tt_local_entry from concurrent delete events

    [ Upstream commit ef72706a0543d0c3a5ab29bd6378fdfb368118d9 ]

    The tt_local_entry deletion performed in batadv_tt_local_remove() was neither
    protecting against simultaneous deletes nor checking whether the element was
    still part of the list before calling hlist_del_rcu().

    Replacing the hlist_del_rcu() call with batadv_hash_remove() provides adequate
    protection via hash spinlocks as well as an is-element-still-in-hash check to
    avoid 'blind' hash removal.

    Fixes: 068ee6e204e1 ("batman-adv: roaming handling mechanism redesign")
    Reported-by: alfonsname@web.de
    Signed-off-by: Marek Lindner <mareklindner@neomailbox.ch>
    Signed-off-by: Antonio Quartulli <antonio@meshcoding.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit ab8311e07dad19e7c45822e1b8493a79205658d7
Author: Linus Walleij <linus.walleij@linaro.org>
Date:   Tue Jul 28 15:31:12 2015 +0200

    fbdev: select versatile helpers for the integrator

    [ Upstream commit 2701fa0864ecb9e49d47a4aa1c02f172ab79639a ]

    Commit 11c32d7b6274cb0f554943d65bd4a126c4a86dcd
    "video: move Versatile CLCD helpers" missed the fact
    that the Integrator/CP is also using the helper, and
    as a result the platform got only stubs and no graphics.
    Add this as a default selection to Kconfig so we have
    graphics again.

    Fixes: 11c32d7b6274 (video: move Versatile CLCD helpers)
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit a7fadae31bf58178f39838ad00d6f467eeb13da0
Author: Julian Anastasov <ja@ssi.bg>
Date:   Wed Jul 8 08:31:33 2015 +0300

    ipvs: fix crash with sync protocol v0 and FTP

    [ Upstream commit 56184858d1fc95c46723436b455cb7261cd8be6f ]

    Fix crash in 3.5+ if FTP is used after switching
    sync_version to 0.

    Fixes: 749c42b620a9 ("ipvs: reduce sync rate with time thresholds")
    Signed-off-by: Julian Anastasov <ja@ssi.bg>
    Signed-off-by: Simon Horman <horms@verge.net.au>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 8e891d1e7d0f1e0f1ef129ed47f405af4f38c3a4
Author: Alex Gartrell <agartrell@fb.com>
Date:   Sun Jul 5 14:28:26 2015 -0700

    ipvs: skb_orphan in case of forwarding

    [ Upstream commit 71563f3414e917c62acd8e0fb0edf8ed6af63e4b ]

    It is possible that we bind against a local socket in early_demux when we
    are actually going to want to forward it.  In this case, the socket serves
    no purpose and only serves to confuse things (particularly functions which
    implicitly expect sk_fullsock to be true, like ip_local_out).
    Additionally, skb_set_owner_w is totally broken for non full-socks.

    Signed-off-by: Alex Gartrell <agartrell@fb.com>
    Fixes: 41063e9dd119 ("ipv4: Early TCP socket demux.")
    Acked-by: Julian Anastasov <ja@ssi.bg>
    Signed-off-by: Simon Horman <horms@verge.net.au>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 0932d43cda2bde73fa8f7c12e2e0834ecdef5e9c
Author: Julian Anastasov <ja@ssi.bg>
Date:   Mon Jun 29 21:51:40 2015 +0300

    ipvs: fix crash if scheduler is changed

    [ Upstream commit 05f00505a89acd21f5d0d20f5797dfbc4cf85243 ]

    I overlooked the svc->sched_data usage from schedulers
    when the services were converted to RCU in 3.10. Now
    the rare ipvsadm -E command can change the scheduler
    but due to the reverse order of ip_vs_bind_scheduler
    and ip_vs_unbind_scheduler we provide new sched_data
    to the old scheduler resulting in a crash.

    To fix it without changing the scheduler methods we
    have to use synchronize_rcu() only for the editing case.
    It means all svc->scheduler readers should expect a
    NULL value. To avoid breakage for the service listing
    and ipvsadm -R we can use the "none" name to indicate
    that scheduler is not assigned, a state when we drop
    new connections.

    Reported-by: Alexander Vasiliev <a.vasylev@404-group.com>
    Fixes: ceec4c381681 ("ipvs: convert services to rcu")
    Signed-off-by: Julian Anastasov <ja@ssi.bg>
    Signed-off-by: Simon Horman <horms@verge.net.au>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit fd33c09af14f6786fed65c8319743a8d709e5996
Author: Julian Anastasov <ja@ssi.bg>
Date:   Sat Jun 27 14:39:30 2015 +0300

    ipvs: do not use random local source address for tunnels

    [ Upstream commit 4754957f04f5f368792a0eb7dab0ae89fb93dcfd ]

    Michael Vallaly reports about wrong source address used
    in rare cases for tunneled traffic. Looks like
    __ip_vs_get_out_rt in 3.10+ is providing uninitialized
    dest_dst->dst_saddr.ip because ip_vs_dest_dst_alloc uses
    kmalloc. While we retry after seeing EINVAL from routing
    for data that does not look like valid local address, it
    still succeeded when this memory was previously used from
    other dests and with different local addresses. As result,
    we can use valid local address that is not suitable for
    our real server.

    Fix it by providing 0.0.0.0 every time our cache is refreshed.
    By this way we will get preferred source address from routing.

    Reported-by: Michael Vallaly <lvs@nolatency.com>
    Fixes: 026ace060dfe ("ipvs: optimize dst usage for real server")
    Signed-off-by: Julian Anastasov <ja@ssi.bg>
    Signed-off-by: Simon Horman <horms@verge.net.au>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit a7596ac980aae5ddbba5ac8954e4651551c35b61
Author: Ben Segall <bsegall@google.com>
Date:   Mon Apr 6 15:28:10 2015 -0700

    sched/fair: Prevent throttling in early pick_next_task_fair()

    [ Upstream commit 54d27365cae88fbcc853b391dcd561e71acb81fa ]

    The optimized task selection logic optimistically selects a new task
    to run without first doing a full put_prev_task(). This is so that we
    can avoid a put/set on the common ancestors of the old and new task.

    Similarly, we should only call check_cfs_rq_runtime() to throttle
    eligible groups if they're part of the common ancestry, otherwise it
    is possible to end up with no eligible task in the simple task
    selection.

    Imagine:
                    /root
            /prev           /next
            /A              /B

    If our optimistic selection ends up throttling /next, we goto simple
    and our put_prev_task() ends up throttling /prev, after which we're
    going to bug out in set_next_entity() because there aren't any tasks
    left.

    Avoid this scenario by only throttling common ancestors.

    Reported-by: Mohammed Naser <mnaser@vexxhost.com>
    Reported-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
    Signed-off-by: Ben Segall <bsegall@google.com>
    [ munged Changelog ]
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: H. Peter Anvin <hpa@zytor.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Roman Gushchin <klamm@yandex-team.ru>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: pjt@google.com
    Fixes: 678d5718d8d0 ("sched/fair: Optimize cgroup pick_next_task_fair()")
    Link: http://lkml.kernel.org/r/xm26wq1oswoq.fsf@sword-of-the-dawn.mtv.corp.google.com
    Signed-off-by: Ingo Molnar <mingo@kernel.org>

    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 5240c25c81adef4633d173424ee133637e8ed8b4
Author: Reyad Attiyat <reyad.attiyat@gmail.com>
Date:   Thu Aug 6 19:23:58 2015 +0300

    usb: xhci: Add support for URB_ZERO_PACKET to bulk/sg transfers

    [ Upstream commit 4758dcd19a7d9ba9610b38fecb93f65f56f86346 ]

    This commit checks for the URB_ZERO_PACKET flag and creates an extra
    zero-length td if the urb transfer length is a multiple of the endpoint's
    max packet length.

    Signed-off-by: Reyad Attiyat <reyad.attiyat@gmail.com>
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 923a0e8f49af962a51734a19943b89bb1c2fc709
Author: Mathias Nyman <mathias.nyman@linux.intel.com>
Date:   Mon Sep 21 17:46:17 2015 +0300

    xhci: init command timeout timer earlier to avoid deleting it uninitialized

    [ Upstream commit cc8e4fc0c3b5e8340bc8358990515d116a3c274c ]

    Don't check if timer is running with a timer_pending() before
    deleting it with del_timer_sync(), this defies the whole point of
    the sync part and can cause a possible race.

    Instead we just want to make sure the timer is initialized early enough
    before we have a chance to delete it.

    Cc: <stable@vger.kernel.org>
    Reported-by: Oliver Neukum <oneukum@suse.com>
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit a15f9f60fb8ed89793e72d08a5537a4ca99d8982
Author: Mathias Nyman <mathias.nyman@linux.intel.com>
Date:   Mon Sep 21 17:46:16 2015 +0300

    xhci: change xhci 1.0 only restrictions to support xhci 1.1

    [ Upstream commit dca7794539eff04b786fb6907186989e5eaaa9c2 ]

    Some changes between xhci 0.96 and xhci 1.0 specifications forced us to
    check the hci version in code, some of these checks were implemented as
    hci_version == 1.0, which will not work with new xhci 1.1 controllers.

    xhci 1.1 behaves similar to xhci 1.0 in these cases, so change these
    checks to hci_version >= 1.0

    Cc: <stable@vger.kernel.org>
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 4b025c015cf467efd35ccad202784d3ff75874e2
Author: Roger Quadros <rogerq@ti.com>
Date:   Mon Sep 21 17:46:15 2015 +0300

    usb: xhci: exit early in xhci_setup_device() if we're halted or dying

    [ Upstream commit 448116bfa856d3c076fa7178ed96661a008a5d45 ]

    During quick plug/removal of OTG adapter during dual-role testing
    it can happen that xhci_alloc_device() is called for the newly
    detected device after the DRD library has called xhci_stop to
    remove the HCD.

    If that is the case, just fail early to prevent the following warning.

    [  154.732649] hub 4-0:1.0: USB hub found
    [  154.742204] hub 4-0:1.0: 1 port detected
    [  154.824458] hub 3-0:1.0: state 7 ports 1 chg 0002 evt 0000
    [  154.854609] hub 4-0:1.0: state 7 ports 1 chg 0000 evt 0000
    [  154.944430] usb 3-1: new high-speed USB device number 2 using xhci-hcd
    [  154.951009] xhci-hcd xhci-hcd.0.auto: xhci_setup_device
    [  155.038191] xhci-hcd xhci-hcd.0.auto: remove, state 4
    [  155.043315] usb usb4: USB disconnect, device number 1
    [  155.055270] xhci-hcd xhci-hcd.0.auto: xhci_stop
    [  155.060094] xhci-hcd xhci-hcd.0.auto: USB bus 4 deregistered
    [  155.066576] xhci-hcd xhci-hcd.0.auto: remove, state 1
    [  155.071710] usb usb3: USB disconnect, device number 1
    [  155.077124] xhci-hcd xhci-hcd.0.auto: xhci_setup_device
    [  155.082389] ------------[ cut here ]------------
    [  155.087690] WARNING: CPU: 0 PID: 72 at drivers/usb/host/xhci.c:3800 xhci_setup_device+0x410/0x484 [xhci_hcd]()
    [  155.097861] Modules linked in: sd_mod usb_storage scsi_mod usb_f_ss_lb g_zero libcomposite ipv6 xhci_plat_hcd xhci_hcd usbcore dwc3 udc_core evdev ti_am335x_adc joydev kfifo_buf industrialio snd_soc_simple_cc
    [  155.146734] CPU: 0 PID: 72 Comm: kworker/0:3 Tainted: G        W       4.1.4-00834-gcd9380b-dirty #50
    [  155.156073] Hardware name: Generic AM43 (Flattened Device Tree)
    [  155.162117] Workqueue: usb_hub_wq hub_event [usbcore]
    [  155.167249] Backtrace:
    [  155.169751] [<c0012af0>] (dump_backtrace) from [<c0012c8c>] (show_stack+0x18/0x1c)
    [  155.177390]  r6:c089d4a4 r5:ffffffff r4:00000000 r3:ee46c000
    [  155.183137] [<c0012c74>] (show_stack) from [<c05f7c14>] (dump_stack+0x84/0xd0)
    [  155.190446] [<c05f7b90>] (dump_stack) from [<c00439ac>] (warn_slowpath_common+0x80/0xbc)
    [  155.198605]  r7:00000009 r6:00000ed8 r5:bf27eb70 r4:00000000
    [  155.204348] [<c004392c>] (warn_slowpath_common) from [<c0043a0c>] (warn_slowpath_null+0x24/0x2c)
    [  155.213202]  r8:ee49f000 r7:ee7c0004 r6:00000000 r5:ee7c0158 r4:ee7c0000
    [  155.220051] [<c00439e8>] (warn_slowpath_null) from [<bf27eb70>] (xhci_setup_device+0x410/0x484 [xhci_hcd])
    [  155.229816] [<bf27e760>] (xhci_setup_device [xhci_hcd]) from [<bf27ec10>] (xhci_address_device+0x14/0x18 [xhci_hcd])
    [  155.240415]  r10:ee598200 r9:00000001 r8:00000002 r7:00000001 r6:00000003 r5:00000002
    [  155.248363]  r4:ee49f000
    [  155.250978] [<bf27ebfc>] (xhci_address_device [xhci_hcd]) from [<bf20cb94>] (hub_port_init+0x1b8/0xa9c [usbcore])
    [  155.261403] [<bf20c9dc>] (hub_port_init [usbcore]) from [<bf2101e0>] (hub_event+0x738/0x1020 [usbcore])
    [  155.270874]  r10:ee598200 r9:ee7c0000 r8:ee7c0038 r7:ee518800 r6:ee49f000 r5:00000001
    [  155.278822]  r4:00000000
    [  155.281426] [<bf20faa8>] (hub_event [usbcore]) from [<c005754c>] (process_one_work+0x128/0x340)
    [  155.290196]  r10:00000000 r9:00000003 r8:00000000 r7:fedfa000 r6:eeec5400 r5:ee598314
    [  155.298151]  r4:ee434380
    [  155.300718] [<c0057424>] (process_one_work) from [<c00578f8>] (worker_thread+0x158/0x49c)
    [  155.308963]  r10:ee434380 r9:00000003 r8:eeec5400 r7:00000008 r6:ee434398 r5:eeec5400
    [  155.316913]  r4:eeec5414
    [  155.319482] [<c00577a0>] (worker_thread) from [<c005cc40>] (kthread+0xdc/0xf8)
    [  155.326765]  r10:00000000 r9:00000000 r8:00000000 r7:c00577a0 r6:ee434380 r5:ee4441c0
    [  155.334713]  r4:00000000 r3:00000000
    [  155.338341] [<c005cb64>] (kthread) from [<c000fc08>] (ret_from_fork+0x14/0x2c)
    [  155.345626]  r7:00000000 r6:00000000 r5:c005cb64 r4:ee4441c0
    [  155.356108] ---[ end trace a58d34c223b190e6 ]---
    [  155.360783] xhci-hcd xhci-hcd.0.auto: Virt dev invalid for slot_id 0x1!
    [  155.574404] xhci-hcd xhci-hcd.0.auto: xhci_setup_device
    [  155.579667] ------------[ cut here ]------------

    Cc: <stable@vger.kernel.org>
    Signed-off-by: Roger Quadros <rogerq@ti.com>
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit b78034d9af682dd587aa49884b559f9ff51e8ef7
Author: Roger Quadros <rogerq@ti.com>
Date:   Mon Sep 21 17:46:13 2015 +0300

    usb: xhci: Clear XHCI_STATE_DYING on start

    [ Upstream commit e5bfeab0ad515b4f6df39fe716603e9dc6d3dfd0 ]

    For whatever reason if XHCI died in the previous instant
    then it will never recover on the next xhci_start unless we
    clear the DYING flag.

    Cc: <stable@vger.kernel.org>
    Signed-off-by: Roger Quadros <rogerq@ti.com>
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit ad0473dde67387a9c5b3e25429cb8adac090a0af
Author: Johan Hovold <johan@kernel.org>
Date:   Wed Sep 23 11:41:42 2015 -0700

    USB: whiteheat: fix potential null-deref at probe

    [ Upstream commit cbb4be652d374f64661137756b8f357a1827d6a4 ]

    Fix potential null-pointer dereference at probe by making sure that the
    required endpoints are present.

    The whiteheat driver assumes there are at least five pairs of bulk
    endpoints, of which the final pair is used for the "command port". An
    attempt to bind to an interface with fewer bulk endpoints would
    currently lead to an oops.

    Fixes CVE-2015-5257.

    Reported-by: Moein Ghasemzadeh <moein@istuary.com>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 51bd52fb41d3f8669d2df20b63e1aa4b61cc9f8d
Author: Michel Dänzer <michel.daenzer@amd.com>
Date:   Mon Sep 28 18:16:31 2015 +0900

    drm/amdgpu:  Restore LCD backlight level on resume

    [ Upstream commit 74b3112e95073b351e3b0b9799795bc76f8415fa ]

    Instead of only enabling the backlight (which seems to set it to max
    brightness), just re-set the current backlight level, which also takes
    care of enabling the backlight if necessary.

    Port of radeon commit:
    drm/radeon: Restore LCD backlight level on resume (>= R5xx)

    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 6131d99de4a7a2d2e24f59dea3698006011f791e
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Tue Jun 23 11:34:21 2015 +0200

    drm: Reject DRI1 hw lock ioctl functions for kms drivers

    [ Upstream commit da168d81b44898404d281d5dbe70154ab5f117c1 ]

    I've done some extensive history digging across libdrm, mesa and
    xf86-video-{intel,nouveau,ati}. The only potential user of this with
    kms drivers I could find was ttmtest, which once used drmGetLock
    still. But that mistake was quickly fixed up. Even the intel xvmc
    library (which otherwise was really good with using dri1 stuff in kms
    mode) managed to never take the hw lock for dri2 (and hence kms).

    Hence it should be save to unconditionally disallow this.

    Cc: Peter Antoine <peter.antoine@intel.com>
    Reviewed-by: Peter Antoine <peter.antoine@intel.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 21330a631016d627759be437d992000b5bdbf7d2
Author: Jani Nikula <jani.nikula@intel.com>
Date:   Thu Sep 17 16:42:07 2015 +0300

    drm/i915/bios: handle MIPI Sequence Block v3+ gracefully

    [ Upstream commit cd67d226ebd909d239d2c6e5a6abd6e2a338d1cd ]

    The VBT MIPI Sequence Block version 3 has forward incompatible changes:

    First, the block size in the header has been specified reserved, and the
    actual size is a separate 32-bit value within the block. The current
    find_section() function to will only look at the size in the block
    header, and, depending on what's in that now reserved size field,
    continue looking for other sections in the wrong place.

    Fix this by taking the new block size field into account. This will
    ensure that the lookups for other sections will work properly, as long
    as the new 32-bit size does not go beyond the opregion VBT mailbox size.

    Second, the contents of the block have been completely
    changed. Gracefully refuse parsing the yet unknown data version.

    Cc: Deepak M <m.deepak@intel.com>
    Cc: stable@vger.kernel.org
    Reviewed-by: Deepak M <m.deepak@intel.com>
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 445e1554e787c657acb9c300c0556b71bddac8e7
Author: Fabiano Fidêncio <fidencio@redhat.com>
Date:   Thu Sep 24 15:18:34 2015 +0200

    drm/qxl: recreate the primary surface when the bo is not primary

    [ Upstream commit 8d0d94015e96b8853c4f7f06eac3f269e1b3d866 ]

    When disabling/enabling a crtc the primary area must be updated
    independently of which crtc has been disabled/enabled.

    Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1264735

    Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit dcd79cf88046986d1e4082ee12793124a0035798
Author: Dave Airlie <airlied@redhat.com>
Date:   Mon Sep 14 10:28:34 2015 +1000

    drm/qxl: only report first monitor as connected if we have no state

    [ Upstream commit 69e5d3f893e19613486f300fd6e631810338aa4b ]

    If the server isn't new enough to give us state, report the first
    monitor as always connected, otherwise believe the server side.

    Cc: stable@vger.kernel.org
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit ca5b6dad41ed3ceecc959b9a19b52c9aded89d39
Author: Steve French <smfrench@gmail.com>
Date:   Mon Sep 28 17:21:07 2015 -0500

    [SMB3] Do not fall back to SMBWriteX in set_file_size error cases

    [ Upstream commit 646200a041203f440fb6fcf9cacd9efeda9de74c ]

    The error paths in set_file_size for cifs and smb3 are incorrect.

    In the unlikely event that a server did not support set file info
    of the file size, the code incorrectly falls back to trying SMBWriteX
    (note that only the original core SMB Write, used for example by DOS,
    can set the file size this way - this actually  does not work for the more
    recent SMBWriteX).  The idea was since the old DOS SMB Write could set
    the file size if you write zero bytes at that offset then use that if
    server rejects the normal set file info call.

    Fortunately the SMBWriteX will never be sent on the wire (except when
    file size is zero) since the length and offset fields were reversed
    in the two places in this function that call SMBWriteX causing
    the fall back path to return an error. It is also important to never call
    an SMB request from an SMB2/sMB3 session (which theoretically would
    be possible, and can cause a brief session drop, although the client
    recovers) so this should be fixed.  In practice this path does not happen
    with modern servers but the error fall back to SMBWriteX is clearly wrong.

    Removing the calls to SMBWriteX in the error paths in cifs_set_file_size

    Pointed out by PaX/grsecurity team

    Signed-off-by: Steve French <steve.french@primarydata.com>
    Reported-by: PaX Team <pageexec@freemail.hu>
    CC: Emese Revfy <re.emese@gmail.com>
    CC: Brad Spengler <spender@grsecurity.net>
    CC: Stable <stable@vger.kernel.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 27dc98701f026c09be9d459ae0bd432527be5ce5
Author: Steve French <smfrench@gmail.com>
Date:   Tue Sep 22 09:29:38 2015 -0500

    disabling oplocks/leases via module parm enable_oplocks broken for SMB3

    [ Upstream commit e0ddde9d44e37fbc21ce893553094ecf1a633ab5 ]

    leases (oplocks) were always requested for SMB2/SMB3 even when oplocks
    disabled in the cifs.ko module.

    Signed-off-by: Steve French <steve.french@primarydata.com>
    Reviewed-by: Chandrika Srinivasan <chandrika.srinivasan@citrix.com>
    CC: Stable <stable@vger.kernel.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 9c6e28cab8ebf2177dfe58930a8e17ca7043a4dc
Author: Peng Tao <tao.peng@primarydata.com>
Date:   Fri Sep 11 11:14:06 2015 +0800

    nfs: fix pg_test page count calculation

    [ Upstream commit 048883e0b934d9a5103d40e209cb14b7f33d2933 ]

    We really want sizeof(struct page *) instead. Otherwise we limit
    maximum IO size to 64 pages rather than 512 pages on a 64bit system.

    Fixes 2e11f829(nfs: cap request size to fit a kmalloced page array).

    Cc: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Peng Tao <tao.peng@primarydata.com>
    Fixes: 2e11f8296d22 ("nfs: cap request size to fit a kmalloced page array")
    Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit e79740704034182a5961d774f4c87025db4eb0e3
Author: Florian Westphal <fw@strlen.de>
Date:   Wed Sep 9 02:57:21 2015 +0200

    netfilter: nf_log: don't zap all loggers on unregister

    [ Upstream commit 205ee117d4dc4a11ac3bd9638bb9b2e839f4de9a ]

    like nf_log_unset, nf_log_unregister must not reset the list of loggers.
    Otherwise, a call to nf_log_unregister() will render loggers of other nf
    protocols unusable:

    iptables -A INPUT -j LOG
    modprobe nf_log_arp ; rmmod nf_log_arp
    iptables -A INPUT -j LOG
    iptables: No chain/target/match by that name

    Fixes: 30e0c6a6be ("netfilter: nf_log: prepare net namespace support for loggers")
    Signed-off-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 0496ef122e0b9296f27e1493aaaa217c9497f8d1
Author: Marcelo Leitner <mleitner@redhat.com>
Date:   Wed Oct 29 10:04:51 2014 -0200

    netfilter: nf_log: Introduce nft_log_dereference() macro

    [ Upstream commit 0c26ed1c07f13ca27e2638ffdd1951013ed96c48 ]

    Wrap up a common call pattern in an easier to handle call.

    Signed-off-by: Marcelo Ricardo Leitner <mleitner@redhat.com>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 0b41eaece3a6f675c3940ca694a10c449ea9d227
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Mon Sep 14 18:04:09 2015 +0200

    netfilter: nft_compat: skip family comparison in case of NFPROTO_UNSPEC

    [ Upstream commit ba378ca9c04a5fc1b2cf0f0274a9d02eb3d1bad9 ]

    Fix lookup of existing match/target structures in the corresponding list
    by skipping the family check if NFPROTO_UNSPEC is used.

    This is resulting in the allocation and insertion of one match/target
    structure for each use of them. So this not only bloats memory
    consumption but also severely affects the time to reload the ruleset
    from the iptables-compat utility.

    After this patch, iptables-compat-restore and iptables-compat take
    almost the same time to reload large rulesets.

    Fixes: 0ca743a55991 ("netfilter: nf_tables: add compatibility layer for x_tables")
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 1aaf3bed304e54b4e4d3cac938f5560bc6b8f52d
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Thu Sep 17 13:37:00 2015 +0200

    netfilter: nf_log: wait for rcu grace after logger unregistration

    [ Upstream commit ad5001cc7cdf9aaee5eb213fdee657e4a3c94776 ]

    The nf_log_unregister() function needs to call synchronize_rcu() to make sure
    that the objects are not dereferenced anymore on module removal.

    Fixes: 5962815a6a56 ("netfilter: nf_log: use an array of loggers instead of list")
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit f71252c2c3d7bac9895de13bf6005bc34daee2ac
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Thu Jul 9 22:56:00 2015 +0200

    netfilter: ctnetlink: put back references to master ct and expect objects

    [ Upstream commit 95dd8653de658143770cb0e55a58d2aab97c79d2 ]

    We have to put back the references to the master conntrack and the expectation
    that we just created, otherwise we'll leak them.

    Fixes: 0ef71ee1a5b9 ("netfilter: ctnetlink: refactor ctnetlink_create_expect")
    Reported-by: Tim Wiess <Tim.Wiess@watchguard.com>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit a9108c7e36ad49c61e4f82a52f00e04bfa9b5882
Author: Joe Stringer <joestringer@nicira.com>
Date:   Tue Jul 21 21:37:31 2015 -0700

    netfilter: nf_conntrack: Support expectations in different zones

    [ Upstream commit 4b31814d20cbe5cd4ccf18089751e77a04afe4f2 ]

    When zones were originally introduced, the expectation functions were
    all extended to perform lookup using the zone. However, insertion was
    not modified to check the zone. This means that two expectations which
    are intended to apply for different connections that have the same tuple
    but exist in different zones cannot both be tracked.

    Fixes: 5d0aa2ccd4 (netfilter: nf_conntrack: add support for "conntrack zones")
    Signed-off-by: Joe Stringer <joestringer@nicira.com>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit aef4db8e27803571e673ea2cf9c0e5c2a6dd1f49
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Fri Aug 28 21:01:43 2015 +0200

    netfilter: nfnetlink: work around wrong endianess in res_id field

    [ Upstream commit a9de9777d613500b089a7416f936bf3ae5f070d2 ]

    The convention in nfnetlink is to use network byte order in every header field
    as well as in the attribute payload. The initial version of the batching
    infrastructure assumes that res_id comes in host byte order though.

    The only client of the batching infrastructure is nf_tables, so let's add a
    workaround to address this inconsistency. We currently have 11 nfnetlink
    subsystems according to NFNL_SUBSYS_COUNT, so we can assume that the subsystem
    2560, ie. htons(10), will not be allocated anytime soon, so it can be an alias
    of nf_tables from the nfnetlink batching path when interpreting the res_id
    field.

    Based on original patch from Florian Westphal.

    Reported-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 7b4543bf7ea8f6018385a29ade02038d532e406a
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Fri Oct 2 11:17:37 2015 -0400

    dm raid: fix round up of default region size

    [ Upstream commit 042745ee53a0a7c1f5aff191a4a24213c6dcfb52 ]

    Commit 3a0f9aaee028 ("dm raid: round region_size to power of two")
    intended to make sure that the default region size is a power of two.
    However, the logic in that commit is incorrect and sets the variable
    region_size to 0 or 1, depending on whether min_region_size is a power
    of two.

    Fix this logic, using roundup_pow_of_two(), so that region_size is
    properly rounded up to the next power of two.

    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Fixes: 3a0f9aaee028 ("dm raid: round region_size to power of two")
    Cc: stable@vger.kernel.org # v3.8+
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit ab92cac0bfb5e4c27ea8f6139118f13b982c51b9
Author: Liu.Zhao <lzsos369@163.com>
Date:   Mon Aug 24 08:36:12 2015 -0700

    USB: option: add ZTE PIDs

    [ Upstream commit 19ab6bc5674a30fdb6a2436b068d19a3c17dc73e ]

    This is intended to add ZTE device PIDs on kernel.

    Signed-off-by: Liu.Zhao <lzsos369@163.com>
    Cc: stable <stable@vger.kernel.org>
    [johan: sort the new entries ]
    Signed-off-by: Johan Hovold <johan@kernel.org>

    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 5fdd843e65edc2727ba630519559430bd276cb9c
Author: Joe Thornber <ejt@redhat.com>
Date:   Wed Aug 12 15:12:09 2015 +0100

    dm btree: add ref counting ops for the leaves of top level btrees

    [ Upstream commit b0dc3c8bc157c60b1d470163882be8c13e1950af ]

    When using nested btrees, the top leaves of the top levels contain
    block addresses for the root of the next tree down.  If we shadow a
    shared leaf node the leaf values (sub tree roots) should be incremented
    accordingly.

    This is only an issue if there is metadata sharing in the top levels.
    Which only occurs if metadata snapshots are being used (as is possible
    with dm-thinp).  And could result in a block from the thinp metadata
    snap being reused early, thus corrupting the thinp metadata snap.

    Signed-off-by: Joe Thornber <ejt@redhat.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 11982b198b595fab7c996fa7b15d655e1a84e933
Author: Chuck Lever <chuck.lever@oracle.com>
Date:   Thu Jul 9 16:45:18 2015 -0400

    svcrdma: Fix send_reply() scatter/gather set-up

    [ Upstream commit 9d11b51ce7c150a69e761e30518f294fc73d55ff ]

    The Linux NFS server returns garbage in the data payload of inline
    NFS/RDMA READ replies. These are READs of under 1000 bytes or so
    where the client has not provided either a reply chunk or a write
    list.

    The NFS server delivers the data payload for an NFS READ reply to
    the transport in an xdr_buf page list. If the NFS client did not
    provide a reply chunk or a write list, send_reply() is supposed to
    set up a separate sge for the page containing the READ data, and
    another sge for XDR padding if needed, then post all of the sges via
    a single SEND Work Request.

    The problem is send_reply() does not advance through the xdr_buf
    when setting up scatter/gather entries for SEND WR. It always calls
    dma_map_xdr with xdr_off set to zero. When there's more than one
    sge, dma_map_xdr() sets up the SEND sge's so they all point to the
    xdr_buf's head.

    The current Linux NFS/RDMA client always provides a reply chunk or
    a write list when performing an NFS READ over RDMA. Therefore, it
    does not exercise this particular case. The Linux server has never
    had to use more than one extra sge for building RPC/RDMA replies
    with a Linux client.

    However, an NFS/RDMA client _is_ allowed to send small NFS READs
    without setting up a write list or reply chunk. The NFS READ reply
    fits entirely within the inline reply buffer in this case. This is
    perhaps a more efficient way of performing NFS READs that the Linux
    NFS/RDMA client may some day adopt.

    Fixes: b432e6b3d9c1 ('svcrdma: Change DMA mapping logic to . . .')
    BugLink: https://bugzilla.linux-nfs.org/show_bug.cgi?id=285
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 41d3120a5cd75117ac7f681514c27180cae7e8c2
Author: Michal Kazior <michal.kazior@tieto.com>
Date:   Wed Aug 19 13:10:43 2015 +0200

    ath10k: fix dma_mapping_error() handling

    [ Upstream commit 5e55e3cbd1042cffa6249f22c10585e63f8a29bf ]

    The function returns 1 when DMA mapping fails. The
    driver would return bogus values and could
    possibly confuse itself if DMA failed.

    Fixes: 767d34fc67af ("ath10k: remove DMA mapping wrappers")
    Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
    Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit b2abcec9c58d844e9cf506329cbff89521457702
Author: Filipe Manana <fdmanana@suse.com>
Date:   Mon Sep 28 09:56:26 2015 +0100

    Btrfs: update fix for read corruption of compressed and shared extents

    [ Upstream commit 808f80b46790f27e145c72112189d6a3be2bc884 ]

    My previous fix in commit 005efedf2c7d ("Btrfs: fix read corruption of
    compressed and shared extents") was effective only if the compressed
    extents cover a file range with a length that is not a multiple of 16
    pages. That's because the detection of when we reached a different range
    of the file that shares the same compressed extent as the previously
    processed range was done at extent_io.c:__do_contiguous_readpages(),
    which covers subranges with a length up to 16 pages, because
    extent_readpages() groups the pages in clusters no larger than 16 pages.
    So fix this by tracking the start of the previously processed file
    range's extent map at extent_readpages().

    The following test case for fstests reproduces the issue:

      seq=`basename $0`
      seqres=$RESULT_DIR/$seq
      echo "QA output created by $seq"
      tmp=/tmp/$$
      status=1      # failure is the default!
      trap "_cleanup; exit \$status" 0 1 2 3 15

      _cleanup()
      {
          rm -f $tmp.*
      }

      # get standard environment, filters and checks
      . ./common/rc
      . ./common/filter

      # real QA test starts here
      _need_to_be_root
      _supported_fs btrfs
      _supported_os Linux
      _require_scratch
      _require_cloner

      rm -f $seqres.full

      test_clone_and_read_compressed_extent()
      {
          local mount_opts=$1

          _scratch_mkfs >>$seqres.full 2>&1
          _scratch_mount $mount_opts

          # Create our test file with a single extent of 64Kb that is going to
          # be compressed no matter which compression algo is used (zlib/lzo).
          $XFS_IO_PROG -f -c "pwrite -S 0xaa 0K 64K" \
              $SCRATCH_MNT/foo | _filter_xfs_io

          # Now clone the compressed extent into an adjacent file offset.
          $CLONER_PROG -s 0 -d $((64 * 1024)) -l $((64 * 1024)) \
              $SCRATCH_MNT/foo $SCRATCH_MNT/foo

          echo "File digest before unmount:"
          md5sum $SCRATCH_MNT/foo | _filter_scratch

          # Remount the fs or clear the page cache to trigger the bug in
          # btrfs. Because the extent has an uncompressed length that is a
          # multiple of 16 pages, all the pages belonging to the second range
          # of the file (64K to 128K), which points to the same extent as the
          # first range (0K to 64K), had their contents full of zeroes instead
          # of the byte 0xaa. This was a bug exclusively in the read path of
          # compressed extents, the correct data was stored on disk, btrfs
          # just failed to fill in the pages correctly.
          _scratch_remount

          echo "File digest after remount:"
          # Must match the digest we got before.
          md5sum $SCRATCH_MNT/foo | _filter_scratch
      }

      echo -e "\nTesting with zlib compression..."
      test_clone_and_read_compressed_extent "-o compress=zlib"

      _scratch_unmount

      echo -e "\nTesting with lzo compression..."
      test_clone_and_read_compressed_extent "-o compress=lzo"

      status=0
      exit

    Cc: stable@vger.kernel.org
    Signed-off-by: Filipe Manana <fdmanana@suse.com>
    Tested-by: Timofey Titovets <nefelim4ag@gmail.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit fc6c5152944cc7462391953667a9ac214dad3a94
Author: Filipe Manana <fdmanana@suse.com>
Date:   Mon Sep 14 09:09:31 2015 +0100

    Btrfs: fix read corruption of compressed and shared extents

    [ Upstream commit 005efedf2c7d0a270ffbe28d8997b03844f3e3e7 ]

    If a file has a range pointing to a compressed extent, followed by
    another range that points to the same compressed extent and a read
    operation attempts to read both ranges (either completely or part of
    them), the pages that correspond to the second range are incorrectly
    filled with zeroes.

    Consider the following example:

      File layout
      [0 - 8K]                      [8K - 24K]
          |                             |
          |                             |
       points to extent X,         points to extent X,
       offset 4K, length of 8K     offset 0, length 16K

      [extent X, compressed length = 4K uncompressed length = 16K]

    If a readpages() call spans the 2 ranges, a single bio to read the extent
    is submitted - extent_io.c:submit_extent_page() would only create a new
    bio to cover the second range pointing to the extent if the extent it
    points to had a different logical address than the extent associated with
    the first range. This has a consequence of the compressed read end io
    handler (compression.c:end_compressed_bio_read()) finish once the extent
    is decompressed into the pages covering the first range, leaving the
    remaining pages (belonging to the second range) filled with zeroes (done
    by compression.c:btrfs_clear_biovec_end()).

    So fix this by submitting the current bio whenever we find a range
    pointing to a compressed extent that was preceded by a range with a
    different extent map. This is the simplest solution for this corner
    case. Making the end io callback populate both ranges (or more, if we
    have multiple pointing to the same extent) is a much more complex
    solution since each bio is tightly coupled with a single extent map and
    the extent maps associated to the ranges pointing to the shared extent
    can have different offsets and lengths.

    The following test case for fstests triggers the issue:

      seq=`basename $0`
      seqres=$RESULT_DIR/$seq
      echo "QA output created by $seq"
      tmp=/tmp/$$
      status=1      # failure is the default!
      trap "_cleanup; exit \$status" 0 1 2 3 15

      _cleanup()
      {
          rm -f $tmp.*
      }

      # get standard environment, filters and checks
      . ./common/rc
      . ./common/filter

      # real QA test starts here
      _need_to_be_root
      _supported_fs btrfs
      _supported_os Linux
      _require_scratch
      _require_cloner

      rm -f $seqres.full

      test_clone_and_read_compressed_extent()
      {
          local mount_opts=$1

          _scratch_mkfs >>$seqres.full 2>&1
          _scratch_mount $mount_opts

          # Create a test file with a single extent that is compressed (the
          # data we write into it is highly compressible no matter which
          # compression algorithm is used, zlib or lzo).
          $XFS_IO_PROG -f -c "pwrite -S 0xaa 0K 4K"        \
                          -c "pwrite -S 0xbb 4K 8K"        \
                          -c "pwrite -S 0xcc 12K 4K"       \
                          $SCRATCH_MNT/foo | _filter_xfs_io

          # Now clone our extent into an adjacent offset.
          $CLONER_PROG -s $((4 * 1024)) -d $((16 * 1024)) -l $((8 * 1024)) \
              $SCRATCH_MNT/foo $SCRATCH_MNT/foo

          # Same as before but for this file we clone the extent into a lower
          # file offset.
          $XFS_IO_PROG -f -c "pwrite -S 0xaa 8K 4K"         \
                          -c "pwrite -S 0xbb 12K 8K"        \
                          -c "pwrite -S 0xcc 20K 4K"        \
                          $SCRATCH_MNT/bar | _filter_xfs_io

          $CLONER_PROG -s $((12 * 1024)) -d 0 -l $((8 * 1024)) \
              $SCRATCH_MNT/bar $SCRATCH_MNT/bar

          echo "File digests before unmounting filesystem:"
          md5sum $SCRATCH_MNT/foo | _filter_scratch
          md5sum $SCRATCH_MNT/bar | _filter_scratch

          # Evicting the inode or clearing the page cache before reading
          # again the file would also trigger the bug - reads were returning
          # all bytes in the range corresponding to the second reference to
          # the extent with a value of 0, but the correct data was persisted
          # (it was a bug exclusively in the read path). The issue happened
          # only if the same readpages() call targeted pages belonging to the
          # first and second ranges that point to the same compressed extent.
          _scratch_remount

          echo "File digests after mounting filesystem again:"
          # Must match the same digests we got before.
          md5sum $SCRATCH_MNT/foo | _filter_scratch
          md5sum $SCRATCH_MNT/bar | _filter_scratch
      }

      echo -e "\nTesting with zlib compression..."
      test_clone_and_read_compressed_extent "-o compress=zlib"

      _scratch_unmount

      echo -e "\nTesting with lzo compression..."
      test_clone_and_read_compressed_extent "-o compress=lzo"

      status=0
      exit

    Cc: stable@vger.kernel.org
    Signed-off-by: Filipe Manana <fdmanana@suse.com>
    Reviewed-by: Qu Wenruo<quwenruo@cn.fujitsu.com>
    Reviewed-by: Liu Bo <bo.li.liu@oracle.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 1fb045a8b0bbfb757e114d5d0ad4dfb335346dc7
Author: Jeff Mahoney <jeffm@suse.com>
Date:   Fri Sep 11 21:44:17 2015 -0400

    btrfs: skip waiting on ordered range for special files

    [ Upstream commit a30e577c96f59b1e1678ea5462432b09bf7d5cbc ]

    In btrfs_evict_inode, we properly truncate the page cache for evicted
    inodes but then we call btrfs_wait_ordered_range for every inode as well.
    It's the right thing to do for regular files but results in incorrect
    behavior for device inodes for block devices.

    filemap_fdatawrite_range gets called with inode->i_mapping which gets
    resolved to the block device inode before getting passed to
    wbc_attach_fdatawrite_inode and ultimately to inode_to_bdi.  What happens
    next depends on whether there's an open file handle associated with the
    inode.  If there is, we write to the block device, which is unexpected
    behavior.  If there isn't, we through normally and inode->i_data is used.
    We can also end up racing against open/close which can result in crashes
    when i_mapping points to a block device inode that has been closed.

    Since there can't be any page cache associated with special file inodes,
    it's safe to skip the btrfs_wait_ordered_range call entirely and avoid
    the problem.

    Cc: <stable@vger.kernel.org>
    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=100911
    Tested-by: Christoph Biedl <linux-kernel.bfrz@manchmal.in-ulm.de>
    Signed-off-by: Jeff Mahoney <jeffm@suse.com>
    Reviewed-by: Filipe Manana <fdmanana@suse.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit e1a73316b1c356860a5d5ee7c7ecf30a3880516d
Author: Yitian Bu <buyitian@gmail.com>
Date:   Fri Oct 2 15:18:41 2015 +0800

    ASoC: dwc: correct irq clear method

    [ Upstream commit 4873867e5f2bd90faad861dd94865099fc3140f3 ]

    from Designware I2S datasheet, tx/rx XRUN irq is cleared by
    reading register TOR/ROR, rather than by writing into them.

    Signed-off-by: Yitian Bu <yitian.bu@tangramtek.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Cc: stable@vger.kernel.org
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 44594dddabd8e4e6b0a388b8ff9b5e06a6e782db
Author: Robert Jarzmik <robert.jarzmik@free.fr>
Date:   Tue Sep 15 20:51:31 2015 +0200

    ASoC: fix broken pxa SoC support

    [ Upstream commit 3c8f7710c1c44fb650bc29b6ef78ed8b60cfaa28 ]

    The previous fix of pxa library support, which was introduced to fix the
    library dependency, broke the previous SoC behavior, where a machine
    code binding pxa2xx-ac97 with a coded relied on :
     - sound/soc/pxa/pxa2xx-ac97.c
     - sound/soc/codecs/XXX.c

    For example, the mioa701_wm9713.c machine code is currently broken. The
    "select ARM" statement wrongly selects the soc/arm/pxa2xx-ac97 for
    compilation, as per an unfortunate fate SND_PXA2XX_AC97 is both declared
    in sound/arm/Kconfig and sound/soc/pxa/Kconfig.

    Fix this by ensuring that SND_PXA2XX_SOC correctly triggers the correct
    pxa2xx-ac97 compilation.

    Fixes: 846172dfe33c ("ASoC: fix SND_PXA2XX_LIB Kconfig warning")
    Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit b402bfb3dd7ae94cea9f9e583631f08837442a0a
Author: Robert Jarzmik <robert.jarzmik@free.fr>
Date:   Tue Sep 22 21:20:22 2015 +0200

    ASoC: pxa: pxa2xx-ac97: fix dma requestor lines

    [ Upstream commit 8811191fdf7ed02ee07cb8469428158572d355a2 ]

    PCM receive and transmit DMA requestor lines were reverted, breaking the
    PCM playback interface for PXA platforms using the sound/soc/ variant
    instead of the sound/arm variant.

    The commit below shows the inversion in the requestor lines.

    Fixes: d65a14587a9b ("ASoC: pxa: use snd_dmaengine_dai_dma_data")
    Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Cc: stable@vger.kernel.org
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit e7c645a25f3a201fd2e8d097a52d50a6ba01fec3
Author: John Flatness <john@zerocrates.org>
Date:   Fri Oct 2 17:07:49 2015 -0400

    ALSA: hda - Apply SPDIF pin ctl to MacBookPro 12,1

    [ Upstream commit e8ff581f7ac2bc3b8886094b7ca635dcc4d1b0e9 ]

    The MacBookPro 12,1 has the same setup as the 11 for controlling the
    status of the optical audio light. Simply apply the existing workaround
    to the subsystem ID for the 12,1.

    [sorted the fixup entry by tiwai]

    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=105401
    Signed-off-by: John Flatness <john@zerocrates.org>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit f60c8a5f2697193ea4b08b0f554c7265df8bbb11
Author: Laura Abbott <labbott@fedoraproject.org>
Date:   Fri Oct 2 11:09:54 2015 -0700

    ALSA: hda: Add dock support for ThinkPad T550

    [ Upstream commit d05ea7da0e8f6df3c62cfee75538f347cb3d89ef ]

    Much like all the other Lenovo laptops, add a quirk to make
    sound work with docking.

    Reported-and-tested-by: lacknerflo@gmail.com
    Signed-off-by: Laura Abbott <labbott@fedoraproject.org>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit e701ac72198baa78ee26b1c6da77173371346122
Author: Takashi Iwai <tiwai@suse.de>
Date:   Mon Oct 5 16:55:09 2015 +0200

    ALSA: synth: Fix conflicting OSS device registration on AWE32

    [ Upstream commit 225db5762dc1a35b26850477ffa06e5cd0097243 ]

    When OSS emulation is loaded on ISA SB AWE32 chip, we get now kernel
    warnings like:
      WARNING: CPU: 0 PID: 2791 at fs/sysfs/dir.c:31 sysfs_warn_dup+0x51/0x80()
      sysfs: cannot create duplicate filename '/devices/isa/sbawe.0/sound/card0/seq-oss-0-0'

    It's because both emux synth and opl3 drivers try to register their
    OSS device object with the same static index number 0.  This hasn't
    been a big problem until the recent rewrite of device management code
    (that exposes sysfs at the same time), but it's been an obvious bug.

    This patch works around it just by using a different index number of
    emux synth object.  There can be a more elegant way to fix, but it's
    enough for now, as this code won't be touched so often, in anyway.

    Reported-and-tested-by: Michael Shell <list1@michaelshell.org>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 0e4cfed8f063028430bfc6883217698fca3c35ab
Author: Mel Gorman <mgorman@techsingularity.net>
Date:   Thu Oct 1 15:36:57 2015 -0700

    mm: hugetlbfs: skip shared VMAs when unmapping private pages to satisfy a fault

    [ Upstream commit 2f84a8990ebbe235c59716896e017c6b2ca1200f ]

    SunDong reported the following on

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

            I think I find a linux bug, I have the test cases is constructed. I
            can stable recurring problems in fedora22(4.0.4) kernel version,
            arch for x86_64.  I construct transparent huge page, when the parent
            and child process with MAP_SHARE, MAP_PRIVATE way to access the same
            huge page area, it has the opportunity to lead to huge page copy on
            write failure, and then it will munmap the child corresponding mmap
            area, but then the child mmap area with VM_MAYSHARE attributes, child
            process munmap this area can trigger VM_BUG_ON in set_vma_resv_flags
            functions (vma - > vm_flags & VM_MAYSHARE).

    There were a number of problems with the report (e.g.  it's hugetlbfs that
    triggers this, not transparent huge pages) but it was fundamentally
    correct in that a VM_BUG_ON in set_vma_resv_flags() can be triggered that
    looks like this

             vma ffff8804651fd0d0 start 00007fc474e00000 end 00007fc475e00000
             next ffff8804651fd018 prev ffff8804651fd188 mm ffff88046b1b1800
             prot 8000000000000027 anon_vma           (null) vm_ops ffffffff8182a7a0
             pgoff 0 file ffff88106bdb9800 private_data           (null)
             flags: 0x84400fb(read|write|shared|mayread|maywrite|mayexec|mayshare|dontexpand|hugetlb)
             ------------
             kernel BUG at mm/hugetlb.c:462!
             SMP
             Modules linked in: xt_pkttype xt_LOG xt_limit [..]
             CPU: 38 PID: 26839 Comm: map Not tainted 4.0.4-default #1
             Hardware name: Dell Inc. PowerEdge R810/0TT6JF, BIOS 2.7.4 04/26/2012
             set_vma_resv_flags+0x2d/0x30

    The VM_BUG_ON is correct because private and shared mappings have
    different reservation accounting but the warning clearly shows that the
    VMA is shared.

    When a private COW fails to allocate a new page then only the process
    that created the VMA gets the page -- all the children unmap the page.
    If the children access that data in the future then they get killed.

    The problem is that the same file is mapped shared and private.  During
    the COW, the allocation fails, the VMAs are traversed to unmap the other
    private pages but a shared VMA is found and the bug is triggered.  This
    patch identifies such VMAs and skips them.

    Signed-off-by: Mel Gorman <mgorman@techsingularity.net>
    Reported-by: SunDong <sund_sky@126.com>
    Reviewed-by: Michal Hocko <mhocko@suse.com>
    Cc: Andrea Arcangeli <aarcange@redhat.com>
    Cc: Hugh Dickins <hughd@google.com>
    Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
    Cc: David Rientjes <rientjes@google.com>
    Reviewed-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit efddc65b3ecb2d1e7043a96d5f673760f22742d2
Author: Joseph Qi <joseph.qi@huawei.com>
Date:   Tue Sep 22 14:59:20 2015 -0700

    ocfs2/dlm: fix deadlock when dispatch assert master

    [ Upstream commit 012572d4fc2e4ddd5c8ec8614d51414ec6cae02a ]

    The order of the following three spinlocks should be:
    dlm_domain_lock < dlm_ctxt->spinlock < dlm_lock_resource->spinlock

    But dlm_dispatch_assert_master() is called while holding
    dlm_ctxt->spinlock and dlm_lock_resource->spinlock, and then it calls
    dlm_grab() which will take dlm_domain_lock.

    Once another thread (for example, dlm_query_join_handler) has already
    taken dlm_domain_lock, and tries to take dlm_ctxt->spinlock deadlock
    happens.

    Signed-off-by: Joseph Qi <joseph.qi@huawei.com>
    Cc: Joel Becker <jlbec@evilplan.org>
    Cc: Mark Fasheh <mfasheh@suse.com>
    Cc: "Junxiao Bi" <junxiao.bi@oracle.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit bf61da4411682000a12ad7756d62fe7985fd8523
Author: Tan, Jui Nee <jui.nee.tan@intel.com>
Date:   Tue Sep 1 10:22:51 2015 +0800

    spi: spi-pxa2xx: Check status register to determine if SSSR_TINT is disabled

    [ Upstream commit 02bc933ebb59208f42c2e6305b2c17fd306f695d ]

    On Intel Baytrail, there is case when interrupt handler get called, no SPI
    message is captured. The RX FIFO is indeed empty when RX timeout pending
    interrupt (SSSR_TINT) happens.

    Use the BIOS version where both HSUART and SPI are on the same IRQ. Both
    drivers are using IRQF_SHARED when calling the request_irq function. When
    running two separate and independent SPI and HSUART application that
    generate data traffic on both components, user will see messages like
    below on the console:

      pxa2xx-spi pxa2xx-spi.0: bad message state in interrupt handler

    This commit will fix this by first checking Receiver Time-out Interrupt,
    if it is disabled, ignore the request and return without servicing.

    Signed-off-by: Tan, Jui Nee <jui.nee.tan@intel.com>
    Acked-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Cc: stable@vger.kernel.org
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit a94229eb62f288a04ddafa39abce4a0b9f6280fc
Author: Max Filippov <jcmvbkbc@gmail.com>
Date:   Tue Sep 22 14:32:03 2015 +0300

    spi: xtensa-xtfpga: fix register endianness

    [ Upstream commit b0b4855099e301c8603ea37da9a0103a96c2e0b1 ]

    XTFPGA SPI controller has native endian registers.
    Fix register acessors so that they work in big-endian configurations.

    Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Cc: stable@vger.kernel.org
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 628e5c38cf55892da4e202e6a4940617e1ec8ee8
Author: Guenter Roeck <linux@roeck-us.net>
Date:   Sun Sep 6 01:46:54 2015 +0300

    spi: Fix documentation of spi_alloc_master()

    [ Upstream commit a394d635193b641f2c86ead5ada5b115d57c51f8 ]

    Actually, spi_master_put() after spi_alloc_master() must _not_ be followed
    by kfree(). The memory is already freed with the call to spi_master_put()
    through spi_master_class, which registers a release function. Calling both
    spi_master_put() and kfree() results in often nasty (and delayed) crashes
    elsewhere in the kernel, often in the networking stack.

    This reverts commit eb4af0f5349235df2e4a5057a72fc8962d00308a.

    Link to patch and concerns: https://lkml.org/lkml/2012/9/3/269
    or
    http://lkml.iu.edu/hypermail/linux/kernel/1209.0/00790.html

    Alexey Klimov: This revert becomes valid after
    94c69f765f1b4a658d96905ec59928e3e3e07e6a when spi-imx.c
    has been fixed and there is no need to call kfree() so comment
    for spi_alloc_master() should be fixed.

    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Alexey Klimov <alexey.klimov@linaro.org>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Cc: stable@vger.kernel.org
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 91f073fb956fa7e16d56b18be462059a203e97d3
Author: Christian Borntraeger <borntraeger@de.ibm.com>
Date:   Mon Sep 28 22:47:42 2015 +0200

    s390/boot/decompression: disable floating point in decompressor

    [ Upstream commit adc0b7fbf6fe9967505c0254d9535ec7288186ae ]

    my gcc 5.1 used an ldgr instruction with a register != 0,2,4,6 for
    spilling/filling into a floating point register in our decompressor.

    This will cause an AFP-register data exception as the decompressor
    did not setup the additional floating point registers via cr0.
    That causes a program check loop that looked like a hang with
    one "Uncompressing Linux... " message (directly booted via kvm)
    or a loop of "Uncompressing Linux... " messages (when booted via
    zipl boot loader).

    The offending code in my build was

       48e400:       e3 c0 af ff ff 71       lay     %r12,-1(%r10)
    -->48e406:       b3 c1 00 1c             ldgr    %f1,%r12
       48e40a:       ec 6c 01 22 02 7f       clij    %r6,2,12,0x48e64e

    but gcc could do spilling into an fpr at any function. We can
    simply disable floating point support at that early stage.

    Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
    Acked-by: Heiko Carstens <heiko.carstens@de.ibm.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit ca49c6cc8e77980557c26c88f43b5699acb3d770
Author: Martin Schwidefsky <schwidefsky@de.ibm.com>
Date:   Tue Sep 8 15:25:39 2015 +0200

    s390/compat: correct uc_sigmask of the compat signal frame

    [ Upstream commit 8d4bd0ed0439dfc780aab801a085961925ed6838 ]

    The uc_sigmask in the ucontext structure is an array of words to keep
    the 64 signal bits (or 1024 if you ask glibc but the kernel sigset_t
    only has 64 bits).

    For 64 bit the sigset_t contains a single 8 byte word, but for 31 bit
    there are two 4 byte words. The compat signal handler code uses a
    simple copy of the 64 bit sigset_t to the 31 bit compat_sigset_t.
    As s390 is a big-endian architecture this is incorrect, the two words
    in the 31 bit sigset_t array need to be swapped.

    Cc: <stable@vger.kernel.org>
    Reported-by: Stefan Liebler <stli@linux.vnet.ibm.com>
    Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit fafb54dbf1d5dfba928085ae5532b7f2c9b6eb67
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Tue Sep 29 14:45:09 2015 +0200

    sched/core: Fix TASK_DEAD race in finish_task_switch()

    [ Upstream commit 95913d97914f44db2b81271c2e2ebd4d2ac2df83 ]

    So the problem this patch is trying to address is as follows:

            CPU0                            CPU1

            context_switch(A, B)
                                            ttwu(A)
                                              LOCK A->pi_lock
                                              A->on_cpu == 0
            finish_task_switch(A)
              prev_state = A->state  <-.
              WMB                      |
              A->on_cpu = 0;           |
              UNLOCK rq0->lock         |
                                       |    context_switch(C, A)
                                       `--  A->state = TASK_DEAD
              prev_state == TASK_DEAD
                put_task_struct(A)
                                            context_switch(A, C)
                                            finish_task_switch(A)
                                              A->state == TASK_DEAD
                                                put_task_struct(A)

    The argument being that the WMB will allow the load of A->state on CPU0
    to cross over and observe CPU1's store of A->state, which will then
    result in a double-drop and use-after-free.

    Now the comment states (and this was true once upon a long time ago)
    that we need to observe A->state while holding rq->lock because that
    will order us against the wakeup; however the wakeup will not in fact
    acquire (that) rq->lock; it takes A->pi_lock these days.

    We can obviously fix this by upgrading the WMB to an MB, but that is
    expensive, so we'd rather avoid that.

    The alternative this patch takes is: smp_store_release(&A->on_cpu, 0),
    which avoids the MB on some archs, but not important ones like ARM.

    Reported-by: Oleg Nesterov <oleg@redhat.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: <stable@vger.kernel.org> # v3.1+
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: linux-kernel@vger.kernel.org
    Cc: manfred@colorfullife.com
    Cc: will.deacon@arm.com
    Fixes: e4a52bcb9a18 ("sched: Remove rq->lock from the first half of ttwu()")
    Link: http://lkml.kernel.org/r/20150929124509.GG3816@twins.programming.kicks-ass.net
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 4de74d2037ad5bcd475c0fa113de00941dd7d567
Author: Vitaly Kuznetsov <vkuznets@redhat.com>
Date:   Fri Sep 25 11:59:52 2015 +0200

    x86/xen: Support kexec/kdump in HVM guests by doing a soft reset

    [ Upstream commit 0b34a166f291d255755be46e43ed5497cdd194f2 ]

    Currently there is a number of issues preventing PVHVM Xen guests from
    doing successful kexec/kdump:

      - Bound event channels.
      - Registered vcpu_info.
      - PIRQ/emuirq mappings.
      - shared_info frame after XENMAPSPACE_shared_info operation.
      - Active grant mappings.

    Basically, newly booted kernel stumbles upon already set up Xen
    interfaces and there is no way to reestablish them. In Xen-4.7 a new
    feature called 'soft reset' is coming. A guest performing kexec/kdump
    operation is supposed to call SCHEDOP_shutdown hypercall with
    SHUTDOWN_soft_reset reason before jumping to new kernel. Hypervisor
    (with some help from toolstack) will do full domain cleanup (but
    keeping its memory and vCPU contexts intact) returning the guest to
    the state it had when it was first booted and thus allowing it to
    start over.

    Doing SHUTDOWN_soft_reset on Xen hypervisors which don't support it is
    probably OK as by default all unknown shutdown reasons cause domain
    destroy with a message in toolstack log: 'Unknown shutdown reason code
    5. Destroying domain.'  which gives a clue to what the problem is and
    eliminates false expectations.

    Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: David Vrabel <david.vrabel@citrix.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit da00c72eae91e6a72ab1fef7ab94fcc382c5edd2
Author: Stephen Smalley <sds@tycho.nsa.gov>
Date:   Thu Oct 1 09:04:22 2015 -0400

    x86/mm: Set NX on gap between __ex_table and rodata

    [ Upstream commit ab76f7b4ab2397ffdd2f1eb07c55697d19991d10 ]

    Unused space between the end of __ex_table and the start of
    rodata can be left W+x in the kernel page tables.  Extend the
    setting of the NX bit to cover this gap by starting from
    text_end rather than rodata_start.

      Before:
      ---[ High Kernel Mapping ]---
      0xffffffff80000000-0xffffffff81000000          16M                               pmd
      0xffffffff81000000-0xffffffff81600000           6M     ro         PSE     GLB x  pmd
      0xffffffff81600000-0xffffffff81754000        1360K     ro                 GLB x  pte
      0xffffffff81754000-0xffffffff81800000         688K     RW                 GLB x  pte
      0xffffffff81800000-0xffffffff81a00000           2M     ro         PSE     GLB NX pmd
      0xffffffff81a00000-0xffffffff81b3b000        1260K     ro                 GLB NX pte
      0xffffffff81b3b000-0xffffffff82000000        4884K     RW                 GLB NX pte
      0xffffffff82000000-0xffffffff82200000           2M     RW         PSE     GLB NX pmd
      0xffffffff82200000-0xffffffffa0000000         478M                               pmd

      After:
      ---[ High Kernel Mapping ]---
      0xffffffff80000000-0xffffffff81000000          16M                               pmd
      0xffffffff81000000-0xffffffff81600000           6M     ro         PSE     GLB x  pmd
      0xffffffff81600000-0xffffffff81754000        1360K     ro                 GLB x  pte
      0xffffffff81754000-0xffffffff81800000         688K     RW                 GLB NX pte
      0xffffffff81800000-0xffffffff81a00000           2M     ro         PSE     GLB NX pmd
      0xffffffff81a00000-0xffffffff81b3b000        1260K     ro                 GLB NX pte
      0xffffffff81b3b000-0xffffffff82000000        4884K     RW                 GLB NX pte
      0xffffffff82000000-0xffffffff82200000           2M     RW         PSE     GLB NX pmd
      0xffffffff82200000-0xffffffffa0000000         478M                               pmd

    Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
    Acked-by: Kees Cook <keescook@chromium.org>
    Cc: <stable@vger.kernel.org>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Mike Galbraith <efault@gmx.de>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: linux-kernel@vger.kernel.org
    Link: http://lkml.kernel.org/r/1443704662-3138-1-git-send-email-sds@tycho.nsa.gov
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit a92668113fc5326cb3c09958a000e7130eaa651f
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Wed Sep 30 08:38:22 2015 +0000

    x86/process: Add proper bound checks in 64bit get_wchan()

    [ Upstream commit eddd3826a1a0190e5235703d1e666affa4d13b96 ]

    Dmitry Vyukov reported the following using trinity and the memory
    error detector AddressSanitizer
    (https://code.google.com/p/address-sanitizer/wiki/AddressSanitizerForKernel).

    [ 124.575597] ERROR: AddressSanitizer: heap-buffer-overflow on
    address ffff88002e280000
    [ 124.576801] ffff88002e280000 is located 131938492886538 bytes to
    the left of 28857600-byte region [ffffffff81282e0a, ffffffff82e0830a)
    [ 124.578633] Accessed by thread T10915:
    [ 124.579295] inlined in describe_heap_address
    ./arch/x86/mm/asan/report.c:164
    [ 124.579295] #0 ffffffff810dd277 in asan_report_error
    ./arch/x86/mm/asan/report.c:278
    [ 124.580137] #1 ffffffff810dc6a0 in asan_check_region
    ./arch/x86/mm/asan/asan.c:37
    [ 124.581050] #2 ffffffff810dd423 in __tsan_read8 ??:0
    [ 124.581893] #3 ffffffff8107c093 in get_wchan
    ./arch/x86/kernel/process_64.c:444

    The address checks in the 64bit implementation of get_wchan() are
    wrong in several ways:

     - The lower bound of the stack is not the start of the stack
       page. It's the start of the stack page plus sizeof (struct
       thread_info)

     - The upper bound must be:

           top_of_stack - TOP_OF_KERNEL_STACK_PADDING - 2 * sizeof(unsigned long).

       The 2 * sizeof(unsigned long) is required because the stack pointer
       points at the frame pointer. The layout on the stack is: ... IP FP
       ... IP FP. So we need to make sure that both IP and FP are in the
       bounds.

    Fix the bound checks and get rid of the mix of numeric constants, u64
    and unsigned long. Making all unsigned long allows us to use the same
    function for 32bit as well.

    Use READ_ONCE() when accessing the stack. This does not prevent a
    concurrent wakeup of the task and the stack changing, but at least it
    avoids TOCTOU.

    Also check task state at the end of the loop. Again that does not
    prevent concurrent changes, but it avoids walking for nothing.

    Add proper comments while at it.

    Reported-by: Dmitry Vyukov <dvyukov@google.com>
    Reported-by: Sasha Levin <sasha.levin@oracle.com>
    Based-on-patch-from: Wolfram Gloger <wmglo@dent.med.uni-muenchen.de>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Borislav Petkov <bp@alien8.de>
    Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
    Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com>
    Cc: Andy Lutomirski <luto@amacapital.net>
    Cc: Andrey Konovalov <andreyknvl@google.com>
    Cc: Kostya Serebryany <kcc@google.com>
    Cc: Alexander Potapenko <glider@google.com>
    Cc: kasan-dev <kasan-dev@googlegroups.com>
    Cc: Denys Vlasenko <dvlasenk@redhat.com>
    Cc: Andi Kleen <ak@linux.intel.com>
    Cc: Wolfram Gloger <wmglo@dent.med.uni-muenchen.de>
    Cc: stable@vger.kernel.org
    Link: http://lkml.kernel.org/r/20150930083302.694788319@linutronix.de
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 4aa755567f1e664c985eb0fb55e2be4b1fe14f17
Author: Andy Lutomirski <luto@amacapital.net>
Date:   Tue Mar 10 11:05:58 2015 -0700

    x86/asm/entry: Create and use a 'TOP_OF_KERNEL_STACK_PADDING' macro

    [ Upstream commit 3ee4298f440c81638cbb5ec06f2497fb7a9a9eb4 ]

    x86_32, unlike x86_64, pads the top of the kernel stack, because the
    hardware stack frame formats are variable in size.

    Document this padding and give it a name.

    This should make no change whatsoever to the compiled kernel
    image. It also doesn't fix any of the current bugs in this area.

    Signed-off-by: Andy Lutomirski <luto@amacapital.net>
    Acked-by: Denys Vlasenko <dvlasenk@redhat.com>
    Cc: Borislav Petkov <bp@alien8.de>
    Cc: H. Peter Anvin <hpa@zytor.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Oleg Nesterov <oleg@redhat.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Link: http://lkml.kernel.org/r/02bf2f54b8dcb76a62a142b6dfe07d4ef7fc582e.1426009661.git.luto@amacapital.net
    [ Fixed small details, such as a missed magic constant in entry_32.S pointed out by Denys Vlasenko. ]
    Signed-off-by: Ingo Molnar <mingo@kernel.org>

    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit e0bc30ecd6debc5a9a88a45f589bc05795e871ec
Author: Lee, Chun-Yi <joeyli.kernel@gmail.com>
Date:   Tue Sep 29 20:58:57 2015 +0800

    x86/kexec: Fix kexec crash in syscall kexec_file_load()

    [ Upstream commit e3c41e37b0f4b18cbd4dac76cbeece5a7558b909 ]

    The original bug is a page fault crash that sometimes happens
    on big machines when preparing ELF headers:

        BUG: unable to handle kernel paging request at ffffc90613fc9000
        IP: [<ffffffff8103d645>] prepare_elf64_ram_headers_callback+0x165/0x260

    The bug is caused by us under-counting the number of memory ranges
    and subsequently not allocating enough ELF header space for them.
    The bug is typically masked on smaller systems, because the ELF header
    allocation is rounded up to the next page.

    This patch modifies the code in fill_up_crash_elf_data() by using
    walk_system_ram_res() instead of walk_system_ram_range() to correctly
    count the max number of crash memory ranges. That's because the
    walk_system_ram_range() filters out small memory regions that
    reside in the same page, but walk_system_ram_res() does not.

    Here's how I found the bug:

    After tracing prepare_elf64_headers() and prepare_elf64_ram_headers_callback(),
    the code uses walk_system_ram_res() to fill-in crash memory regions information
    to the program header, so it counts those small memory regions that
    reside in a page area.

    But, when the kernel was using walk_system_ram_range() in
    fill_up_crash_elf_data() to count the number of crash memory regions,
    it filters out small regions.

    I printed those small memory regions, for example:

      kexec: Get nr_ram ranges. vaddr=0xffff880077592258 paddr=0x77592258, sz=0xdc0

    Based on the code in walk_system_ram_range(), this memory region
    will be filtered out:

      pfn = (0x77592258 + 0x1000 - 1) >> 12 = 0x77593
      end_pfn = (0x77592258 + 0xfc0 -1 + 1) >> 12 = 0x77593
      end_pfn - pfn = 0x77593 - 0x77593 = 0  <=== if (end_pfn > pfn) is FALSE

    So, the max_nr_ranges that's counted by the kernel doesn't include
    small memory regions - causing us to under-allocate the required space.
    That causes the page fault crash that happens in a later code path
    when preparing ELF headers.

    This bug is not easy to reproduce on small machines that have few
    CPUs, because the allocated page aligned ELF buffer has more free
    space to cover those small memory regions' PT_LOAD headers.

    Signed-off-by: Lee, Chun-Yi <jlee@suse.com>
    Cc: Andy Lutomirski <luto@kernel.org>
    Cc: Baoquan He <bhe@redhat.com>
    Cc: Jiang Liu <jiang.liu@linux.intel.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Mike Galbraith <efault@gmx.de>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Stephen Rothwell <sfr@canb.auug.org.au>
    Cc: Takashi Iwai <tiwai@suse.de>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Viresh Kumar <viresh.kumar@linaro.org>
    Cc: Vivek Goyal <vgoyal@redhat.com>
    Cc: kexec@lists.infradead.org
    Cc: linux-kernel@vger.kernel.org
    Cc: <stable@vger.kernel.org>
    Link: http://lkml.kernel.org/r/1443531537-29436-1-git-send-email-jlee@suse.com
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 38b54f8d748555c3e34dade08f112461e8c1db03
Author: Matt Fleming <matt.fleming@intel.com>
Date:   Fri Sep 25 23:02:18 2015 +0100

    x86/efi: Fix boot crash by mapping EFI memmap entries bottom-up at runtime, instead of top-down

    [ Upstream commit a5caa209ba9c29c6421292e7879d2387a2ef39c9 ]

    Beginning with UEFI v2.5 EFI_PROPERTIES_TABLE was introduced
    that signals that the firmware PE/COFF loader supports splitting
    code and data sections of PE/COFF images into separate EFI
    memory map entries. This allows the kernel to map those regions
    with strict memory protections, e.g. EFI_MEMORY_RO for code,
    EFI_MEMORY_XP for data, etc.

    Unfortunately, an unwritten requirement of this new feature is
    that the regions need to be mapped with the same offsets
    relative to each other as observed in the EFI memory map. If
    this is not done crashes like this may occur,

      BUG: unable to handle kernel paging request at fffffffefe6086dd
      IP: [<fffffffefe6086dd>] 0xfffffffefe6086dd
      Call Trace:
       [<ffffffff8104c90e>] efi_call+0x7e/0x100
       [<ffffffff81602091>] ? virt_efi_set_variable+0x61/0x90
       [<ffffffff8104c583>] efi_delete_dummy_variable+0x63/0x70
       [<ffffffff81f4e4aa>] efi_enter_virtual_mode+0x383/0x392
       [<ffffffff81f37e1b>] start_kernel+0x38a/0x417
       [<ffffffff81f37495>] x86_64_start_reservations+0x2a/0x2c
       [<ffffffff81f37582>] x86_64_start_kernel+0xeb/0xef

    Here 0xfffffffefe6086dd refers to an address the firmware
    expects to be mapped but which the OS never claimed was mapped.
    The issue is that included in these regions are relative
    addresses to other regions which were emitted by the firmware
    toolchain before the "splitting" of sections occurred at
    runtime.

    Needless to say, we don't satisfy this unwritten requirement on
    x86_64 and instead map the EFI memory map entries in reverse
    order. The above crash is almost certainly triggerable with any
    kernel newer than v3.13 because that's when we rewrote the EFI
    runtime region mapping code, in commit d2f7cbe7b26a ("x86/efi:
    Runtime services virtual mapping"). For kernel versions before
    v3.13 things may work by pure luck depending on the
    fragmentation of the kernel virtual address space at the time we
    map the EFI regions.

    Instead of mapping the EFI memory map entries in reverse order,
    where entry N has a higher virtual address than entry N+1, map
    them in the same order as they appear in the EFI memory map to
    preserve this relative offset between regions.

    This patch has been kept as small as possible with the intention
    that it should be applied aggressively to stable and
    distribution kernels. It is very much a bugfix rather than
    support for a new feature, since when EFI_PROPERTIES_TABLE is
    enabled we must map things as outlined above to even boot - we
    have no way of asking the firmware not to split the code/data
    regions.

    In fact, this patch doesn't even make use of the more strict
    memory protections available in UEFI v2.5. That will come later.

    Suggested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Reported-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Signed-off-by: Matt Fleming <matt.fleming@intel.com>
    Cc: <stable@vger.kernel.org>
    Cc: Borislav Petkov <bp@suse.de>
    Cc: Chun-Yi <jlee@suse.com>
    Cc: Dave Young <dyoung@redhat.com>
    Cc: H. Peter Anvin <hpa@zytor.com>
    Cc: James Bottomley <JBottomley@Odin.com>
    Cc: Lee, Chun-Yi <jlee@suse.com>
    Cc: Leif Lindholm <leif.lindholm@linaro.org>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Matthew Garrett <mjg59@srcf.ucam.org>
    Cc: Mike Galbraith <efault@gmx.de>
    Cc: Peter Jones <pjones@redhat.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: linux-kernel@vger.kernel.org
    Link: http://lkml.kernel.org/r/1443218539-7610-2-git-send-email-matt@codeblueprint.co.uk
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit c2b75739d99428b5dd97e4afbfee4a892b7c51a9
Author: Dirk Müller <dmueller@suse.com>
Date:   Thu Oct 1 13:43:42 2015 +0200

    Use WARN_ON_ONCE for missing X86_FEATURE_NRIPS

    [ Upstream commit d2922422c48df93f3edff7d872ee4f3191fefb08 ]

    The cpu feature flags are not ever going to change, so warning
    everytime can cause a lot of kernel log spam
    (in our case more than 10GB/hour).

    The warning seems to only occur when nested virtualization is
    enabled, so it's probably triggered by a KVM bug.  This is a
    sensible and safe change anyway, and the KVM bug fix might not
    be suitable for stable releases anyway.

    Cc: stable@vger.kernel.org
    Signed-off-by: Dirk Mueller <dmueller@suse.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit fc7030ab9d506cac49acbb50535f5437478434cd
Author: Andy Lutomirski <luto@kernel.org>
Date:   Sun Sep 20 16:32:04 2015 -0700

    x86/paravirt: Replace the paravirt nop with a bona fide empty function

    [ Upstream commit fc57a7c68020dcf954428869eafd934c0ab1536f ]

    PARAVIRT_ADJUST_EXCEPTION_FRAME generates this code (using nmi as an
    example, trimmed for readability):

        ff 15 00 00 00 00       callq  *0x0(%rip)        # 2796 <nmi+0x6>
                  2792: R_X86_64_PC32     pv_irq_ops+0x2c

    That's a call through a function pointer to regular C function that
    does nothing on native boots, but that function isn't protected
    against kprobes, isn't marked notrace, and is certainly not
    guaranteed to preserve any registers if the compiler is feeling
    perverse.  This is bad news for a CLBR_NONE operation.

    Of course, if everything works correctly, once paravirt ops are
    patched, it gets nopped out, but what if we hit this code before
    paravirt ops are patched in?  This can potentially cause breakage
    that is very difficult to debug.

    A more subtle failure is possible here, too: if _paravirt_nop uses
    the stack at all (even just to push RBP), it will overwrite the "NMI
    executing" variable if it's called in the NMI prologue.

    The Xen case, perhaps surprisingly, is fine, because it's already
    written in asm.

    Fix all of the cases that default to paravirt_nop (including
    adjust_exception_frame) with a big hammer: replace paravirt_nop with
    an asm function that is just a ret instruction.

    The Xen case may have other problems, so document them.

    This is part of a fix for some random crashes that Sasha saw.

    Reported-and-tested-by: Sasha Levin <sasha.levin@oracle.com>
    Signed-off-by: Andy Lutomirski <luto@kernel.org>
    Cc: stable@vger.kernel.org
    Link: http://lkml.kernel.org/r/8f5d2ba295f9d73751c33d97fda03e0495d9ade0.1442791737.git.luto@kernel.org
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit b4bc0132aee9d929b6b5affbbf77a709e872c155
Author: David Woodhouse <dwmw2@infradead.org>
Date:   Wed Sep 16 14:10:03 2015 +0100

    x86/platform: Fix Geode LX timekeeping in the generic x86 build

    [ Upstream commit 03da3ff1cfcd7774c8780d2547ba0d995f7dc03d ]

    In 2007, commit 07190a08eef36 ("Mark TSC on GeodeLX reliable")
    bypassed verification of the TSC on Geode LX. However, this code
    (now in the check_system_tsc_reliable() function in
    arch/x86/kernel/tsc.c) was only present if CONFIG_MGEODE_LX was
    set.

    OpenWRT has recently started building its generic Geode target
    for Geode GX, not LX, to include support for additional
    platforms. This broke the timekeeping on LX-based devices,
    because the TSC wasn't marked as reliable:
    https://dev.openwrt.org/ticket/20531

    By adding a runtime check on is_geode_lx(), we can also include
    the fix if CONFIG_MGEODEGX1 or CONFIG_X86_GENERIC are set, thus
    fixing the problem.

    Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
    Cc: Andres Salomon <dilinger@queued.net>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Marcelo Tosatti <marcelo@kvack.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: stable@vger.kernel.org
    Link: http://lkml.kernel.org/r/1442409003.131189.87.camel@infradead.org
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 9789806a559e37d3d2f57024476e23f059e2d4fc
Author: Shaohua Li <shli@fb.com>
Date:   Thu Jul 30 16:24:43 2015 -0700

    x86/apic: Serialize LVTT and TSC_DEADLINE writes

    [ Upstream commit 5d7c631d926b59aa16f3c56eaeb83f1036c81dc7 ]

    The APIC LVTT register is MMIO mapped but the TSC_DEADLINE register is an
    MSR. The write to the TSC_DEADLINE MSR is not serializing, so it's not
    guaranteed that the write to LVTT has reached the APIC before the
    TSC_DEADLINE MSR is written. In such a case the write to the MSR is
    ignored and as a consequence the local timer interrupt never fires.

    The SDM decribes this issue for xAPIC and x2APIC modes. The
    serialization methods recommended by the SDM differ.

    xAPIC:
     "1. Memory-mapped write to LVT Timer Register, setting bits 18:17 to 10b.
      2. WRMSR to the IA32_TSC_DEADLINE MSR a value much larger than current time-stamp counter.
      3. If RDMSR of the IA32_TSC_DEADLINE MSR returns zero, go to step 2.
      4. WRMSR to the IA32_TSC_DEADLINE MSR the desired deadline."

    x2APIC:
     "To allow for efficient access to the APIC registers in x2APIC mode,
      the serializing semantics of WRMSR are relaxed when writing to the
      APIC registers. Thus, system software should not use 'WRMSR to APIC
      registers in x2APIC mode' as a serializing instruction. Read and write
      accesses to the APIC registers will occur in program order. A WRMSR to
      an APIC register may complete before all preceding stores are globally
      visible; software can prevent this by inserting a serializing
      instruction, an SFENCE, or an MFENCE before the WRMSR."

    The xAPIC method is to just wait for the memory mapped write to hit
    the LVTT by checking whether the MSR write has reached the hardware.
    There is no reason why a proper MFENCE after the memory mapped write would
    not do the same. Andi Kleen confirmed that MFENCE is sufficient for the
    xAPIC case as well.

    Issue MFENCE before writing to the TSC_DEADLINE MSR. This can be done
    unconditionally as all CPUs which have TSC_DEADLINE also have MFENCE
    support.

    [ tglx: Massaged the changelog ]

    Signed-off-by: Shaohua Li <shli@fb.com>
    Reviewed-by: Ingo Molnar <mingo@kernel.org>
    Cc: <Kernel-team@fb.com>
    Cc: <lenb@kernel.org>
    Cc: <fenghua.yu@intel.com>
    Cc: Andi Kleen <ak@linux.intel.com>
    Cc: H. Peter Anvin <hpa@zytor.com>
    Cc: stable@vger.kernel.org #v3.7+
    Link: http://lkml.kernel.org/r/20150909041352.GA2059853@devbig257.prn2.facebook.com
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 6848085e78fb3e5849646f3fe4ce1b95cc73cfb1
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date:   Mon Sep 28 18:57:03 2015 +0300

    dmaengine: dw: properly read DWC_PARAMS register

    [ Upstream commit 6bea0f6d1c47b07be88dfd93f013ae05fcb3d8bf ]

    In case we have less than maximum allowed channels (8) and autoconfiguration is
    enabled the DWC_PARAMS read is wrong because it uses different arithmetic to
    what is needed for channel priority setup.

    Re-do the caclulations properly. This now works on AVR32 board well.

    Fixes: fed2574b3c9f (dw_dmac: introduce software emulation of LLP transfers)
    Cc: yitian.bu@tangramtek.com
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Signed-off-by: Vinod Koul <vinod.koul@intel.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit cf9499e2cbf0a0f082a48639e2ec75f5c1fb0ea8
Author: Felipe F. Tonello <eu@felipetonello.com>
Date:   Wed Sep 16 18:40:32 2015 +0100

    ARM: dts: fix usb pin control for imx-rex dts

    [ Upstream commit 0af822110871400908d5b6f83a8908c45f881d8f ]

    This fixes a duplicated pin control causing this error:

    imx6q-pinctrl 20e0000.iomuxc: pin MX6Q_PAD_GPIO_1 already
    requested by regulators:regulator@2; cannot claim for 2184000.usb
    imx6q-pinctrl 20e0000.iomuxc: pin-137 (2184000.usb) status -22
    imx6q-pinctrl 20e0000.iomuxc: could not request pin 137
    (MX6Q_PAD_GPIO_1) from group usbotggrp  on device 20e0000.iomuxc
    imx_usb 2184000.usb: Error applying setting, reverse things
    back
    imx6q-pinctrl 20e0000.iomuxc: pin MX6Q_PAD_EIM_D31 already
    requested by regulators:regulator@1; cannot claim for 2184200.usb
    imx6q-pinctrl 20e0000.iomuxc: pin-52 (2184200.usb) status -22
    imx6q-pinctrl 20e0000.iomuxc: could not request pin 52 (MX6Q_PAD_EIM_D31)
    from group usbh1grp  on device 20e0000.iomuxc
    imx_usb 2184200.usb: Error applying setting, reverse things
    back

    Signed-off-by: Felipe F. Tonello <eu@felipetonello.com>
    Fixes: e2047e33f2bd ("ARM: dts: add initial Rex Pro board support")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 0c873b18c057d82d7ae10fc3b7a0b6cee5258927
Author: Carl Frederik Werner <frederik@cfbw.eu>
Date:   Wed Sep 2 10:07:57 2015 +0900

    ARM: dts: omap3-beagle: make i2c3, ddc and tfp410 gpio work again

    [ Upstream commit 3a2fa775bd1d0579113666c1a2e37654a34018a0 ]

    Let's fix pinmux address of gpio 170 used by tfp410 powerdown-gpio.

    According to the OMAP35x Technical Reference Manual
      CONTROL_PADCONF_I2C3_SDA[15:0]  0x480021C4 mode0: i2c3_sda
      CONTROL_PADCONF_I2C3_SDA[31:16] 0x480021C4 mode4: gpio_170
    the pinmux address of gpio 170 must be 0x480021C6.

    The former wrong address broke i2c3 (used by hdmi ddc), resulting in
    kernel message:
      omap_i2c 48060000.i2c: controller timed out

    Fixes: 8cecf52befd7 ("ARM: omap3-beagle.dts: add display information")
    Cc: stable@vger.kernel.org # v3.15+
    Signed-off-by: Carl Frederik Werner <frederik@cfbw.eu>
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 11fdbfcd5ecbc2be8f0ee8e4f937f04edd943adf
Author: Grazvydas Ignotas <notasas@gmail.com>
Date:   Wed Sep 16 01:34:31 2015 +0300

    ARM: dts: omap5-uevm.dts: fix i2c5 pinctrl offsets

    [ Upstream commit 1dbdad75074d16c3e3005180f81a01cdc04a7872 ]

    The i2c5 pinctrl offsets are wrong. If the bootloader doesn't set the
    pins up, communication with tca6424a doesn't work (controller timeouts)
    and it is not possible to enable HDMI.

    Fixes: 9be495c42609 ("ARM: dts: omap5-evm: Add I2c pinctrl data")
    Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 583d530162e8569818c1019b1e8666cc24b9f210
Author: Paul Bolle <pebolle@tiscali.nl>
Date:   Fri Jul 31 14:08:58 2015 +0200

    windfarm: decrement client count when unregistering

    [ Upstream commit fe2b592173ff0274e70dc44d1d28c19bb995aa7c ]

    wf_unregister_client() increments the client count when a client
    unregisters. That is obviously incorrect. Decrement that client count
    instead.

    Fixes: 75722d3992f5 ("[PATCH] ppc64: Thermal control for SMU based machines")

    Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 0d665fe30603081abe412f630153b746e99a90a4
Author: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Date:   Thu Sep 3 13:24:40 2015 +0100

    ARM: 8429/1: disable GCC SRA optimization

    [ Upstream commit a077224fd35b2f7fbc93f14cf67074fc792fbac2 ]

    While working on the 32-bit ARM port of UEFI, I noticed a strange
    corruption in the kernel log. The following snprintf() statement
    (in drivers/firmware/efi/efi.c:efi_md_typeattr_format())

            snprintf(pos, size, "|%3s|%2s|%2s|%2s|%3s|%2s|%2s|%2s|%2s]",

    was producing the following output in the log:

            |    |   |   |   |    |WB|WT|WC|UC]
            |    |   |   |   |    |WB|WT|WC|UC]
            |    |   |   |   |    |WB|WT|WC|UC]
            |RUN|   |   |   |    |WB|WT|WC|UC]*
            |RUN|   |   |   |    |WB|WT|WC|UC]*
            |    |   |   |   |    |WB|WT|WC|UC]
            |RUN|   |   |   |    |WB|WT|WC|UC]*
            |    |   |   |   |    |WB|WT|WC|UC]
            |RUN|   |   |   |    |   |   |   |UC]
            |RUN|   |   |   |    |   |   |   |UC]

    As it turns out, this is caused by incorrect code being emitted for
    the string() function in lib/vsprintf.c. The following code

            if (!(spec.flags & LEFT)) {
                    while (len < spec.field_width--) {
                            if (buf < end)
                                    *buf = ' ';
                            ++buf;
                    }
            }
            for (i = 0; i < len; ++i) {
                    if (buf < end)
                            *buf = *s;
                    ++buf; ++s;
            }
            while (len < spec.field_width--) {
                    if (buf < end)
                            *buf = ' ';
                    ++buf;
            }

    when called with len == 0, triggers an issue in the GCC SRA optimization
    pass (Scalar Replacement of Aggregates), which handles promotion of signed
    struct members incorrectly. This is a known but as yet unresolved issue.
    (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65932). In this particular
    case, it is causing the second while loop to be executed erroneously a
    single time, causing the additional space characters to be printed.

    So disable the optimization by passing -fno-ipa-sra.

    Cc: <stable@vger.kernel.org>
    Acked-by: Nicolas Pitre <nico@linaro.org>
    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 56e1daf66f9ff64b5782a4fa796ab435f862b126
Author: Russell King <rmk+kernel@arm.linux.org.uk>
Date:   Fri Sep 11 16:44:02 2015 +0100

    ARM: fix Thumb2 signal handling when ARMv6 is enabled

    [ Upstream commit 9b55613f42e8d40d5c9ccb8970bde6af4764b2ab ]

    When a kernel is built covering ARMv6 to ARMv7, we omit to clear the
    IT state when entering a signal handler.  This can cause the first
    few instructions to be conditionally executed depending on the parent
    context.

    In any case, the original test for >= ARMv7 is broken - ARMv6 can have
    Thumb-2 support as well, and an ARMv6T2 specific build would omit this
    code too.

    Relax the test back to ARMv6 or greater.  This results in us always
    clearing the IT state bits in the PSR, even on CPUs where these bits
    are reserved.  However, they're reserved for the IT state, so this
    should cause no harm.

    Cc: <stable@vger.kernel.org>
    Fixes: d71e1352e240 ("Clear the IT state when invoking a Thumb-2 signal handler")
    Acked-by: Tony Lindgren <tony@atomide.com>
    Tested-by: H. Nikolaus Schaller <hns@goldelico.com>
    Tested-by: Grazvydas Ignotas <notasas@gmail.com>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 494b66391df00c3261cbf0a5fc24a21da97760c2
Author: Guenter Roeck <linux@roeck-us.net>
Date:   Mon Aug 31 16:13:47 2015 -0700

    hwmon: (nct6775) Swap STEP_UP_TIME and STEP_DOWN_TIME registers for most chips

    [ Upstream commit 728d29400488d54974d3317fe8a232b45fdb42ee ]

    The STEP_UP_TIME and STEP_DOWN_TIME registers are swapped for all chips but
    NCT6775.

    Reported-by: Grazvydas Ignotas <notasas@gmail.com>
    Reviewed-by: Jean Delvare <jdelvare@suse.de>
    Cc: stable@vger.kernel.org # v3.10+
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 19241b13ba1964e3bce3ee7e1944bbf5d193c45f
Author: Dominik Dingel <dingel@linux.vnet.ibm.com>
Date:   Fri Sep 18 11:27:45 2015 +0200

    sched: access local runqueue directly in single_task_running

    [ Upstream commit 00cc1633816de8c95f337608a1ea64e228faf771 ]

    Commit 2ee507c47293 ("sched: Add function single_task_running to let a task
    check if it is the only task running on a cpu") referenced the current
    runqueue with the smp_processor_id.  When CONFIG_DEBUG_PREEMPT is enabled,
    that is only allowed if preemption is disabled or the currrent task is
    bound to the local cpu (e.g. kernel worker).

    With commit f78195129963 ("kvm: add halt_poll_ns module parameter") KVM
    calls single_task_running. If CONFIG_DEBUG_PREEMPT is enabled that
    generates a lot of kernel messages.

    To avoid adding preemption in that cases, as it would limit the usefulness,
    we change single_task_running to access directly the cpu local runqueue.

    Cc: Tim Chen <tim.c.chen@linux.intel.com>
    Suggested-by: Peter Zijlstra <peterz@infradead.org>
    Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Cc: <stable@vger.kernel.org>
    Fixes: 2ee507c472939db4b146d545352b8a7c79ef47f8
    Signed-off-by: Dominik Dingel <dingel@linux.vnet.ibm.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 91c16bc6d9d5195821a0d3a2c6a95855a1788e28
Author: Francesco Lavra <francescolavra.fl@gmail.com>
Date:   Sat Jul 25 08:25:18 2015 +0200

    watchdog: sunxi: fix activation of system reset

    [ Upstream commit 0919e4445190da18496d31aac08b90828a47d45f ]

    Commit f2147de33470 ("watchdog: sunxi: support parameterized compatible
    strings") introduced a regression in sunxi_wdt_start(), by which
    the system reset function of the watchdog is not enabled upon
    starting the watchdog. As a result, the system is not reset when the
    watchdog expires. Fix it.

    Fixes: f2147de33470 ("watchdog: sunxi: support parameterized compatible strings")
    Signed-off-by: Francesco Lavra <francescolavra.fl@gmail.com>
    Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
    Reviewed-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
    Cc: stable@vger.kernel.org
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 2e1e6fe49ec9c433da336f7234cb3432628d6414
Author: Arnaldo Carvalho de Melo <acme@redhat.com>
Date:   Fri Sep 11 12:36:12 2015 -0300

    perf header: Fixup reading of HEADER_NRCPUS feature

    [ Upstream commit caa470475d9b59eeff093ae650800d34612c4379 ]

    The original patch introducing this header wrote the number of CPUs available
    and online in one order and then swapped those values when reading, fix it.

    Before:

      # perf record usleep 1
      # perf report --header-only | grep 'nrcpus \(online\|avail\)'
      # nrcpus online : 4
      # nrcpus avail : 4
      # echo 0 > /sys/devices/system/cpu/cpu2/online
      # perf record usleep 1
      # perf report --header-only | grep 'nrcpus \(online\|avail\)'
      # nrcpus online : 4
      # nrcpus avail : 3
      # echo 0 > /sys/devices/system/cpu/cpu1/online
      # perf record usleep 1
      # perf report --header-only | grep 'nrcpus \(online\|avail\)'
      # nrcpus online : 4
      # nrcpus avail : 2

    After the fix, bringing back the CPUs online:

      # perf report --header-only | grep 'nrcpus \(online\|avail\)'
      # nrcpus online : 2
      # nrcpus avail : 4
      # echo 1 > /sys/devices/system/cpu/cpu2/online
      # perf record usleep 1
      # perf report --header-only | grep 'nrcpus \(online\|avail\)'
      # nrcpus online : 3
      # nrcpus avail : 4
      # echo 1 > /sys/devices/system/cpu/cpu1/online
      # perf record usleep 1
      # perf report --header-only | grep 'nrcpus \(online\|avail\)'
      # nrcpus online : 4
      # nrcpus avail : 4

    Acked-by: Namhyung Kim <namhyung@kernel.org>
    Cc: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Borislav Petkov <bp@suse.de>
    Cc: David Ahern <dsahern@gmail.com>
    Cc: Frederic Weisbecker <fweisbec@gmail.com>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Kan Liang <kan.liang@intel.com>
    Cc: Stephane Eranian <eranian@google.com>
    Cc: Wang Nan <wangnan0@huawei.com>
    Fixes: fbe96f29ce4b ("perf tools: Make perf.data more self-descriptive (v8)")
    Link: http://lkml.kernel.org/r/20150911153323.GP23511@kernel.org
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit cea6abba6d7ffdcfe210ed65612ebc914fffdcfd
Author: Kan Liang <kan.liang@intel.com>
Date:   Thu Jul 2 03:08:43 2015 -0400

    perf stat: Get correct cpu id for print_aggr

    [ Upstream commit 601083cffb7cabdcc55b8195d732f0f7028570fa ]

    print_aggr() fails to print per-core/per-socket statistics after commit
    582ec0829b3d ("perf stat: Fix per-socket output bug for uncore events")
    if events have differnt cpus. Because in print_aggr(), aggr_get_id needs
    index (not cpu id) to find core/pkg id. Also, evsel cpu maps should be
    used to get aggregated id.

    Here is an example:

    Counting events cycles,uncore_imc_0/cas_count_read/. (Uncore event has
    cpumask 0,18)

      $ perf stat -e cycles,uncore_imc_0/cas_count_read/ -C0,18 --per-core sleep 2

    Without this patch, it failes to get CPU 18 result.

       Performance counter stats for 'CPU(s) 0,18':

      S0-C0           1            7526851      cycles
      S0-C0           1               1.05 MiB  uncore_imc_0/cas_count_read/
      S1-C0           0      <not counted>      cycles
      S1-C0           0      <not counted> MiB  uncore_imc_0/cas_count_read/

    With this patch, it can get both CPU0 and CPU18 result.

       Performance counter stats for 'CPU(s) 0,18':

      S0-C0           1            6327768      cycles
      S0-C0           1               0.47 MiB  uncore_imc_0/cas_count_read/
      S1-C0           1             330228      cycles
      S1-C0           1               0.29 MiB  uncore_imc_0/cas_count_read/

    Signed-off-by: Kan Liang <kan.liang@intel.com>
    Acked-by: Jiri Olsa <jolsa@kernel.org>
    Acked-by: Stephane Eranian <eranian@google.com>
    Cc: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Andi Kleen <ak@linux.intel.com>
    Cc: David Ahern <dsahern@gmail.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Fixes: 582ec0829b3d ("perf stat: Fix per-socket output bug for uncore events")
    Link: http://lkml.kernel.org/r/1435820925-51091-1-git-send-email-kan.liang@intel.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 9b81b4499a1a6bec228f622822d6fe95e45aca29
Author: Arnaldo Carvalho de Melo <acme@redhat.com>
Date:   Mon Aug 10 16:53:54 2015 -0300

    perf report: Add support for srcfile sort key

    [ Upstream commit 31191a85fb875cf123cea56bbfd34f4b941f3c79 ]

    In some cases it's useful to characterize samples by file. This is
    useful to get a higher level categorization, for example to map cost to
    subsystems.

    Add a srcfile sort key to perf report. It builds on top of the existing
    srcline support.

    Commiter notes:

    E.g.:

      # perf record -F 10000 usleep 1
      [ perf record: Woken up 1 times to write data ]
      [ perf record: Captured and wrote 0.016 MB perf.data (13 samples) ]
      [root@zoo ~]# perf report -s srcfile --stdio
      # Total Lost Samples: 0
      #
      # Samples: 13  of event 'cycles'
      # Event count (approx.): 869878
      #
      # Overhead  Source File
      # ........  ...........
          60.99%  .
          20.62%  paravirt.h
          14.23%  rmap.c
           4.04%  signal.c
           0.11%  msr.h

      #

    The first line is collecting all the files for which srcfiles couldn't somehow
    get resolved to:

      # perf report -s srcfile,dso --stdio
      # Total Lost Samples: 0
      #
      # Samples: 13  of event 'cycles'
      # Event count (approx.): 869878
      #
      # Overhead  Source File  Shared Object
      # ........  ...........  ................
          40.97%  .            ld-2.20.so
          20.62%  paravirt.h   [kernel.vmlinux]
          20.02%  .            libc-2.20.so
          14.23%  rmap.c       [kernel.vmlinux]
           4.04%  signal.c     [kernel.vmlinux]
           0.11%  msr.h        [kernel.vmlinux]

      #

    XXX: Investigate why that is not resolving on Fedora 21, Andi says he hasn't
         seen this on Fedora 22.

    Signed-off-by: Andi Kleen <ak@linux.intel.com>
    Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Link: http://lkml.kernel.org/r/1438988064-21834-1-git-send-email-andi@firstfloor.org
    [ Added column length update, from 0e65bdb3f90f ('perf hists: Update the column width for the "srcline" sort key') ]
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>

    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit ec50d9d6b275078f709a6192809e1ba42722335b
Author: Adrian Hunter <adrian.hunter@intel.com>
Date:   Thu Sep 24 13:05:22 2015 +0300

    perf tools: Fix copying of /proc/kcore

    [ Upstream commit b5cabbcbd157a4bf5a92dfc85134999a3b55342d ]

    A copy of /proc/kcore containing the kernel text can be made to the
    buildid cache. e.g.

            perf buildid-cache -v -k /proc/kcore

    To workaround objdump limitations, a copy is also made when annotating
    against /proc/kcore.

    The copying process stops working from libelf about v1.62 onwards (the
    problem was found with v1.63).

    The cause is that a call to gelf_getphdr() in kcore__add_phdr() fails
    because additional validation has been added to gelf_getphdr().

    The use of gelf_getphdr() is a misguided attempt to get default
    initialization of the Gelf_Phdr structure.  That should not be
    necessary because every member of the Gelf_Phdr structure is
    subsequently assigned.  So just remove the call to gelf_getphdr().

    Similarly, a call to gelf_getehdr() in gelf_kcore__init() can be
    removed also.

    Committer notes:

    Note to stable@kernel.org, from Adrian in the cover letter for this
    patchkit:

    The "Fix copying of /proc/kcore" problem goes back to v3.13 if you think
    it is important enough for stable.

    Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Cc: stable@kernel.org
    Link: http://lkml.kernel.org/r/1443089122-19082-3-git-send-email-adrian.hunter@intel.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 722554c1a2811ca703dc9e5d7afa029b5b19f4da
Author: Jenny Derzhavetz <jennyf@mellanox.com>
Date:   Sun Sep 6 14:52:20 2015 +0300

    iser-target: remove command with state ISTATE_REMOVE

    [ Upstream commit a4c15cd957cbd728f685645de7a150df5912591a ]

    As documented in iscsit_sequence_cmd:
    /*
     * Existing callers for iscsit_sequence_cmd() will silently
     * ignore commands with CMDSN_LOWER_THAN_EXP, so force this
     * return for CMDSN_MAXCMDSN_OVERRUN as well..
     */

    We need to silently finish a command when it's in ISTATE_REMOVE.
    This fixes an teardown hang we were seeing where a mis-behaved
    initiator (triggered by allocation error injections) sent us a
    cmdsn which was lower than expected.

    Signed-off-by: Jenny Derzhavetz <jennyf@mellanox.com>
    Signed-off-by: Sagi Grimberg <sagig@mellanox.com>
    Cc: <stable@vger.kernel.org> # v3.10+
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 642f48476545bf45bde2047c7bd79ce0ddf121e0
Author: Michal Hocko <mhocko@suse.com>
Date:   Thu Aug 27 20:16:37 2015 +0200

    scsi: fix scsi_error_handler vs. scsi_host_dev_release race

    [ Upstream commit 537b604c8b3aa8b96fe35f87dd085816552e294c ]

    b9d5c6b7ef57 ("[SCSI] cleanup setting task state in
    scsi_error_handler()") has introduced a race between scsi_error_handler
    and scsi_host_dev_release resulting in the hang when the device goes
    away because scsi_error_handler might miss a wake up:

    CPU0                                    CPU1
    scsi_error_handler                      scsi_host_dev_release
                                              kthread_stop()
      kthread_should_stop()
        test_bit(KTHREAD_SHOULD_STOP)
                                                set_bit(KTHREAD_SHOULD_STOP)
                                                wake_up_process()
                                                wait_for_completion()

      set_current_state(TASK_INTERRUPTIBLE)
      schedule()

    The most straightforward solution seems to be to invert the ordering of
    the set_current_state and kthread_should_stop.

    The issue has been noticed during reboot test on a 3.0 based kernel but
    the current code seems to be affected in the same way.

    [jejb: additional comment added]
    Cc: <stable@vger.kernel.org> # 3.6+
    Reported-and-debugged-by: Mike Mayer <Mike.Meyer@teradata.com>
    Signed-off-by: Michal Hocko <mhocko@suse.com>
    Reviewed-by: Dan Williams <dan.j.williams@intel.com>
    Reviewed-by: Hannes Reinecke <hare@suse.de>
    Signed-off-by: James Bottomley <JBottomley@Odin.com>

    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit c8259f6224297e938da2023bed712f54a6876541
Author: Andy Grover <agrover@redhat.com>
Date:   Mon Aug 24 10:26:03 2015 -0700

    target/iscsi: Fix np_ip bracket issue by removing np_ip

    [ Upstream commit 76c28f1fcfeb42b47f798fe498351ee1d60086ae ]

    Revert commit 1997e6259, which causes double brackets on ipv6
    inaddr_any addresses.

    Since we have np_sockaddr, if we need a textual representation we can
    use "%pISc".

    Change iscsit_add_network_portal() and iscsit_add_np() signatures to remove
    *ip_str parameter.

    Fix and extend some comments earlier in the function.

    Tested to work for :: and ::1 via iscsiadm, previously :: failed, see
    https://bugzilla.redhat.com/show_bug.cgi?id=1249107 .

    CC: stable@vger.kernel.org
    Signed-off-by: Andy Grover <agrover@redhat.com>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 4c42a394e4158f92fa24867f52c18f0c196bbfb9
Author: John Stultz <john.stultz@linaro.org>
Date:   Wed Sep 9 16:07:30 2015 -0700

    time: Fix timekeeping_freqadjust()'s incorrect use of abs() instead of abs64()

    [ Upstream commit 2619d7e9c92d524cb155ec89fd72875321512e5b ]

    The internal clocksteering done for fine-grained error
    correction uses a logarithmic approximation, so any time
    adjtimex() adjusts the clock steering, timekeeping_freqadjust()
    quickly approximates the correct clock frequency over a series
    of ticks.

    Unfortunately, the logic in timekeeping_freqadjust(), introduced
    in commit:

      dc491596f639 ("timekeeping: Rework frequency adjustments to work better w/ nohz")

    used the abs() function with a s64 error value to calculate the
    size of the approximated adjustment to be made.

    Per include/linux/kernel.h:

      "abs() should not be used for 64-bit types (s64, u64, long long) - use abs64()".

    Thus on 32-bit platforms, this resulted in the clocksteering to
    take a quite dampended random walk trying to converge on the
    proper frequency, which caused the adjustments to be made much
    slower then intended (most easily observed when large
    adjustments are made).

    This patch fixes the issue by using abs64() instead.

    Reported-by: Nuno Gonçalves <nunojpg@gmail.com>
    Tested-by: Nuno Goncalves <nunojpg@gmail.com>
    Signed-off-by: John Stultz <john.stultz@linaro.org>
    Cc: <stable@vger.kernel.org> # v3.17+
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Miroslav Lichvar <mlichvar@redhat.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Prarit Bhargava <prarit@redhat.com>
    Cc: Richard Cochran <richardcochran@gmail.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Link: http://lkml.kernel.org/r/1441840051-20244-1-git-send-email-john.stultz@linaro.org
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 1d2c99928fed10d937e9a7956a1d7a44dbd4196b
Author: Jason Wang <jasowang@redhat.com>
Date:   Tue Sep 15 14:41:56 2015 +0800

    kvm: fix double free for fast mmio eventfd

    [ Upstream commit eefd6b06b17c5478e7c24bea6f64beaa2c431ca6 ]

    We register wildcard mmio eventfd on two buses, once for KVM_MMIO_BUS
    and once on KVM_FAST_MMIO_BUS but with a single iodev
    instance. This will lead to an issue: kvm_io_bus_destroy() knows
    nothing about the devices on two buses pointing to a single dev. Which
    will lead to double free[1] during exit. Fix this by allocating two
    instances of iodevs then registering one on KVM_MMIO_BUS and another
    on KVM_FAST_MMIO_BUS.

    CPU: 1 PID: 2894 Comm: qemu-system-x86 Not tainted 3.19.0-26-generic #28-Ubuntu
    Hardware name: LENOVO 2356BG6/2356BG6, BIOS G7ET96WW (2.56 ) 09/12/2013
    task: ffff88009ae0c4b0 ti: ffff88020e7f0000 task.ti: ffff88020e7f0000
    RIP: 0010:[<ffffffffc07e25d8>]  [<ffffffffc07e25d8>] ioeventfd_release+0x28/0x60 [kvm]
    RSP: 0018:ffff88020e7f3bc8  EFLAGS: 00010292
    RAX: dead000000200200 RBX: ffff8801ec19c900 RCX: 000000018200016d
    RDX: ffff8801ec19cf80 RSI: ffffea0008bf1d40 RDI: ffff8801ec19c900
    RBP: ffff88020e7f3bd8 R08: 000000002fc75a01 R09: 000000018200016d
    R10: ffffffffc07df6ae R11: ffff88022fc75a98 R12: ffff88021e7cc000
    R13: ffff88021e7cca48 R14: ffff88021e7cca50 R15: ffff8801ec19c880
    FS:  00007fc1ee3e6700(0000) GS:ffff88023e240000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00007f8f389d8000 CR3: 000000023dc13000 CR4: 00000000001427e0
    Stack:
    ffff88021e7cc000 0000000000000000 ffff88020e7f3be8 ffffffffc07e2622
    ffff88020e7f3c38 ffffffffc07df69a ffff880232524160 ffff88020e792d80
     0000000000000000 ffff880219b78c00 0000000000000008 ffff8802321686a8
    Call Trace:
    [<ffffffffc07e2622>] ioeventfd_destructor+0x12/0x20 [kvm]
    [<ffffffffc07df69a>] kvm_put_kvm+0xca/0x210 [kvm]
    [<ffffffffc07df818>] kvm_vcpu_release+0x18/0x20 [kvm]
    [<ffffffff811f69f7>] __fput+0xe7/0x250
    [<ffffffff811f6bae>] ____fput+0xe/0x10
    [<ffffffff81093f04>] task_work_run+0xd4/0xf0
    [<ffffffff81079358>] do_exit+0x368/0xa50
    [<ffffffff81082c8f>] ? recalc_sigpending+0x1f/0x60
    [<ffffffff81079ad5>] do_group_exit+0x45/0xb0
    [<ffffffff81085c71>] get_signal+0x291/0x750
    [<ffffffff810144d8>] do_signal+0x28/0xab0
    [<ffffffff810f3a3b>] ? do_futex+0xdb/0x5d0
    [<ffffffff810b7028>] ? __wake_up_locked_key+0x18/0x20
    [<ffffffff810f3fa6>] ? SyS_futex+0x76/0x170
    [<ffffffff81014fc9>] do_notify_resume+0x69/0xb0
    [<ffffffff817cb9af>] int_signal+0x12/0x17
    Code: 5d c3 90 0f 1f 44 00 00 55 48 89 e5 53 48 89 fb 48 83 ec 08 48 8b 7f 20 e8 06 d6 a5 c0 48 8b 43 08 48 8b 13 48 89 df 48 89 42 08 <48> 89 10 48 b8 00 01 10 00 00
     RIP  [<ffffffffc07e25d8>] ioeventfd_release+0x28/0x60 [kvm]
     RSP <ffff88020e7f3bc8>

    Cc: stable@vger.kernel.org
    Cc: Gleb Natapov <gleb@kernel.org>
    Cc: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Jason Wang <jasowang@redhat.com>
    Reviewed-by: Cornelia Huck <cornelia.huck@de.ibm.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit e26876a7c059fc01dc32f7625e27c8e92b11ac02
Author: Jason Wang <jasowang@redhat.com>
Date:   Tue Sep 15 14:41:55 2015 +0800

    kvm: factor out core eventfd assign/deassign logic

    [ Upstream commit 85da11ca587c8eb73993a1b503052391a73586f9 ]

    This patch factors out core eventfd assign/deassign logic and leaves
    the argument checking and bus index selection to callers.

    Cc: stable@vger.kernel.org
    Cc: Gleb Natapov <gleb@kernel.org>
    Cc: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Jason Wang <jasowang@redhat.com>
    Reviewed-by: Cornelia Huck <cornelia.huck@de.ibm.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit a5211987ae02a92988717ebbb39191ceb4d8269e
Author: Jason Wang <jasowang@redhat.com>
Date:   Tue Sep 15 14:41:57 2015 +0800

    kvm: fix zero length mmio searching

    [ Upstream commit 8f4216c7d28976f7ec1b2bcbfa0a9f787133c45e ]

    Currently, if we had a zero length mmio eventfd assigned on
    KVM_MMIO_BUS. It will never be found by kvm_io_bus_cmp() since it
    always compares the kvm_io_range() with the length that guest
    wrote. This will cause e.g for vhost, kick will be trapped by qemu
    userspace instead of vhost. Fixing this by using zero length if an
    iodevice is zero length.

    Cc: stable@vger.kernel.org
    Cc: Gleb Natapov <gleb@kernel.org>
    Cc: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Jason Wang <jasowang@redhat.com>
    Reviewed-by: Cornelia Huck <cornelia.huck@de.ibm.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 50c79062c4b65ec170f1ce21453fae743a7f25cd
Author: Jason Wang <jasowang@redhat.com>
Date:   Tue Sep 15 14:41:54 2015 +0800

    kvm: don't try to register to KVM_FAST_MMIO_BUS for non mmio eventfd

    [ Upstream commit 8453fecbecae26edb3f278627376caab05d9a88d ]

    We only want zero length mmio eventfd to be registered on
    KVM_FAST_MMIO_BUS. So check this explicitly when arg->len is zero to
    make sure this.

    Cc: stable@vger.kernel.org
    Cc: Gleb Natapov <gleb@kernel.org>
    Cc: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Jason Wang <jasowang@redhat.com>
    Reviewed-by: Cornelia Huck <cornelia.huck@de.ibm.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 4dd2671da85b129bc287c26f6d9e56bf7af1b2ff
Author: Marek Majtyka <marek.majtyka@tieto.com>
Date:   Wed Sep 16 12:04:55 2015 +0200

    arm: KVM: Fix incorrect device to IPA mapping

    [ Upstream commit ca09f02f122b2ecb0f5ddfc5fd47b29ed657d4fd ]

    A critical bug has been found in device memory stage1 translation for
    VMs with more then 4GB of address space. Once vm_pgoff size is smaller
    then pa (which is true for LPAE case, u32 and u64 respectively) some
    more significant bits of pa may be lost as a shift operation is performed
    on u32 and later cast onto u64.

    Example: vm_pgoff(u32)=0x00210030, PAGE_SHIFT=12
            expected pa(u64):   0x0000002010030000
            produced pa(u64):   0x0000000010030000

    The fix is to change the order of operations (casting first onto phys_addr_t
    and then shifting).

    Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
    [maz: fixed changelog and patch formatting]
    Cc: stable@vger.kernel.org
    Signed-off-by: Marek Majtyka <marek.majtyka@tieto.com>
    Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>

    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit a7fd9e578e016ff5cf597fb7dfdc08bd9d260693
Author: Kyle Evans <kvans32@gmail.com>
Date:   Fri Sep 11 10:40:17 2015 -0500

    hp-wmi: limit hotkey enable

    [ Upstream commit 8a1513b49321e503fd6c8b6793e3b1f9a8a3285b ]

    Do not write initialize magic on systems that do not have
    feature query 0xb. Fixes Bug #82451.

    Redefine FEATURE_QUERY to align with 0xb and FEATURE2 with 0xd
    for code clearity.

    Add a new test function, hp_wmi_bios_2008_later() & simplify
    hp_wmi_bios_2009_later(), which fixes a bug in cases where
    an improper value is returned. Probably also fixes Bug #69131.

    Add missing __init tag.

    Signed-off-by: Kyle Evans <kvans32@gmail.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Darren Hart <dvhart@linux.intel.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit a7e5b4e81bcdae0297594ab5917e40d5ce19fe36
Author: Luis Henriques <luis.henriques@canonical.com>
Date:   Thu Sep 17 16:01:40 2015 -0700

    zram: fix possible use after free in zcomp_create()

    [ Upstream commit 3aaf14da807a4e9931a37f21e4251abb8a67021b ]

    zcomp_create() verifies the success of zcomp_strm_{multi,single}_create()
    through comp->stream, which can potentially be pointing to memory that
    was freed if these functions returned an error.

    While at it, replace a 'ERR_PTR(-ENOMEM)' by a more generic
    'ERR_PTR(error)' as in the future zcomp_strm_{multi,siggle}_create()
    could return other error codes.  Function documentation updated
    accordingly.

    Fixes: beca3ec71fe5 ("zram: add multi stream functionality")
    Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
    Acked-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
    Acked-by: Minchan Kim <minchan@kernel.org>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit ae92f497561a09952ac913488f5844a61287d516
Author: Stas Sergeev <stsp@list.ru>
Date:   Mon Jul 20 17:49:57 2015 -0700

    of_mdio: add new DT property 'managed' to specify the PHY management type

    [ Upstream commit 4cba5c2103657d43d0886e4cff8004d95a3d0def ]

    Currently the PHY management type is selected by the MAC driver arbitrary.
    The decision is based on the presence of the "fixed-link" node and on a
    will of the driver's authors.
    This caused a regression recently, when mvneta driver suddenly started
    to use the in-band status for auto-negotiation on fixed links.
    It appears the auto-negotiation may not work when expected by the MAC driver.
    Sebastien Rannou explains:
    << Yes, I confirm that my HW does not generate an in-band status. AFAIK, it's
    a PHY that aggregates 4xSGMIIs to 1xQSGMII ; the MAC side of the PHY (with
    inband status) is connected to the switch through QSGMII, and in this context
    we are on the media side of the PHY. >>
    https://lkml.org/lkml/2015/7/10/206

    This patch introduces the new string property 'managed' that allows
    the user to set the management type explicitly.
    The supported values are:
    "auto" - default. Uses either MDIO or nothing, depending on the presence
    of the fixed-link node
    "in-band-status" - use in-band status

    Signed-off-by: Stas Sergeev <stsp@users.sourceforge.net>

    CC: Rob Herring <robh+dt@kernel.org>
    CC: Pawel Moll <pawel.moll@arm.com>
    CC: Mark Rutland <mark.rutland@arm.com>
    CC: Ian Campbell <ijc+devicetree@hellion.org.uk>
    CC: Kumar Gala <galak@codeaurora.org>
    CC: Florian Fainelli <f.fainelli@gmail.com>
    CC: Grant Likely <grant.likely@linaro.org>
    CC: devicetree@vger.kernel.org
    CC: linux-kernel@vger.kernel.org
    CC: netdev@vger.kernel.org
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 8848902935b212be629e02c5b55d5c52119ba45c
Author: Florian Fainelli <f.fainelli@gmail.com>
Date:   Mon Jul 20 17:49:55 2015 -0700

    net: dsa: bcm_sf2: Do not override speed settings

    [ Upstream commit d2eac98f7d1b950b762a7eca05a9ce0ea1d878d2 ]

    The SF2 driver currently overrides speed settings for its port
    configured using a fixed PHY, this is both unnecessary and incorrect,
    because we keep feedback to the hardware parameters that we read from
    the PHY device, which in the case of a fixed PHY cannot possibly change
    speed.

    This is a required change to allow the fixed PHY code to allow
    registering a PHY with a link configured as DOWN by default and avoid
    some sort of circular dependency where we require the link_update
    callback to run to program the hardware, and we then utilize the fixed
    PHY parameters to program the hardware with the same settings.

    Fixes: 246d7f773c13 ("net: dsa: add Broadcom SF2 switch driver")
    Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 25da25549f1d08f135dcde8eeb09480e7fae6756
Author: Eric Dumazet <edumazet@google.com>
Date:   Wed Sep 23 14:00:21 2015 -0700

    tcp: add proper TS val into RST packets

    [ Upstream commit 675ee231d960af2af3606b4480324e26797eb010 ]

    RST packets sent on behalf of TCP connections with TS option (RFC 7323
    TCP timestamps) have incorrect TS val (set to 0), but correct TS ecr.

    A > B: Flags [S], seq 0, win 65535, options [mss 1000,nop,nop,TS val 100
    ecr 0], length 0
    B > A: Flags [S.], seq 2444755794, ack 1, win 28960, options [mss
    1460,nop,nop,TS val 7264344 ecr 100], length 0
    A > B: Flags [.], ack 1, win 65535, options [nop,nop,TS val 110 ecr
    7264344], length 0

    B > A: Flags [R.], seq 1, ack 1, win 28960, options [nop,nop,TS val 0
    ecr 110], length 0

    We need to call skb_mstamp_get() to get proper TS val,
    derived from skb->skb_mstamp

    Note that RFC 1323 was advocating to not send TS option in RST segment,
    but RFC 7323 recommends the opposite :

      Once TSopt has been successfully negotiated, that is both <SYN> and
      <SYN,ACK> contain TSopt, the TSopt MUST be sent in every non-<RST>
      segment for the duration of the connection, and SHOULD be sent in an
      <RST> segment (see Section 5.2 for details)

    Note this RFC recommends to send TS val = 0, but we believe it is
    premature : We do not know if all TCP stacks are properly
    handling the receive side :

       When an <RST> segment is
       received, it MUST NOT be subjected to the PAWS check by verifying an
       acceptable value in SEG.TSval, and information from the Timestamps
       option MUST NOT be used to update connection state information.
       SEG.TSecr MAY be used to provide stricter <RST> acceptance checks.

    In 5 years, if/when all TCP stack are RFC 7323 ready, we might consider
    to decide to send TS val = 0, if it buys something.

    Fixes: 7faee5c0d514 ("tcp: remove TCP_SKB_CB(skb)->when")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Acked-by: Yuchung Cheng <ycheng@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 0d79984cc01bf66e2c4a98673b4c6b3bb9a08f66
Author: Florian Fainelli <f.fainelli@gmail.com>
Date:   Tue Sep 8 20:06:41 2015 -0700

    net: dsa: bcm_sf2: Fix 64-bits register writes

    [ Upstream commit 03679a14739a0d4c14b52ba65a69ff553bfba73b ]

    The macro to write 64-bits quantities to the 32-bits register swapped
    the value and offsets arguments, we want to preserve the ordering of the
    arguments with respect to how writel() is implemented for instance:
    value first, offset/base second.

    Fixes: 246d7f773c13 ("net: dsa: add Broadcom SF2 switch driver")
    Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
    Reviewed-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 21a8f4ec1874e08358b92cbca0263c23c9d72f16
Author: Atsushi Nemoto <nemoto@toshiba-tops.co.jp>
Date:   Wed Sep 2 17:49:29 2015 +0900

    net: eth: altera: fix napi poll_list corruption

    [ Upstream commit 4548a697e4969d695047cebd6d9af5e2f6cc728e ]

    tse_poll() calls __napi_complete() with irq enabled.  This leads napi
    poll_list corruption and may stop all napi drivers working.
    Use napi_complete() instead of __napi_complete().

    Signed-off-by: Atsushi Nemoto <nemoto@toshiba-tops.co.jp>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 5fb432dcb91062176880d21d7249562c2aa75a19
Author: Eric Sandeen <sandeen@redhat.com>
Date:   Sat Aug 15 10:45:06 2015 -0400

    ext4: don't manipulate recovery flag when freezing no-journal fs

    [ Upstream commit c642dc9e1aaed953597e7092d7df329e6234096e ]

    At some point along this sequence of changes:

    f6e63f9 ext4: fold ext4_nojournal_sops into ext4_sops
    bb04457 ext4: support freezing ext2 (nojournal) file systems
    9ca9238 ext4: Use separate super_operations structure for no_journal filesystems

    ext4 started setting needs_recovery on filesystems without journals
    when they are unfrozen.  This makes no sense, and in fact confuses
    blkid to the point where it doesn't recognize the filesystem at all.

    (freeze ext2; unfreeze ext2; run blkid; see no output; run dumpe2fs,
    see needs_recovery set on fs w/ no journal).

    To fix this, don't manipulate the INCOMPAT_RECOVER feature on
    filesystems without journals.

    Reported-by: Stu Mark <smark@datto.com>
    Reviewed-by: Jan Kara <jack@suse.com>
    Signed-off-by: Eric Sandeen <sandeen@redhat.com>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Cc: stable@vger.kernel.org
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit f6efbdbc3a9bb1676d186d805a4e3475018146c1
Author: Daniel Axtens <dja@axtens.net>
Date:   Tue Sep 15 15:04:07 2015 +1000

    cxl: Fix unbalanced pci_dev_get in cxl_probe

    [ Upstream commit 2925c2fdf1e0eb642482f5b30577e9435aaa8edb ]

    Currently the first thing we do in cxl_probe is to grab a reference
    on the pci device. Later on, we call device_register on our adapter.
    In our remove path, we call device_unregister, but we never call
    pci_dev_put. We therefore leak the device every time we do a
    reflash.

    device_register/unregister is sufficient to hold the reference.
    Therefore, drop the call to pci_dev_get.

    Here's why this is safe.
    The proposed cxl_probe(pdev) calls cxl_adapter_init:
        a) init calls cxl_adapter_alloc, which creates a struct cxl,
           conventionally called adapter. This struct contains a
           device entry, adapter->dev.

        b) init calls cxl_configure_adapter, where we set
           adapter->dev.parent = &dev->dev (here dev is the pci dev)

    So at this point, the cxl adapter's device's parent is the PCI
    device that I want to be refcounted properly.

        c) init calls cxl_register_adapter
           *) cxl_register_adapter calls device_register(&adapter->dev)

    So now we're in device_register, where dev is the adapter device, and
    we want to know if the PCI device is safe after we return.

    device_register(&adapter->dev) calls device_initialize() and then
    device_add().

    device_add() does a get_device(). device_add() also explicitly grabs
    the device's parent, and calls get_device() on it:

             parent = get_device(dev->parent);

    So therefore, device_register() takes a lock on the parent PCI dev,
    which is what pci_dev_get() was guarding. pci_dev_get() can therefore
    be safely removed.

    Fixes: f204e0b8cedd ("cxl: Driver code for powernv PCIe based cards for userspace access")
    Cc: stable@vger.kernel.org
    Signed-off-by: Daniel Axtens <dja@axtens.net>
    Acked-by: Ian Munsie <imunsie@au1.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 788e0546bd53f9a9da38b671bc4fb644f14f1efc
Author: Shota Suzuki <suzuki_shota_t3@lab.ntt.co.jp>
Date:   Wed Jul 1 09:25:52 2015 +0900

    igb: Fix oops caused by missing queue pairing

    [ Upstream commit 72ddef0506da852dc82f078f37ced8ef4d74a2bf ]

    When initializing igb driver (e.g. 82576, I350), IGB_FLAG_QUEUE_PAIRS is
    set if adapter->rss_queues exceeds half of max_rss_queues in
    igb_init_queue_configuration().
    On the other hand, IGB_FLAG_QUEUE_PAIRS is not set even if the number of
    queues exceeds half of max_combined in igb_set_channels() when changing
    the number of queues by "ethtool -L".
    In this case, if numvecs is larger than MAX_MSIX_ENTRIES (10), the size
    of adapter->msix_entries[], an overflow can occur in
    igb_set_interrupt_capability(), which in turn leads to an oops.

    Fix this problem as follows:
     - When changing the number of queues by "ethtool -L", set
       IGB_FLAG_QUEUE_PAIRS in the same way as initializing igb driver.
     - When increasing the size of q_vector, reallocate it appropriately.
       (With IGB_FLAG_QUEUE_PAIRS set, the size of q_vector gets larger.)

    Another possible way to fix this problem is to cap the queues at its
    initial number, which is the number of the initial online cpus. But this
    is not the optimal way because we cannot increase queues when another
    cpu becomes online.

    Note that before commit cd14ef54d25b ("igb: Change to use statically
    allocated array for MSIx entries"), this problem did not cause oops
    but just made the number of queues become 1 because of entering msi_only
    mode in igb_set_interrupt_capability().

    Fixes: 907b7835799f ("igb: Add ethtool support to configure number of channels")
    CC: stable <stable@vger.kernel.org>
    Signed-off-by: Shota Suzuki <suzuki_shota_t3@lab.ntt.co.jp>
    Tested-by: Aaron Brown <aaron.f.brown@intel.com>
    Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit d098c085d0ae8dfa8a52f541fd7ba6c2dc69102d
Author: Larry Finger <Larry.Finger@lwfinger.net>
Date:   Wed Jul 8 10:18:50 2015 -0500

    rtlwifi: rtl8821ae: Fix an expression that is always false

    [ Upstream commit 251086f588720277a6f5782020a648ce32c4e00b ]

    In routine _rtl8821ae_set_media_status(), an incorrect mask results in a test
    for AP status to always be false. Similar bugs were fixed in rtl8192cu and
    rtl8192de, but this instance was missed at that time.

    Reported-by: David Binderman <dcb314@hotmail.com>
    Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
    Cc: Stable <stable@vger.kernel.org> [3.18+]
    Cc: David Binderman <dcb314@hotmail.com>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 5cadbe921f575c8cc69907a3ed62541cef571b98
Author: Andy Lutomirski <luto@kernel.org>
Date:   Wed Jul 15 10:29:38 2015 -0700

    x86/nmi/64: Use DF to avoid userspace RSP confusing nested NMI detection

    [ Upstream commit 810bc075f78ff2c221536eb3008eac6a492dba2d ]

    We have a tricky bug in the nested NMI code: if we see RSP
    pointing to the NMI stack on NMI entry from kernel mode, we
    assume that we are executing a nested NMI.

    This isn't quite true.  A malicious userspace program can point
    RSP at the NMI stack, issue SYSCALL, and arrange for an NMI to
    happen while RSP is still pointing at the NMI stack.

    Fix it with a sneaky trick.  Set DF in the region of code that
    the RSP check is intended to detect.  IRET will clear DF
    atomically.

    ( Note: other than paravirt, there's little need for all this
      complexity. We could check RIP instead of RSP. )

    Signed-off-by: Andy Lutomirski <luto@kernel.org>
    Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
    Cc: Borislav Petkov <bp@suse.de>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: stable@vger.kernel.org
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 6acb4e24f7101f011d1ab85ddd2f63fc0f26b2b4
Author: Andy Lutomirski <luto@kernel.org>
Date:   Wed Jul 15 10:29:37 2015 -0700

    x86/nmi/64: Reorder nested NMI checks

    [ Upstream commit a27507ca2d796cfa8d907de31ad730359c8a6d06 ]

    Check the repeat_nmi .. end_repeat_nmi special case first.  The
    next patch will rework the RSP check and, as a side effect, the
    RSP check will no longer detect repeat_nmi .. end_repeat_nmi, so
    we'll need this ordering of the checks.

    Note: this is more subtle than it appears.  The check for
    repeat_nmi .. end_repeat_nmi jumps straight out of the NMI code
    instead of adjusting the "iret" frame to force a repeat.  This
    is necessary, because the code between repeat_nmi and
    end_repeat_nmi sets "NMI executing" and then writes to the
    "iret" frame itself.  If a nested NMI comes in and modifies the
    "iret" frame while repeat_nmi is also modifying it, we'll end up
    with garbage.  The old code got this right, as does the new
    code, but the new code is a bit more explicit.

    If we were to move the check right after the "NMI executing"
    check, then we'd get it wrong and have random crashes.

    ( Because the "NMI executing" check would jump to the code that would
      modify the "iret" frame without checking if the interrupted NMI was
      currently modifying it. )

    Signed-off-by: Andy Lutomirski <luto@kernel.org>
    Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
    Cc: Borislav Petkov <bp@suse.de>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: stable@vger.kernel.org
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit aac26b9c16d68f5b13a606f7100fea119083aa52
Author: Andy Lutomirski <luto@kernel.org>
Date:   Wed Jul 15 10:29:36 2015 -0700

    x86/nmi/64: Improve nested NMI comments

    [ Upstream commit 0b22930ebad563ae97ff3f8d7b9f12060b4c6e6b ]

    I found the nested NMI documentation to be difficult to follow.
    Improve the comments.

    Signed-off-by: Andy Lutomirski <luto@kernel.org>
    Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
    Cc: Borislav Petkov <bp@suse.de>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: stable@vger.kernel.org
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 838d2bbdb0468307fad3d1d5f396f99bc87d0a65
Author: Ivan Vecera <ivecera@redhat.com>
Date:   Thu Aug 6 22:48:23 2015 +0200

    bna: fix interrupts storm caused by erroneous packets

    [ Upstream commit ade4dc3e616e33c80d7e62855fe1b6f9895bc7c3 ]

    The commit "e29aa33 bna: Enable Multi Buffer RX" moved packets counter
    increment from the beginning of the NAPI processing loop after the check
    for erroneous packets so they are never accounted. This counter is used
    to inform firmware about number of processed completions (packets).
    As these packets are never acked the firmware fires IRQs for them again
    and again.

    Fixes: e29aa33 ("bna: Enable Multi Buffer RX")
    Signed-off-by: Ivan Vecera <ivecera@redhat.com>
    Acked-by: Rasesh Mody <rasesh.mody@qlogic.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 3a2c446444593647bdc13d6da6fcabfc99ac7470
Author: Eric Dumazet <edumazet@google.com>
Date:   Sat Aug 1 12:14:33 2015 +0200

    udp: fix dst races with multicast early demux

    [ Upstream commit 10e2eb878f3ca07ac2f05fa5ca5e6c4c9174a27a ]

    Multicast dst are not cached. They carry DST_NOCACHE.

    As mentioned in commit f8864972126899 ("ipv4: fix dst race in
    sk_dst_get()"), these dst need special care before caching them
    into a socket.

    Caching them is allowed only if their refcnt was not 0, ie we
    must use atomic_inc_not_zero()

    Also, we must use READ_ONCE() to fetch sk->sk_rx_dst, as mentioned
    in commit d0c294c53a771 ("tcp: prevent fetching dst twice in early demux
    code")

    Fixes: 421b3885bf6d ("udp: ipv4: Add udp early demux")
    Tested-by: Gregory Hoggarth <Gregory.Hoggarth@alliedtelesis.co.nz>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: Gregory Hoggarth <Gregory.Hoggarth@alliedtelesis.co.nz>
    Reported-by: Alex Gartrell <agartrell@fb.com>
    Cc: Michal Kubeček <mkubecek@suse.cz>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 4320f02c4667d3106fe0c9e308694490a3b51913
Author: Lars Westerhoff <lars.westerhoff@newtec.eu>
Date:   Tue Jul 28 01:32:21 2015 +0300

    packet: missing dev_put() in packet_do_bind()

    [ Upstream commit 158cd4af8dedbda0d612d448c724c715d0dda649 ]

    When binding a PF_PACKET socket, the use count of the bound interface is
    always increased with dev_hold in dev_get_by_{index,name}.  However,
    when rebound with the same protocol and device as in the previous bind
    the use count of the interface was not decreased.  Ultimately, this
    caused the deletion of the interface to fail with the following message:

    unregister_netdevice: waiting for dummy0 to become free. Usage count = 1

    This patch moves the dev_put out of the conditional part that was only
    executed when either the protocol or device changed on a bind.

    Fixes: 902fefb82ef7 ('packet: improve socket create/bind latency in some cases')
    Signed-off-by: Lars Westerhoff <lars.westerhoff@newtec.eu>
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Reviewed-by: Daniel Borkmann <dborkman@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit e6551e40ada2272f7388c7e2d157ef3474ba2c34
Author: Wilson Kok <wkok@cumulusnetworks.com>
Date:   Tue Sep 22 21:40:22 2015 -0700

    fib_rules: fix fib rule dumps across multiple skbs

    [ Upstream commit 41fc014332d91ee90c32840bf161f9685b7fbf2b ]

    dump_rules returns skb length and not error.
    But when family == AF_UNSPEC, the caller of dump_rules
    assumes that it returns an error. Hence, when family == AF_UNSPEC,
    we continue trying to dump on -EMSGSIZE errors resulting in
    incorrect dump idx carried between skbs belonging to the same dump.
    This results in fib rule dump always only dumping rules that fit
    into the first skb.

    This patch fixes dump_rules to return error so that we exit correctly
    and idx is correctly maintained between skbs that are part of the
    same dump.

    Signed-off-by: Wilson Kok <wkok@cumulusnetworks.com>
    Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 8f1cdabcc6ccd7dea59fffc692e122c0b5eaf9f2
Author: Jesse Gross <jesse@nicira.com>
Date:   Mon Sep 21 20:21:20 2015 -0700

    openvswitch: Zero flows on allocation.

    [ Upstream commit ae5f2fb1d51fa128a460bcfbe3c56d7ab8bf6a43 ]

    When support for megaflows was introduced, OVS needed to start
    installing flows with a mask applied to them. Since masking is an
    expensive operation, OVS also had an optimization that would only
    take the parts of the flow keys that were covered by a non-zero
    mask. The values stored in the remaining pieces should not matter
    because they are masked out.

    While this works fine for the purposes of matching (which must always
    look at the mask), serialization to netlink can be problematic. Since
    the flow and the mask are serialized separately, the uninitialized
    portions of the flow can be encoded with whatever values happen to be
    present.

    In terms of functionality, this has little effect since these fields
    will be masked out by definition. However, it leaks kernel memory to
    userspace, which is a potential security vulnerability. It is also
    possible that other code paths could look at the masked key and get
    uninitialized data, although this does not currently appear to be an
    issue in practice.

    This removes the mask optimization for flows that are being installed.
    This was always intended to be the case as the mask optimizations were
    really targetting per-packet flow operations.

    Fixes: 03f0d916 ("openvswitch: Mega flow implementation")
    Signed-off-by: Jesse Gross <jesse@nicira.com>
    Acked-by: Pravin B Shelar <pshelar@nicira.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 738a811a9ee144f98717ae29441825615b551c0d
Author: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Date:   Thu Sep 10 17:31:15 2015 -0300

    sctp: fix race on protocol/netns initialization

    [ Upstream commit 8e2d61e0aed2b7c4ecb35844fe07e0b2b762dee4 ]

    Consider sctp module is unloaded and is being requested because an user
    is creating a sctp socket.

    During initialization, sctp will add the new protocol type and then
    initialize pernet subsys:

            status = sctp_v4_protosw_init();
            if (status)
                    goto err_protosw_init;

            status = sctp_v6_protosw_init();
            if (status)
                    goto err_v6_protosw_init;

            status = register_pernet_subsys(&sctp_net_ops);

    The problem is that after those calls to sctp_v{4,6}_protosw_init(), it
    is possible for userspace to create SCTP sockets like if the module is
    already fully loaded. If that happens, one of the possible effects is
    that we will have readers for net->sctp.local_addr_list list earlier
    than expected and sctp_net_init() does not take precautions while
    dealing with that list, leading to a potential panic but not limited to
    that, as sctp_sock_init() will copy a bunch of blank/partially
    initialized values from net->sctp.

    The race happens like this:

         CPU 0                           |  CPU 1
      socket()                           |
       __sock_create                     | socket()
        inet_create                      |  __sock_create
         list_for_each_entry_rcu(        |
            answer, &inetsw[sock->type], |
            list) {                      |   inet_create
          /* no hits */                  |
         if (unlikely(err)) {            |
          ...                            |
          request_module()               |
          /* socket creation is blocked  |
           * the module is fully loaded  |
           */                            |
           sctp_init                     |
            sctp_v4_protosw_init         |
             inet_register_protosw       |
              list_add_rcu(&p->list,     |
                           last_perm);   |
                                         |  list_for_each_entry_rcu(
                                         |     answer, &inetsw[sock->type],
            sctp_v6_protosw_init         |     list) {
                                         |     /* hit, so assumes protocol
                                         |      * is already loaded
                                         |      */
                                         |  /* socket creation continues
                                         |   * before netns is initialized
                                         |   */
            register_pernet_subsys       |

    Simply inverting the initialization order between
    register_pernet_subsys() and sctp_v4_protosw_init() is not possible
    because register_pernet_subsys() will create a control sctp socket, so
    the protocol must be already visible by then. Deferring the socket
    creation to a work-queue is not good specially because we loose the
    ability to handle its errors.

    So, as suggested by Vlad, the fix is to split netns initialization in
    two moments: defaults and control socket, so that the defaults are
    already loaded by when we register the protocol, while control socket
    initialization is kept at the same moment it is today.

    Fixes: 4db67e808640 ("sctp: Make the address lists per network namespace")
    Signed-off-by: Vlad Yasevich <vyasevich@gmail.com>
    Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 821cb36fe391803e70c61bab8321abc1108ddcce
Author: Daniel Borkmann <daniel@iogearbox.net>
Date:   Thu Sep 10 20:05:46 2015 +0200

    netlink, mmap: transform mmap skb into full skb on taps

    [ Upstream commit 1853c949646005b5959c483becde86608f548f24 ]

    Ken-ichirou reported that running netlink in mmap mode for receive in
    combination with nlmon will throw a NULL pointer dereference in
    __kfree_skb() on nlmon_xmit(), in my case I can also trigger an "unable
    to handle kernel paging request". The problem is the skb_clone() in
    __netlink_deliver_tap_skb() for skbs that are mmaped.

    I.e. the cloned skb doesn't have a destructor, whereas the mmap netlink
    skb has it pointed to netlink_skb_destructor(), set in the handler
    netlink_ring_setup_skb(). There, skb->head is being set to NULL, so
    that in such cases, __kfree_skb() doesn't perform a skb_release_data()
    via skb_release_all(), where skb->head is possibly being freed through
    kfree(head) into slab allocator, although netlink mmap skb->head points
    to the mmap buffer. Similarly, the same has to be done also for large
    netlink skbs where the data area is vmalloced. Therefore, as discussed,
    make a copy for these rather rare cases for now. This fixes the issue
    on my and Ken-ichirou's test-cases.

    Reference: http://thread.gmane.org/gmane.linux.network/371129
    Fixes: bcbde0d449ed ("net: netlink: virtual tap device management")
    Reported-by: Ken-ichirou MATSUZAWA <chamaken@gmail.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Tested-by: Ken-ichirou MATSUZAWA <chamaken@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 371a4bbb343053875e2165958b98a54514a9c186
Author: Richard Laing <richard.laing@alliedtelesis.co.nz>
Date:   Thu Sep 3 13:52:31 2015 +1200

    net/ipv6: Correct PIM6 mrt_lock handling

    [ Upstream commit 25b4a44c19c83d98e8c0807a7ede07c1f28eab8b ]

    In the IPv6 multicast routing code the mrt_lock was not being released
    correctly in the MFC iterator, as a result adding or deleting a MIF would
    cause a hang because the mrt_lock could not be acquired.

    This fix is a copy of the code for the IPv4 case and ensures that the lock
    is released correctly.

    Signed-off-by: Richard Laing <richard.laing@alliedtelesis.co.nz>
    Acked-by: Cong Wang <cwang@twopensource.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 232baded6d6fd8814de60534d30ced820552c015
Author: Daniel Borkmann <daniel@iogearbox.net>
Date:   Thu Sep 3 00:29:07 2015 +0200

    ipv6: fix exthdrs offload registration in out_rt path

    [ Upstream commit e41b0bedba0293b9e1e8d1e8ed553104b9693656 ]

    We previously register IPPROTO_ROUTING offload under inet6_add_offload(),
    but in error path, we try to unregister it with inet_del_offload(). This
    doesn't seem correct, it should actually be inet6_del_offload(), also
    ipv6_exthdrs_offload_exit() from that commit seems rather incorrect (it
    also uses rthdr_offload twice), but it got removed entirely later on.

    Fixes: 3336288a9fea ("ipv6: Switch to using new offload infrastructure.")
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit f9e86ab009f39ff2d25379f3fed3a5d8f2ad25e7
Author: Eugene Shatokhin <eugene.shatokhin@rosalab.ru>
Date:   Mon Aug 24 23:13:42 2015 +0300

    usbnet: Get EVENT_NO_RUNTIME_PM bit before it is cleared

    [ Upstream commit f50791ac1aca1ac1b0370d62397b43e9f831421a ]

    It is needed to check EVENT_NO_RUNTIME_PM bit of dev->flags in
    usbnet_stop(), but its value should be read before it is cleared
    when dev->flags is set to 0.

    The problem was spotted and the fix was provided by
    Oliver Neukum <oneukum@suse.de>.

    Signed-off-by: Eugene Shatokhin <eugene.shatokhin@rosalab.ru>
    Acked-by: Oliver Neukum <oneukum@suse.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 78aa277b5c1ad0b2091b94bf1d57db9b557e186e
Author: huaibin Wang <huaibin.wang@6wind.com>
Date:   Tue Aug 25 16:20:34 2015 +0200

    ip6_gre: release cached dst on tunnel removal

    [ Upstream commit d4257295ba1b389c693b79de857a96e4b7cd8ac0 ]

    When a tunnel is deleted, the cached dst entry should be released.

    This problem may prevent the removal of a netns (seen with a x-netns IPv6
    gre tunnel):
      unregister_netdevice: waiting for lo to become free. Usage count = 3

    CC: Dmitry Kozlov <xeb@mail.ru>
    Fixes: c12b395a4664 ("gre: Support GRE over IPv6")
    Signed-off-by: huaibin Wang <huaibin.wang@6wind.com>
    Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit fa89e04f61900d6888517ac0c42907c569fc7c44
Author: Daniel Borkmann <daniel@iogearbox.net>
Date:   Tue Jul 7 00:07:52 2015 +0200

    rtnetlink: verify IFLA_VF_INFO attributes before passing them to driver

    [ Upstream commit 4f7d2cdfdde71ffe962399b7020c674050329423 ]

    Jason Gunthorpe reported that since commit c02db8c6290b ("rtnetlink: make
    SR-IOV VF interface symmetric"), we don't verify IFLA_VF_INFO attributes
    anymore with respect to their policy, that is, ifla_vfinfo_policy[].

    Before, they were part of ifla_policy[], but they have been nested since
    placed under IFLA_VFINFO_LIST, that contains the attribute IFLA_VF_INFO,
    which is another nested attribute for the actual VF attributes such as
    IFLA_VF_MAC, IFLA_VF_VLAN, etc.

    Despite the policy being split out from ifla_policy[] in this commit,
    it's never applied anywhere. nla_for_each_nested() only does basic nla_ok()
    testing for struct nlattr, but it doesn't know about the data context and
    their requirements.

    Fix, on top of Jason's initial work, does 1) parsing of the attributes
    with the right policy, and 2) using the resulting parsed attribute table
    from 1) instead of the nla_for_each_nested() loop (just like we used to
    do when still part of ifla_policy[]).

    Reference: http://thread.gmane.org/gmane.linux.network/368913
    Fixes: c02db8c6290b ("rtnetlink: make SR-IOV VF interface symmetric")
    Reported-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
    Cc: Chris Wright <chrisw@sous-sol.org>
    Cc: Sucheta Chakraborty <sucheta.chakraborty@qlogic.com>
    Cc: Greg Rose <gregory.v.rose@intel.com>
    Cc: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
    Cc: Rony Efraim <ronye@mellanox.com>
    Cc: Vlad Zolotarov <vladz@cloudius-systems.com>
    Cc: Nicolas Dichtel <nicolas.dichtel@6wind.com>
    Cc: Thomas Graf <tgraf@suug.ch>
    Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Acked-by: Vlad Zolotarov <vladz@cloudius-systems.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 7acebc24194b31d4e5b98f9e436ae960c0948dd6
Author: Vlad Zolotarov <vladz@cloudius-systems.com>
Date:   Mon Mar 30 21:35:23 2015 +0300

    if_link: Add an additional parameter to ifla_vf_info for RSS querying

    [ Upstream commit 01a3d796813d6302af9f828f34b73d21a4b96c9a ]

    Add configuration setting for drivers to allow/block an RSS Redirection
    Table and a Hash Key querying for discrete VFs.

    On some devices VF share the mentioned above information with PF and
    querying it may adduce a theoretical security risk. We want to let a
    system administrator to decide if he/she wants to take this risk or not.

    Signed-off-by: Vlad Zolotarov <vladz@cloudius-systems.com>
    Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com>
    Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 2117c584b5952c240d194486a9aeba34265736bc
Author: Hin-Tak Leung <htl10@users.sourceforge.net>
Date:   Wed Sep 9 15:38:04 2015 -0700

    hfs,hfsplus: cache pages correctly between bnode_create and bnode_free

    [ Upstream commit 7cb74be6fd827e314f81df3c5889b87e4c87c569 ]

    Pages looked up by __hfs_bnode_create() (called by hfs_bnode_create() and
    hfs_bnode_find() for finding or creating pages corresponding to an inode)
    are immediately kmap()'ed and used (both read and write) and kunmap()'ed,
    and should not be page_cache_release()'ed until hfs_bnode_free().

    This patch fixes a problem I first saw in July 2012: merely running "du"
    on a large hfsplus-mounted directory a few times on a reasonably loaded
    system would get the hfsplus driver all confused and complaining about
    B-tree inconsistencies, and generates a "BUG: Bad page state".  Most
    recently, I can generate this problem on up-to-date Fedora 22 with shipped
    kernel 4.0.5, by running "du /" (="/" + "/home" + "/mnt" + other smaller
    mounts) and "du /mnt" simultaneously on two windows, where /mnt is a
    lightly-used QEMU VM image of the full Mac OS X 10.9:

    $ df -i / /home /mnt
    Filesystem                  Inodes   IUsed      IFree IUse% Mounted on
    /dev/mapper/fedora-root    3276800  551665    2725135   17% /
    /dev/mapper/fedora-home   52879360  716221   52163139    2% /home
    /dev/nbd0p2             4294967295 1387818 4293579477    1% /mnt

    After applying the patch, I was able to run "du /" (60+ times) and "du
    /mnt" (150+ times) continuously and simultaneously for 6+ hours.

    There are many reports of the hfsplus driver getting confused under load
    and generating "BUG: Bad page state" or other similar issues over the
    years.  [1]

    The unpatched code [2] has always been wrong since it entered the kernel
    tree.  The only reason why it gets away with it is that the
    kmap/memcpy/kunmap follow very quickly after the page_cache_release() so
    the kernel has not had a chance to reuse the memory for something else,
    most of the time.

    The current RW driver appears to have followed the design and development
    of the earlier read-only hfsplus driver [3], where-by version 0.1 (Dec
    2001) had a B-tree node-centric approach to
    read_cache_page()/page_cache_release() per bnode_get()/bnode_put(),
    migrating towards version 0.2 (June 2002) of caching and releasing pages
    per inode extents.  When the current RW code first entered the kernel [2]
    in 2005, there was an REF_PAGES conditional (and "//" commented out code)
    to switch between B-node centric paging to inode-centric paging.  There
    was a mistake with the direction of one of the REF_PAGES conditionals in
    __hfs_bnode_create().  In a subsequent "remove debug code" commit [4], the
    read_cache_page()/page_cache_release() per bnode_get()/bnode_put() were
    removed, but a page_cache_release() was mistakenly left in (propagating
    the "REF_PAGES <-> !REF_PAGE" mistake), and the commented-out
    page_cache_release() in bnode_release() (which should be spanned by
    !REF_PAGES) was never enabled.

    References:
    [1]:
    Michael Fox, Apr 2013
    http://www.spinics.net/lists/linux-fsdevel/msg63807.html
    ("hfsplus volume suddenly inaccessable after 'hfs: recoff %d too large'")

    Sasha Levin, Feb 2015
    http://lkml.org/lkml/2015/2/20/85 ("use after free")

    https://bugs.launchpad.net/ubuntu/+source/linux/+bug/740814
    https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1027887
    https://bugzilla.kernel.org/show_bug.cgi?id=42342
    https://bugzilla.kernel.org/show_bug.cgi?id=63841
    https://bugzilla.kernel.org/show_bug.cgi?id=78761

    [2]:
    http://git.kernel.org/cgit/linux/kernel/git/tglx/history.git/commit/\
    fs/hfs/bnode.c?id=d1081202f1d0ee35ab0beb490da4b65d4bc763db
    commit d1081202f1d0ee35ab0beb490da4b65d4bc763db
    Author: Andrew Morton <akpm@osdl.org>
    Date:   Wed Feb 25 16:17:36 2004 -0800

        [PATCH] HFS rewrite

    http://git.kernel.org/cgit/linux/kernel/git/tglx/history.git/commit/\
    fs/hfsplus/bnode.c?id=91556682e0bf004d98a529bf829d339abb98bbbd

    commit 91556682e0bf004d98a529bf829d339abb98bbbd
    Author: Andrew Morton <akpm@osdl.org>
    Date:   Wed Feb 25 16:17:48 2004 -0800

        [PATCH] HFS+ support

    [3]:
    http://sourceforge.net/projects/linux-hfsplus/

    http://sourceforge.net/projects/linux-hfsplus/files/Linux%202.4.x%20patch/hfsplus%200.1/
    http://sourceforge.net/projects/linux-hfsplus/files/Linux%202.4.x%20patch/hfsplus%200.2/

    http://linux-hfsplus.cvs.sourceforge.net/viewvc/linux-hfsplus/linux/\
    fs/hfsplus/bnode.c?r1=1.4&r2=1.5

    Date:   Thu Jun 6 09:45:14 2002 +0000
    Use buffer cache instead of page cache in bnode.c. Cache inode extents.

    [4]:
    http://git.kernel.org/cgit/linux/kernel/git/\
    stable/linux-stable.git/commit/?id=a5e3985fa014029eb6795664c704953720cc7f7d

    commit a5e3985fa014029eb6795664c704953720cc7f7d
    Author: Roman Zippel <zippel@linux-m68k.org>
    Date:   Tue Sep 6 15:18:47 2005 -0700

    [PATCH] hfs: remove debug code

    Signed-off-by: Hin-Tak Leung <htl10@users.sourceforge.net>
    Signed-off-by: Sergei Antonov <saproj@gmail.com>
    Reviewed-by: Anton Altaparmakov <anton@tuxera.com>
    Reported-by: Sasha Levin <sasha.levin@oracle.com>
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Cc: Christoph Hellwig <hch@infradead.org>
    Cc: Vyacheslav Dubeyko <slava@dubeyko.com>
    Cc: Sougata Santra <sougata@tuxera.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 13f3dc548b25086fb4e66636f6a1c8ba79b8353c
Author: Noa Osherovich <noaos@mellanox.com>
Date:   Thu Jul 30 17:34:24 2015 +0300

    IB/mlx4: Use correct SL on AH query under RoCE

    [ Upstream commit 5e99b139f1b68acd65e36515ca347b03856dfb5a ]

    The mlx4 IB driver implementation for ib_query_ah used a wrong offset
    (28 instead of 29) when link type is Ethernet. Fixed to use the correct one.

    Fixes: fa417f7b520e ('IB/mlx4: Add support for IBoE')
    Signed-off-by: Shani Michaeli <shanim@mellanox.com>
    Signed-off-by: Noa Osherovich <noaos@mellanox.com>
    Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
    Signed-off-by: Doug Ledford <dledford@redhat.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 40968908297a4416894af5a203b43632d331435c
Author: Jack Morgenstein <jackm@dev.mellanox.co.il>
Date:   Thu Jul 30 17:34:23 2015 +0300

    IB/mlx4: Forbid using sysfs to change RoCE pkeys

    [ Upstream commit 2b135db3e81301d0452e6aa107349abe67b097d6 ]

    The pkey mapping for RoCE must remain the default mapping:
    VFs:
      virtual index 0 = mapped to real index 0 (0xFFFF)
      All others indices: mapped to a real pkey index containing an
                          invalid pkey.
    PF:
      virtual index i = real index i.

    Don't allow users to change these mappings using files found in
    sysfs.

    Fixes: c1e7e466120b ('IB/mlx4: Add iov directory in sysfs under the ib device')
    Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
    Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
    Signed-off-by: Doug Ledford <dledford@redhat.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 15b3aadf15f0bb696184235163ff42ab0cb7e26c
Author: Yishai Hadas <yishaih@mellanox.com>
Date:   Thu Aug 13 18:32:03 2015 +0300

    IB/uverbs: Fix race between ib_uverbs_open and remove_one

    [ Upstream commit 35d4a0b63dc0c6d1177d4f532a9deae958f0662c ]

    Fixes: 2a72f212263701b927559f6850446421d5906c41 ("IB/uverbs: Remove dev_table")

    Before this commit there was a device look-up table that was protected
    by a spin_lock used by ib_uverbs_open and by ib_uverbs_remove_one. When
    it was dropped and container_of was used instead, it enabled the race
    with remove_one as dev might be freed just after:
    dev = container_of(inode->i_cdev, struct ib_uverbs_device, cdev) but
    before the kref_get.

    In addition, this buggy patch added some dead code as
    container_of(x,y,z) can never be NULL and so dev can never be NULL.
    As a result the comment above ib_uverbs_open saying "the open method
    will either immediately run -ENXIO" is wrong as it can never happen.

    The solution follows Jason Gunthorpe suggestion from below URL:
    https://www.mail-archive.com/linux-rdma@vger.kernel.org/msg25692.html

    cdev will hold a kref on the parent (the containing structure,
    ib_uverbs_device) and only when that kref is released it is
    guaranteed that open will never be called again.

    In addition, fixes the active count scheme to use an atomic
    not a kref to prevent WARN_ON as pointed by above comment
    from Jason.

    Signed-off-by: Yishai Hadas <yishaih@mellanox.com>
    Signed-off-by: Shachar Raindel <raindel@mellanox.com>
    Reviewed-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
    Signed-off-by: Doug Ledford <dledford@redhat.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 7c1d757a1fe62ec2983751441724acd0e2f8cd3c
Author: Christoph Hellwig <hch@lst.de>
Date:   Wed Aug 26 11:00:37 2015 +0200

    IB/uverbs: reject invalid or unknown opcodes

    [ Upstream commit b632ffa7cee439ba5dce3b3bc4a5cbe2b3e20133 ]

    We have many WR opcodes that are only supported in kernel space
    and/or require optional information to be copied into the WR
    structure.  Reject all those not explicitly handled so that we
    can't pass invalid information to drivers.

    Cc: stable@vger.kernel.org
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Reviewed-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
    Reviewed-by: Sagi Grimberg <sagig@mellanox.com>
    Signed-off-by: Doug Ledford <dledford@redhat.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit f3990e99b398e64af5f75eea3e4acc09260b667a
Author: Mike Marciniszyn <mike.marciniszyn@intel.com>
Date:   Tue Jul 21 08:36:07 2015 -0400

    IB/qib: Change lkey table allocation to support more MRs

    [ Upstream commit d6f1c17e162b2a11e708f28fa93f2f79c164b442 ]

    The lkey table is allocated with with a get_user_pages() with an
    order based on a number of index bits from a module parameter.

    The underlying kernel code cannot allocate that many contiguous pages.

    There is no reason the underlying memory needs to be physically
    contiguous.

    This patch:
    - switches the allocation/deallocation to vmalloc/vfree
    - caps the number of bits to 23 to insure at least 1 generation bit
      o this matches the module parameter description

    Cc: stable@vger.kernel.org
    Reviewed-by: Vinit Agnihotri <vinit.abhay.agnihotri@intel.com>
    Signed-off-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
    Signed-off-by: Doug Ledford <dledford@redhat.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 15c8f5c3e07d2059e02b686fc8f1abfd7201d4ca
Author: Hin-Tak Leung <htl10@users.sourceforge.net>
Date:   Wed Sep 9 15:38:07 2015 -0700

    hfs: fix B-tree corruption after insertion at position 0

    [ Upstream commit b4cc0efea4f0bfa2477c56af406cfcf3d3e58680 ]

    Fix B-tree corruption when a new record is inserted at position 0 in the
    node in hfs_brec_insert().

    This is an identical change to the corresponding hfs b-tree code to Sergei
    Antonov's "hfsplus: fix B-tree corruption after insertion at position 0",
    to keep similar code paths in the hfs and hfsplus drivers in sync, where
    appropriate.

    Signed-off-by: Hin-Tak Leung <htl10@users.sourceforge.net>
    Cc: Sergei Antonov <saproj@gmail.com>
    Cc: Joe Perches <joe@perches.com>
    Reviewed-by: Vyacheslav Dubeyko <slava@dubeyko.com>
    Cc: Anton Altaparmakov <anton@tuxera.com>
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Cc: Christoph Hellwig <hch@infradead.org>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 3a2915dad9da74c13fd6a83c7d0465ce89fd4403
Author: NeilBrown <neilb@suse.com>
Date:   Mon Jul 6 17:37:49 2015 +1000

    md/raid10: always set reshape_safe when initializing reshape_position.

    [ Upstream commit 299b0685e31c9f3dcc2d58ee3beca761a40b44b3 ]

    'reshape_position' tracks where in the reshape we have reached.
    'reshape_safe' tracks where in the reshape we have safely recorded
    in the metadata.

    These are compared to determine when to update the metadata.
    So it is important that reshape_safe is initialised properly.
    Currently it isn't.  When starting a reshape from the beginning
    it usually has the correct value by luck.  But when reducing the
    number of devices in a RAID10, it has the wrong value and this leads
    to the metadata not being updated correctly.
    This can lead to corruption if the reshape is not allowed to complete.

    This patch is suitable for any -stable kernel which supports RAID10
    reshape, which is 3.5 and later.

    Fixes: 3ea7daa5d7fd ("md/raid10: add reshape support")
    Cc: stable@vger.kernel.org (v3.5+ please wait for -final to be out for 2 weeks)
    Signed-off-by: NeilBrown <neilb@suse.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit c1802263482f6ce2501830c8aca14f582b7130cf
Author: Jialing Fu <jlfu@marvell.com>
Date:   Fri Aug 28 11:13:09 2015 +0800

    mmc: core: fix race condition in mmc_wait_data_done

    [ Upstream commit 71f8a4b81d040b3d094424197ca2f1bf811b1245 ]

    The following panic is captured in ker3.14, but the issue still exists
    in latest kernel.
    ---------------------------------------------------------------------
    [   20.738217] c0 3136 (Compiler) Unable to handle kernel NULL pointer dereference
    at virtual address 00000578
    ......
    [   20.738499] c0 3136 (Compiler) PC is at _raw_spin_lock_irqsave+0x24/0x60
    [   20.738527] c0 3136 (Compiler) LR is at _raw_spin_lock_irqsave+0x20/0x60
    [   20.740134] c0 3136 (Compiler) Call trace:
    [   20.740165] c0 3136 (Compiler) [<ffffffc0008ee900>] _raw_spin_lock_irqsave+0x24/0x60
    [   20.740200] c0 3136 (Compiler) [<ffffffc0000dd024>] __wake_up+0x1c/0x54
    [   20.740230] c0 3136 (Compiler) [<ffffffc000639414>] mmc_wait_data_done+0x28/0x34
    [   20.740262] c0 3136 (Compiler) [<ffffffc0006391a0>] mmc_request_done+0xa4/0x220
    [   20.740314] c0 3136 (Compiler) [<ffffffc000656894>] sdhci_tasklet_finish+0xac/0x264
    [   20.740352] c0 3136 (Compiler) [<ffffffc0000a2b58>] tasklet_action+0xa0/0x158
    [   20.740382] c0 3136 (Compiler) [<ffffffc0000a2078>] __do_softirq+0x10c/0x2e4
    [   20.740411] c0 3136 (Compiler) [<ffffffc0000a24bc>] irq_exit+0x8c/0xc0
    [   20.740439] c0 3136 (Compiler) [<ffffffc00008489c>] handle_IRQ+0x48/0xac
    [   20.740469] c0 3136 (Compiler) [<ffffffc000081428>] gic_handle_irq+0x38/0x7c
    ----------------------------------------------------------------------
    Because in SMP, "mrq" has race condition between below two paths:
    path1: CPU0: <tasklet context>
      static void mmc_wait_data_done(struct mmc_request *mrq)
      {
         mrq->host->context_info.is_done_rcv = true;
         //
         // If CPU0 has just finished "is_done_rcv = true" in path1, and at
         // this moment, IRQ or ICache line missing happens in CPU0.
         // What happens in CPU1 (path2)?
         //
         // If the mmcqd thread in CPU1(path2) hasn't entered to sleep mode:
         // path2 would have chance to break from wait_event_interruptible
         // in mmc_wait_for_data_req_done and continue to run for next
         // mmc_request (mmc_blk_rw_rq_prep).
         //
         // Within mmc_blk_rq_prep, mrq is cleared to 0.
         // If below line still gets host from "mrq" as the result of
         // compiler, the panic happens as we traced.
         wake_up_interruptible(&mrq->host->context_info.wait);
      }

    path2: CPU1: <The mmcqd thread runs mmc_queue_thread>
      static int mmc_wait_for_data_req_done(...
      {
         ...
         while (1) {
               wait_event_interruptible(context_info->wait,
                       (context_info->is_done_rcv ||
                        context_info->is_new_req));
               static void mmc_blk_rw_rq_prep(...
               {
               ...
               memset(brq, 0, sizeof(struct mmc_blk_request));

    This issue happens very coincidentally; however adding mdelay(1) in
    mmc_wait_data_done as below could duplicate it easily.

       static void mmc_wait_data_done(struct mmc_request *mrq)
       {
         mrq->host->context_info.is_done_rcv = true;
    +    mdelay(1);
         wake_up_interruptible(&mrq->host->context_info.wait);
        }

    At runtime, IRQ or ICache line missing may just happen at the same place
    of the mdelay(1).

    This patch gets the mmc_context_info at the beginning of function, it can
    avoid this race condition.

    Signed-off-by: Jialing Fu <jlfu@marvell.com>
    Tested-by: Shawn Lin <shawn.lin@rock-chips.com>
    Fixes: 2220eedfd7ae ("mmc: fix async request mechanism ....")
    Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit d8ef0bd7baadc1284b09b817ac61e7fe098b1c54
Author: Jann Horn <jann@thejh.net>
Date:   Wed Sep 9 15:38:28 2015 -0700

    fs: if a coredump already exists, unlink and recreate with O_EXCL

    [ Upstream commit fbb1816942c04429e85dbf4c1a080accc534299e ]

    It was possible for an attacking user to trick root (or another user) into
    writing his coredumps into an attacker-readable, pre-existing file using
    rename() or link(), causing the disclosure of secret data from the victim
    process' virtual memory.  Depending on the configuration, it was also
    possible to trick root into overwriting system files with coredumps.  Fix
    that issue by never writing coredumps into existing files.

    Requirements for the attack:
     - The attack only applies if the victim's process has a nonzero
       RLIMIT_CORE and is dumpable.
     - The attacker can trick the victim into coredumping into an
       attacker-writable directory D, either because the core_pattern is
       relative and the victim's cwd is attacker-writable or because an
       absolute core_pattern pointing to a world-writable directory is used.
     - The attacker has one of these:
      A: on a system with protected_hardlinks=0:
         execute access to a folder containing a victim-owned,
         attacker-readable file on the same partition as D, and the
         victim-owned file will be deleted before the main part of the attack
         takes place. (In practice, there are lots of files that fulfill
         this condition, e.g. entries in Debian's /var/lib/dpkg/info/.)
         This does not apply to most Linux systems because most distros set
         protected_hardlinks=1.
      B: on a system with protected_hardlinks=1:
         execute access to a folder containing a victim-owned,
         attacker-readable and attacker-writable file on the same partition
         as D, and the victim-owned file will be deleted before the main part
         of the attack takes place.
         (This seems to be uncommon.)
      C: on any system, independent of protected_hardlinks:
         write access to a non-sticky folder containing a victim-owned,
         attacker-readable file on the same partition as D
         (This seems to be uncommon.)

    The basic idea is that the attacker moves the victim-owned file to where
    he expects the victim process to dump its core.  The victim process dumps
    its core into the existing file, and the attacker reads the coredump from
    it.

    If the attacker can't move the file because he does not have write access
    to the containing directory, he can instead link the file to a directory
    he controls, then wait for the original link to the file to be deleted
    (because the kernel checks that the link count of the corefile is 1).

    A less reliable variant that requires D to be non-sticky works with link()
    and does not require deletion of the original link: link() the file into
    D, but then unlink() it directly before the kernel performs the link count
    check.

    On systems with protected_hardlinks=0, this variant allows an attacker to
    not only gain information from coredumps, but also clobber existing,
    victim-writable files with coredumps.  (This could theoretically lead to a
    privilege escalation.)

    Signed-off-by: Jann Horn <jann@thejh.net>
    Cc: Kees Cook <keescook@chromium.org>
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 19d585ab7bd36fb656008f8148049acde7643c91
Author: Jaewon Kim <jaewon31.kim@samsung.com>
Date:   Tue Sep 8 15:02:21 2015 -0700

    vmscan: fix increasing nr_isolated incurred by putback unevictable pages

    [ Upstream commit c54839a722a02818677bcabe57e957f0ce4f841d ]

    reclaim_clean_pages_from_list() assumes that shrink_page_list() returns
    number of pages removed from the candidate list.  But shrink_page_list()
    puts back mlocked pages without passing it to caller and without
    counting as nr_reclaimed.  This increases nr_isolated.

    To fix this, this patch changes shrink_page_list() to pass unevictable
    pages back to caller.  Caller will take care those pages.

    Minchan said:

    It fixes two issues.

    1. With unevictable page, cma_alloc will be successful.

    Exactly speaking, cma_alloc of current kernel will fail due to
    unevictable pages.

    2. fix leaking of NR_ISOLATED counter of vmstat

    With it, too_many_isolated works.  Otherwise, it could make hang until
    the process get SIGKILL.

    Signed-off-by: Jaewon Kim <jaewon31.kim@samsung.com>
    Acked-by: Minchan Kim <minchan@kernel.org>
    Cc: Mel Gorman <mgorman@techsingularity.net>
    Acked-by: Vlastimil Babka <vbabka@suse.cz>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit ee2cdeabb2b5bff780b1e61af5fc13967573e466
Author: Helge Deller <deller@gmx.de>
Date:   Thu Sep 3 22:45:21 2015 +0200

    parisc: Filter out spurious interrupts in PA-RISC irq handler

    [ Upstream commit b1b4e435e4ef7de77f07bf2a42c8380b960c2d44 ]

    When detecting a serial port on newer PA-RISC machines (with iosapic) we have a
    long way to go to find the right IRQ line, registering it, then registering the
    serial port and the irq handler for the serial port. During this phase spurious
    interrupts for the serial port may happen which then crashes the kernel because
    the action handler might not have been set up yet.

    So, basically it's a race condition between the serial port hardware and the
    CPU which sets up the necessary fields in the irq sructs. The main reason for
    this race is, that we unmask the serial port irqs too early without having set
    up everything properly before (which isn't easily possible because we need the
    IRQ number to register the serial ports).

    This patch is a work-around for this problem. It adds checks to the CPU irq
    handler to verify if the IRQ action field has been initialized already. If not,
    we just skip this interrupt (which isn't critical for a serial port at bootup).
    The real fix would probably involve rewriting all PA-RISC specific IRQ code
    (for CPU, IOSAPIC, GSC and EISA) to use IRQ domains with proper parenting of
    the irq chips and proper irq enabling along this line.

    This bug has been in the PA-RISC port since the beginning, but the crashes
    happened very rarely with currently used hardware.  But on the latest machine
    which I bought (a C8000 workstation), which uses the fastest CPUs (4 x PA8900,
    1GHz) and which has the largest possible L1 cache size (64MB each), the kernel
    crashed at every boot because of this race. So, without this patch the machine
    would currently be unuseable.

    For the record, here is the flow logic:
    1. serial_init_chip() in 8250_gsc.c calls iosapic_serial_irq().
    2. iosapic_serial_irq() calls txn_alloc_irq() to find the irq.
    3. iosapic_serial_irq() calls cpu_claim_irq() to register the CPU irq
    4. cpu_claim_irq() unmasks the CPU irq (which it shouldn't!)
    5. serial_init_chip() then registers the 8250 port.
    Problems:
    - In step 4 the CPU irq shouldn't have been registered yet, but after step 5
    - If serial irq happens between 4 and 5 have finished, the kernel will crash

    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit e158509bb2c10c88079043b2acdac71c34b0f666
Author: John David Anglin <dave.anglin@bell.net>
Date:   Mon Sep 7 20:13:28 2015 -0400

    parisc: Use double word condition in 64bit CAS operation

    [ Upstream commit 1b59ddfcf1678de38a1f8ca9fb8ea5eebeff1843 ]

    The attached change fixes the condition used in the "sub" instruction.
    A double word comparison is needed.  This fixes the 64-bit LWS CAS
    operation on 64-bit kernels.

    I can now enable 64-bit atomic support in GCC.

    Cc: <stable@vger.kernel.org>
    Signed-off-by: John David Anglin <dave.anglin>
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 5d9b942696a6bcf8f1e498991f5eba35329ab1e6
Author: Trond Myklebust <trond.myklebust@primarydata.com>
Date:   Mon Aug 17 12:57:07 2015 -0500

    NFS: nfs_set_pgio_error sometimes misses errors

    [ Upstream commit e9ae58aeee8842a50f7e199d602a5ccb2e41a95f ]

    We should ensure that we always set the pgio_header's error field
    if a READ or WRITE RPC call returns an error. The current code depends
    on 'hdr->good_bytes' always being initialised to a large value, which
    is not always done correctly by callers.
    When this happens, applications may end up missing important errors.

    Cc: stable@vger.kernel.org
    Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 2e81b26ee568c88b68c7b4e58a71bbdfe83fb338
Author: Kinglong Mee <kinglongmee@gmail.com>
Date:   Sat Aug 15 21:52:10 2015 +0800

    NFS: Fix a NULL pointer dereference of migration recovery ops for v4.2 client

    [ Upstream commit 18e3b739fdc826481c6a1335ce0c5b19b3d415da ]

    ---Steps to Reproduce--
    <nfs-server>
    # cat /etc/exports
    /nfs/referal  *(rw,insecure,no_subtree_check,no_root_squash,crossmnt)
    /nfs/old      *(ro,insecure,subtree_check,root_squash,crossmnt)

    <nfs-client>
    # mount -t nfs nfs-server:/nfs/ /mnt/
    # ll /mnt/*/

    <nfs-server>
    # cat /etc/exports
    /nfs/referal   *(rw,insecure,no_subtree_check,no_root_squash,crossmnt,refer=/nfs/old/@nfs-server)
    /nfs/old       *(ro,insecure,subtree_check,root_squash,crossmnt)
    # service nfs restart

    <nfs-client>
    # ll /mnt/*/    --->>>>> oops here

    [ 5123.102925] BUG: unable to handle kernel NULL pointer dereference at           (null)
    [ 5123.103363] IP: [<ffffffffa03ed38b>] nfs4_proc_get_locations+0x9b/0x120 [nfsv4]
    [ 5123.103752] PGD 587b9067 PUD 3cbf5067 PMD 0
    [ 5123.104131] Oops: 0000 [#1]
    [ 5123.104529] Modules linked in: nfsv4(OE) nfs(OE) fscache(E) nfsd(OE) xfs libcrc32c iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi coretemp crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel ppdev vmw_balloon parport_pc parport i2c_piix4 shpchp auth_rpcgss nfs_acl vmw_vmci lockd grace sunrpc vmwgfx drm_kms_helper ttm drm mptspi serio_raw scsi_transport_spi e1000 mptscsih mptbase ata_generic pata_acpi [last unloaded: nfsd]
    [ 5123.105887] CPU: 0 PID: 15853 Comm: ::1-manager Tainted: G           OE   4.2.0-rc6+ #214
    [ 5123.106358] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 05/20/2014
    [ 5123.106860] task: ffff88007620f300 ti: ffff88005877c000 task.ti: ffff88005877c000
    [ 5123.107363] RIP: 0010:[<ffffffffa03ed38b>]  [<ffffffffa03ed38b>] nfs4_proc_get_locations+0x9b/0x120 [nfsv4]
    [ 5123.107909] RSP: 0018:ffff88005877fdb8  EFLAGS: 00010246
    [ 5123.108435] RAX: ffff880053f3bc00 RBX: ffff88006ce6c908 RCX: ffff880053a0d240
    [ 5123.108968] RDX: ffffea0000e6d940 RSI: ffff8800399a0000 RDI: ffff88006ce6c908
    [ 5123.109503] RBP: ffff88005877fe28 R08: ffffffff81c708a0 R09: 0000000000000000
    [ 5123.110045] R10: 00000000000001a2 R11: ffff88003ba7f5c8 R12: ffff880054c55800
    [ 5123.110618] R13: 0000000000000000 R14: ffff880053a0d240 R15: ffff880053a0d240
    [ 5123.111169] FS:  0000000000000000(0000) GS:ffffffff81c27000(0000) knlGS:0000000000000000
    [ 5123.111726] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [ 5123.112286] CR2: 0000000000000000 CR3: 0000000054cac000 CR4: 00000000001406f0
    [ 5123.112888] Stack:
    [ 5123.113458]  ffffea0000e6d940 ffff8800399a0000 00000000000167d0 0000000000000000
    [ 5123.114049]  0000000000000000 0000000000000000 0000000000000000 00000000a7ec82c6
    [ 5123.114662]  ffff88005877fe18 ffffea0000e6d940 ffff8800399a0000 ffff880054c55800
    [ 5123.115264] Call Trace:
    [ 5123.115868]  [<ffffffffa03fb44b>] nfs4_try_migration+0xbb/0x220 [nfsv4]
    [ 5123.116487]  [<ffffffffa03fcb3b>] nfs4_run_state_manager+0x4ab/0x7b0 [nfsv4]
    [ 5123.117104]  [<ffffffffa03fc690>] ? nfs4_do_reclaim+0x510/0x510 [nfsv4]
    [ 5123.117813]  [<ffffffff810a4527>] kthread+0xd7/0xf0
    [ 5123.118456]  [<ffffffff810a4450>] ? kthread_worker_fn+0x160/0x160
    [ 5123.119108]  [<ffffffff816d9cdf>] ret_from_fork+0x3f/0x70
    [ 5123.119723]  [<ffffffff810a4450>] ? kthread_worker_fn+0x160/0x160
    [ 5123.120329] Code: 4c 8b 6a 58 74 17 eb 52 48 8d 55 a8 89 c6 4c 89 e7 e8 4a b5 ff ff 8b 45 b0 85 c0 74 1c 4c 89 f9 48 8b 55 90 48 8b 75 98 48 89 df <41> ff 55 00 3d e8 d8 ff ff 41 89 c6 74 cf 48 8b 4d c8 65 48 33
    [ 5123.121643] RIP  [<ffffffffa03ed38b>] nfs4_proc_get_locations+0x9b/0x120 [nfsv4]
    [ 5123.122308]  RSP <ffff88005877fdb8>
    [ 5123.122942] CR2: 0000000000000000

    Fixes: ec011fe847 ("NFS: Introduce a vector of migration recovery ops")
    Cc: stable@vger.kernel.org # v3.13+
    Signed-off-by: Kinglong Mee <kinglongmee@gmail.com>
    Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 9c4acd614315606108151ba7f2b13987368ea13c
Author: NeilBrown <neilb@suse.com>
Date:   Thu Jul 30 13:00:56 2015 +1000

    NFSv4: don't set SETATTR for O_RDONLY|O_EXCL

    [ Upstream commit efcbc04e16dfa95fef76309f89710dd1d99a5453 ]

    It is unusual to combine the open flags O_RDONLY and O_EXCL, but
    it appears that libre-office does just that.

    [pid  3250] stat("/home/USER/.config", {st_mode=S_IFDIR|0700, st_size=8192, ...}) = 0
    [pid  3250] open("/home/USER/.config/libreoffice/4-suse/user/extensions/buildid", O_RDONLY|O_EXCL <unfinished ...>

    NFSv4 takes O_EXCL as a sign that a setattr command should be sent,
    probably to reset the timestamps.

    When it was an O_RDONLY open, the SETATTR command does not
    identify any actual attributes to change.
    If no delegation was provided to the open, the SETATTR uses the
    all-zeros stateid and the request is accepted (at least by the
    Linux NFS server - no harm, no foul).

    If a read-delegation was provided, this is used in the SETATTR
    request, and a Netapp filer will justifiably claim
    NFS4ERR_BAD_STATEID, which the Linux client takes as a sign
    to retry - indefinitely.

    So only treat O_EXCL specially if O_CREAT was also given.

    Signed-off-by: NeilBrown <neilb@suse.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit fe3882a4751d2b4fd004b4ce6f0e3ddebd093b52
Author: Filipe Manana <fdmanana@suse.com>
Date:   Wed Aug 12 11:54:35 2015 +0100

    Btrfs: check if previous transaction aborted to avoid fs corruption

    [ Upstream commit 1f9b8c8fbc9a4d029760b16f477b9d15500e3a34 ]

    While we are committing a transaction, it's possible the previous one is
    still finishing its commit and therefore we wait for it to finish first.
    However we were not checking if that previous transaction ended up getting
    aborted after we waited for it to commit, so we ended up committing the
    current transaction which can lead to fs corruption because the new
    superblock can point to trees that have had one or more nodes/leafs that
    were never durably persisted.
    The following sequence diagram exemplifies how this is possible:

              CPU 0                                                        CPU 1

      transaction N starts

      (...)

      btrfs_commit_transaction(N)

        cur_trans->state = TRANS_STATE_COMMIT_START;
        (...)
        cur_trans->state = TRANS_STATE_COMMIT_DOING;
        (...)

        cur_trans->state = TRANS_STATE_UNBLOCKED;
        root->fs_info->running_transaction = NULL;

                                                                  btrfs_start_transaction()
                                                                     --> starts transaction N + 1

        btrfs_write_and_wait_transaction(trans, root);
          --> starts writing all new or COWed ebs created
              at transaction N

                                                                  creates some new ebs, COWs some
                                                                  existing ebs but doesn't COW or
                                                                  deletes eb X

                                                                  btrfs_commit_transaction(N + 1)
                                                                    (...)
                                                                    cur_trans->state = TRANS_STATE_COMMIT_START;
                                                                    (...)
                                                                    wait_for_commit(root, prev_trans);
                                                                      --> prev_trans == transaction N

        btrfs_write_and_wait_transaction() continues
        writing ebs
           --> fails writing eb X, we abort transaction N
               and set bit BTRFS_FS_STATE_ERROR on
               fs_info->fs_state, so no new transactions
               can start after setting that bit

           cleanup_transaction()
             btrfs_cleanup_one_transaction()
               wakes up task at CPU 1

                                                                    continues, doesn't abort because
                                                                    cur_trans->aborted (transaction N + 1)
                                                                    is zero, and no checks for bit
                                                                    BTRFS_FS_STATE_ERROR in fs_info->fs_state
                                                                    are made

                                                                    btrfs_write_and_wait_transaction(trans, root);
                                                                      --> succeeds, no errors during writeback

                                                                    write_ctree_super(trans, root, 0);
                                                                      --> succeeds
                                                                      --> we have now a superblock that points us
                                                                          to some root that uses eb X, which was
                                                                          never written to disk

    In this scenario future attempts to read eb X from disk results in an
    error message like "parent transid verify failed on X wanted Y found Z".

    So fix this by aborting the current transaction if after waiting for the
    previous transaction we verify that it was aborted.

    Cc: stable@vger.kernel.org
    Signed-off-by: Filipe Manana <fdmanana@suse.com>
    Reviewed-by: Josef Bacik <jbacik@fb.com>
    Reviewed-by: Liu Bo <bo.li.liu@oracle.com>
    Signed-off-by: Chris Mason <clm@fb.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit e5ce14705d3199531b646c9e03724eaec77c6471
Author: Sakari Ailus <sakari.ailus@iki.fi>
Date:   Fri Jun 12 20:06:23 2015 -0300

    [media] v4l: omap3isp: Fix sub-device power management code

    [ Upstream commit 9d39f05490115bf145e5ea03c0b7ec9d3d015b01 ]

    Commit 813f5c0ac5cc ("media: Change media device link_notify behaviour")
    modified the media controller link setup notification API and updated the
    OMAP3 ISP driver accordingly. As a side effect it introduced a bug by
    turning power on after setting the link instead of before. This results in
    sub-devices not being powered down in some cases when they should be. Fix
    it.

    Fixes: 813f5c0ac5cc [media] media: Change media device link_notify behaviour

    Signed-off-by: Sakari Ailus <sakari.ailus@iki.fi>
    Cc: stable@vger.kernel.org # since v3.10
    Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 51d0384968780c9532bb63f9842e82c336fa7ab8
Author: David Härdeman <david@hardeman.nu>
Date:   Tue May 19 19:03:12 2015 -0300

    [media] rc-core: fix remove uevent generation

    [ Upstream commit a66b0c41ad277ae62a3ae6ac430a71882f899557 ]

    The input_dev is already gone when the rc device is being unregistered
    so checking for its presence only means that no remove uevent will be
    generated.

    Cc: stable@kernel.org
    Signed-off-by: David Härdeman <david@hardeman.nu>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 8da2e87b95215ef4acd944ed1d552d5082ba98f8
Author: Minfei Huang <mnfhuang@gmail.com>
Date:   Sun Jul 12 20:18:42 2015 +0800

    x86/mm: Initialize pmd_idx in page_table_range_init_count()

    [ Upstream commit 9962eea9e55f797f05f20ba6448929cab2a9f018 ]

    The variable pmd_idx is not initialized for the first iteration of the
    for loop.

    Assign the proper value which indexes the start address.

    Fixes: 719272c45b82 'x86, mm: only call early_ioremap_page_table_range_init() once'
    Signed-off-by: Minfei Huang <mnfhuang@gmail.com>
    Cc: tony.luck@intel.com
    Cc: wangnan0@huawei.com
    Cc: david.vrabel@citrix.com
    Reviewed-by: yinghai@kernel.org
    Link: http://lkml.kernel.org/r/1436703522-29552-1-git-send-email-mhuang@redhat.com
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 3cc3b3025f6259e23bfe2e1b95c4173001144cba
Author: Jeffery Miller <jmiller@neverware.com>
Date:   Tue Sep 1 11:23:02 2015 -0400

    Add radeon suspend/resume quirk for HP Compaq dc5750.

    [ Upstream commit 09bfda10e6efd7b65bcc29237bee1765ed779657 ]

    With the radeon driver loaded the HP Compaq dc5750
    Small Form Factor machine fails to resume from suspend.
    Adding a quirk similar to other devices avoids
    the problem and the system resumes properly.

    Signed-off-by: Jeffery Miller <jmiller@neverware.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 01104f30a6751e2b04cfc43a4b745a249d3ad04e
Author: Jann Horn <jann@thejh.net>
Date:   Fri Sep 11 16:27:27 2015 +0200

    CIFS: fix type confusion in copy offload ioctl

    [ Upstream commit 4c17a6d56bb0cad3066a714e94f7185a24b40f49 ]

    This might lead to local privilege escalation (code execution as
    kernel) for systems where the following conditions are met:

     - CONFIG_CIFS_SMB2 and CONFIG_CIFS_POSIX are enabled
     - a cifs filesystem is mounted where:
      - the mount option "vers" was used and set to a value >=2.0
      - the attacker has write access to at least one file on the filesystem

    To attack this, an attacker would have to guess the target_tcon
    pointer (but guessing wrong doesn't cause a crash, it just returns an
    error code) and win a narrow race.

    CC: Stable <stable@vger.kernel.org>
    Signed-off-by: Jann Horn <jann@thejh.net>
    Signed-off-by: Steve French <smfrench@gmail.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 435facb28b835f014b6a21ff887442d0e03cef03
Author: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Date:   Tue Sep 15 12:30:08 2015 +0530

    powerpc/mm: Recompute hash value after a failed update

    [ Upstream commit 36b35d5d807b7e57aff7d08e63de8b17731ee211 ]

    If we had secondary hash flag set, we ended up modifying hash value in
    the updatepp code path. Hence with a failed updatepp we will be using
    a wrong hash value for the following hash insert. Fix this by
    recomputing hash before insert.

    Without this patch we can end up with using wrong slot number in linux
    pte. That can result in us missing an hash pte update or invalidate
    which can cause memory corruption or even machine check.

    Fixes: 6d492ecc6489 ("powerpc/THP: Add code to handle HPTE faults for hugepages")
    Cc: stable@vger.kernel.org # v3.11+
    Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
    Reviewed-by: Paul Mackerras <paulus@samba.org>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 3d108c1cfc2af67d14cb280fb118eee327fbb347
Author: Thomas Huth <thuth@redhat.com>
Date:   Fri Jul 17 12:46:58 2015 +0200

    powerpc/rtas: Introduce rtas_get_sensor_fast() for IRQ handlers

    [ Upstream commit 1c2cb594441d02815d304cccec9742ff5c707495 ]

    The EPOW interrupt handler uses rtas_get_sensor(), which in turn
    uses rtas_busy_delay() to wait for RTAS becoming ready in case it
    is necessary. But rtas_busy_delay() is annotated with might_sleep()
    and thus may not be used by interrupts handlers like the EPOW handler!
    This leads to the following BUG when CONFIG_DEBUG_ATOMIC_SLEEP is
    enabled:

     BUG: sleeping function called from invalid context at arch/powerpc/kernel/rtas.c:496
     in_atomic(): 1, irqs_disabled(): 1, pid: 0, name: swapper/1
     CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.2.0-rc2-thuth #6
     Call Trace:
     [c00000007ffe7b90] [c000000000807670] dump_stack+0xa0/0xdc (unreliable)
     [c00000007ffe7bc0] [c0000000000e1f14] ___might_sleep+0x134/0x180
     [c00000007ffe7c20] [c00000000002aec0] rtas_busy_delay+0x30/0xd0
     [c00000007ffe7c50] [c00000000002bde4] rtas_get_sensor+0x74/0xe0
     [c00000007ffe7ce0] [c000000000083264] ras_epow_interrupt+0x44/0x450
     [c00000007ffe7d90] [c000000000120260] handle_irq_event_percpu+0xa0/0x300
     [c00000007ffe7e70] [c000000000120524] handle_irq_event+0x64/0xc0
     [c00000007ffe7eb0] [c000000000124dbc] handle_fasteoi_irq+0xec/0x260
     [c00000007ffe7ef0] [c00000000011f4f0] generic_handle_irq+0x50/0x80
     [c00000007ffe7f20] [c000000000010f3c] __do_irq+0x8c/0x200
     [c00000007ffe7f90] [c0000000000236cc] call_do_irq+0x14/0x24
     [c00000007e6f39e0] [c000000000011144] do_IRQ+0x94/0x110
     [c00000007e6f3a30] [c000000000002594] hardware_interrupt_common+0x114/0x180

    Fix this issue by introducing a new rtas_get_sensor_fast() function
    that does not use rtas_busy_delay() - and thus can only be used for
    sensors that do not cause a BUSY condition - known as "fast" sensors.

    The EPOW sensor is defined to be "fast" in sPAPR - mpe.

    Fixes: 587f83e8dd50 ("powerpc/pseries: Use rtas_get_sensor in RAS code")
    Signed-off-by: Thomas Huth <thuth@redhat.com>
    Reviewed-by: Nathan Fontenot <nfont@linux.vnet.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit fb508c16d90ab7964fdbb38374954343159e1435
Author: Michael Ellerman <mpe@ellerman.id.au>
Date:   Fri Aug 7 16:19:43 2015 +1000

    powerpc/mm: Fix pte_pagesize_index() crash on 4K w/64K hash

    [ Upstream commit 74b5037baa2011a2799e2c43adde7d171b072f9e ]

    The powerpc kernel can be built to have either a 4K PAGE_SIZE or a 64K
    PAGE_SIZE.

    However when built with a 4K PAGE_SIZE there is an additional config
    option which can be enabled, PPC_HAS_HASH_64K, which means the kernel
    also knows how to hash a 64K page even though the base PAGE_SIZE is 4K.

    This is used in one obscure configuration, to support 64K pages for SPU
    local store on the Cell processor when the rest of the kernel is using
    4K pages.

    In this configuration, pte_pagesize_index() is defined to just pass
    through its arguments to get_slice_psize(). However pte_pagesize_index()
    is called for both user and kernel addresses, whereas get_slice_psize()
    only knows how to handle user addresses.

    This has been broken forever, however until recently it happened to
    work. That was because in get_slice_psize() the large kernel address
    would cause the right shift of the slice mask to return zero.

    However in commit 7aa0727f3302 ("powerpc/mm: Increase the slice range to
    64TB"), the get_slice_psize() code was changed so that instead of a
    right shift we do an array lookup based on the address. When passed a
    kernel address this means we index way off the end of the slice array
    and return random junk.

    That is only fatal if we happen to hit something non-zero, but when we
    do return a non-zero value we confuse the MMU code and eventually cause
    a check stop.

    This fix is ugly, but simple. When we're called for a kernel address we
    return 4K, which is always correct in this configuration, otherwise we
    use the slice mask.

    Fixes: 7aa0727f3302 ("powerpc/mm: Increase the slice range to 64TB")
    Reported-by: Cyril Bur <cyrilbur@gmail.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 9d2debc73c13911b0969e34b0a2b4ca0c0d249d3
Author: Takashi Iwai <tiwai@suse.de>
Date:   Thu Aug 13 18:05:06 2015 +0200

    ALSA: hda - Use ALC880_FIXUP_FUJITSU for FSC Amilo M1437

    [ Upstream commit a161574e200ae63a5042120e0d8c36830e81bde3 ]

    It turned out that the machine has a bass speaker, so take a correct
    fixup entry.

    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=102501
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 60300afece1ee742fd4514654d87bd82441821e3
Author: Takashi Iwai <tiwai@suse.de>
Date:   Thu Aug 13 18:02:39 2015 +0200

    ALSA: hda - Enable headphone jack detect on old Fujitsu laptops

    [ Upstream commit bb148bdeb0ab16fc0ae8009799471e4d7180073b ]

    According to the bug report, FSC Amilo laptops with ALC880 can detect
    the headphone jack but currently the driver disables it.  It's partly
    intentionally, as non-working jack detect was reported in the past.
    Let's enable now.

    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=102501
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit ae78a159fed6e17c22dfeb1c6c18ce442d2f8d89
Author: Takashi Iwai <tiwai@suse.de>
Date:   Thu Sep 3 22:20:00 2015 -0700

    Input: evdev - do not report errors form flush()

    [ Upstream commit eb38f3a4f6e86f8bb10a3217ebd85ecc5d763aae ]

    We've got bug reports showing the old systemd-logind (at least
    system-210) aborting unexpectedly, and this turned out to be because
    of an invalid error code from close() call to evdev devices.  close()
    is supposed to return only either EINTR or EBADFD, while the device
    returned ENODEV.  logind was overreacting to it and decided to kill
    itself when an unexpected error code was received.  What a tragedy.

    The bad error code comes from flush fops, and actually evdev_flush()
    returns ENODEV when device is disconnected or client's access to it is
    revoked. But in these cases the fact that flush did not actually happen is
    not an error, but rather normal behavior. For non-disconnected devices
    result of flush is also not that interesting as there is no potential of
    data loss and even if it fails application has no way of handling the
    error. Because of that we are better off always returning success from
    evdev_flush().

    Also returning EINTR from flush()/close() is discouraged (as it is not
    clear how application should handle this error), so let's stop taking
    evdev->mutex interruptibly.

    Bugzilla: http://bugzilla.suse.com/show_bug.cgi?id=939834
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 5fc83fad2a50c76695d7e56b48a1849b815229ae
Author: Marc Zyngier <marc.zyngier@arm.com>
Date:   Wed Sep 16 16:18:59 2015 +0100

    arm64: KVM: Disable virtual timer even if the guest is not using it

    [ Upstream commit c4cbba9fa078f55d9f6d081dbb4aec7cf969e7c7 ]

    When running a guest with the architected timer disabled (with QEMU and
    the kernel_irqchip=off option, for example), it is important to make
    sure the timer gets turned off. Otherwise, the guest may try to
    enable it anyway, leading to a screaming HW interrupt.

    The fix is to unconditionally turn off the virtual timer on guest
    exit.

    Cc: stable@vger.kernel.org
    Reviewed-by: Christoffer Dall <christoffer.dall@linaro.org>
    Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 87b71fa85761e22cfb4ba62b6f54bbc57863a37d
Author: Will Deacon <will.deacon@arm.com>
Date:   Tue Mar 17 12:15:02 2015 +0000

    arm64: errata: add module build workaround for erratum #843419

    [ Upstream commit df057cc7b4fa59e9b55f07ffdb6c62bf02e99a00 ]

    Cortex-A53 processors <= r0p4 are affected by erratum #843419 which can
    lead to a memory access using an incorrect address in certain sequences
    headed by an ADRP instruction.

    There is a linker fix to generate veneers for ADRP instructions, but
    this doesn't work for kernel modules which are built as unlinked ELF
    objects.

    This patch adds a new config option for the erratum which, when enabled,
    builds kernel modules with the mcmodel=large flag. This uses absolute
    addressing for all kernel symbols, thereby removing the use of ADRP as
    a PC-relative form of addressing. The ADRP relocs are removed from the
    module loader so that we fail to load any potentially affected modules.

    Cc: <stable@vger.kernel.org>
    Acked-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 0d4e0280e189269c26454584a83c2ab9a10a2c06
Author: Will Deacon <will.deacon@arm.com>
Date:   Wed Sep 2 18:49:28 2015 +0100

    arm64: head.S: initialise mdcr_el2 in el2_setup

    [ Upstream commit d10bcd473301888f957ec4b6b12aa3621be78d59 ]

    When entering the kernel at EL2, we fail to initialise the MDCR_EL2
    register which controls debug access and PMU capabilities at EL1.

    This patch ensures that the register is initialised so that all traps
    are disabled and all the PMU counters are available to the host. When a
    guest is scheduled, KVM takes care to configure trapping appropriately.

    Cc: <stable@vger.kernel.org>
    Acked-by: Marc Zyngier <marc.zyngier@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 38dc08cef862db3e36ca9834d64864c15a25b1dc
Author: Will Deacon <will.deacon@arm.com>
Date:   Tue Sep 15 12:07:06 2015 +0100

    arm64: compat: fix vfp save/restore across signal handlers in big-endian

    [ Upstream commit bdec97a855ef1e239f130f7a11584721c9a1bf04 ]

    When saving/restoring the VFP registers from a compat (AArch32)
    signal frame, we rely on the compat registers forming a prefix of the
    native register file and therefore make use of copy_{to,from}_user to
    transfer between the native fpsimd_state and the compat_vfp_sigframe.

    Unfortunately, this doesn't work so well in a big-endian environment.
    Our fpsimd save/restore code operates directly on 128-bit quantities
    (Q registers) whereas the compat_vfp_sigframe represents the registers
    as an array of 64-bit (D) registers. The architecture packs the compat D
    registers into the Q registers, with the least significant bytes holding
    the lower register. Consequently, we need to swap the 64-bit halves when
    converting between these two representations on a big-endian machine.

    This patch replaces the __copy_{to,from}_user invocations in our
    compat VFP signal handling code with explicit __put_user loops that
    operate on 64-bit values and swap them accordingly.

    Cc: <stable@vger.kernel.org>
    Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 6faa56d421e277f8d08ab02de615b9080c629837
Author: Jeff Vander Stoep <jeffv@google.com>
Date:   Tue Aug 18 20:50:10 2015 +0100

    arm64: kconfig: Move LIST_POISON to a safe value

    [ Upstream commit bf0c4e04732479f650ff59d1ee82de761c0071f0 ]

    Move the poison pointer offset to 0xdead000000000000, a
    recognized value that is not mappable by user-space exploits.

    Cc: <stable@vger.kernel.org>
    Acked-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Thierry Strudel <tstrudel@google.com>
    Signed-off-by: Jeff Vander Stoep <jeffv@google.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit dabbb4936dc232bffb5467c3aaf9d2ced053aa55
Author: Bob Copeland <me@bobcopeland.com>
Date:   Sat Jun 13 10:16:31 2015 -0400

    mac80211: enable assoc check for mesh interfaces

    [ Upstream commit 3633ebebab2bbe88124388b7620442315c968e8f ]

    We already set a station to be associated when peering completes, both
    in user space and in the kernel.  Thus we should always have an
    associated sta before sending data frames to that station.

    Failure to check assoc state can cause crashes in the lower-level driver
    due to transmitting unicast data frames before driver sta structures
    (e.g. ampdu state in ath9k) are initialized.  This occurred when
    forwarding in the presence of fixed mesh paths: frames were transmitted
    to stations with whom we hadn't yet completed peering.

    Cc: stable@vger.kernel.org
    Reported-by: Alexis Green <agreen@cococorp.com>
    Tested-by: Jesse Jones <jjones@cococorp.com>
    Signed-off-by: Bob Copeland <me@bobcopeland.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit f37667746772aaf74372a661ac9be0e2f8bbf87a
Author: Jean Delvare <jdelvare@suse.de>
Date:   Tue Sep 1 18:07:41 2015 +0200

    tg3: Fix temperature reporting

    [ Upstream commit d3d11fe08ccc9bff174fc958722b5661f0932486 ]

    The temperature registers appear to report values in degrees Celsius
    while the hwmon API mandates values to be exposed in millidegrees
    Celsius. Do the conversion so that the values reported by "sensors"
    are correct.

    Fixes: aed93e0bf493 ("tg3: Add hwmon support for temperature")
    Signed-off-by: Jean Delvare <jdelvare@suse.de>
    Cc: Prashant Sreedharan <prashant@broadcom.com>
    Cc: Michael Chan <mchan@broadcom.com>
    Cc: stable@vger.kernel.org [v3.6+]
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 125f124f47bdc80702e69e1b912989bad1398a84
Author: Eric W. Biederman <ebiederm@xmission.com>
Date:   Mon Aug 10 17:35:07 2015 -0500

    unshare: Unsharing a thread does not require unsharing a vm

    [ Upstream commit 12c641ab8270f787dfcce08b5f20ce8b65008096 ]

    In the logic in the initial commit of unshare made creating a new
    thread group for a process, contingent upon creating a new memory
    address space for that process.  That is wrong.  Two separate
    processes in different thread groups can share a memory address space
    and clone allows creation of such proceses.

    This is significant because it was observed that mm_users > 1 does not
    mean that a process is multi-threaded, as reading /proc/PID/maps
    temporarily increments mm_users, which allows other processes to
    (accidentally) interfere with unshare() calls.

    Correct the check in check_unshare_flags() to test for
    !thread_group_empty() for CLONE_THREAD, CLONE_SIGHAND, and CLONE_VM.
    For sighand->count > 1 for CLONE_SIGHAND and CLONE_VM.
    For !current_is_single_threaded instead of mm_users > 1 for CLONE_VM.

    By using the correct checks in unshare this removes the possibility of
    an accidental denial of service attack.

    Additionally using the correct checks in unshare ensures that only an
    explicit unshare(CLONE_VM) can possibly trigger the slow path of
    current_is_single_threaded().  As an explict unshare(CLONE_VM) is
    pointless it is not expected there are many applications that make
    that call.

    Cc: stable@vger.kernel.org
    Fixes: b2e0d98705e60e45bbb3c0032c48824ad7ae0704 userns: Implement unshare of the user namespace
    Reported-by: Ricky Zhou <rickyz@chromium.org>
    Reported-by: Kees Cook <keescook@chromium.org>
    Reviewed-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 14982eddaefdb75c39bb5b1d3459ef21daea33ed
Author: Ming Lei <ming.lei@canonical.com>
Date:   Sun Aug 9 03:41:50 2015 -0400

    blk-mq: fix buffer overflow when reading sysfs file of 'pending'

    [ Upstream commit 596f5aad2a704b72934e5abec1b1b4114c16f45b ]

    There may be lots of pending requests so that the buffer of PAGE_SIZE
    can't hold them at all.

    One typical example is scsi-mq, the queue depth(.can_queue) of
    scsi_host and blk-mq is quite big but scsi_device's queue_depth
    is a bit small(.cmd_per_lun), then it is quite easy to have lots
    of pending requests in hw queue.

    This patch fixes the following warning and the related memory
    destruction.

    [  359.025101] fill_read_buffer: blk_mq_hw_sysfs_show+0x0/0x7d returned bad count^M
    [  359.055595] irq event stamp: 15537^M
    [  359.055606] general protection fault: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC ^M
    [  359.055614] Dumping ftrace buffer:^M
    [  359.055660]    (ftrace buffer empty)^M
    [  359.055672] Modules linked in: nbd ipv6 kvm_intel kvm serio_raw^M
    [  359.055678] CPU: 4 PID: 21631 Comm: stress-ng-sysfs Not tainted 4.2.0-rc5-next-20150805 #434^M
    [  359.055679] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011^M
    [  359.055682] task: ffff8802161cc000 ti: ffff88021b4a8000 task.ti: ffff88021b4a8000^M
    [  359.055693] RIP: 0010:[<ffffffff811541c5>]  [<ffffffff811541c5>] __kmalloc+0xe8/0x152^M

    Cc: <stable@vger.kernel.org>
    Signed-off-by: Ming Lei <ming.lei@canonical.com>
    Signed-off-by: Jens Axboe <axboe@fb.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 3c3b6c4338a98d671015c8cc895ef3319c342af5 (tag: 2.9.0_20180918-1544)
Author: Jenkins <jenkins@bqbot.bq.local>
Date:   Wed Oct 17 14:28:58 2018 +0200

    Version 2.9.0_20180918-1544 released

commit 824af7f4a1fe77948c5e2e9ad297cd006dfc1ee1 (tag: 2.8.0_20180514-1614)
Author: Jenkins <jenkins@bqbot.bq.local>
Date:   Tue May 29 14:05:49 2018 +0200

    Version 2.8.0_20180514-1614 released

commit da78d0f22f3a31008788071f0b0c7dc69893aa7f (tag: 2.7.0_20180301-0952)
Author: Jenkins <jenkins@bqbot.bq.local>
Date:   Mon Mar 19 12:49:18 2018 +0100

    Version 2.7.0_20180301-0952 released

commit cae1942ba4d6ba74c3cfd9a9e8e6ebddddb0d542 (tag: 2.6.2_20180126-1035, tag: 2.6.0_20171221-1051)
Author: Jenkins <jenkins@bqbot.bq.local>
Date:   Fri Dec 29 13:14:00 2017 +0100

    Version 2.6.0_20171221-1051 released

commit eba0fa2f0459fca1207334a8f0e532595bcef53c (tag: 2.5.0_20170911-1032)
Author: Jenkins <jenkins@bqbot.bq.local>
Date:   Mon Sep 25 12:07:59 2017 +0200

    Version 2.5.0_20170911-1032 released

commit cfd722448994d16140d1ac6289de749f1b6f9c8a (tag: 2.4.0_20170619-0900)
Author: Jenkins <jenkins@bqbot.bq.local>
Date:   Mon Jun 26 15:06:50 2017 +0200

    Version 2.4.0_20170619-0900 released

commit d53a412245c9ed05f0440270fc83b1db6d250b3b (tag: 2.3.0_20170405-1554)
Author: Jenkins <jenkins@bqbot.bq.local>
Date:   Mon Apr 24 11:01:59 2017 +0200

    Version 2.3.0_20170405-1554 released

commit 1ebb8de13024abc8a424d8417f75c34daadeaa39 (tag: 2.1.1_20161020-1222)
Author: Jenkins <jenkins@bqbot.bq.local>
Date:   Mon Oct 31 11:41:10 2016 +0100

    Version 2.1.1_20161020-1222 released

commit 49283b7994e37386c4cfbceaf9927391abfb541b (tag: 2.1.0_20160907-1500)
Author: Jenkins <jenkins@bqbot.bq.local>
Date:   Mon Oct 31 11:37:24 2016 +0100

    Version 2.1.0_20160907-1500 released

commit ef70771e85978d94062f4d8f48038d3b4a1faec6 (tag: 2.0.0_20160817-1110)
Author: Jenkins <jenkins@bqbot.bq.local>
Date:   Wed Oct 26 16:28:01 2016 +0200

    Version 2.0.0_20160817-1110 released