1. 27 Nov, 2020 4 commits
  2. 26 Nov, 2020 8 commits
  3. 25 Nov, 2020 14 commits
    • Vladimir Oltean's avatar
      enetc: Let the hardware auto-advance the taprio base-time of 0 · 90cf87d1
      Vladimir Oltean authored
      The tc-taprio base time indicates the beginning of the tc-taprio
      schedule, which is cyclic by definition (where the length of the cycle
      in nanoseconds is called the cycle time). The base time is a 64-bit PTP
      time in the TAI domain.
      
      Logically, the base-time should be a future time. But that imposes some
      restrictions to user space, which has to retrieve the current PTP time
      from the NIC first, then calculate a base time that will still be larger
      than the base time by the time the kernel driver programs this value
      into the hardware. Actually ensuring that the programmed base time is in
      the future is still a problem even if the kernel alone deals with this.
      
      Luckily, the enetc hardware already advances a base-time that is in the
      past into a congruent time in the immediate future, according to the
      same formula that can be found in the software implementation of taprio
      (in taprio_get_start_time):
      
      	/* Schedule the start time for the beginning of the next
      	 * cycle.
      	 */
      	n = div64_s64(ktime_sub_ns(now, base), cycle);
      	*start = ktime_add_ns(base, (n + 1) * cycle);
      
      There's only one problem: the driver doesn't let the hardware do that.
      It interferes with the base-time passed from user space, by special-casing
      the situation when the base-time is zero, and replaces that with the
      current PTP time. This changes the intended effective base-time of the
      schedule, which will in the end have a different phase offset than if
      the base-time of 0.000000000 was to be advanced by an integer multiple
      of the cycle-time.
      
      Fixes: 34c6adf1 ("enetc: Configure the Time-Aware Scheduler via tc-taprio offload")
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Link: https://lore.kernel.org/r/20201124220259.3027991-1-vladimir.oltean@nxp.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      90cf87d1
    • Eric Dumazet's avatar
      gro_cells: reduce number of synchronize_net() calls · 2543a600
      Eric Dumazet authored
      After cited commit, gro_cells_destroy() became damn slow
      on hosts with a lot of cores.
      
      This is because we have one additional synchronize_net() per cpu as
      stated in the changelog.
      
      gro_cells_init() is setting NAPI_STATE_NO_BUSY_POLL, and this was enough
      to not have one synchronize_net() call per netif_napi_del()
      
      We can factorize all the synchronize_net() to a single one,
      right before freeing per-cpu memory.
      
      Fixes: 5198d545 ("net: remove napi_hash_del() from driver-facing API")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Link: https://lore.kernel.org/r/20201124203822.1360107-1-eric.dumazet@gmail.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      2543a600
    • Antonio Borneo's avatar
      net: stmmac: fix incorrect merge of patch upstream · 12a8fe56
      Antonio Borneo authored
      Commit 75792624 ("net: stmmac: add flexible PPS to dwmac
      4.10a") was intended to modify the struct dwmac410_ops, but it got
      somehow badly merged and modified the struct dwmac4_ops.
      
      Revert the modification in struct dwmac4_ops and re-apply it
      properly in struct dwmac410_ops.
      
      Fixes: 75792624 ("net: stmmac: add flexible PPS to dwmac 4.10a")
      Signed-off-by: default avatarAntonio Borneo <antonio.borneo@st.com>
      Reported-by: default avatarAhmad Fatoum <a.fatoum@pengutronix.de>
      Link: https://lore.kernel.org/r/20201124223729.886992-1-antonio.borneo@st.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      12a8fe56
    • Wang Hai's avatar
      ipv6: addrlabel: fix possible memory leak in ip6addrlbl_net_init · e255e11e
      Wang Hai authored
      kmemleak report a memory leak as follows:
      
      unreferenced object 0xffff8880059c6a00 (size 64):
        comm "ip", pid 23696, jiffies 4296590183 (age 1755.384s)
        hex dump (first 32 bytes):
          20 01 00 10 00 00 00 00 00 00 00 00 00 00 00 00   ...............
          1c 00 00 00 00 00 00 00 00 00 00 00 07 00 00 00  ................
        backtrace:
          [<00000000aa4e7a87>] ip6addrlbl_add+0x90/0xbb0
          [<0000000070b8d7f1>] ip6addrlbl_net_init+0x109/0x170
          [<000000006a9ca9d4>] ops_init+0xa8/0x3c0
          [<000000002da57bf2>] setup_net+0x2de/0x7e0
          [<000000004e52d573>] copy_net_ns+0x27d/0x530
          [<00000000b07ae2b4>] create_new_namespaces+0x382/0xa30
          [<000000003b76d36f>] unshare_nsproxy_namespaces+0xa1/0x1d0
          [<0000000030653721>] ksys_unshare+0x3a4/0x780
          [<0000000007e82e40>] __x64_sys_unshare+0x2d/0x40
          [<0000000031a10c08>] do_syscall_64+0x33/0x40
          [<0000000099df30e7>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
      
      We should free all rules when we catch an error in ip6addrlbl_net_init().
      otherwise a memory leak will occur.
      
      Fixes: 2a8cc6c8 ("[IPV6] ADDRCONF: Support RFC3484 configurable address selection policy table.")
      Reported-by: default avatarHulk Robot <hulkci@huawei.com>
      Signed-off-by: default avatarWang Hai <wanghai38@huawei.com>
      Link: https://lore.kernel.org/r/20201124071728.8385-1-wanghai38@huawei.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      e255e11e
    • Jakub Kicinski's avatar
      Documentation: netdev-FAQ: suggest how to post co-dependent series · 6f7a1f9c
      Jakub Kicinski authored
      Make an explicit suggestion how to post user space side of kernel
      patches to avoid reposts when patchwork groups the wrong patches.
      
      v2: mention the cases unlike iproute2 explicitly
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Reviewed-by: default avatarDavid Ahern <dsahern@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6f7a1f9c
    • Jakub Kicinski's avatar
      Merge tag 'batadv-net-pullrequest-20201124' of git://git.open-mesh.org/linux-merge · 26c89965
      Jakub Kicinski authored
      Simon Wunderlich says:
      
      ====================
      Here is a batman-adv bugfix:
      
       - set module owner to THIS_MODULE, by Taehee Yoo
      
      * tag 'batadv-net-pullrequest-20201124' of git://git.open-mesh.org/linux-merge:
        batman-adv: set .owner to THIS_MODULE
      ====================
      
      Link: https://lore.kernel.org/r/20201124134417.17269-1-sw@simonwunderlich.deSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      26c89965
    • Jakub Kicinski's avatar
      Merge branch 'ibmvnic-null-pointer-dereference' · 49d66ed8
      Jakub Kicinski authored
      Lijun Pan says:
      
      ====================
      ibmvnic: null pointer dereference
      
      Fix two NULL pointer dereference crash issues.
      Improve module removal procedure.
      ====================
      
      Link: https://lore.kernel.org/r/20201123193547.57225-1-ljp@linux.ibm.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      49d66ed8
    • Lijun Pan's avatar
      ibmvnic: enhance resetting status check during module exit · 3ada2881
      Lijun Pan authored
      Based on the discussion with Sukadev Bhattiprolu and Dany Madden,
      we believe that checking adapter->resetting bit is preferred
      since RESETTING state flag is not as strict as resetting bit.
      RESETTING state flag is removed since it is verbose now.
      
      Fixes: 7d7195a0 ("ibmvnic: Do not process device remove during device reset")
      Signed-off-by: default avatarLijun Pan <ljp@linux.ibm.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      3ada2881
    • Lijun Pan's avatar
      ibmvnic: fix NULL pointer dereference in ibmvic_reset_crq · 0e435bef
      Lijun Pan authored
      crq->msgs could be NULL if the previous reset did not complete after
      freeing crq->msgs. Check for NULL before dereferencing them.
      
      Snippet of call trace:
      ...
      ibmvnic 30000003 env3 (unregistering): Releasing sub-CRQ
      ibmvnic 30000003 env3 (unregistering): Releasing CRQ
      BUG: Kernel NULL pointer dereference on read at 0x00000000
      Faulting instruction address: 0xc0000000000c1a30
      Oops: Kernel access of bad area, sig: 11 [#1]
      LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries
      Modules linked in: ibmvnic(E-) rpadlpar_io rpaphp xt_CHECKSUM xt_MASQUERADE xt_conntrack ipt_REJECT nf_reject_ipv4 nft_compat nft_counter nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables xsk_diag tcp_diag udp_diag tun raw_diag inet_diag unix_diag bridge af_packet_diag netlink_diag stp llc rfkill sunrpc pseries_rng xts vmx_crypto uio_pdrv_genirq uio binfmt_misc ip_tables xfs libcrc32c sd_mod t10_pi sg ibmvscsi ibmveth scsi_transport_srp dm_mirror dm_region_hash dm_log dm_mod [last unloaded: ibmvnic]
      CPU: 20 PID: 8426 Comm: kworker/20:0 Tainted: G            E     5.10.0-rc1+ #12
      Workqueue: events __ibmvnic_reset [ibmvnic]
      NIP:  c0000000000c1a30 LR: c008000001b00c18 CTR: 0000000000000400
      REGS: c00000000d05b7a0 TRAP: 0380   Tainted: G            E      (5.10.0-rc1+)
      MSR:  800000000280b033 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE>  CR: 44002480  XER: 20040000
      CFAR: c0000000000c19ec IRQMASK: 0
      GPR00: 0000000000000400 c00000000d05ba30 c008000001b17c00 0000000000000000
      GPR04: 0000000000000000 0000000000000000 0000000000000000 00000000000001e2
      GPR08: 000000000001f400 ffffffffffffd950 0000000000000000 c008000001b0b280
      GPR12: c0000000000c19c8 c00000001ec72e00 c00000000019a778 c00000002647b440
      GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
      GPR20: 0000000000000006 0000000000000001 0000000000000003 0000000000000002
      GPR24: 0000000000001000 c008000001b0d570 0000000000000005 c00000007ab5d550
      GPR28: c00000007ab5c000 c000000032fcf848 c00000007ab5cc00 c000000032fcf800
      NIP [c0000000000c1a30] memset+0x68/0x104
      LR [c008000001b00c18] ibmvnic_reset_crq+0x70/0x110 [ibmvnic]
      Call Trace:
      [c00000000d05ba30] [0000000000000800] 0x800 (unreliable)
      [c00000000d05bab0] [c008000001b0a930] do_reset.isra.40+0x224/0x634 [ibmvnic]
      [c00000000d05bb80] [c008000001b08574] __ibmvnic_reset+0x17c/0x3c0 [ibmvnic]
      [c00000000d05bc50] [c00000000018d9ac] process_one_work+0x2cc/0x800
      [c00000000d05bd20] [c00000000018df58] worker_thread+0x78/0x520
      [c00000000d05bdb0] [c00000000019a934] kthread+0x1c4/0x1d0
      [c00000000d05be20] [c00000000000d5d0] ret_from_kernel_thread+0x5c/0x6c
      
      Fixes: 032c5e82 ("Driver for IBM System i/p VNIC protocol")
      Signed-off-by: default avatarLijun Pan <ljp@linux.ibm.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      0e435bef
    • Lijun Pan's avatar
      ibmvnic: fix NULL pointer dereference in reset_sub_crq_queues · a0faaa27
      Lijun Pan authored
      adapter->tx_scrq and adapter->rx_scrq could be NULL if the previous reset
      did not complete after freeing sub crqs. Check for NULL before
      dereferencing them.
      
      Snippet of call trace:
      ibmvnic 30000006 env6: Releasing sub-CRQ
      ibmvnic 30000006 env6: Releasing CRQ
      ...
      ibmvnic 30000006 env6: Got Control IP offload Response
      ibmvnic 30000006 env6: Re-setting tx_scrq[0]
      BUG: Kernel NULL pointer dereference on read at 0x00000000
      Faulting instruction address: 0xc008000003dea7cc
      Oops: Kernel access of bad area, sig: 11 [#1]
      LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries
      Modules linked in: rpadlpar_io rpaphp xt_CHECKSUM xt_MASQUERADE xt_conntrack ipt_REJECT nf_reject_ipv4 nft_compat nft_counter nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables xsk_diag tcp_diag udp_diag raw_diag inet_diag unix_diag af_packet_diag netlink_diag tun bridge stp llc rfkill sunrpc pseries_rng xts vmx_crypto uio_pdrv_genirq uio binfmt_misc ip_tables xfs libcrc32c sd_mod t10_pi sg ibmvscsi ibmvnic ibmveth scsi_transport_srp dm_mirror dm_region_hash dm_log dm_mod
      CPU: 80 PID: 1856 Comm: kworker/80:2 Tainted: G        W         5.8.0+ #4
      Workqueue: events __ibmvnic_reset [ibmvnic]
      NIP:  c008000003dea7cc LR: c008000003dea7bc CTR: 0000000000000000
      REGS: c0000007ef7db860 TRAP: 0380   Tainted: G        W          (5.8.0+)
      MSR:  800000000280b033 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE>  CR: 28002422  XER: 0000000d
      CFAR: c000000000bd9520 IRQMASK: 0
      GPR00: c008000003dea7bc c0000007ef7dbaf0 c008000003df7400 c0000007fa26ec00
      GPR04: c0000007fcd0d008 c0000007fcd96350 0000000000000027 c0000007fcd0d010
      GPR08: 0000000000000023 0000000000000000 0000000000000000 0000000000000000
      GPR12: 0000000000002000 c00000001ec18e00 c0000000001982f8 c0000007bad6e840
      GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
      GPR20: 0000000000000000 0000000000000000 0000000000000000 fffffffffffffef7
      GPR24: 0000000000000402 c0000007fa26f3a8 0000000000000003 c00000016f8ec048
      GPR28: 0000000000000000 0000000000000000 0000000000000000 c0000007fa26ec00
      NIP [c008000003dea7cc] ibmvnic_reset_init+0x15c/0x258 [ibmvnic]
      LR [c008000003dea7bc] ibmvnic_reset_init+0x14c/0x258 [ibmvnic]
      Call Trace:
      [c0000007ef7dbaf0] [c008000003dea7bc] ibmvnic_reset_init+0x14c/0x258 [ibmvnic] (unreliable)
      [c0000007ef7dbb80] [c008000003de8860] __ibmvnic_reset+0x408/0x970 [ibmvnic]
      [c0000007ef7dbc50] [c00000000018b7cc] process_one_work+0x2cc/0x800
      [c0000007ef7dbd20] [c00000000018bd78] worker_thread+0x78/0x520
      [c0000007ef7dbdb0] [c0000000001984c4] kthread+0x1d4/0x1e0
      [c0000007ef7dbe20] [c00000000000cea8] ret_from_kernel_thread+0x5c/0x74
      
      Fixes: 57a49436 ("ibmvnic: Reset sub-crqs during driver reset")
      Signed-off-by: default avatarLijun Pan <ljp@linux.ibm.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      a0faaa27
    • Jakub Kicinski's avatar
      Merge branch 'fixes-for-ena-driver' · 5fc145f1
      Jakub Kicinski authored
      Shay Agroskin says:
      
      ====================
      Fixes for ENA driver
      
      - fix wrong data offset on machines that support rx offset
      - work-around Intel iommu issue
      - fix out of bound access when request id is wrong
      ====================
      
      Link: https://lore.kernel.org/r/20201123190859.21298-1-shayagr@amazon.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      5fc145f1
    • Shay Agroskin's avatar
      net: ena: fix packet's addresses for rx_offset feature · 1396d314
      Shay Agroskin authored
      This patch fixes two lines in which the rx_offset received by the device
      wasn't taken into account:
      
      - prefetch function:
      	In our driver the copied data would reside in
      	rx_info->page + rx_headroom + rx_offset
      
      	so the prefetch function is changed accordingly.
      
      - setting page_offset to zero for descriptors > 1:
      	for every descriptor but the first, the rx_offset is zero. Hence
      	the page_offset value should be set to rx_headroom.
      
      	The previous implementation changed the value of rx_info after
      	the descriptor was added to the SKB (essentially providing wrong
      	page offset).
      
      Fixes: 68f236df ("net: ena: add support for the rx offset feature")
      Signed-off-by: default avatarShay Agroskin <shayagr@amazon.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      1396d314
    • Shay Agroskin's avatar
      net: ena: set initial DMA width to avoid intel iommu issue · 09323b3b
      Shay Agroskin authored
      The ENA driver uses the readless mechanism, which uses DMA, to find
      out what the DMA mask is supposed to be.
      
      If DMA is used without setting the dma_mask first, it causes the
      Intel IOMMU driver to think that ENA is a 32-bit device and therefore
      disables IOMMU passthrough permanently.
      
      This patch sets the dma_mask to be ENA_MAX_PHYS_ADDR_SIZE_BITS=48
      before readless initialization in
      ena_device_init()->ena_com_mmio_reg_read_request_init(),
      which is large enough to workaround the intel_iommu issue.
      
      DMA mask is set again to the correct value after it's received from the
      device after readless is initialized.
      
      The patch also changes the driver to use dma_set_mask_and_coherent()
      function instead of the two pci_set_dma_mask() and
      pci_set_consistent_dma_mask() ones. Both methods achieve the same
      effect.
      
      Fixes: 1738cd3e ("net: ena: Add a driver for Amazon Elastic Network Adapters (ENA)")
      Signed-off-by: default avatarMike Cui <mikecui@amazon.com>
      Signed-off-by: default avatarArthur Kiyanovski <akiyano@amazon.com>
      Signed-off-by: default avatarShay Agroskin <shayagr@amazon.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      09323b3b
    • Shay Agroskin's avatar
      net: ena: handle bad request id in ena_netdev · 5b7022cf
      Shay Agroskin authored
      After request id is checked in validate_rx_req_id() its value is still
      used in the line
      	rx_ring->free_ids[next_to_clean] =
      					rx_ring->ena_bufs[i].req_id;
      even if it was found to be out-of-bound for the array free_ids.
      
      The patch moves the request id to an earlier stage in the napi routine and
      makes sure its value isn't used if it's found out-of-bounds.
      
      Fixes: 30623e1e ("net: ena: avoid memory access violation by validating req_id properly")
      Signed-off-by: default avatarIdo Segev <idose@amazon.com>
      Signed-off-by: default avatarShay Agroskin <shayagr@amazon.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      5b7022cf
  4. 24 Nov, 2020 10 commits
  5. 23 Nov, 2020 1 commit
  6. 21 Nov, 2020 3 commits