30 May, 2018

40 commits

  • [ Upstream commit bbc09e7842a5023ba5bc0f8d559b9dd464e44006 ]

    when the following command sequence is entered

    # tc action add action bpf bytecode '4,40 0 0 12,31 0 1 2048,6 0 0 262144,6 0 0 0' index 100
    RTNETLINK answers: Invalid argument
    We have an error talking to the kernel
    # tc action add action bpf bytecode '4,40 0 0 12,21 0 1 2048,6 0 0 262144,6 0 0 0' index 100
    RTNETLINK answers: No space left on device
    We have an error talking to the kernel

    act_bpf correctly refuses to install the first TC rule, because 31 is not
    a valid instruction. However, it refuses to install the second TC rule,
    even if the BPF code is correct. Furthermore, it's no more possible to
    install any other rule having the same value of 'index' until act_bpf
    module is unloaded/inserted again. After the idr has been reserved, call
    tcf_idr_release() instead of tcf_idr_cleanup(), to fix this issue.

    Fixes: 65a206c01e8e ("net/sched: Change act_api and act_xxx modules to use IDR")
    Acked-by: Jamal Hadi Salim
    Signed-off-by: Davide Caratti
    Signed-off-by: David S. Miller
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Davide Caratti
     
  • [ Upstream commit caf61b1b8b88ccf1451f7321a176393797e8d292 ]

    Once the FW is transitioned to error, FLUSH cqes can be received.
    We want the driver to be aware of the fact that QP is already in error.

    Without this fix, a user may see false error messages in the dmesg log,
    mentioning that a FLUSH cqe was received while QP is not in error state.

    Fixes: cecbcddf ("qedr: Add support for QP verbs")
    Signed-off-by: Michal Kalderon
    Signed-off-by: Ariel Elior
    Signed-off-by: Jason Gunthorpe
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Kalderon, Michal
     
  • [ Upstream commit b15606f47b89b0b09936d7f45b59ba6275527041 ]

    Return code wasn't set properly when CNQ allocation failed.
    This only affect error message logging, currently user will
    receive an error message that says the qedr driver load failed
    with rc '0', instead of ENOMEM

    Fixes: ec72fce4 ("qedr: Add support for RoCE HW init")
    Signed-off-by: Michal Kalderon
    Signed-off-by: Ariel Elior
    Signed-off-by: Jason Gunthorpe
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Kalderon, Michal
     
  • [ Upstream commit c3594f22302cca5e924e47ec1cc8edd265708f41 ]

    QPs that were configured with ack timeout value lower than 1
    msec will not implement re-transmission timeout.
    This means that if a packet / ACK were dropped, the QP
    will not retransmit this packet.

    This can lead to an application hang.

    Fixes: cecbcddf6 ("qedr: Add support for QP verbs")
    Signed-off-by: Michal Kalderon
    Signed-off-by: Ariel Elior
    Signed-off-by: Jason Gunthorpe
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Kalderon, Michal
     
  • [ Upstream commit 5f3e3b85cc0a5eae1c46d72e47d3de7bf208d9e2 ]

    The option size check is using optval instead of optlen
    causing the set option call to fail. Use the correct
    field, optlen, for size check.

    Fixes: 6a21dfc0d0db ("RDMA/ucma: Limit possible option size")
    Signed-off-by: Chien Tin Tung
    Signed-off-by: Shiraz Saleem
    Reviewed-by: Leon Romanovsky
    Signed-off-by: Jason Gunthorpe
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Chien Tin Tung
     
  • [ Upstream commit 825d487583089f9a33d31650c9c41f6474aab7fc ]

    Some filesystems have timestamps with coarse precision that may allow
    for a recently built object file to have the same timestamp as the
    updated time on one of its dependency files. When that happens, the
    object file doesn't get rebuilt as it should.

    This is especially the case on filesystems that don't have sub-second
    time precision, such as ext3 or Ext4 with 128B inodes.

    Let's prevent that by making sure updated dependency files have a newer
    timestamp than the first file we created (i.e. autoksyms.h.tmpnew).

    Reported-by: Thomas Lindroth
    Signed-off-by: Nicolas Pitre
    Tested-by: Thomas Lindroth
    Signed-off-by: Masahiro Yamada
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Nicolas Pitre
     
  • [ Upstream commit 9b9322db5c5a1917a66c71fe47c3848a9a31227e ]

    The commit "regulatory: add NUL to request alpha2" increases the length of
    alpha2 to 3. This causes a regression on brcmfmac, because
    brcmf_cfg80211_reg_notifier() expect valid ISO3166 codes in the complete
    array. So fix this accordingly.

    Fixes: 657308f73e67 ("regulatory: add NUL to request alpha2")
    Signed-off-by: Stefan Wahren
    Acked-by: Franky Lin
    Signed-off-by: Kalle Valo
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Stefan Wahren
     
  • [ Upstream commit c917e0f259908e75bd2a65877e25f9d90c22c848 ]

    When a perf_event is attached to parent cgroup, it should count events
    for all children cgroups:

    parent_group /sys/fs/cgroup/p/c/cgroup.procs

    # after the test process is done, stop perf in the first console shows

    instructions p

    The instruction should not be "not counted" as the process runs in the
    child cgroup.

    We found this is because perf_event->cgrp and cpuctx->cgrp are not
    identical, thus perf_event->cgrp are not updated properly.

    This patch fixes this by updating perf_cgroup properly for ancestor
    cgroup(s).

    Reported-by: Ephraim Park
    Signed-off-by: Song Liu
    Signed-off-by: Peter Zijlstra (Intel)
    Cc:
    Cc:
    Cc: Alexander Shishkin
    Cc: Arnaldo Carvalho de Melo
    Cc: Jiri Olsa
    Cc: Linus Torvalds
    Cc: Peter Zijlstra
    Cc: Stephane Eranian
    Cc: Thomas Gleixner
    Cc: Vince Weaver
    Link: http://lkml.kernel.org/r/20180312165943.1057894-1-songliubraving@fb.com
    Signed-off-by: Ingo Molnar
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Song Liu
     
  • [ Upstream commit 192b4af6cd28cdad9b42fd79c21a90a2aeb0bec7 ]

    Since commit 846c7dfc1193 ("drm/atomic: Try to preserve the crtc enabled
    state in drm_atomic_remove_fb, v2."), removing the last framebuffer will
    no longer disable the corresponding pipeline, which causes the KMS core
    to complain about leaked connectors on driver unbind.

    Fix this by calling drm_atomic_helper_shutdown() on driver unbind, which
    will cause all display pipelines to be shut down and therefore drop the
    extra references on the connectors.

    Signed-off-by: Thierry Reding
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Thierry Reding
     
  • [ Upstream commit 4a6d2e525b43eba5870ea7e360f59aa65de00705 ]

    When starting aggregation, the code checks the status of the queue
    allocated to the aggregation tid, which might not yet be allocated
    and thus the queue index may be invalid.
    Fix this by reserving a new queue in case the queue id is invalid.

    While at it, clean up some unreachable code (a condition that is
    already handled earlier) and remove all the non-DQA comments since
    non-DQA mode is no longer supported.

    Fixes: cf961e16620f ("iwlwifi: mvm: support dqa-mode agg on non-shared queue")
    Signed-off-by: Avraham Stern
    Signed-off-by: Luca Coelho
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Avraham Stern
     
  • [ Upstream commit df65c8d1728adee2a52c30287d33da83a8c87480 ]

    If the driver failed to resume from D3, it is possible that it has
    no valid aux station. In such case, fw restart will end up in sending
    station related commands with an invalid station id, which will
    result in an assert.

    Fix this by allocating a new station id for the aux station if it
    does not have a valid id even in the case of fw restart.

    Signed-off-by: Avraham Stern
    Signed-off-by: Luca Coelho
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Avraham Stern
     
  • [ Upstream commit 4b387906b1c3692bb790388c335515c0cf098a23 ]

    When a queue is reserved for aggregation, the queue id is assigned
    to the tid_data. This is fine since iwl_mvm_sta_tx_agg_oper()
    takes care of allocating the queue before actual tx starts.
    When the reservation is cancelled (e.g. when the AP declined the
    aggregation request) the tid_data is not cleared. As a result,
    following tx for this tid was trying to use an unallocated queue.

    Fix this by setting the txq_id for the tid to invalid when unreserving
    the queue.

    Signed-off-by: Avraham Stern
    Signed-off-by: Luca Coelho
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Avraham Stern
     
  • [ Upstream commit 19125cb0591ae63cd4591e3dfe4c22058e748518 ]

    After switching to a new channel, driver schedules session protection
    time event in order to hear the beacon on the new channel.
    The duration of the protection is two beacon intervals.
    However, since we start to switch slightly before beacon with count 1, in
    case we don't hear (or AP doesn't transmit) the very first beacon on the
    new channel the protection ends without hearing any beacon at all.
    At this stage the switch is not complete, the queues are closed and the
    interface doesn't have quota yet or TBTT events. As the result, we are
    stuck forever waiting for iwl_mvm_post_channel_switch() to be called.

    Fix this by increasing the protection time to be 3 beacon intervals and
    in addition drop the connection if the time event ends before we got any
    beacon.

    Signed-off-by: Andrei Otcheretianski
    Signed-off-by: Luca Coelho
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Andrei Otcheretianski
     
  • [ Upstream commit f8a554b4aa9686bb2c12f6bae516e58783289a03 ]

    We shouldn't allow a tunnel to have IP_MAX_MTU as MTU, because
    another IPv6 header is going on top of our packets. Without this
    patch, we might end up building packets bigger than IP_MAX_MTU.

    Fixes: b96f9afee4eb ("ipv4/6: use core net MTU range checking")
    Signed-off-by: Stefano Brivio
    Acked-by: Sabrina Dubroca
    Signed-off-by: Steffen Klassert
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Stefano Brivio
     
  • [ Upstream commit 03080e5ec72740c1a62e6730f2a5f3f114f11b19 ]

    Don't hardcode a MTU value on vti tunnel initialization,
    ip_tunnel_newlink() is able to deal with this already. See also
    commit ffc2b6ee4174 ("ip_gre: fix IFLA_MTU ignored on NEWLINK").

    Fixes: 1181412c1a67 ("net/ipv4: VTI support new module for ip_vti.")
    Signed-off-by: Stefano Brivio
    Acked-by: Sabrina Dubroca
    Signed-off-by: Steffen Klassert
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Stefano Brivio
     
  • [ Upstream commit 24fc79798b8ddfd46f2dd363a8d29072c083b977 ]

    Otherwise, it's possible to specify invalid MTU values directly
    on creation of a link (via 'ip link add'). This is already
    prevented on subsequent MTU changes by commit b96f9afee4eb
    ("ipv4/6: use core net MTU range checking").

    Fixes: c54419321455 ("GRE: Refactor GRE tunneling code.")
    Signed-off-by: Stefano Brivio
    Acked-by: Sabrina Dubroca
    Signed-off-by: Steffen Klassert
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Stefano Brivio
     
  • [ Upstream commit dd1df24737727e119c263acf1be2a92763938297 ]

    This re-introduces the effect of commit a32452366b72 ("vti4:
    Don't count header length twice.") which was accidentally
    reverted by merge commit f895f0cfbb77 ("Merge branch 'master' of
    git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec").

    The commit message from Steffen Klassert said:

    We currently count the size of LL_MAX_HEADER and struct iphdr
    twice for vti4 devices, this leads to a wrong device mtu.
    The size of LL_MAX_HEADER and struct iphdr is already counted in
    ip_tunnel_bind_dev(), so don't do it again in vti_tunnel_init().

    And this is still the case now: ip_tunnel_bind_dev() already
    accounts for the header length of the link layer (not
    necessarily LL_MAX_HEADER, if the output device is found), plus
    one IP header.

    For example, with a vti device on top of veth, with MTU of 1500,
    the existing implementation would set the initial vti MTU to
    1332, accounting once for LL_MAX_HEADER (128, included in
    hard_header_len by vti) and twice for the same IP header (once
    from hard_header_len, once from ip_tunnel_bind_dev()).

    It should instead be 1480, because ip_tunnel_bind_dev() is able
    to figure out that the output device is veth, so no additional
    link layer header is attached, and will properly count one
    single IP header.

    The existing issue had the side effect of avoiding PMTUD for
    most xfrm policies, by arbitrarily lowering the initial MTU.
    However, the only way to get a consistent PMTU value is to let
    the xfrm PMTU discovery do its course, and commit d6af1a31cc72
    ("vti: Add pmtu handling to vti_xmit.") now takes care of local
    delivery cases where the application ignores local socket
    notifications.

    Fixes: b9959fd3b0fa ("vti: switch to new ip tunnel code")
    Fixes: f895f0cfbb77 ("Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec")
    Signed-off-by: Stefano Brivio
    Acked-by: Sabrina Dubroca
    Signed-off-by: Steffen Klassert
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Stefano Brivio
     
  • [ Upstream commit fc04fdb2c8a894283259f5621d31d75610701091 ]

    batadv_check_unicast_ttvn may redirect a packet to itself or another
    originator. This involves rewriting the ttvn and the destination address in
    the batadv unicast header. These field were not yet pulled (with skb rcsum
    update) and thus any change to them also requires a change in the receive
    checksum.

    Reported-by: Matthias Schiffer
    Fixes: a73105b8d4c7 ("batman-adv: improved client announcement mechanism")
    Signed-off-by: Sven Eckelmann
    Signed-off-by: Simon Wunderlich
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Sven Eckelmann
     
  • [ Upstream commit 1f110e7cae09e6c6a144616480d1a9dd99c5208a ]

    when the following command

    # tc action add action sample rate 100 group 100 index 100

    is run for the first time, and psample_group_get(100) fails to create a
    new group, tcf_sample_cleanup() calls psample_group_put(NULL), thus
    causing the following error:

    BUG: unable to handle kernel NULL pointer dereference at 000000000000001c
    IP: psample_group_put+0x15/0x71 [psample]
    PGD 8000000075775067 P4D 8000000075775067 PUD 7453c067 PMD 0
    Oops: 0002 [#1] SMP PTI
    Modules linked in: act_sample(E) psample ip6table_filter ip6_tables iptable_filter binfmt_misc ext4 snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hda_core mbcache jbd2 crct10dif_pclmul snd_hwdep crc32_pclmul snd_seq ghash_clmulni_intel pcbc snd_seq_device snd_pcm aesni_intel crypto_simd snd_timer glue_helper snd cryptd joydev pcspkr i2c_piix4 soundcore virtio_balloon nfsd auth_rpcgss nfs_acl lockd grace sunrpc ip_tables xfs libcrc32c ata_generic pata_acpi qxl drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm virtio_net ata_piix virtio_console virtio_blk libata serio_raw crc32c_intel virtio_pci i2c_core virtio_ring virtio floppy dm_mirror dm_region_hash dm_log dm_mod [last unloaded: act_tunnel_key]
    CPU: 2 PID: 5740 Comm: tc Tainted: G E 4.16.0-rc4.act_vlan.orig+ #403
    Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
    RIP: 0010:psample_group_put+0x15/0x71 [psample]
    RSP: 0018:ffffb8a80032f7d0 EFLAGS: 00010246
    RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000024
    RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffffffffc06d93c0
    RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000044
    R10: 00000000bd003000 R11: ffff979fba04aa59 R12: 0000000000000000
    R13: 0000000000000000 R14: 0000000000000000 R15: ffff979fbba3f22c
    FS: 00007f7638112740(0000) GS:ffff979fbfd00000(0000) knlGS:0000000000000000
    CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 000000000000001c CR3: 00000000734ea001 CR4: 00000000001606e0
    Call Trace:
    __tcf_idr_release+0x79/0xf0
    tcf_sample_init+0x125/0x1d0 [act_sample]
    tcf_action_init_1+0x2cc/0x430
    tcf_action_init+0xd3/0x1b0
    tc_ctl_action+0x18b/0x240
    rtnetlink_rcv_msg+0x29c/0x310
    ? _cond_resched+0x15/0x30
    ? __kmalloc_node_track_caller+0x1b9/0x270
    ? rtnl_calcit.isra.28+0x100/0x100
    netlink_rcv_skb+0xd2/0x110
    netlink_unicast+0x17c/0x230
    netlink_sendmsg+0x2cd/0x3c0
    sock_sendmsg+0x30/0x40
    ___sys_sendmsg+0x27a/0x290
    ? filemap_map_pages+0x34a/0x3a0
    ? __handle_mm_fault+0xbfd/0xe20
    __sys_sendmsg+0x51/0x90
    do_syscall_64+0x6e/0x1a0
    entry_SYSCALL_64_after_hwframe+0x3d/0xa2
    RIP: 0033:0x7f7637523ba0
    RSP: 002b:00007fff0473ef58 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
    RAX: ffffffffffffffda RBX: 00007fff0473f080 RCX: 00007f7637523ba0
    RDX: 0000000000000000 RSI: 00007fff0473efd0 RDI: 0000000000000003
    RBP: 000000005aaaac80 R08: 0000000000000002 R09: 0000000000000000
    R10: 00007fff0473e9e0 R11: 0000000000000246 R12: 0000000000000000
    R13: 00007fff0473f094 R14: 0000000000000001 R15: 0000000000669f60
    Code: be 02 00 00 00 48 89 df e8 a9 fe ff ff e9 7c ff ff ff 0f 1f 40 00 0f 1f 44 00 00 53 48 89 fb 48 c7 c7 c0 93 6d c0 e8 db 20 8c ef 6b 1c 01 74 10 48 c7 c7 c0 93 6d c0 ff 14 25 e8 83 83 b0 5b
    RIP: psample_group_put+0x15/0x71 [psample] RSP: ffffb8a80032f7d0
    CR2: 000000000000001c

    Fix it in tcf_sample_cleanup(), ensuring that calls to psample_group_put(p)
    are done only when p is not NULL.

    Fixes: cadb9c9fdbc6 ("net/sched: act_sample: Fix error path in init")
    Signed-off-by: Davide Caratti
    Acked-by: Jiri Pirko
    Signed-off-by: David S. Miller
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Davide Caratti
     
  • [ Upstream commit 6f27d2c2a8c236d296201c19abb8533ec20d212b ]

    Checking for 0 is insufficient: when an SKB without a batadv header, but
    with a VLAN header is received, hdr_size will be 4, making the following
    code interpret the Ethernet header as a batadv header.

    Fixes: be1db4f6615b ("batman-adv: make the Distributed ARP Table vlan aware")
    Signed-off-by: Matthias Schiffer
    Signed-off-by: Sven Eckelmann
    Signed-off-by: Simon Wunderlich
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Matthias Schiffer
     
  • [ Upstream commit cbe7128c4b92e2004984f477fd38dfa81662f02e ]

    With reorder header off, received packets are untagged in skb_vlan_untag()
    called from within __netif_receive_skb_core(), and later the tag will be
    inserted back in vlan_do_receive().

    This caused out of order vlan headers when we create a vlan device on top
    of another vlan device, because vlan_do_receive() inserts a tag as the
    outermost vlan tag. E.g. the outer tag is first removed in skb_vlan_untag()
    and inserted back in vlan_do_receive(), then the inner tag is next removed
    and inserted back as the outermost tag.

    This patch fixes the behaviour by inserting the inner tag at the right
    position.

    Signed-off-by: Toshiaki Makita
    Signed-off-by: David S. Miller
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Toshiaki Makita
     
  • [ Upstream commit 4bbb3e0e8239f9079bf1fe20b3c0cb598714ae61 ]

    When we have a bridge with vlan_filtering on and a vlan device on top of
    it, packets would be corrupted in skb_vlan_untag() called from
    br_dev_xmit().

    The problem sits in skb_reorder_vlan_header() used in skb_vlan_untag(),
    which makes use of skb->mac_len. In this function mac_len is meant for
    handling rx path with vlan devices with reorder_header disabled, but in
    tx path mac_len is typically 0 and cannot be used, which is the problem
    in this case.

    The current code even does not properly handle rx path (skb_vlan_untag()
    called from __netif_receive_skb_core()) with reorder_header off actually.

    In rx path single tag case, it works as follows:

    - Before skb_reorder_vlan_header()

    mac_header data
    v v
    +-------------------+-------------+------+----
    | ETH | VLAN | ETH |
    | ADDRS | TPID | TCI | TYPE |
    +-------------------+-------------+------+----


    to be removed

    - After skb_reorder_vlan_header()

    mac_header data
    v v
    +-------------------+------+----
    | ETH | ETH |
    | ADDRS | TYPE |
    +-------------------+------+----

    This is ok, but in rx double tag case, it corrupts packets:

    - Before skb_reorder_vlan_header()

    mac_header data
    v v
    +-------------------+-------------+-------------+------+----
    | ETH | VLAN | VLAN | ETH |
    | ADDRS | TPID | TCI | TPID | TCI | TYPE |
    +-------------------+-------------+-------------+------+----


    should be removed

    actually will be removed

    - After skb_reorder_vlan_header()

    mac_header data
    v v
    +-------------------+------+----
    | ETH | ETH |
    | ADDRS | TYPE |
    +-------------------+------+----

    So, two of vlan tags are both removed while only inner one should be
    removed and mac_header (and mac_len) is broken.

    skb_vlan_untag() is meant for removing the vlan header at (skb->data - 2),
    so use skb->data and skb->mac_header to calculate the right offset.

    Reported-by: Brandon Carpenter
    Fixes: a6e18ff11170 ("vlan: Fix untag operations of stacked vlans with REORDER_HEADER off")
    Signed-off-by: Toshiaki Makita
    Signed-off-by: David S. Miller
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Toshiaki Makita
     
  • [ Upstream commit 75fd4fec3e4c43b131c7c4958adb3ab9f1665513 ]

    The earlier patch called the station add functions but didn't
    assign their return value to the ret variable, so that the
    checks for it were meaningless. Fix that.

    Found by smatch:

    .../mac80211.c:2560 iwl_mvm_start_ap_ibss() warn: we tested 'ret' before and it was 'false'
    .../mac80211.c:2563 iwl_mvm_start_ap_ibss() warn: we tested 'ret' before and it was 'false'

    Fixes: 3a89411cd31c ("iwlwifi: mvm: fix assert 0x2B00 on older FWs")
    Signed-off-by: Johannes Berg
    Signed-off-by: Luca Coelho
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Johannes Berg
     
  • [ Upstream commit e829b17caf96c2da34620e335fb777592990906c ]

    Currently when an IGTK is set for an AP, it is set as a regular key.
    Since the cipher is set to CMAC, the STA_KEY_FLG_EXT flag is added to
    the host command, which causes assert 0x253D on NICs that do not support
    this.

    Fixes: 85aeb58cec1a ("iwlwifi: mvm: Enable security on new TX API")
    Signed-off-by: Beni Lev
    Signed-off-by: Luca Coelho
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Beni Lev
     
  • [ Upstream commit 334167decf98f01a66c91ea84180c278bc4ad290 ]

    The tid being used for the queue (cab_queue) for the MCAST
    station has been changed recently to be 0 (for BE).
    The flush path still flushed only the special tid (15)
    which means that the firmware wasn't flushing the right
    queue and we could get a firmware crash upon remove
    station if we had an MCAST packet on the ring.

    The current code that flushes queues for a station only
    differentiates between internal stations (stations that
    aren't instantiated in mac80211, like the MCAST station)
    and the non-internal ones.
    Internal stations can be either: BCAST (beacons), MCAST
    (for cab_queue), GENERAL_PURPOSE (p2p dev, and sniffer
    injection). The internal stations can use different tids.

    To make the code simpler, just flush all the tids always
    and add the special internal tid (15) for internal
    stations. The firmware will know how to handle this even
    if we hadn't any queue mapped that that tid.

    Fixes: e340c1a6ef4b ("iwlwifi: mvm: Correctly set the tid for mcast queue")
    Signed-off-by: Emmanuel Grumbach
    Signed-off-by: Luca Coelho
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Emmanuel Grumbach
     
  • [ Upstream commit 46c0ef6e1eb95f619d9f62da4332749153db92f7 ]

    In the xfrm_local_error, rcu_read_unlock should be called when afinfo
    is not NULL. because xfrm_state_get_afinfo calls rcu_read_unlock
    if afinfo is NULL.

    Fixes: af5d27c4e12b ("xfrm: remove xfrm_state_put_afinfo")
    Signed-off-by: Taehee Yoo
    Signed-off-by: Steffen Klassert
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Taehee Yoo
     
  • [ Upstream commit 9e75dc61eaa9acd1bff83c3b814ac2af6dc1f64c ]

    Fixes: 3c66c87dc9 ("drm/nouveau/disp: remove hw-specific customisation
    of output paths")
    Suggested-by: Ben Skeggs
    Signed-off-by: Karol Herbst
    Signed-off-by: Ben Skeggs
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Karol Herbst
     
  • [ Upstream commit 6a055b92de15af987b4027826d43aa103c65a3c4 ]

    Right now the vblank event completion is racing with the atomic update,
    which is especially bad when the PRE is in use, as one of the hardware
    issue workaround might extend the atomic commit for quite some time.

    If the vblank IRQ happens to trigger during that time, we will prematurely
    signal the atomic commit completion to userspace, which causes tearing
    when userspace re-uses a framebuffer we haven't managed to flip away from
    yet.

    Signed-off-by: Lucas Stach
    Signed-off-by: Philipp Zabel
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Lucas Stach
     
  • [ Upstream commit 746d024c3211813946b319411aeb2b47767f8fb0 ]

    gcc-8 reports that we access an array with a negative index
    in an error case:

    drivers/gpu/ipu-v3/ipu-prg.c: In function 'ipu_prg_channel_disable':
    drivers/gpu/ipu-v3/ipu-prg.c:252:43: error: array subscript -22 is below array bounds of 'struct ipu_prg_channel[3]' [-Werror=array-bounds]

    This moves the range check in front of the first time that
    variable gets used.

    Signed-off-by: Arnd Bergmann
    Signed-off-by: Philipp Zabel
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Arnd Bergmann
     
  • [ Upstream commit 62b06f8f429cd233e4e2e7bbd21081ad60c9018f ]

    Our irq_is_pending() helper function accesses multiple members of the
    vgic_irq struct, so we need to hold the lock when calling it.
    Add that requirement as a comment to the definition and take the lock
    around the call in vgic_mmio_read_pending(), where we were missing it
    before.

    Fixes: 96b298000db4 ("KVM: arm/arm64: vgic-new: Add PENDING registers handlers")
    Signed-off-by: Andre Przywara
    Signed-off-by: Marc Zyngier
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Andre Przywara
     
  • [ Upstream commit cf55612a945039476abfd73e39064b2e721c3272 ]

    The NETIF_F_GSO_SOFTWARE implies support for GSO on SCTP, but the
    sunvnet driver does not support GSO for sctp. Here we remove the
    NETIF_F_GSO_SOFTWARE feature flag and only report NETIF_F_ALL_TSO
    instead.

    Signed-off-by: Cathy Zhou
    Signed-off-by: Shannon Nelson
    Signed-off-by: David S. Miller
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Cathy Zhou
     
  • [ Upstream commit d52e5a7e7ca49457dd31fc8b42fb7c0d58a31221 ]

    Prior to the rework of PMTU information storage in commit
    2c8cec5c10bc ("ipv4: Cache learned PMTU information in inetpeer."),
    when a PMTU event advertising a PMTU smaller than
    net.ipv4.route.min_pmtu was received, we would disable setting the DF
    flag on packets by locking the MTU metric, and set the PMTU to
    net.ipv4.route.min_pmtu.

    Since then, we don't disable DF, and set PMTU to
    net.ipv4.route.min_pmtu, so the intermediate router that has this link
    with a small MTU will have to drop the packets.

    This patch reestablishes pre-2.6.39 behavior by splitting
    rtable->rt_pmtu into a bitfield with rt_mtu_locked and rt_pmtu.
    rt_mtu_locked indicates that we shouldn't set the DF bit on that path,
    and is checked in ip_dont_fragment().

    One possible workaround is to set net.ipv4.route.min_pmtu to a value low
    enough to accommodate the lowest MTU encountered.

    Fixes: 2c8cec5c10bc ("ipv4: Cache learned PMTU information in inetpeer.")
    Signed-off-by: Sabrina Dubroca
    Reviewed-by: Stefano Brivio
    Signed-off-by: David S. Miller
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Sabrina Dubroca
     
  • [ Upstream commit 537f4146c53c95aac977852b371bafb9c6755ee1 ]

    Never directly free @dev after calling device_register(), even
    if it returned an error! Always use put_device() to give up the
    reference initialized in this function instead.

    Signed-off-by: Arvind Yadav
    Signed-off-by: Tejun Heo
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Arvind Yadav
     
  • [ Upstream commit 3c4fe80b32c685bdc02b280814d0cfe80d441c72 ]

    During initialization, if we encounter errors, there is a code path that
    calls bnxt_hwrm_vnic_set_tpa() with invalid VNIC ID. This may cause a
    warning in firmware logs.

    Fixes: c0c050c58d84 ("bnxt_en: New Broadcom ethernet driver.")
    Signed-off-by: Michael Chan
    Signed-off-by: David S. Miller
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Michael Chan
     
  • [ Upstream commit c9b3bce18da4a0aebc27853052dea39aa64b7d75 ]

    Make sure to apply the correct pin state in suspend/resume callbacks.
    Putting pins in sleep state saves power.

    Signed-off-by: Bich Hemon
    Signed-off-by: Marc Kleine-Budde
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Bich HEMON
     
  • [ Upstream commit b7db978ac283b237835129ac87f26cbac94d04e7 ]

    Due to a typo, the mask was destroyed by a comparison instead of a bit
    shift.

    Reported-by: Geert Uytterhoeven
    Signed-off-by: Wolfram Sang
    Signed-off-by: Marc Kleine-Budde
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Wolfram Sang
     
  • [ Upstream commit 932909d9b28d27e807ff8eecb68c7748f6701628 ]

    The last rule in the blob has next_entry offset that is same as total size.
    This made "ebtables32 -A OUTPUT -d de:ad:be:ef:01:02" fail on 64 bit kernel.

    Fixes: b71812168571fa ("netfilter: ebtables: CONFIG_COMPAT: don't trust userland offsets")
    Signed-off-by: Florian Westphal
    Signed-off-by: Pablo Neira Ayuso
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Florian Westphal
     
  • [ Upstream commit 3cd2c313f1d618f92d1294addc6c685c17065761 ]

    On the CP110 components which are present on the Armada 7K/8K SoC we need
    to explicitly enable the clock for the registers. However it is not
    needed for the AP8xx component, that's why this clock is optional.

    With this patch both clock have now a name, but in order to be backward
    compatible, the name of the first clock is not used. It allows to still
    use this clock with a device tree using the old binding.

    Reviewed-by: Rob Herring
    Signed-off-by: Vinod Koul
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Gregory CLEMENT
     
  • [ Upstream commit ac68b1b3b9c73e652dc7ce0585672e23c5a2dca4 ]

    As reported by Dan the parentheses is in the wrong place, and since
    unlikely() call returns either 0 or 1 it's never less than zero. The
    second issue is that signed integer overflows like "INT_MAX + 1" are
    undefined behavior.

    Since num_test_devs represents the number of devices, we want to stop
    prior to hitting the max, and not rely on the wrap arround at all. So
    just cap at num_test_devs + 1, prior to assigning a new device.

    Link: http://lkml.kernel.org/r/20180224030046.24238-1-mcgrof@kernel.org
    Fixes: d9c6a72d6fa2 ("kmod: add test driver to stress test the module loader")
    Reported-by: Dan Carpenter
    Signed-off-by: Luis R. Rodriguez
    Acked-by: Kees Cook
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Luis R. Rodriguez
     
  • [ Upstream commit 0627be7d3c871035364923559543c9b2ff5357f2 ]

    Fix userfaultfd_hugetlb on hosts which have more than 64 cpus.

    ---------------------------
    running userfaultfd_hugetlb
    ---------------------------
    invalid MiB
    Usage:
    [FAIL]

    Via userfaultfd.c we can know, hugetlb_size needs to meet hugetlb_size
    >= nr_cpus * hugepage_size. hugepage_size is often 2M, so when host
    cpus > 64, it requires more than 128M.

    [zhijianx.li@intel.com: update changelog/comments and variable name]
    Link: http://lkml.kernel.org/r/20180302024356.83359-1-zhijianx.li@intel.com
    Link: http://lkml.kernel.org/r/20180303125027.81638-1-zhijianx.li@intel.com
    Link: http://lkml.kernel.org/r/20180302024356.83359-1-zhijianx.li@intel.com
    Signed-off-by: Li Zhijian
    Cc: Shuah Khan
    Cc: SeongJae Park
    Cc: Philippe Ombredanne
    Cc: Aneesh Kumar K.V
    Cc: Mike Kravetz
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Li Zhijian