1. 25 8月, 2019 40 次提交
    • M
      mmc: sdhci-of-arasan: Do now show error message in case of deffered probe · 7c13983a
      Michal Simek 提交于
      commit 60208a267208c27fa3f23dfd36cbda180471fa98 upstream.
      
      When mmc-pwrseq property is passed mmc_pwrseq_alloc() can return
      -EPROBE_DEFER because driver for power sequence provider is not probed
      yet. Do not show error message when this situation happens.
      Signed-off-by: NMichal Simek <michal.simek@xilinx.com>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7c13983a
    • M
      net/mlx5e: Use flow keys dissector to parse packets for ARFS · 447f5f48
      Maxim Mikityanskiy 提交于
      [ Upstream commit 405b93eb764367a670e729da18e54dc42db32620 ]
      
      The current ARFS code relies on certain fields to be set in the SKB
      (e.g. transport_header) and extracts IP addresses and ports by custom
      code that parses the packet. The necessary SKB fields, however, are not
      always set at that point, which leads to an out-of-bounds access. Use
      skb_flow_dissect_flow_keys() to get the necessary information reliably,
      fix the out-of-bounds access and reuse the code.
      
      Fixes: 18c908e4 ("net/mlx5e: Add accelerated RFS support")
      Signed-off-by: NMaxim Mikityanskiy <maximmi@mellanox.com>
      Reviewed-by: NTariq Toukan <tariqt@mellanox.com>
      Signed-off-by: NSaeed Mahameed <saeedm@mellanox.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      447f5f48
    • H
      net/mlx5e: Only support tx/rx pause setting for port owner · fbd8ab68
      Huy Nguyen 提交于
      [ Upstream commit 466df6eb4a9e813b3cfc674363316450c57a89c5 ]
      
      Only support changing tx/rx pause frame setting if the net device
      is the vport group manager.
      
      Fixes: 3c2d18ef ("net/mlx5e: Support ethtool get/set_pauseparam")
      Signed-off-by: NHuy Nguyen <huyn@mellanox.com>
      Reviewed-by: NParav Pandit <parav@mellanox.com>
      Signed-off-by: NSaeed Mahameed <saeedm@mellanox.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fbd8ab68
    • R
      xen/netback: Reset nr_frags before freeing skb · b3410f0f
      Ross Lagerwall 提交于
      [ Upstream commit 3a0233ddec554b886298de2428edb5c50a20e694 ]
      
      At this point nr_frags has been incremented but the frag does not yet
      have a page assigned so freeing the skb results in a crash. Reset
      nr_frags before freeing the skb to prevent this.
      Signed-off-by: NRoss Lagerwall <ross.lagerwall@citrix.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b3410f0f
    • C
      tipc: initialise addr_trail_end when setting node addresses · cc4ff0f4
      Chris Packham 提交于
      [ Upstream commit 8874ecae2977e5a2d4f0ba301364435b81c05938 ]
      
      We set the field 'addr_trial_end' to 'jiffies', instead of the current
      value 0, at the moment the node address is initialized. This guarantees
      we don't inadvertently enter an address trial period when the node
      address is explicitly set by the user.
      Signed-off-by: NChris Packham <chris.packham@alliedtelesis.co.nz>
      Acked-by: NJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      cc4ff0f4
    • Y
      team: Add vlan tx offload to hw_enc_features · e89bb758
      YueHaibing 提交于
      [ Upstream commit 227f2f030e28d8783c3d10ce70ff4ba79cad653f ]
      
      We should also enable team's vlan tx offload in hw_enc_features,
      pass the vlan packets to the slave devices with vlan tci, let the
      slave handle vlan tunneling offload implementation.
      
      Fixes: 3268e5cb ("team: Advertise tunneling offload features")
      Signed-off-by: NYueHaibing <yuehaibing@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e89bb758
    • X
      sctp: fix the transport error_count check · eeb148d2
      Xin Long 提交于
      [ Upstream commit a1794de8b92ea6bc2037f445b296814ac826693e ]
      
      As the annotation says in sctp_do_8_2_transport_strike():
      
        "If the transport error count is greater than the pf_retrans
         threshold, and less than pathmaxrtx ..."
      
      It should be transport->error_count checked with pathmaxrxt,
      instead of asoc->pf_retrans.
      
      Fixes: 5aa93bcf ("sctp: Implement quick failover draft from tsvwg")
      Signed-off-by: NXin Long <lucien.xin@gmail.com>
      Acked-by: NMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Signed-off-by: NJakub Kicinski <jakub.kicinski@netronome.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      eeb148d2
    • Z
      sctp: fix memleak in sctp_send_reset_streams · 227f204a
      zhengbin 提交于
      [ Upstream commit 6d5afe20397b478192ed8c38ec0ee10fa3aec649 ]
      
      If the stream outq is not empty, need to kfree nstr_list.
      
      Fixes: d570a59c ("sctp: only allow the out stream reset when the stream outq is empty")
      Reported-by: NHulk Robot <hulkci@huawei.com>
      Signed-off-by: Nzhengbin <zhengbin13@huawei.com>
      Acked-by: NMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Acked-by: NNeil Horman <nhorman@tuxdriver.com>
      Signed-off-by: NJakub Kicinski <jakub.kicinski@netronome.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      227f204a
    • E
      net/packet: fix race in tpacket_snd() · 154e6bc4
      Eric Dumazet 提交于
      [ Upstream commit 32d3182cd2cd29b2e7e04df7b0db350fbe11289f ]
      
      packet_sendmsg() checks tx_ring.pg_vec to decide
      if it must call tpacket_snd().
      
      Problem is that the check is lockless, meaning another thread
      can issue a concurrent setsockopt(PACKET_TX_RING ) to flip
      tx_ring.pg_vec back to NULL.
      
      Given that tpacket_snd() grabs pg_vec_lock mutex, we can
      perform the check again to solve the race.
      
      syzbot reported :
      
      kasan: CONFIG_KASAN_INLINE enabled
      kasan: GPF could be caused by NULL-ptr deref or user memory access
      general protection fault: 0000 [#1] PREEMPT SMP KASAN
      CPU: 1 PID: 11429 Comm: syz-executor394 Not tainted 5.3.0-rc4+ #101
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      RIP: 0010:packet_lookup_frame+0x8d/0x270 net/packet/af_packet.c:474
      Code: c1 ee 03 f7 73 0c 80 3c 0e 00 0f 85 cb 01 00 00 48 8b 0b 89 c0 4c 8d 24 c1 48 b8 00 00 00 00 00 fc ff df 4c 89 e1 48 c1 e9 03 <80> 3c 01 00 0f 85 94 01 00 00 48 8d 7b 10 4d 8b 3c 24 48 b8 00 00
      RSP: 0018:ffff88809f82f7b8 EFLAGS: 00010246
      RAX: dffffc0000000000 RBX: ffff8880a45c7030 RCX: 0000000000000000
      RDX: 0000000000000000 RSI: 1ffff110148b8e06 RDI: ffff8880a45c703c
      RBP: ffff88809f82f7e8 R08: ffff888087aea200 R09: fffffbfff134ae50
      R10: fffffbfff134ae4f R11: ffffffff89a5727f R12: 0000000000000000
      R13: 0000000000000001 R14: ffff8880a45c6ac0 R15: 0000000000000000
      FS:  00007fa04716f700(0000) GS:ffff8880ae900000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00007fa04716edb8 CR3: 0000000091eb4000 CR4: 00000000001406e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      Call Trace:
       packet_current_frame net/packet/af_packet.c:487 [inline]
       tpacket_snd net/packet/af_packet.c:2667 [inline]
       packet_sendmsg+0x590/0x6250 net/packet/af_packet.c:2975
       sock_sendmsg_nosec net/socket.c:637 [inline]
       sock_sendmsg+0xd7/0x130 net/socket.c:657
       ___sys_sendmsg+0x3e2/0x920 net/socket.c:2311
       __sys_sendmmsg+0x1bf/0x4d0 net/socket.c:2413
       __do_sys_sendmmsg net/socket.c:2442 [inline]
       __se_sys_sendmmsg net/socket.c:2439 [inline]
       __x64_sys_sendmmsg+0x9d/0x100 net/socket.c:2439
       do_syscall_64+0xfd/0x6a0 arch/x86/entry/common.c:296
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      Fixes: 69e3c75f ("net: TX_RING and packet mmap")
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Reported-by: Nsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      154e6bc4
    • W
      net/mlx4_en: fix a memory leak bug · f588dccf
      Wenwen Wang 提交于
      [ Upstream commit 48ec7014c56e5eb2fbf6f479896143622d834f3b ]
      
      In mlx4_en_config_rss_steer(), 'rss_map->indir_qp' is allocated through
      kzalloc(). After that, mlx4_qp_alloc() is invoked to configure RSS
      indirection. However, if mlx4_qp_alloc() fails, the allocated
      'rss_map->indir_qp' is not deallocated, leading to a memory leak bug.
      
      To fix the above issue, add the 'qp_alloc_err' label to free
      'rss_map->indir_qp'.
      
      Fixes: 4931c6ef ("net/mlx4_en: Optimized single ring steering")
      Signed-off-by: NWenwen Wang <wenwen@cs.uga.edu>
      Reviewed-by: NTariq Toukan <tariqt@mellanox.com>
      Signed-off-by: NJakub Kicinski <jakub.kicinski@netronome.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f588dccf
    • C
      net: dsa: Check existence of .port_mdb_add callback before calling it · 8905a249
      Chen-Yu Tsai 提交于
      [ Upstream commit 58799865be84e2a895dab72de0e1b996ed943f22 ]
      
      The dsa framework has optional .port_mdb_{prepare,add,del} callback fields
      for drivers to handle multicast database entries. When adding an entry, the
      framework goes through a prepare phase, then a commit phase. Drivers not
      providing these callbacks should be detected in the prepare phase.
      
      DSA core may still bypass the bridge layer and call the dsa_port_mdb_add
      function directly with no prepare phase or no switchdev trans object,
      and the framework ends up calling an undefined .port_mdb_add callback.
      This results in a NULL pointer dereference, as shown in the log below.
      
      The other functions seem to be properly guarded. Do the same for
      .port_mdb_add in dsa_switch_mdb_add_bitmap() as well.
      
          8<--- cut here ---
          Unable to handle kernel NULL pointer dereference at virtual address 00000000
          pgd = (ptrval)
          [00000000] *pgd=00000000
          Internal error: Oops: 80000005 [#1] SMP ARM
          Modules linked in: rtl8xxxu rtl8192cu rtl_usb rtl8192c_common rtlwifi mac80211 cfg80211
          CPU: 1 PID: 134 Comm: kworker/1:2 Not tainted 5.3.0-rc1-00247-gd3519030752a #1
          Hardware name: Allwinner sun7i (A20) Family
          Workqueue: events switchdev_deferred_process_work
          PC is at 0x0
          LR is at dsa_switch_event+0x570/0x620
          pc : [<00000000>]    lr : [<c08533ec>]    psr: 80070013
          sp : ee871db8  ip : 00000000  fp : ee98d0a4
          r10: 0000000c  r9 : 00000008  r8 : ee89f710
          r7 : ee98d040  r6 : ee98d088  r5 : c0f04c48  r4 : ee98d04c
          r3 : 00000000  r2 : ee89f710  r1 : 00000008  r0 : ee98d040
          Flags: Nzcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
          Control: 10c5387d  Table: 6deb406a  DAC: 00000051
          Process kworker/1:2 (pid: 134, stack limit = 0x(ptrval))
          Stack: (0xee871db8 to 0xee872000)
          1da0:                                                       ee871e14 103ace2d
          1dc0: 00000000 ffffffff 00000000 ee871e14 00000005 00000000 c08524a0 00000000
          1de0: ffffe000 c014bdfc c0f04c48 ee871e98 c0f04c48 ee9e5000 c0851120 c014bef0
          1e00: 00000000 b643aea2 ee9b4068 c08509a8 ee2bf940 ee89f710 ee871ecb 00000000
          1e20: 00000008 103ace2d 00000000 c087e248 ee29c868 103ace2d 00000001 ffffffff
          1e40: 00000000 ee871e98 00000006 00000000 c0fb2a50 c087e2d0 ffffffff c08523c4
          1e60: ffffffff c014bdfc 00000006 c0fad2d0 ee871e98 ee89f710 00000000 c014c500
          1e80: 00000000 ee89f3c0 c0f04c48 00000000 ee9e5000 c087dfb4 ee9e5000 00000000
          1ea0: ee89f710 ee871ecb 00000001 103ace2d 00000000 c0f04c48 00000000 c087e0a8
          1ec0: 00000000 efd9a3e0 0089f3c0 103ace2d ee89f700 ee89f710 ee9e5000 00000122
          1ee0: 00000100 c087e130 ee89f700 c0fad2c8 c1003ef0 c087de4c 2e928000 c0fad2ec
          1f00: c0fad2ec ee839580 ef7a62c0 ef7a9400 00000000 c087def8 c0fad2ec c01447dc
          1f20: ef315640 ef7a62c0 00000008 ee839580 ee839594 ef7a62c0 00000008 c0f03d00
          1f40: ef7a62d8 ef7a62c0 ffffe000 c0145b84 ffffe000 c0fb2420 c0bfaa8c 00000000
          1f60: ffffe000 ee84b600 ee84b5c0 00000000 ee870000 ee839580 c0145b40 ef0e5ea4
          1f80: ee84b61c c014a6f8 00000001 ee84b5c0 c014a5b0 00000000 00000000 00000000
          1fa0: 00000000 00000000 00000000 c01010e8 00000000 00000000 00000000 00000000
          1fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
          1fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
          [<c08533ec>] (dsa_switch_event) from [<c014bdfc>] (notifier_call_chain+0x48/0x84)
          [<c014bdfc>] (notifier_call_chain) from [<c014bef0>] (raw_notifier_call_chain+0x18/0x20)
          [<c014bef0>] (raw_notifier_call_chain) from [<c08509a8>] (dsa_port_mdb_add+0x48/0x74)
          [<c08509a8>] (dsa_port_mdb_add) from [<c087e248>] (__switchdev_handle_port_obj_add+0x54/0xd4)
          [<c087e248>] (__switchdev_handle_port_obj_add) from [<c087e2d0>] (switchdev_handle_port_obj_add+0x8/0x14)
          [<c087e2d0>] (switchdev_handle_port_obj_add) from [<c08523c4>] (dsa_slave_switchdev_blocking_event+0x94/0xa4)
          [<c08523c4>] (dsa_slave_switchdev_blocking_event) from [<c014bdfc>] (notifier_call_chain+0x48/0x84)
          [<c014bdfc>] (notifier_call_chain) from [<c014c500>] (blocking_notifier_call_chain+0x50/0x68)
          [<c014c500>] (blocking_notifier_call_chain) from [<c087dfb4>] (switchdev_port_obj_notify+0x44/0xa8)
          [<c087dfb4>] (switchdev_port_obj_notify) from [<c087e0a8>] (switchdev_port_obj_add_now+0x90/0x104)
          [<c087e0a8>] (switchdev_port_obj_add_now) from [<c087e130>] (switchdev_port_obj_add_deferred+0x14/0x5c)
          [<c087e130>] (switchdev_port_obj_add_deferred) from [<c087de4c>] (switchdev_deferred_process+0x64/0x104)
          [<c087de4c>] (switchdev_deferred_process) from [<c087def8>] (switchdev_deferred_process_work+0xc/0x14)
          [<c087def8>] (switchdev_deferred_process_work) from [<c01447dc>] (process_one_work+0x218/0x50c)
          [<c01447dc>] (process_one_work) from [<c0145b84>] (worker_thread+0x44/0x5bc)
          [<c0145b84>] (worker_thread) from [<c014a6f8>] (kthread+0x148/0x150)
          [<c014a6f8>] (kthread) from [<c01010e8>] (ret_from_fork+0x14/0x2c)
          Exception stack(0xee871fb0 to 0xee871ff8)
          1fa0:                                     00000000 00000000 00000000 00000000
          1fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
          1fe0: 00000000 00000000 00000000 00000000 00000013 00000000
          Code: bad PC value
          ---[ end trace 1292c61abd17b130 ]---
      
          [<c08533ec>] (dsa_switch_event) from [<c014bdfc>] (notifier_call_chain+0x48/0x84)
          corresponds to
      
      	$ arm-linux-gnueabihf-addr2line -C -i -e vmlinux c08533ec
      
      	linux/net/dsa/switch.c:156
      	linux/net/dsa/switch.c:178
      	linux/net/dsa/switch.c:328
      
      Fixes: e6db98db ("net: dsa: add switch mdb bitmap functions")
      Signed-off-by: NChen-Yu Tsai <wens@csie.org>
      Reviewed-by: NVivien Didelot <vivien.didelot@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8905a249
    • Y
      bonding: Add vlan tx offload to hw_enc_features · d61d8ea9
      YueHaibing 提交于
      [ Upstream commit d595b03de2cb0bdf9bcdf35ff27840cc3a37158f ]
      
      As commit 30d8177e8ac7 ("bonding: Always enable vlan tx offload")
      said, we should always enable bonding's vlan tx offload, pass the
      vlan packets to the slave devices with vlan tci, let them to handle
      vlan implementation.
      
      Now if encapsulation protocols like VXLAN is used, skb->encapsulation
      may be set, then the packet is passed to vlan device which based on
      bonding device. However in netif_skb_features(), the check of
      hw_enc_features:
      
      	 if (skb->encapsulation)
                       features &= dev->hw_enc_features;
      
      clears NETIF_F_HW_VLAN_CTAG_TX/NETIF_F_HW_VLAN_STAG_TX. This results
      in same issue in commit 30d8177e8ac7 like this:
      
      vlan_dev_hard_start_xmit
        -->dev_queue_xmit
          -->validate_xmit_skb
            -->netif_skb_features //NETIF_F_HW_VLAN_CTAG_TX is cleared
            -->validate_xmit_vlan
              -->__vlan_hwaccel_push_inside //skb->tci is cleared
      ...
       --> bond_start_xmit
         --> bond_xmit_hash //BOND_XMIT_POLICY_ENCAP34
           --> __skb_flow_dissect // nhoff point to IP header
              -->  case htons(ETH_P_8021Q)
                   // skb_vlan_tag_present is false, so
                   vlan = __skb_header_pointer(skb, nhoff, sizeof(_vlan),
                   //vlan point to ip header wrongly
      
      Fixes: b2a103e6 ("bonding: convert to ndo_fix_features")
      Signed-off-by: NYueHaibing <yuehaibing@huawei.com>
      Acked-by: NJay Vosburgh <jay.vosburgh@canonical.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d61d8ea9
    • M
      bnx2x: Fix VF's VLAN reconfiguration in reload. · 40933af4
      Manish Chopra 提交于
      [ Upstream commit 4a4d2d372fb9b9229327e2ed01d5d9572eddf4de ]
      
      Commit 04f05230c5c13 ("bnx2x: Remove configured vlans as
      part of unload sequence."), introduced a regression in driver
      that as a part of VF's reload flow, VLANs created on the VF
      doesn't get re-configured in hardware as vlan metadata/info
      was not getting cleared for the VFs which causes vlan PING to stop.
      
      This patch clears the vlan metadata/info so that VLANs gets
      re-configured back in the hardware in VF's reload flow and
      PING/traffic continues for VLANs created over the VFs.
      
      Fixes: 04f05230c5c13 ("bnx2x: Remove configured vlans as part of unload sequence.")
      Signed-off-by: NManish Chopra <manishc@marvell.com>
      Signed-off-by: NSudarsana Kalluru <skalluru@marvell.com>
      Signed-off-by: NShahed Shaikh <shshaikh@marvell.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      40933af4
    • J
      iommu/amd: Move iommu_init_pci() to .init section · 03d54393
      Joerg Roedel 提交于
      commit 24d2c521749d8547765b555b7a85cca179bb2275 upstream.
      
      The function is only called from another __init function, so
      it should be moved to .init too.
      Signed-off-by: NJoerg Roedel <jroedel@suse.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      03d54393
    • Y
      Input: psmouse - fix build error of multiple definition · 62e023dd
      YueHaibing 提交于
      commit 49e6979e7e92cf496105b5636f1df0ac17c159c0 upstream.
      
      trackpoint_detect() should be static inline while
      CONFIG_MOUSE_PS2_TRACKPOINT is not set, otherwise, we build fails:
      
      drivers/input/mouse/alps.o: In function `trackpoint_detect':
      alps.c:(.text+0x8e00): multiple definition of `trackpoint_detect'
      drivers/input/mouse/psmouse-base.o:psmouse-base.c:(.text+0x1b50): first defined here
      Reported-by: NHulk Robot <hulkci@huawei.com>
      Fixes: 55e3d922 ("Input: psmouse - allow disabing certain protocol extensions")
      Signed-off-by: NYueHaibing <yuehaibing@huawei.com>
      Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
      Cc: Hui Wang <hui.wang@canonical.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      62e023dd
    • D
      netfilter: conntrack: Use consistent ct id hash calculation · 28ff7d3b
      Dirk Morris 提交于
      commit 656c8e9cc1badbc18eefe6ba01d33ebbcae61b9a upstream.
      
      Change ct id hash calculation to only use invariants.
      
      Currently the ct id hash calculation is based on some fields that can
      change in the lifetime on a conntrack entry in some corner cases. The
      current hash uses the whole tuple which contains an hlist pointer which
      will change when the conntrack is placed on the dying list resulting in
      a ct id change.
      
      This patch also removes the reply-side tuple and extension pointer from
      the hash calculation so that the ct id will will not change from
      initialization until confirmation.
      
      Fixes: 3c79107631db1f7 ("netfilter: ctnetlink: don't use conntrack/expect object addresses as id")
      Signed-off-by: NDirk Morris <dmorris@metaloft.com>
      Acked-by: NFlorian Westphal <fw@strlen.de>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      28ff7d3b
    • W
      arm64: ftrace: Ensure module ftrace trampoline is coherent with I-side · 30b9da0e
      Will Deacon 提交于
      commit b6143d10d23ebb4a77af311e8b8b7f019d0163e6 upstream.
      
      The initial support for dynamic ftrace trampolines in modules made use
      of an indirect branch which loaded its target from the beginning of
      a special section (e71a4e1b ("arm64: ftrace: add support for far
      branches to dynamic ftrace")). Since no instructions were being patched,
      no cache maintenance was needed. However, later in be0f272b ("arm64:
      ftrace: emit ftrace-mod.o contents through code") this code was reworked
      to output the trampoline instructions directly into the PLT entry but,
      unfortunately, the necessary cache maintenance was overlooked.
      
      Add a call to __flush_icache_range() after writing the new trampoline
      instructions but before patching in the branch to the trampoline.
      
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: James Morse <james.morse@arm.com>
      Cc: <stable@vger.kernel.org>
      Fixes: be0f272b ("arm64: ftrace: emit ftrace-mod.o contents through code")
      Signed-off-by: NWill Deacon <will@kernel.org>
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      30b9da0e
    • M
      dm: disable DISCARD if the underlying storage no longer supports it · a1cd2f70
      Mike Snitzer 提交于
      commit bcb44433bba5eaff293888ef22ffa07f1f0347d6 upstream.
      
      Storage devices which report supporting discard commands like
      WRITE_SAME_16 with unmap, but reject discard commands sent to the
      storage device.  This is a clear storage firmware bug but it doesn't
      change the fact that should a program cause discards to be sent to a
      multipath device layered on this buggy storage, all paths can end up
      failed at the same time from the discards, causing possible I/O loss.
      
      The first discard to a path will fail with Illegal Request, Invalid
      field in cdb, e.g.:
       kernel: sd 8:0:8:19: [sdfn] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
       kernel: sd 8:0:8:19: [sdfn] tag#0 Sense Key : Illegal Request [current]
       kernel: sd 8:0:8:19: [sdfn] tag#0 Add. Sense: Invalid field in cdb
       kernel: sd 8:0:8:19: [sdfn] tag#0 CDB: Write same(16) 93 08 00 00 00 00 00 a0 08 00 00 00 80 00 00 00
       kernel: blk_update_request: critical target error, dev sdfn, sector 10487808
      
      The SCSI layer converts this to the BLK_STS_TARGET error number, the sd
      device disables its support for discard on this path, and because of the
      BLK_STS_TARGET error multipath fails the discard without failing any
      path or retrying down a different path.  But subsequent discards can
      cause path failures.  Any discards sent to the path which already failed
      a discard ends up failing with EIO from blk_cloned_rq_check_limits with
      an "over max size limit" error since the discard limit was set to 0 by
      the sd driver for the path.  As the error is EIO, this now fails the
      path and multipath tries to send the discard down the next path.  This
      cycle continues as discards are sent until all paths fail.
      
      Fix this by training DM core to disable DISCARD if the underlying
      storage already did so.
      
      Also, fix branching in dm_done() and clone_endio() to reflect the
      mutually exclussive nature of the IO operations in question.
      
      Cc: stable@vger.kernel.org
      Reported-by: NDavid Jeffery <djeffery@redhat.com>
      Signed-off-by: NMike Snitzer <snitzer@redhat.com>
      [Salvatore Bonaccorso: backported to 4.19: Adjust for context changes in
      drivers/md/dm-core.h]
      Signed-off-by: NSalvatore Bonaccorso <carnil@debian.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a1cd2f70
    • R
      drm/i915/cfl: Add a new CFL PCI ID. · 4af28b2f
      Rodrigo Vivi 提交于
      commit d0e062ebb3a44b56a7e672da568334c76f763552 upstream.
      
      One more CFL ID added to spec.
      
      Cc: José Roberto de Souza <jose.souza@intel.com>
      Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
      Reviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180803232721.20038-1-rodrigo.vivi@intel.comSigned-off-by: NWan Yusof, Wan Fahim AsqalaniX <wan.fahim.asqalanix.wan.yusof@intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4af28b2f
    • T
      USB: serial: option: Add Motorola modem UARTs · 3ca5b7b4
      Tony Lindgren 提交于
      commit 6caf0be40a707689e8ff8824fdb96ef77685b1ba upstream.
      
      On Motorola Mapphone devices such as Droid 4 there are five USB ports
      that do not use the same layout as Gobi 1K/2K/etc devices listed in
      qcserial.c. So we should use qcaux.c or option.c as noted by
      Dan Williams <dan.j.williams@intel.com>.
      
      As the Motorola USB serial ports have an interrupt endpoint as shown
      with lsusb -v, we should use option.c instead of qcaux.c as pointed out
      by Johan Hovold <johan@kernel.org>.
      
      The ff/ff/ff interfaces seem to always be UARTs on Motorola devices.
      For the other interfaces, class 0x0a (CDC Data) should not in general
      be added as they are typically part of a multi-interface function as
      noted earlier by Bjørn Mork <bjorn@mork.no>.
      
      However, looking at the Motorola mapphone kernel code, the mdm6600 0x0a
      class is only used for flashing the modem firmware, and there are no
      other interfaces. So I've added that too with more details below as it
      works just fine.
      
      The ttyUSB ports on Droid 4 are:
      
      ttyUSB0 DIAG, CQDM-capable
      ttyUSB1 MUX or NMEA, no response
      ttyUSB2 MUX or NMEA, no response
      ttyUSB3 TCMD
      ttyUSB4 AT-capable
      
      The ttyUSB0 is detected as QCDM capable by ModemManager. I think
      it's only used for debugging with ModemManager --debug for sending
      custom AT commands though. ModemManager already can manage data
      connection using the USB QMI ports that are already handled by the
      qmi_wwan.c driver.
      
      To enable the MUX or NMEA ports, it seems that something needs to be
      done additionally to enable them, maybe via the DIAG or TCMD port.
      It might be just a NVRAM setting somewhere, but I have no idea what
      NVRAM settings may need changing for that.
      
      The TCMD port seems to be a Motorola custom protocol for testing
      the modem and to configure it's NVRAM and seems to work just fine
      based on a quick test with a minimal tcmdrw tool I wrote.
      
      The voice modem AT-capable port seems to provide only partial
      support, and no PM support compared to the TS 27.010 based UART
      wired directly to the modem.
      
      The UARTs added with this change are the same product IDs as the
      Motorola Mapphone Android Linux kernel mdm6600_id_table. I don't
      have any mdm9600 based devices, so I have only tested these on
      mdm6600 based droid 4.
      
      Then for the class 0x0a (CDC Data) mode, the Motorola Mapphone Android
      Linux kernel driver moto_flashqsc.c just seems to change the
      port->bulk_out_size to 8K from the default. And is only used for
      flashing the modem firmware it seems.
      
      I've verified that flashing the modem with signed firmware works just
      fine with the option driver after manually toggling the GPIO pins, so
      I've added droid 4 modem flashing mode to the option driver. I've not
      added the other devices listed in moto_flashqsc.c in case they really
      need different port->bulk_out_size. Those can be added as they get
      tested to work for flashing the modem.
      
      After this patch the output of /sys/kernel/debug/usb/devices has
      the following for normal 22b8:2a70 mode including the related qmi_wwan
      interfaces:
      
      T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=12   MxCh= 0
      D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
      P:  Vendor=22b8 ProdID=2a70 Rev= 0.00
      S:  Manufacturer=Motorola, Incorporated
      S:  Product=Flash MZ600
      C:* #Ifs= 9 Cfg#= 1 Atr=e0 MxPwr=500mA
      I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
      E:  Ad=81(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
      E:  Ad=01(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
      I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
      E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
      E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
      I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
      E:  Ad=83(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
      E:  Ad=03(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
      I:* If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
      E:  Ad=84(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
      E:  Ad=04(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
      I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
      E:  Ad=85(I) Atr=03(Int.) MxPS=  64 Ivl=5ms
      E:  Ad=86(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
      E:  Ad=05(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
      I:* If#= 5 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=fb Prot=ff Driver=qmi_wwan
      E:  Ad=87(I) Atr=03(Int.) MxPS=  64 Ivl=5ms
      E:  Ad=88(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
      E:  Ad=06(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
      I:* If#= 6 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=fb Prot=ff Driver=qmi_wwan
      E:  Ad=89(I) Atr=03(Int.) MxPS=  64 Ivl=5ms
      E:  Ad=8a(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
      E:  Ad=07(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
      I:* If#= 7 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=fb Prot=ff Driver=qmi_wwan
      E:  Ad=8b(I) Atr=03(Int.) MxPS=  64 Ivl=5ms
      E:  Ad=8c(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
      E:  Ad=08(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
      I:* If#= 8 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=fb Prot=ff Driver=qmi_wwan
      E:  Ad=8d(I) Atr=03(Int.) MxPS=  64 Ivl=5ms
      E:  Ad=8e(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
      E:  Ad=09(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
      
      In 22b8:900e "qc_dload" mode the device shows up as:
      
      T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=12   MxCh= 0
      D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
      P:  Vendor=22b8 ProdID=900e Rev= 0.00
      S:  Manufacturer=Motorola, Incorporated
      S:  Product=Flash MZ600
      C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=500mA
      I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
      E:  Ad=81(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
      E:  Ad=01(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
      
      And in 22b8:4281 "ram_downloader" mode the device shows up as:
      
      T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=12   MxCh= 0
      D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
      P:  Vendor=22b8 ProdID=4281 Rev= 0.00
      S:  Manufacturer=Motorola, Incorporated
      S:  Product=Flash MZ600
      C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=500mA
      I:* If#= 0 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=fc Driver=option
      E:  Ad=81(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
      E:  Ad=01(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
      
      Cc: Bjørn Mork <bjorn@mork.no>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Lars Melin <larsm17@gmail.com>
      Cc: Marcel Partap <mpartap@gmx.net>
      Cc: Merlijn Wajer <merlijn@wizzup.org>
      Cc: Michael Scott <hashcode0f@gmail.com>
      Cc: NeKit <nekit1000@gmail.com>
      Cc: Pavel Machek <pavel@ucw.cz>
      Cc: Sebastian Reichel <sre@kernel.org>
      Tested-by: NPavel Machek <pavel@ucw.cz>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NJohan Hovold <johan@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3ca5b7b4
    • B
      USB: serial: option: add the BroadMobi BM818 card · e480d6cf
      Bob Ham 提交于
      commit e5d8badf37e6b547842f2fcde10361b29e08bd36 upstream.
      
      Add a VID:PID for the BroadMobi BM818 M.2 card
      
      T:  Bus=01 Lev=03 Prnt=40 Port=03 Cnt=01 Dev#= 44 Spd=480 MxCh= 0
      D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
      P:  Vendor=2020 ProdID=2060 Rev=00.00
      S:  Manufacturer=Qualcomm, Incorporated
      S:  Product=Qualcomm CDMA Technologies MSM
      C:  #Ifs= 5 Cfg#= 1 Atr=e0 MxPwr=500mA
      I:  If#=0x0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
      I:  If#=0x1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
      I:  If#=0x2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
      I:  If#=0x3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=fe Prot=ff Driver=(none)
      I:  If#=0x4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
      Signed-off-by: NBob Ham <bob.ham@puri.sm>
      Signed-off-by: NAngus Ainslie (Purism) <angus@akkea.ca>
      Cc: stable <stable@vger.kernel.org>
      [ johan: use USB_DEVICE_INTERFACE_CLASS() ]
      Signed-off-by: NJohan Hovold <johan@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e480d6cf
    • Y
      USB: serial: option: Add support for ZTE MF871A · 8175fa29
      Yoshiaki Okamoto 提交于
      commit 7e7ae38bf928c5cfa6dd6e9a2cf8b42c84a27c92 upstream.
      
      This patch adds support for MF871A USB modem (aka Speed USB STICK U03)
      to option driver. This modem is manufactured by ZTE corporation, and
      sold by KDDI.
      
      Interface layout:
      0: AT
      1: MODEM
      
      usb-devices output:
      T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  9 Spd=480 MxCh= 0
      D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
      P:  Vendor=19d2 ProdID=1481 Rev=52.87
      S:  Manufacturer=ZTE,Incorporated
      S:  Product=ZTE Technologies MSM
      S:  SerialNumber=1234567890ABCDEF
      C:  #Ifs= 2 Cfg#= 1 Atr=80 MxPwr=500mA
      I:  If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
      I:  If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
      Co-developed-by: NHiroyuki Yamamoto <hyamamo@allied-telesis.co.jp>
      Signed-off-by: NHiroyuki Yamamoto <hyamamo@allied-telesis.co.jp>
      Signed-off-by: NYoshiaki Okamoto <yokamoto@allied-telesis.co.jp>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NJohan Hovold <johan@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8175fa29
    • R
      USB: serial: option: add D-Link DWM-222 device ID · afb677b2
      Rogan Dawes 提交于
      commit 552573e42aab5f75aff9bab855a9677979d9a7d5 upstream.
      
      Add device id for D-Link DWM-222 A2.
      
      MI_00 D-Link HS-USB Diagnostics
      MI_01 D-Link HS-USB Modem
      MI_02 D-Link HS-USB AT Port
      MI_03 D-Link HS-USB NMEA
      MI_04 D-Link HS-USB WWAN Adapter (qmi_wwan)
      MI_05 USB Mass Storage Device
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NRogan Dawes <rogan@dawes.za.net>
      Signed-off-by: NJohan Hovold <johan@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      afb677b2
    • O
      USB: CDC: fix sanity checks in CDC union parser · 487d66ae
      Oliver Neukum 提交于
      commit 54364278fb3cabdea51d6398b07c87415065b3fc upstream.
      
      A few checks checked for the size of the pointer to a structure
      instead of the structure itself. Copy & paste issue presumably.
      
      Fixes: e4c6fb77 ("usbnet: move the CDC parser into USB core")
      Cc: stable <stable@vger.kernel.org>
      Reported-by: syzbot+45a53506b65321c1fe91@syzkaller.appspotmail.com
      Signed-off-by: NOliver Neukum <oneukum@suse.com>
      Link: https://lore.kernel.org/r/20190813093541.18889-1-oneukum@suse.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      487d66ae
    • O
      usb: cdc-acm: make sure a refcount is taken early enough · c02c0249
      Oliver Neukum 提交于
      commit c52873e5a1ef72f845526d9f6a50704433f9c625 upstream.
      
      destroy() will decrement the refcount on the interface, so that
      it needs to be taken so early that it never undercounts.
      
      Fixes: 7fb57a01 ("USB: cdc-acm: Fix potential deadlock (lockdep warning)")
      Cc: stable <stable@vger.kernel.org>
      Reported-and-tested-by: syzbot+1b2449b7b5dc240d107a@syzkaller.appspotmail.com
      Signed-off-by: NOliver Neukum <oneukum@suse.com>
      Link: https://lore.kernel.org/r/20190808142119.7998-1-oneukum@suse.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c02c0249
    • Y
      usb: gadget: udc: renesas_usb3: Fix sysfs interface of "role" · f417f971
      Yoshihiro Shimoda 提交于
      commit 5dac665cf403967bb79a7aeb8c182a621fe617ff upstream.
      
      Since the role_store() uses strncmp(), it's possible to refer
      out-of-memory if the sysfs data size is smaller than strlen("host").
      This patch fixes it by using sysfs_streq() instead of strncmp().
      
      Fixes: cc995c9e ("usb: gadget: udc: renesas_usb3: add support for usb role swap")
      Cc: <stable@vger.kernel.org> # v4.12+
      Reviewed-by: NGeert Uytterhoeven <geert+renesas@glider.be>
      Signed-off-by: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
      Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f417f971
    • A
      USB: core: Fix races in character device registration and deregistraion · 7f52d6d2
      Alan Stern 提交于
      commit 303911cfc5b95d33687d9046133ff184cf5043ff upstream.
      
      The syzbot fuzzer has found two (!) races in the USB character device
      registration and deregistration routines.  This patch fixes the races.
      
      The first race results from the fact that usb_deregister_dev() sets
      usb_minors[intf->minor] to NULL before calling device_destroy() on the
      class device.  This leaves a window during which another thread can
      allocate the same minor number but will encounter a duplicate name
      error when it tries to register its own class device.  A typical error
      message in the system log would look like:
      
          sysfs: cannot create duplicate filename '/class/usbmisc/ldusb0'
      
      The patch fixes this race by destroying the class device first.
      
      The second race is in usb_register_dev().  When that routine runs, it
      first allocates a minor number, then drops minor_rwsem, and then
      creates the class device.  If the device creation fails, the minor
      number is deallocated and the whole routine returns an error.  But
      during the time while minor_rwsem was dropped, there is a window in
      which the minor number is allocated and so another thread can
      successfully open the device file.  Typically this results in
      use-after-free errors or invalid accesses when the other thread closes
      its open file reference, because the kernel then tries to release
      resources that were already deallocated when usb_register_dev()
      failed.  The patch fixes this race by keeping minor_rwsem locked
      throughout the entire routine.
      
      Reported-and-tested-by: syzbot+30cf45ebfe0b0c4847a1@syzkaller.appspotmail.com
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      CC: <stable@vger.kernel.org>
      Link: https://lore.kernel.org/r/Pine.LNX.4.44L0.1908121607590.1659-100000@iolanthe.rowland.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7f52d6d2
    • J
      iio: adc: max9611: Fix temperature reading in probe · 367d103a
      Jacopo Mondi 提交于
      commit b9ddd5091160793ee9fac10da765cf3f53d2aaf0 upstream.
      
      The max9611 driver reads the die temperature at probe time to validate
      the communication channel. Use the actual read value to perform the test
      instead of the read function return value, which was mistakenly used so
      far.
      
      The temperature reading test was only successful because the 0 return
      value is in the range of supported temperatures.
      
      Fixes: 69780a3b ("iio: adc: Add Maxim max9611 ADC driver")
      Signed-off-by: NJacopo Mondi <jacopo+renesas@jmondi.org>
      Cc: <Stable@vger.kernel.org>
      Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      367d103a
    • I
      staging: comedi: dt3000: Fix rounding up of timer divisor · dac96992
      Ian Abbott 提交于
      commit 8e2a589a3fc36ce858d42e767c3bcd8fc62a512b upstream.
      
      `dt3k_ns_to_timer()` determines the prescaler and divisor to use to
      produce a desired timing period.  It is influenced by a rounding mode
      and can round the divisor up, down, or to the nearest value.  However,
      the code for rounding up currently does the same as rounding down!  Fix
      ir by using the `DIV_ROUND_UP()` macro to calculate the divisor when
      rounding up.
      
      Also, change the types of the `divider`, `base` and `prescale` variables
      from `int` to `unsigned int` to avoid mixing signed and unsigned types
      in the calculations.
      
      Also fix a typo in a nearby comment: "improvment" => "improvement".
      Signed-off-by: NIan Abbott <abbotti@mev.co.uk>
      Cc: stable <stable@vger.kernel.org>
      Link: https://lore.kernel.org/r/20190812120814.21188-1-abbotti@mev.co.ukSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      dac96992
    • I
      staging: comedi: dt3000: Fix signed integer overflow 'divider * base' · 2e394bcf
      Ian Abbott 提交于
      commit b4d98bc3fc93ec3a58459948a2c0e0c9b501cd88 upstream.
      
      In `dt3k_ns_to_timer()` the following lines near the end of the function
      result in a signed integer overflow:
      
      	prescale = 15;
      	base = timer_base * (1 << prescale);
      	divider = 65535;
      	*nanosec = divider * base;
      
      (`divider`, `base` and `prescale` are type `int`, `timer_base` and
      `*nanosec` are type `unsigned int`.  The value of `timer_base` will be
      either 50 or 100.)
      
      The main reason for the overflow is that the calculation for `base` is
      completely wrong.  It should be:
      
      	base = timer_base * (prescale + 1);
      
      which matches an earlier instance of this calculation in the same
      function.
      Reported-by: NDavid Binderman <dcb314@hotmail.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NIan Abbott <abbotti@mev.co.uk>
      Link: https://lore.kernel.org/r/20190812111517.26803-1-abbotti@mev.co.ukSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2e394bcf
    • M
      KVM: arm/arm64: Sync ICH_VMCR_EL2 back when about to block · 8c7053d1
      Marc Zyngier 提交于
      commit 5eeaf10eec394b28fad2c58f1f5c3a5da0e87d1c upstream.
      
      Since commit commit 328e5664 ("KVM: arm/arm64: vgic: Defer
      touching GICH_VMCR to vcpu_load/put"), we leave ICH_VMCR_EL2 (or
      its GICv2 equivalent) loaded as long as we can, only syncing it
      back when we're scheduled out.
      
      There is a small snag with that though: kvm_vgic_vcpu_pending_irq(),
      which is indirectly called from kvm_vcpu_check_block(), needs to
      evaluate the guest's view of ICC_PMR_EL1. At the point were we
      call kvm_vcpu_check_block(), the vcpu is still loaded, and whatever
      changes to PMR is not visible in memory until we do a vcpu_put().
      
      Things go really south if the guest does the following:
      
      	mov x0, #0	// or any small value masking interrupts
      	msr ICC_PMR_EL1, x0
      
      	[vcpu preempted, then rescheduled, VMCR sampled]
      
      	mov x0, #ff	// allow all interrupts
      	msr ICC_PMR_EL1, x0
      	wfi		// traps to EL2, so samping of VMCR
      
      	[interrupt arrives just after WFI]
      
      Here, the hypervisor's view of PMR is zero, while the guest has enabled
      its interrupts. kvm_vgic_vcpu_pending_irq() will then say that no
      interrupts are pending (despite an interrupt being received) and we'll
      block for no reason. If the guest doesn't have a periodic interrupt
      firing once it has blocked, it will stay there forever.
      
      To avoid this unfortuante situation, let's resync VMCR from
      kvm_arch_vcpu_blocking(), ensuring that a following kvm_vcpu_check_block()
      will observe the latest value of PMR.
      
      This has been found by booting an arm64 Linux guest with the pseudo NMI
      feature, and thus using interrupt priorities to mask interrupts instead
      of the usual PSTATE masking.
      
      Cc: stable@vger.kernel.org # 4.12
      Fixes: 328e5664 ("KVM: arm/arm64: vgic: Defer touching GICH_VMCR to vcpu_load/put")
      Signed-off-by: NMarc Zyngier <maz@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      
      8c7053d1
    • A
      arm64: KVM: regmap: Fix unexpected switch fall-through · c8d95668
      Anders Roxell 提交于
      commit 3d584a3c85d6fe2cf878f220d4ad7145e7f89218 upstream.
      
      When fall-through warnings was enabled by default, commit d93512ef0f0e
      ("Makefile: Globally enable fall-through warning"), the following
      warnings was starting to show up:
      
      In file included from ../arch/arm64/include/asm/kvm_emulate.h:19,
                       from ../arch/arm64/kvm/regmap.c:13:
      ../arch/arm64/kvm/regmap.c: In function ‘vcpu_write_spsr32’:
      ../arch/arm64/include/asm/kvm_hyp.h:31:3: warning: this statement may fall
       through [-Wimplicit-fallthrough=]
         asm volatile(ALTERNATIVE(__msr_s(r##nvh, "%x0"), \
         ^~~
      ../arch/arm64/include/asm/kvm_hyp.h:46:31: note: in expansion of macro ‘write_sysreg_elx’
       #define write_sysreg_el1(v,r) write_sysreg_elx(v, r, _EL1, _EL12)
                                     ^~~~~~~~~~~~~~~~
      ../arch/arm64/kvm/regmap.c:180:3: note: in expansion of macro ‘write_sysreg_el1’
         write_sysreg_el1(v, SYS_SPSR);
         ^~~~~~~~~~~~~~~~
      ../arch/arm64/kvm/regmap.c:181:2: note: here
        case KVM_SPSR_ABT:
        ^~~~
      In file included from ../arch/arm64/include/asm/cputype.h:132,
                       from ../arch/arm64/include/asm/cache.h:8,
                       from ../include/linux/cache.h:6,
                       from ../include/linux/printk.h:9,
                       from ../include/linux/kernel.h:15,
                       from ../include/asm-generic/bug.h:18,
                       from ../arch/arm64/include/asm/bug.h:26,
                       from ../include/linux/bug.h:5,
                       from ../include/linux/mmdebug.h:5,
                       from ../include/linux/mm.h:9,
                       from ../arch/arm64/kvm/regmap.c:11:
      ../arch/arm64/include/asm/sysreg.h:837:2: warning: this statement may fall
       through [-Wimplicit-fallthrough=]
        asm volatile("msr " __stringify(r) ", %x0"  \
        ^~~
      ../arch/arm64/kvm/regmap.c:182:3: note: in expansion of macro ‘write_sysreg’
         write_sysreg(v, spsr_abt);
         ^~~~~~~~~~~~
      ../arch/arm64/kvm/regmap.c:183:2: note: here
        case KVM_SPSR_UND:
        ^~~~
      
      Rework to add a 'break;' in the swich-case since it didn't have that,
      leading to an interresting set of bugs.
      
      Cc: stable@vger.kernel.org # v4.17+
      Fixes: a8928195 ("KVM: arm64: Prepare to handle deferred save/restore of 32-bit registers")
      Signed-off-by: NAnders Roxell <anders.roxell@linaro.org>
      [maz: reworked commit message, fixed stable range]
      Signed-off-by: NMarc Zyngier <maz@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      
      c8d95668
    • Q
      asm-generic: fix -Wtype-limits compiler warnings · 0755b6b1
      Qian Cai 提交于
      [ Upstream commit cbedfe11347fe418621bd188d58a206beb676218 ]
      
      Commit d66acc39 ("bitops: Optimise get_order()") introduced a
      compilation warning because "rx_frag_size" is an "ushort" while
      PAGE_SHIFT here is 16.
      
      The commit changed the get_order() to be a multi-line macro where
      compilers insist to check all statements in the macro even when
      __builtin_constant_p(rx_frag_size) will return false as "rx_frag_size"
      is a module parameter.
      
      In file included from ./arch/powerpc/include/asm/page_64.h:107,
                       from ./arch/powerpc/include/asm/page.h:242,
                       from ./arch/powerpc/include/asm/mmu.h:132,
                       from ./arch/powerpc/include/asm/lppaca.h:47,
                       from ./arch/powerpc/include/asm/paca.h:17,
                       from ./arch/powerpc/include/asm/current.h:13,
                       from ./include/linux/thread_info.h:21,
                       from ./arch/powerpc/include/asm/processor.h:39,
                       from ./include/linux/prefetch.h:15,
                       from drivers/net/ethernet/emulex/benet/be_main.c:14:
      drivers/net/ethernet/emulex/benet/be_main.c: In function 'be_rx_cqs_create':
      ./include/asm-generic/getorder.h:54:9: warning: comparison is always
      true due to limited range of data type [-Wtype-limits]
         (((n) < (1UL << PAGE_SHIFT)) ? 0 :  \
               ^
      drivers/net/ethernet/emulex/benet/be_main.c:3138:33: note: in expansion
      of macro 'get_order'
        adapter->big_page_size = (1 << get_order(rx_frag_size)) * PAGE_SIZE;
                                       ^~~~~~~~~
      
      Fix it by moving all of this multi-line macro into a proper function,
      and killing __get_order() off.
      
      [akpm@linux-foundation.org: remove __get_order() altogether]
      [cai@lca.pw: v2]
        Link: http://lkml.kernel.org/r/1564000166-31428-1-git-send-email-cai@lca.pw
      Link: http://lkml.kernel.org/r/1563914986-26502-1-git-send-email-cai@lca.pw
      Fixes: d66acc39 ("bitops: Optimise get_order()")
      Signed-off-by: NQian Cai <cai@lca.pw>
      Reviewed-by: NNathan Chancellor <natechancellor@gmail.com>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Jakub Jelinek <jakub@redhat.com>
      Cc: Nick Desaulniers <ndesaulniers@google.com>
      Cc: Bill Wendling <morbo@google.com>
      Cc: James Y Knight <jyknight@google.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      0755b6b1
    • Y
      ocfs2: remove set but not used variable 'last_hash' · 7113a1bc
      YueHaibing 提交于
      [ Upstream commit 7bc36e3ce91471b6377c8eadc0a2f220a2280083 ]
      
      Fixes gcc '-Wunused-but-set-variable' warning:
      
        fs/ocfs2/xattr.c: In function ocfs2_xattr_bucket_find:
        fs/ocfs2/xattr.c:3828:6: warning: variable last_hash set but not used [-Wunused-but-set-variable]
      
      It's never used and can be removed.
      
      Link: http://lkml.kernel.org/r/20190716132110.34836-1-yuehaibing@huawei.comSigned-off-by: NYueHaibing <yuehaibing@huawei.com>
      Acked-by: NJoseph Qi <joseph.qi@linux.alibaba.com>
      Cc: Mark Fasheh <mark@fasheh.com>
      Cc: Joel Becker <jlbec@evilplan.org>
      Cc: Junxiao Bi <junxiao.bi@oracle.com>
      Cc: Changwei Ge <gechangwei@live.cn>
      Cc: Gang He <ghe@suse.com>
      Cc: Jun Piao <piaojun@huawei.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      7113a1bc
    • Y
      Revert "kmemleak: allow to coexist with fault injection" · 01d8d08f
      Yang Shi 提交于
      [ Upstream commit df9576def004d2cd5beedc00cb6e8901427634b9 ]
      
      When running ltp's oom test with kmemleak enabled, the below warning was
      triggerred since kernel detects __GFP_NOFAIL & ~__GFP_DIRECT_RECLAIM is
      passed in:
      
        WARNING: CPU: 105 PID: 2138 at mm/page_alloc.c:4608 __alloc_pages_nodemask+0x1c31/0x1d50
        Modules linked in: loop dax_pmem dax_pmem_core ip_tables x_tables xfs virtio_net net_failover virtio_blk failover ata_generic virtio_pci virtio_ring virtio libata
        CPU: 105 PID: 2138 Comm: oom01 Not tainted 5.2.0-next-20190710+ #7
        Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.10.2-0-g5f4c7b1-prebuilt.qemu-project.org 04/01/2014
        RIP: 0010:__alloc_pages_nodemask+0x1c31/0x1d50
        ...
         kmemleak_alloc+0x4e/0xb0
         kmem_cache_alloc+0x2a7/0x3e0
         mempool_alloc_slab+0x2d/0x40
         mempool_alloc+0x118/0x2b0
         bio_alloc_bioset+0x19d/0x350
         get_swap_bio+0x80/0x230
         __swap_writepage+0x5ff/0xb20
      
      The mempool_alloc_slab() clears __GFP_DIRECT_RECLAIM, however kmemleak
      has __GFP_NOFAIL set all the time due to d9570ee3 ("kmemleak:
      allow to coexist with fault injection").  But, it doesn't make any sense
      to have __GFP_NOFAIL and ~__GFP_DIRECT_RECLAIM specified at the same
      time.
      
      According to the discussion on the mailing list, the commit should be
      reverted for short term solution.  Catalin Marinas would follow up with
      a better solution for longer term.
      
      The failure rate of kmemleak metadata allocation may increase in some
      circumstances, but this should be expected side effect.
      
      Link: http://lkml.kernel.org/r/1563299431-111710-1-git-send-email-yang.shi@linux.alibaba.com
      Fixes: d9570ee3 ("kmemleak: allow to coexist with fault injection")
      Signed-off-by: NYang Shi <yang.shi@linux.alibaba.com>
      Suggested-by: NCatalin Marinas <catalin.marinas@arm.com>
      Acked-by: NMichal Hocko <mhocko@suse.com>
      Cc: Dmitry Vyukov <dvyukov@google.com>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Matthew Wilcox <willy@infradead.org>
      Cc: Qian Cai <cai@lca.pw>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      01d8d08f
    • C
      drm/exynos: fix missing decrement of retry counter · cf9a18d7
      Colin Ian King 提交于
      [ Upstream commit 1bbbab097a05276e312dd2462791d32b21ceb1ee ]
      
      Currently the retry counter is not being decremented, leading to a
      potential infinite spin if the scalar_reads don't change state.
      
      Addresses-Coverity: ("Infinite loop")
      Fixes: 280e54c9 ("drm/exynos: scaler: Reset hardware before starting the operation")
      Signed-off-by: NColin Ian King <colin.king@canonical.com>
      Signed-off-by: NInki Dae <inki.dae@samsung.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      cf9a18d7
    • J
      drm: msm: Fix add_gpu_components · c256729f
      Jeffrey Hugo 提交于
      [ Upstream commit 9ca7ad6c7706edeae331c1632d0c63897418ebad ]
      
      add_gpu_components() adds found GPU nodes from the DT to the match list,
      regardless of the status of the nodes.  This is a problem, because if the
      nodes are disabled, they should not be on the match list because they will
      not be matched.  This prevents display from initing if a GPU node is
      defined, but it's status is disabled.
      
      Fix this by checking the node's status before adding it to the match list.
      
      Fixes: dc3ea265 (drm/msm: Drop the gpu binding)
      Reviewed-by: NRob Clark <robdclark@gmail.com>
      Signed-off-by: NJeffrey Hugo <jeffrey.l.hugo@gmail.com>
      Signed-off-by: NSean Paul <seanpaul@chromium.org>
      Link: https://patchwork.freedesktop.org/patch/msgid/20190626180015.45242-1-jeffrey.l.hugo@gmail.comSigned-off-by: NSasha Levin <sashal@kernel.org>
      c256729f
    • J
      IB/mad: Fix use-after-free in ib mad completion handling · b4f0fee7
      Jack Morgenstein 提交于
      [ Upstream commit 770b7d96cfff6a8bf6c9f261ba6f135dc9edf484 ]
      
      We encountered a use-after-free bug when unloading the driver:
      
      [ 3562.116059] BUG: KASAN: use-after-free in ib_mad_post_receive_mads+0xddc/0xed0 [ib_core]
      [ 3562.117233] Read of size 4 at addr ffff8882ca5aa868 by task kworker/u13:2/23862
      [ 3562.118385]
      [ 3562.119519] CPU: 2 PID: 23862 Comm: kworker/u13:2 Tainted: G           OE     5.1.0-for-upstream-dbg-2019-05-19_16-44-30-13 #1
      [ 3562.121806] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu2 04/01/2014
      [ 3562.123075] Workqueue: ib-comp-unb-wq ib_cq_poll_work [ib_core]
      [ 3562.124383] Call Trace:
      [ 3562.125640]  dump_stack+0x9a/0xeb
      [ 3562.126911]  print_address_description+0xe3/0x2e0
      [ 3562.128223]  ? ib_mad_post_receive_mads+0xddc/0xed0 [ib_core]
      [ 3562.129545]  __kasan_report+0x15c/0x1df
      [ 3562.130866]  ? ib_mad_post_receive_mads+0xddc/0xed0 [ib_core]
      [ 3562.132174]  kasan_report+0xe/0x20
      [ 3562.133514]  ib_mad_post_receive_mads+0xddc/0xed0 [ib_core]
      [ 3562.134835]  ? find_mad_agent+0xa00/0xa00 [ib_core]
      [ 3562.136158]  ? qlist_free_all+0x51/0xb0
      [ 3562.137498]  ? mlx4_ib_sqp_comp_worker+0x1970/0x1970 [mlx4_ib]
      [ 3562.138833]  ? quarantine_reduce+0x1fa/0x270
      [ 3562.140171]  ? kasan_unpoison_shadow+0x30/0x40
      [ 3562.141522]  ib_mad_recv_done+0xdf6/0x3000 [ib_core]
      [ 3562.142880]  ? _raw_spin_unlock_irqrestore+0x46/0x70
      [ 3562.144277]  ? ib_mad_send_done+0x1810/0x1810 [ib_core]
      [ 3562.145649]  ? mlx4_ib_destroy_cq+0x2a0/0x2a0 [mlx4_ib]
      [ 3562.147008]  ? _raw_spin_unlock_irqrestore+0x46/0x70
      [ 3562.148380]  ? debug_object_deactivate+0x2b9/0x4a0
      [ 3562.149814]  __ib_process_cq+0xe2/0x1d0 [ib_core]
      [ 3562.151195]  ib_cq_poll_work+0x45/0xf0 [ib_core]
      [ 3562.152577]  process_one_work+0x90c/0x1860
      [ 3562.153959]  ? pwq_dec_nr_in_flight+0x320/0x320
      [ 3562.155320]  worker_thread+0x87/0xbb0
      [ 3562.156687]  ? __kthread_parkme+0xb6/0x180
      [ 3562.158058]  ? process_one_work+0x1860/0x1860
      [ 3562.159429]  kthread+0x320/0x3e0
      [ 3562.161391]  ? kthread_park+0x120/0x120
      [ 3562.162744]  ret_from_fork+0x24/0x30
      ...
      [ 3562.187615] Freed by task 31682:
      [ 3562.188602]  save_stack+0x19/0x80
      [ 3562.189586]  __kasan_slab_free+0x11d/0x160
      [ 3562.190571]  kfree+0xf5/0x2f0
      [ 3562.191552]  ib_mad_port_close+0x200/0x380 [ib_core]
      [ 3562.192538]  ib_mad_remove_device+0xf0/0x230 [ib_core]
      [ 3562.193538]  remove_client_context+0xa6/0xe0 [ib_core]
      [ 3562.194514]  disable_device+0x14e/0x260 [ib_core]
      [ 3562.195488]  __ib_unregister_device+0x79/0x150 [ib_core]
      [ 3562.196462]  ib_unregister_device+0x21/0x30 [ib_core]
      [ 3562.197439]  mlx4_ib_remove+0x162/0x690 [mlx4_ib]
      [ 3562.198408]  mlx4_remove_device+0x204/0x2c0 [mlx4_core]
      [ 3562.199381]  mlx4_unregister_interface+0x49/0x1d0 [mlx4_core]
      [ 3562.200356]  mlx4_ib_cleanup+0xc/0x1d [mlx4_ib]
      [ 3562.201329]  __x64_sys_delete_module+0x2d2/0x400
      [ 3562.202288]  do_syscall_64+0x95/0x470
      [ 3562.203277]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      The problem was that the MAD PD was deallocated before the MAD CQ.
      There was completion work pending for the CQ when the PD got deallocated.
      When the mad completion handling reached procedure
      ib_mad_post_receive_mads(), we got a use-after-free bug in the following
      line of code in that procedure:
         sg_list.lkey = qp_info->port_priv->pd->local_dma_lkey;
      (the pd pointer in the above line is no longer valid, because the
      pd has been deallocated).
      
      We fix this by allocating the PD before the CQ in procedure
      ib_mad_port_open(), and deallocating the PD after freeing the CQ
      in procedure ib_mad_port_close().
      
      Since the CQ completion work queue is flushed during ib_free_cq(),
      no completions will be pending for that CQ when the PD is later
      deallocated.
      
      Note that freeing the CQ before deallocating the PD is the practice
      in the ULPs.
      
      Fixes: 4be90bc6 ("IB/mad: Remove ib_get_dma_mr calls")
      Signed-off-by: NJack Morgenstein <jackm@dev.mellanox.co.il>
      Signed-off-by: NLeon Romanovsky <leonro@mellanox.com>
      Link: https://lore.kernel.org/r/20190801121449.24973-1-leon@kernel.orgSigned-off-by: NDoug Ledford <dledford@redhat.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      b4f0fee7
    • G
      IB/mlx5: Fix MR registration flow to use UMR properly · a0258ff4
      Guy Levi 提交于
      [ Upstream commit e5366d309a772fef264ec85e858f9ea46f939848 ]
      
      Driver shouldn't allow to use UMR to register a MR when
      umr_modify_atomic_disabled is set. Otherwise it will always end up with a
      failure in the post send flow which sets the UMR WQE to modify atomic access
      right.
      
      Fixes: c8d75a98 ("IB/mlx5: Respect new UMR capabilities")
      Signed-off-by: NGuy Levi <guyle@mellanox.com>
      Reviewed-by: NMoni Shoua <monis@mellanox.com>
      Signed-off-by: NLeon Romanovsky <leonro@mellanox.com>
      Link: https://lore.kernel.org/r/20190731081929.32559-1-leon@kernel.orgSigned-off-by: NDoug Ledford <dledford@redhat.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      a0258ff4
    • L
      IB/core: Add mitigation for Spectre V1 · efb742ce
      Luck, Tony 提交于
      [ Upstream commit 61f259821dd3306e49b7d42a3f90fb5a4ff3351b ]
      
      Some processors may mispredict an array bounds check and
      speculatively access memory that they should not. With
      a user supplied array index we like to play things safe
      by masking the value with the array size before it is
      used as an index.
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      Link: https://lore.kernel.org/r/20190731043957.GA1600@agluck-desk2.amr.corp.intel.comSigned-off-by: NDoug Ledford <dledford@redhat.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      efb742ce