“f253981406c9f9f79d6439fc2bd31fd1a10f68cb”上不存在“drivers/media/pci/cx25821/cx25821-video.c”
  1. 17 7月, 2021 8 次提交
  2. 14 7月, 2021 4 次提交
    • Í
      sfc: add logs explaining XDP_TX/REDIRECT is not available · d2a16bde
      Íñigo Huguet 提交于
      If it's not possible to allocate enough channels for XDP, XDP_TX and
      XDP_REDIRECT don't work. However, only a message saying that not enough
      channels were available was shown, but not saying what are the
      consequences in that case. The user didn't know if he/she can use XDP
      or not, if the performance is reduced, or what.
      Signed-off-by: NÍñigo Huguet <ihuguet@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d2a16bde
    • Í
      sfc: ensure correct number of XDP queues · 788bc000
      Íñigo Huguet 提交于
      Commit 99ba0ea6 ("sfc: adjust efx->xdp_tx_queue_count with the real
      number of initialized queues") intended to fix a problem caused by a
      round up when calculating the number of XDP channels and queues.
      However, this was not the real problem. The real problem was that the
      number of XDP TX queues had been reduced to half in
      commit e26ca4b5 ("sfc: reduce the number of requested xdp ev queues"),
      but the variable xdp_tx_queue_count had remained the same.
      
      Once the correct number of XDP TX queues is created again in the
      previous patch of this series, this also can be reverted since the error
      doesn't actually exist.
      
      Only in the case that there is a bug in the code we can have different
      values in xdp_queue_number and efx->xdp_tx_queue_count. Because of this,
      and per Edward Cree's suggestion, I add instead a WARN_ON to catch if it
      happens again in the future.
      
      Note that the number of allocated queues can be higher than the number
      of used ones due to the round up, as explained in the existing comment
      in the code. That's why we also have to stop increasing xdp_queue_number
      beyond efx->xdp_tx_queue_count.
      Signed-off-by: NÍñigo Huguet <ihuguet@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      788bc000
    • Í
      sfc: fix lack of XDP TX queues - error XDP TX failed (-22) · f28100cb
      Íñigo Huguet 提交于
      Fixes: e26ca4b5 sfc: reduce the number of requested xdp ev queues
      
      The buggy commit intended to allocate less channels for XDP in order to
      be more unlikely to reach the limit of 32 channels of the driver.
      
      The idea was to use each IRQ/eventqeue for more XDP TX queues than
      before, calculating which is the maximum number of TX queues that one
      event queue can handle. For example, in EF10 each event queue could
      handle up to 8 queues, better than the 4 they were handling before the
      change. This way, it would have to allocate half of channels than before
      for XDP TX.
      
      The problem is that the TX queues are also contained inside the channel
      structs, and there are only 4 queues per channel. Reducing the number of
      channels means also reducing the number of queues, resulting in not
      having the desired number of 1 queue per CPU.
      
      This leads to getting errors on XDP_TX and XDP_REDIRECT if they're
      executed from a high numbered CPU, because there only exist queues for
      the low half of CPUs, actually. If XDP_TX/REDIRECT is executed in a low
      numbered CPU, the error doesn't happen. This is the error in the logs
      (repeated many times, even rate limited):
      sfc 0000:5e:00.0 ens3f0np0: XDP TX failed (-22)
      
      This errors happens in function efx_xdp_tx_buffers, where it expects to
      have a dedicated XDP TX queue per CPU.
      
      Reverting the change makes again more likely to reach the limit of 32
      channels in machines with many CPUs. If this happen, no XDP_TX/REDIRECT
      will be possible at all, and we will have this log error messages:
      
      At interface probe:
      sfc 0000:5e:00.0: Insufficient resources for 12 XDP event queues (24 other channels, max 32)
      
      At every subsequent XDP_TX/REDIRECT failure, rate limited:
      sfc 0000:5e:00.0 ens3f0np0: XDP TX failed (-22)
      
      However, without reverting the change, it makes the user to think that
      everything is OK at probe time, but later it fails in an unpredictable
      way, depending on the CPU that handles the packet.
      
      It is better to restore the predictable behaviour. If the user sees the
      error message at probe time, he/she can try to configure the best way it
      fits his/her needs. At least, he/she will have 2 options:
      - Accept that XDP_TX/REDIRECT is not available (he/she may not need it)
      - Load sfc module with modparam 'rss_cpus' with a lower number, thus
        creating less normal RX queues/channels, letting more free resources
        for XDP, with some performance penalty.
      
      Anyway, let the calculation of maximum TX queues that can be handled by
      a single event queue, and use it only if it's less than the number of TX
      queues per channel. This doesn't happen in practice, but could happen if
      some constant values are tweaked in the future, such us
      EFX_MAX_TXQ_PER_CHANNEL, EFX_MAX_EVQ_SIZE or EFX_MAX_DMAQ_SIZE.
      
      Related mailing list thread:
      https://lore.kernel.org/bpf/20201215104327.2be76156@carbon/Signed-off-by: NÍñigo Huguet <ihuguet@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f28100cb
    • V
      net: ocelot: fix switchdev objects synced for wrong netdev with LAG offload · e56c6bbd
      Vladimir Oltean 提交于
      The point with a *dev and a *brport_dev is that when we have a LAG net
      device that is a bridge port, *dev is an ocelot net device and
      *brport_dev is the bonding/team net device. The ocelot net device
      beneath the LAG does not exist from the bridge's perspective, so we need
      to sync the switchdev objects belonging to the brport_dev and not to the
      dev.
      
      Fixes: e4bd44e8 ("net: ocelot: replay switchdev events when joining bridge")
      Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e56c6bbd
  3. 13 7月, 2021 1 次提交
  4. 10 7月, 2021 3 次提交
  5. 09 7月, 2021 4 次提交
  6. 08 7月, 2021 2 次提交
  7. 07 7月, 2021 2 次提交
    • C
      octeontx2-pf: Fix assigned error return value that is never used · ad1f3797
      Colin Ian King 提交于
      Currently when the call to otx2_mbox_alloc_msg_cgx_mac_addr_update fails
      the error return variable rc is being assigned -ENOMEM and does not
      return early. rc is then re-assigned and the error case is not handled
      correctly. Fix this by returning -ENOMEM rather than assigning rc.
      
      Addresses-Coverity: ("Unused value")
      Fixes: 79d2be38 ("octeontx2-pf: offload DMAC filters to CGX/RPM block")
      Signed-off-by: NColin Ian King <colin.king@canonical.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ad1f3797
    • T
      ixgbevf: use xso.real_dev instead of xso.dev in callback functions of struct xfrmdev_ops · 2de7e4f6
      Taehee Yoo 提交于
      There are two pointers in struct xfrm_state_offload, *dev, *real_dev.
      These are used in callback functions of struct xfrmdev_ops.
      The *dev points whether bonding interface or real interface.
      If bonding ipsec offload is used, it points bonding interface If not,
      it points real interface.
      And real_dev always points real interface.
      So, ixgbevf should always use real_dev instead of dev.
      Of course, real_dev always not be null.
      
      Test commands:
          ip link add bond0 type bond
          #eth0 is ixgbevf interface
          ip link set eth0 master bond0
          ip link set bond0 up
          ip x s add proto esp dst 14.1.1.1 src 15.1.1.1 spi 0x07 mode \
      transport reqid 0x07 replay-window 32 aead 'rfc4106(gcm(aes))' \
      0x44434241343332312423222114131211f4f3f2f1 128 sel src 14.0.0.52/24 \
      dst 14.0.0.70/24 proto tcp offload dev bond0 dir in
      
      Splat looks like:
      KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
      CPU: 6 PID: 688 Comm: ip Not tainted 5.13.0-rc3+ #1168
      RIP: 0010:ixgbevf_ipsec_find_empty_idx+0x28/0x1b0 [ixgbevf]
      Code: 00 00 0f 1f 44 00 00 55 53 48 89 fb 48 83 ec 08 40 84 f6 0f 84 9c
      00 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 04 02
      84 c0 74 08 3c 01 0f 8e 4c 01 00 00 66 81 3b 00 04 0f
      RSP: 0018:ffff8880089af390 EFLAGS: 00010246
      RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000001
      RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000000
      RBP: ffff8880089af4f8 R08: 0000000000000003 R09: fffffbfff4287e11
      R10: 0000000000000001 R11: ffff888005de8908 R12: 0000000000000000
      R13: ffff88810936a000 R14: ffff88810936a000 R15: ffff888004d78040
      FS:  00007fdf9883a680(0000) GS:ffff88811a400000(0000)
      knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 000055bc14adbf40 CR3: 000000000b87c005 CR4: 00000000003706e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      Call Trace:
       ixgbevf_ipsec_add_sa+0x1bf/0x9c0 [ixgbevf]
       ? rcu_read_lock_sched_held+0x91/0xc0
       ? ixgbevf_ipsec_parse_proto_keys.isra.9+0x280/0x280 [ixgbevf]
       ? lock_acquire+0x191/0x720
       ? bond_ipsec_add_sa+0x48/0x350 [bonding]
       ? lockdep_hardirqs_on_prepare+0x3e0/0x3e0
       ? rcu_read_lock_held+0x91/0xa0
       ? rcu_read_lock_sched_held+0xc0/0xc0
       bond_ipsec_add_sa+0x193/0x350 [bonding]
       xfrm_dev_state_add+0x2a9/0x770
       ? memcpy+0x38/0x60
       xfrm_add_sa+0x2278/0x3b10 [xfrm_user]
       ? xfrm_get_policy+0xaa0/0xaa0 [xfrm_user]
       ? register_lock_class+0x1750/0x1750
       xfrm_user_rcv_msg+0x331/0x660 [xfrm_user]
       ? rcu_read_lock_sched_held+0x91/0xc0
       ? xfrm_user_state_lookup.constprop.39+0x320/0x320 [xfrm_user]
       ? find_held_lock+0x3a/0x1c0
       ? mutex_lock_io_nested+0x1210/0x1210
       ? sched_clock_cpu+0x18/0x170
       netlink_rcv_skb+0x121/0x350
      [ ... ]
      
      Fixes: 272c2330 ("xfrm: bail early on slave pass over skb")
      Signed-off-by: NTaehee Yoo <ap420073@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2de7e4f6
  8. 06 7月, 2021 3 次提交
  9. 04 7月, 2021 1 次提交
  10. 03 7月, 2021 3 次提交
  11. 02 7月, 2021 9 次提交