* [PATCH 84/87] ethernet: mellanox: mlxsw: remove memset after pci_alloc_persistent
From: Fuqian Huang @ 2019-06-27 17:43 UTC (permalink / raw)
Cc: Fuqian Huang, Jiri Pirko, Ido Schimmel, David S. Miller, netdev,
linux-kernel
pci_alloc_persistent calls dma_alloc_coherent directly.
In commit af7ddd8a627c
("Merge tag 'dma-mapping-4.21' of git://git.infradead.org/users/hch/dma-mapping"),
dma_alloc_coherent has already zeroed the memory.
So memset is not needed.
Signed-off-by: Fuqian Huang <huangfq.daxian@gmail.com>
---
drivers/net/ethernet/mellanox/mlxsw/pci.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/pci.c b/drivers/net/ethernet/mellanox/mlxsw/pci.c
index b40455f8293d..be310ac0883a 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/pci.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/pci.c
@@ -835,7 +835,6 @@ static int mlxsw_pci_queue_init(struct mlxsw_pci *mlxsw_pci, char *mbox,
&mem_item->mapaddr);
if (!mem_item->buf)
return -ENOMEM;
- memset(mem_item->buf, 0, mem_item->size);
q->elem_info = kcalloc(q->count, sizeof(*q->elem_info), GFP_KERNEL);
if (!q->elem_info) {
--
2.11.0
^ permalink raw reply related
* [PATCH 83/87] ethernet: neterion: remove memset after pci_alloc_persistent
From: Fuqian Huang @ 2019-06-27 17:43 UTC (permalink / raw)
Cc: Fuqian Huang, Jon Mason, David S. Miller, netdev, linux-kernel
pci_alloc_persistent calls dma_alloc_coherent directly.
In commit af7ddd8a627c
("Merge tag 'dma-mapping-4.21' of git://git.infradead.org/users/hch/dma-mapping"),
dma_alloc_coherent has already zeroed the memory.
So memset is not needed.
Signed-off-by: Fuqian Huang <huangfq.daxian@gmail.com>
---
drivers/net/ethernet/neterion/s2io.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/ethernet/neterion/s2io.c b/drivers/net/ethernet/neterion/s2io.c
index 3b2ae1a21678..e0b2bf327905 100644
--- a/drivers/net/ethernet/neterion/s2io.c
+++ b/drivers/net/ethernet/neterion/s2io.c
@@ -747,7 +747,6 @@ static int init_shared_mem(struct s2io_nic *nic)
return -ENOMEM;
}
mem_allocated += size;
- memset(tmp_v_addr, 0, size);
size = sizeof(struct rxd_info) *
rxd_count[nic->rxd_mode];
--
2.11.0
^ permalink raw reply related
* [PATCH 82/87] ethernet: netxen: remove memset after pci_alloc_persistent
From: Fuqian Huang @ 2019-06-27 17:44 UTC (permalink / raw)
Cc: Fuqian Huang, Manish Chopra, Rahul Verma, GR-Linux-NIC-Dev,
David S. Miller, netdev, linux-kernel
pci_alloc_persistent calls dma_alloc_coherent directly.
In commit af7ddd8a627c
("Merge tag 'dma-mapping-4.21' of git://git.infradead.org/users/hch/dma-mapping"),
dma_alloc_coherent has already zeroed the memory.
So memset is not needed.
Signed-off-by: Fuqian Huang <huangfq.daxian@gmail.com>
---
drivers/net/ethernet/qlogic/netxen/netxen_nic_ctx.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/netxen/netxen_nic_ctx.c b/drivers/net/ethernet/qlogic/netxen/netxen_nic_ctx.c
index 433052f734ed..5e9f8ee99800 100644
--- a/drivers/net/ethernet/qlogic/netxen/netxen_nic_ctx.c
+++ b/drivers/net/ethernet/qlogic/netxen/netxen_nic_ctx.c
@@ -442,10 +442,8 @@ nx_fw_cmd_create_tx_ctx(struct netxen_adapter *adapter)
goto out_free_rq;
}
- memset(rq_addr, 0, rq_size);
prq = rq_addr;
- memset(rsp_addr, 0, rsp_size);
prsp = rsp_addr;
prq->host_rsp_dma_addr = cpu_to_le64(rsp_phys_addr);
@@ -755,7 +753,6 @@ int netxen_alloc_hw_resources(struct netxen_adapter *adapter)
return -ENOMEM;
}
- memset(addr, 0, sizeof(struct netxen_ring_ctx));
recv_ctx->hwctx = addr;
recv_ctx->hwctx->ctx_id = cpu_to_le32(port);
recv_ctx->hwctx->cmd_consumer_offset =
--
2.11.0
^ permalink raw reply related
* [PATCH 81/87] ethernet: ti: remove memset after pci_alloc_persistent
From: Fuqian Huang @ 2019-06-27 17:44 UTC (permalink / raw)
Cc: Fuqian Huang, Samuel Chessman, David S. Miller, netdev,
linux-kernel
pci_alloc_persistent calls dma_alloc_coherent directly.
In commit af7ddd8a627c
("Merge tag 'dma-mapping-4.21' of git://git.infradead.org/users/hch/dma-mapping"),
dma_alloc_coherent has already zeroed the memory.
So memset is not needed.
Signed-off-by: Fuqian Huang <huangfq.daxian@gmail.com>
---
drivers/net/ethernet/ti/tlan.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/ethernet/ti/tlan.c b/drivers/net/ethernet/ti/tlan.c
index b4ab1a5f6cd0..78f0f2d59e22 100644
--- a/drivers/net/ethernet/ti/tlan.c
+++ b/drivers/net/ethernet/ti/tlan.c
@@ -855,7 +855,6 @@ static int tlan_init(struct net_device *dev)
dev->name);
return -ENOMEM;
}
- memset(priv->dma_storage, 0, dma_size);
priv->rx_list = (struct tlan_list *)
ALIGN((unsigned long)priv->dma_storage, 8);
priv->rx_list_dma = ALIGN(priv->dma_storage_dma, 8);
--
2.11.0
^ permalink raw reply related
* [PATCH 80/87] net: hippi: remove memset after pci_alloc_consistent
From: Fuqian Huang @ 2019-06-27 17:44 UTC (permalink / raw)
Cc: Fuqian Huang, Jes Sorensen, David S. Miller, linux-hippi, netdev,
linux-kernel
pci_alloc_consistent calls dma_alloc_coherent directly.
In commit af7ddd8a627c
("Merge tag 'dma-mapping-4.21' of git://git.infradead.org/users/hch/dma-mapping"),
dma_alloc_coherent has already zeroed the memory.
So memset is not needed.
Signed-off-by: Fuqian Huang <huangfq.daxian@gmail.com>
---
drivers/net/hippi/rrunner.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/hippi/rrunner.c b/drivers/net/hippi/rrunner.c
index 7b9350dbebdd..2a6ec5394966 100644
--- a/drivers/net/hippi/rrunner.c
+++ b/drivers/net/hippi/rrunner.c
@@ -1196,7 +1196,6 @@ static int rr_open(struct net_device *dev)
goto error;
}
rrpriv->rx_ctrl_dma = dma_addr;
- memset(rrpriv->rx_ctrl, 0, 256*sizeof(struct ring_ctrl));
rrpriv->info = pci_alloc_consistent(pdev, sizeof(struct rr_info),
&dma_addr);
@@ -1205,7 +1204,6 @@ static int rr_open(struct net_device *dev)
goto error;
}
rrpriv->info_dma = dma_addr;
- memset(rrpriv->info, 0, sizeof(struct rr_info));
wmb();
spin_lock_irqsave(&rrpriv->lock, flags);
--
2.11.0
^ permalink raw reply related
* [PATCH 79/87] net: vmxnet3: remove memset after dma_alloc_coherent
From: Fuqian Huang @ 2019-06-27 17:45 UTC (permalink / raw)
Cc: Fuqian Huang, Ronak Doshi, VMware, Inc., David S. Miller, netdev,
linux-kernel
In commit af7ddd8a627c
("Merge tag 'dma-mapping-4.21' of git://git.infradead.org/users/hch/dma-mapping"),
dma_alloc_coherent has already zeroed the memory.
So memset is not needed.
Signed-off-by: Fuqian Huang <huangfq.daxian@gmail.com>
---
drivers/net/vmxnet3/vmxnet3_drv.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/vmxnet3/vmxnet3_drv.c b/drivers/net/vmxnet3/vmxnet3_drv.c
index 89984fcab01e..a5ba7ed07e9c 100644
--- a/drivers/net/vmxnet3/vmxnet3_drv.c
+++ b/drivers/net/vmxnet3/vmxnet3_drv.c
@@ -3429,7 +3429,6 @@ vmxnet3_probe_device(struct pci_dev *pdev,
err = -ENOMEM;
goto err_ver;
}
- memset(adapter->coal_conf, 0, sizeof(*adapter->coal_conf));
adapter->coal_conf->coalMode = VMXNET3_COALESCE_DISABLED;
adapter->default_coal_mode = true;
}
--
2.11.0
^ permalink raw reply related
* [PATCH 78/87] wireless: ath10k: remove memset after dma_alloc_coherent
From: Fuqian Huang @ 2019-06-27 17:45 UTC (permalink / raw)
Cc: Fuqian Huang, Kalle Valo, David S. Miller, ath10k, linux-wireless,
netdev, linux-kernel
In commit af7ddd8a627c
("Merge tag 'dma-mapping-4.21' of git://git.infradead.org/users/hch/dma-mapping"),
dma_alloc_coherent has already zeroed the memory.
So memset is not needed.
Signed-off-by: Fuqian Huang <huangfq.daxian@gmail.com>
---
drivers/net/wireless/ath/ath10k/ce.c | 5 -----
1 file changed, 5 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/ce.c b/drivers/net/wireless/ath/ath10k/ce.c
index eca87f7c5b6c..294fbc1e89ab 100644
--- a/drivers/net/wireless/ath/ath10k/ce.c
+++ b/drivers/net/wireless/ath/ath10k/ce.c
@@ -1704,9 +1704,6 @@ ath10k_ce_alloc_dest_ring_64(struct ath10k *ar, unsigned int ce_id,
/* Correctly initialize memory to 0 to prevent garbage
* data crashing system when download firmware
*/
- memset(dest_ring->base_addr_owner_space_unaligned, 0,
- nentries * sizeof(struct ce_desc_64) + CE_DESC_RING_ALIGN);
-
dest_ring->base_addr_owner_space =
PTR_ALIGN(dest_ring->base_addr_owner_space_unaligned,
CE_DESC_RING_ALIGN);
@@ -2019,8 +2016,6 @@ void ath10k_ce_alloc_rri(struct ath10k *ar)
value |= ar->hw_ce_regs->upd->mask;
ath10k_ce_write32(ar, ce_base_addr + ctrl1_regs, value);
}
-
- memset(ce->vaddr_rri, 0, CE_COUNT * sizeof(u32));
}
EXPORT_SYMBOL(ath10k_ce_alloc_rri);
--
2.11.0
^ permalink raw reply related
* [PATCH 77/87] wireless: broadcom: remove memset after dma_alloc_coherent
From: Fuqian Huang @ 2019-06-27 17:45 UTC (permalink / raw)
Cc: Fuqian Huang, Arend van Spriel, Franky Lin, Hante Meuleman,
Chi-Hsien Lin, Wright Feng, Kalle Valo, David S. Miller,
Rafał Miłecki, Hans de Goede, Luis Chamberlain,
linux-wireless, brcm80211-dev-list.pdl, brcm80211-dev-list,
netdev, linux-kernel
In commit af7ddd8a627c
("Merge tag 'dma-mapping-4.21' of git://git.infradead.org/users/hch/dma-mapping"),
dma_alloc_coherent has already zeroed the memory.
So memset is not needed.
Signed-off-by: Fuqian Huang <huangfq.daxian@gmail.com>
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
index 83e4938527f4..3fc08fe7c3a2 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
@@ -1033,8 +1033,6 @@ brcmf_pcie_init_dmabuffer_for_device(struct brcmf_pciedev_info *devinfo,
address & 0xffffffff);
brcmf_pcie_write_tcm32(devinfo, tcm_dma_phys_addr + 4, address >> 32);
- memset(ring, 0, size);
-
return (ring);
}
--
2.11.0
^ permalink raw reply related
* Re: [PATCH net-next 00/16] mlxsw: PTP timestamping support
From: David Miller @ 2019-06-27 17:46 UTC (permalink / raw)
To: idosch; +Cc: richardcochran, netdev, jiri, petrm, mlxsw, idosch
In-Reply-To: <20190627173525.GA16859@splinter>
From: Ido Schimmel <idosch@idosch.org>
Date: Thu, 27 Jun 2019 20:35:25 +0300
> On Thu, Jun 27, 2019 at 09:51:34AM -0700, Richard Cochran wrote:
>> On Thu, Jun 27, 2019 at 04:52:43PM +0300, Ido Schimmel wrote:
>> > From: Ido Schimmel <idosch@mellanox.com>
>> >
>> > This is the second patchset adding PTP support in mlxsw. Next patchset
>> > will add PTP shapers which are required to maintain accuracy under rates
>> > lower than 40Gb/s, while subsequent patchsets will add tracepoints and
>> > selftests.
>>
>> Please add the PTP maintainer onto CC for PTP patch submissions.
>
> No problem. To be clear, I didn't Cc you since this is all internal to
> mlxsw.
That's not the issue.
As the PTP maintainer he wants to see if your driver is using the PTP
interfaces properly and providing PTP information as intended by the
various APIs.
^ permalink raw reply
* [PATCH 76/87] wireless: quantenna: pcie: remove memset after dmam_alloc_coherent
From: Fuqian Huang @ 2019-06-27 17:46 UTC (permalink / raw)
Cc: Fuqian Huang, Igor Mitsyanko, Avinash Patil, Sergey Matyukevich,
Kalle Valo, David S. Miller, Andrey Shevchenko, linux-wireless,
netdev, linux-kernel
In commit af7ddd8a627c
("Merge tag 'dma-mapping-4.21' of git://git.infradead.org/users/hch/dma-mapping"),
dmam_alloc_coherent has already zeroed the memory.
So memset is not needed.
Signed-off-by: Fuqian Huang <huangfq.daxian@gmail.com>
---
drivers/net/wireless/quantenna/qtnfmac/pcie/pearl_pcie.c | 2 --
drivers/net/wireless/quantenna/qtnfmac/pcie/topaz_pcie.c | 2 --
2 files changed, 4 deletions(-)
diff --git a/drivers/net/wireless/quantenna/qtnfmac/pcie/pearl_pcie.c b/drivers/net/wireless/quantenna/qtnfmac/pcie/pearl_pcie.c
index 3aa3714d4dfd..5ec1c9bc1612 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/pcie/pearl_pcie.c
+++ b/drivers/net/wireless/quantenna/qtnfmac/pcie/pearl_pcie.c
@@ -244,8 +244,6 @@ static int pearl_alloc_bd_table(struct qtnf_pcie_pearl_state *ps)
/* tx bd */
- memset(vaddr, 0, len);
-
ps->bd_table_vaddr = vaddr;
ps->bd_table_paddr = paddr;
ps->bd_table_len = len;
diff --git a/drivers/net/wireless/quantenna/qtnfmac/pcie/topaz_pcie.c b/drivers/net/wireless/quantenna/qtnfmac/pcie/topaz_pcie.c
index 9a4380ed7f1b..1f91088e3dff 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/pcie/topaz_pcie.c
+++ b/drivers/net/wireless/quantenna/qtnfmac/pcie/topaz_pcie.c
@@ -199,8 +199,6 @@ static int topaz_alloc_bd_table(struct qtnf_pcie_topaz_state *ts,
if (!vaddr)
return -ENOMEM;
- memset(vaddr, 0, len);
-
/* tx bd */
ts->tx_bd_vbase = vaddr;
--
2.11.0
^ permalink raw reply related
* [PATCH 72/87] ethernet: chelsio: remove memset after kvzalloc
From: Fuqian Huang @ 2019-06-27 17:46 UTC (permalink / raw)
Cc: Fuqian Huang, Vishal Kulkarni, David S. Miller, netdev,
linux-kernel
kvzalloc already zeroes the memory.
memset is unneeded.
Signed-off-by: Fuqian Huang <huangfq.daxian@gmail.com>
---
drivers/net/ethernet/chelsio/cxgb4/sched.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/sched.c b/drivers/net/ethernet/chelsio/cxgb4/sched.c
index ba6c153ee45c..60218dc676a8 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/sched.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/sched.c
@@ -207,7 +207,6 @@ static int t4_sched_queue_bind(struct port_info *pi, struct ch_sched_queue *p)
goto out_err;
/* Bind queue to specified class */
- memset(qe, 0, sizeof(*qe));
qe->cntxt_id = qid;
memcpy(&qe->param, p, sizeof(qe->param));
--
2.11.0
^ permalink raw reply related
* [PATCH 73/87] ethernet: freescale: Remove memset after dma_alloc_coherent
From: Fuqian Huang @ 2019-06-27 17:46 UTC (permalink / raw)
Cc: Fuqian Huang, Fugang Duan, David S. Miller, netdev, linux-kernel
In commit af7ddd8a627c
("Merge tag 'dma-mapping-4.21' of git://git.infradead.org/users/hch/dma-mapping"),
dma_alloc_coherent has already zeroed the memory.
So memset is not needed.
Signed-off-by: Fuqian Huang <huangfq.daxian@gmail.com>
---
drivers/net/ethernet/freescale/fec_main.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
index 38f10f7dcbc3..ec87b8b78d21 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -3143,8 +3143,6 @@ static int fec_enet_init(struct net_device *ndev)
return -ENOMEM;
}
- memset(cbd_base, 0, bd_size);
-
/* Get the Ethernet address */
fec_get_mac(ndev);
/* make sure MAC we just acquired is programmed into the hw */
--
2.11.0
^ permalink raw reply related
* [PATCH 75/87] ethernet: marvell: remove memset after pci_alloc_consistent
From: Fuqian Huang @ 2019-06-27 17:46 UTC (permalink / raw)
Cc: Fuqian Huang, Mirko Lindner, Stephen Hemminger, David S. Miller,
netdev, linux-kernel
pci_alloc_consistent calls dma_alloc_coherent directly.
In commit af7ddd8a627c
("Merge tag 'dma-mapping-4.21' of git://git.infradead.org/users/hch/dma-mapping"),
dma_alloc_coherent has already zeroed the memory.
So memset is not needed.
Signed-off-by: Fuqian Huang <huangfq.daxian@gmail.com>
---
drivers/net/ethernet/marvell/skge.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/ethernet/marvell/skge.c b/drivers/net/ethernet/marvell/skge.c
index 35a92fd2cf39..9ac854c2b371 100644
--- a/drivers/net/ethernet/marvell/skge.c
+++ b/drivers/net/ethernet/marvell/skge.c
@@ -2558,8 +2558,6 @@ static int skge_up(struct net_device *dev)
goto free_pci_mem;
}
- memset(skge->mem, 0, skge->mem_size);
-
err = skge_ring_alloc(&skge->rx_ring, skge->mem, skge->dma);
if (err)
goto free_pci_mem;
--
2.11.0
^ permalink raw reply related
* [PATCH 74/87] ethernet: jme.c: remove memset after dma_alloc_coherent
From: Fuqian Huang @ 2019-06-27 17:46 UTC (permalink / raw)
Cc: Fuqian Huang, Guo-Fu Tseng, David S. Miller, netdev, linux-kernel
In commit af7ddd8a627c
("Merge tag 'dma-mapping-4.21' of git://git.infradead.org/users/hch/dma-mapping"),
dma_alloc_coherent has already zeroed the memory.
So memset is not needed.
Signed-off-by: Fuqian Huang <huangfq.daxian@gmail.com>
---
drivers/net/ethernet/jme.c | 5 -----
1 file changed, 5 deletions(-)
diff --git a/drivers/net/ethernet/jme.c b/drivers/net/ethernet/jme.c
index 76b7b7b85e35..0b668357db4d 100644
--- a/drivers/net/ethernet/jme.c
+++ b/drivers/net/ethernet/jme.c
@@ -582,11 +582,6 @@ jme_setup_tx_resources(struct jme_adapter *jme)
if (unlikely(!(txring->bufinf)))
goto err_free_txring;
- /*
- * Initialize Transmit Descriptors
- */
- memset(txring->alloc, 0, TX_RING_ALLOC_SIZE(jme->tx_ring_size));
-
return 0;
err_free_txring:
--
2.11.0
^ permalink raw reply related
* Re: [PATCH 79/87] net: vmxnet3: remove memset after dma_alloc_coherent
From: David Miller @ 2019-06-27 17:47 UTC (permalink / raw)
To: huangfq.daxian; +Cc: doshir, pv-drivers, netdev, linux-kernel
In-Reply-To: <20190627174509.5829-1-huangfq.daxian@gmail.com>
I'd kindly request that you separate these sets of changes into one
set per subsystem and submit them properly that way.
I'm really not going to sift through 87 patches and pull out the ones
individually that got to my tree(s). That's your job to collect them
into appropriate groups properly.
Thank you.
^ permalink raw reply
* Re: [PATCH bpf-next 1/3] libbpf: capture value in BTF type info for BTF-defined map defs
From: Andrii Nakryiko @ 2019-06-27 17:47 UTC (permalink / raw)
To: Song Liu
Cc: Andrii Nakryiko, Alexei Starovoitov, daniel@iogearbox.net,
Kernel Team, bpf@vger.kernel.org, netdev@vger.kernel.org
In-Reply-To: <E28D922F-9D97-4836-B687-B4CBC3549AE1@fb.com>
On Thu, Jun 27, 2019 at 10:27 AM Song Liu <songliubraving@fb.com> wrote:
>
>
>
> > On Jun 26, 2019, at 4:21 PM, Andrii Nakryiko <andriin@fb.com> wrote:
> >
> > Change BTF-defined map definitions to capture compile-time integer
> > values as part of BTF type definition, to avoid split of key/value type
> > information and actual type/size/flags initialization for maps.
>
> If I have an old bpf program and compiled it with new llvm, will it
> work with new libbpf?
You mean BPF programs that used previous incarnation of BTF-defined
maps? No, they won't work. But we never released them, so I think it's
ok to change them. Nothing should be using that except for selftests,
which I fixed.
>
>
> >
> > Signed-off-by: Andrii Nakryiko <andriin@fb.com>
> > ---
<snip>
> > diff --git a/tools/testing/selftests/bpf/bpf_helpers.h b/tools/testing/selftests/bpf/bpf_helpers.h
> > index 1a5b1accf091..aa5ddf58c088 100644
> > --- a/tools/testing/selftests/bpf/bpf_helpers.h
> > +++ b/tools/testing/selftests/bpf/bpf_helpers.h
> > @@ -8,6 +8,9 @@
> > */
> > #define SEC(NAME) __attribute__((section(NAME), used))
> >
> > +#define __int(name, val) int (*name)[val]
> > +#define __type(name, val) val *name
> > +
>
> I think we need these two in libbpf.
Yes, but it's another story for another set of patches. We'll need to
provide bpf_helpers as part of libbpf for inclusion into BPF programs,
but there are a bunch of problems right now with existing
bpf_heplers.h that prevents us from just copying it into libbpf. We'll
need to resolve those first.
But then again, there is no use of __int and __type for user-space
programs, so for now it's ok.
>
> Thanks,
> Song
>
> > /* helper macro to print out debug messages */
> > #define bpf_printk(fmt, ...) \
> > ({ \
> > --
> > 2.17.1
> >
>
^ permalink raw reply
* Re: [RFC] longer netdev names proposal
From: Jakub Kicinski @ 2019-06-27 17:48 UTC (permalink / raw)
To: Jiri Pirko; +Cc: netdev, davem, sthemmin, dsahern, mlxsw
In-Reply-To: <20190627094327.GF2424@nanopsycho>
On Thu, 27 Jun 2019 11:43:27 +0200, Jiri Pirko wrote:
> Hi all.
>
> In the past, there was repeatedly discussed the IFNAMSIZ (16) limit for
> netdevice name length. Now when we have PF and VF representors
> with port names like "pfXvfY", it became quite common to hit this limit:
> 0123456789012345
> enp131s0f1npf0vf6
> enp131s0f1npf0vf22
>
> Since IFLA_NAME is just a string, I though it might be possible to use
> it to carry longer names as it is. However, the userspace tools, like
> iproute2, are doing checks before print out. So for example in output of
> "ip addr" when IFLA_NAME is longer than IFNAMSIZE, the netdevice is
> completely avoided.
>
> So here is a proposal that might work:
> 1) Add a new attribute IFLA_NAME_EXT that could carry names longer than
> IFNAMSIZE, say 64 bytes. The max size should be only defined in kernel,
> user should be prepared for any string size.
> 2) Add a file in sysfs that would indicate that NAME_EXT is supported by
> the kernel.
> 3) Udev is going to look for the sysfs indication file. In case when
> kernel supports long names, it will do rename to longer name, setting
> IFLA_NAME_EXT. If not, it does what it does now - fail.
> 4) There are two cases that can happen during rename:
> A) The name is shorter than IFNAMSIZ
> -> both IFLA_NAME and IFLA_NAME_EXT would contain the same string:
> original IFLA_NAME = eth0
> original IFLA_NAME_EXT = eth0
> renamed IFLA_NAME = enp5s0f1npf0vf1
> renamed IFLA_NAME_EXT = enp5s0f1npf0vf1
> B) The name is longer tha IFNAMSIZ
> -> IFLA_NAME would contain the original one, IFLA_NAME_EXT would
> contain the new one:
> original IFLA_NAME = eth0
> original IFLA_NAME_EXT = eth0
> renamed IFLA_NAME = eth0
> renamed IFLA_NAME_EXT = enp131s0f1npf0vf22
I think B is the only way, A risks duplicate IFLA_NAMEs over ioctl,
right? And maybe there is some crazy application out there which
mixes netlink and ioctl.
I guess it's not worse than status quo, given that today renames
will fail and we will either get truncated names or eth0s..
> This would allow the old tools to work with "eth0" and the new
> tools would work with "enp131s0f1npf0vf22". In sysfs, there would
> be symlink from one name to another.
>
> Also, there might be a warning added to kernel if someone works
> with IFLA_NAME that the userspace tool should be upgraded.
>
> Eventually, only IFLA_NAME_EXT is going to be used by everyone.
>
> I'm aware there are other places where similar new attribute
> would have to be introduced too (ip rule for example).
> I'm not saying this is a simple work.
>
> Question is what to do with the ioctl api (get ifindex etc). I would
> probably leave it as is and push tools to use rtnetlink instead.
>
> Any ideas why this would not work? Any ideas how to solve this
> differently?
Since we'd have to update all user space to make use of the new names
I'd be tempted to move to a more structured device identification.
5: enp131s0f1npf0vf6: <BROADCAST,MULTICAST> ...
vs:
5: eth5 (parent enp131s0f1 pf 0 vf 6 peer X*): <BROADCAST,MULTICAST> ...
* ;)
And allow filtering/selection of device based on more attributes than
just name and ifindex. In practice in container workloads, for example,
the names are already very much insufficient to identify the device.
Refocusing on attributes is probably a big effort and not that practical
for traditional CLI users? IDK
Anyway, IMHO your scheme is strictly better than status quo.
^ permalink raw reply
* Re: [net-next 00/10][pull request] Intel Wired LAN Driver Updates 2019-06-26
From: David Miller @ 2019-06-27 17:49 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, nhorman, sassmann
In-Reply-To: <20190626193103.2169-1-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Wed, 26 Jun 2019 12:30:53 -0700
> This series contains updates to ixgbe and i40e only.
Pulled, thanks Jeff.
^ permalink raw reply
* Re: [RFC] longer netdev names proposal
From: Stephen Hemminger @ 2019-06-27 17:56 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: Jiri Pirko, netdev, davem, sthemmin, dsahern, mlxsw
In-Reply-To: <20190627104808.1404049a@cakuba.netronome.com>
On Thu, 27 Jun 2019 10:48:08 -0700
Jakub Kicinski <jakub.kicinski@netronome.com> wrote:
> On Thu, 27 Jun 2019 11:43:27 +0200, Jiri Pirko wrote:
> > Hi all.
> >
> > In the past, there was repeatedly discussed the IFNAMSIZ (16) limit for
> > netdevice name length. Now when we have PF and VF representors
> > with port names like "pfXvfY", it became quite common to hit this limit:
> > 0123456789012345
> > enp131s0f1npf0vf6
> > enp131s0f1npf0vf22
> >
> > Since IFLA_NAME is just a string, I though it might be possible to use
> > it to carry longer names as it is. However, the userspace tools, like
> > iproute2, are doing checks before print out. So for example in output of
> > "ip addr" when IFLA_NAME is longer than IFNAMSIZE, the netdevice is
> > completely avoided.
> >
> > So here is a proposal that might work:
> > 1) Add a new attribute IFLA_NAME_EXT that could carry names longer than
> > IFNAMSIZE, say 64 bytes. The max size should be only defined in kernel,
> > user should be prepared for any string size.
> > 2) Add a file in sysfs that would indicate that NAME_EXT is supported by
> > the kernel.
> > 3) Udev is going to look for the sysfs indication file. In case when
> > kernel supports long names, it will do rename to longer name, setting
> > IFLA_NAME_EXT. If not, it does what it does now - fail.
> > 4) There are two cases that can happen during rename:
> > A) The name is shorter than IFNAMSIZ
> > -> both IFLA_NAME and IFLA_NAME_EXT would contain the same string:
> > original IFLA_NAME = eth0
> > original IFLA_NAME_EXT = eth0
> > renamed IFLA_NAME = enp5s0f1npf0vf1
> > renamed IFLA_NAME_EXT = enp5s0f1npf0vf1
> > B) The name is longer tha IFNAMSIZ
> > -> IFLA_NAME would contain the original one, IFLA_NAME_EXT would
> > contain the new one:
> > original IFLA_NAME = eth0
> > original IFLA_NAME_EXT = eth0
> > renamed IFLA_NAME = eth0
> > renamed IFLA_NAME_EXT = enp131s0f1npf0vf22
>
> I think B is the only way, A risks duplicate IFLA_NAMEs over ioctl,
> right? And maybe there is some crazy application out there which
> mixes netlink and ioctl.
>
> I guess it's not worse than status quo, given that today renames
> will fail and we will either get truncated names or eth0s..
>
> > This would allow the old tools to work with "eth0" and the new
> > tools would work with "enp131s0f1npf0vf22". In sysfs, there would
> > be symlink from one name to another.
> >
> > Also, there might be a warning added to kernel if someone works
> > with IFLA_NAME that the userspace tool should be upgraded.
> >
> > Eventually, only IFLA_NAME_EXT is going to be used by everyone.
> >
> > I'm aware there are other places where similar new attribute
> > would have to be introduced too (ip rule for example).
> > I'm not saying this is a simple work.
> >
> > Question is what to do with the ioctl api (get ifindex etc). I would
> > probably leave it as is and push tools to use rtnetlink instead.
> >
> > Any ideas why this would not work? Any ideas how to solve this
> > differently?
>
> Since we'd have to update all user space to make use of the new names
> I'd be tempted to move to a more structured device identification.
>
> 5: enp131s0f1npf0vf6: <BROADCAST,MULTICAST> ...
>
> vs:
>
> 5: eth5 (parent enp131s0f1 pf 0 vf 6 peer X*): <BROADCAST,MULTICAST> ...
>
> * ;)
>
> And allow filtering/selection of device based on more attributes than
> just name and ifindex. In practice in container workloads, for example,
> the names are already very much insufficient to identify the device.
> Refocusing on attributes is probably a big effort and not that practical
> for traditional CLI users? IDK
>
> Anyway, IMHO your scheme is strictly better than status quo.
Or Cisco style naming ;-) Ethernet0/0
There is a better solution for human use already.
the field ifalias allows arbitrary values and hooked into SNMP.
Why not have userspace fill in this field with something by default?
^ permalink raw reply
* Re: [PATCH bpf-next 1/3] libbpf: capture value in BTF type info for BTF-defined map defs
From: Song Liu @ 2019-06-27 17:55 UTC (permalink / raw)
To: Andrii Nakryiko
Cc: Andrii Nakryiko, Alexei Starovoitov, daniel@iogearbox.net,
Kernel Team, bpf@vger.kernel.org, netdev@vger.kernel.org
In-Reply-To: <CAEf4Bza1p4ozVV-Vn8ibV6JRtGc_voh-Mkx51eWvuVi1P8ogSA@mail.gmail.com>
> On Jun 27, 2019, at 10:47 AM, Andrii Nakryiko <andrii.nakryiko@gmail.com> wrote:
>
> On Thu, Jun 27, 2019 at 10:27 AM Song Liu <songliubraving@fb.com> wrote:
>>
>>
>>
>>> On Jun 26, 2019, at 4:21 PM, Andrii Nakryiko <andriin@fb.com> wrote:
>>>
>>> Change BTF-defined map definitions to capture compile-time integer
>>> values as part of BTF type definition, to avoid split of key/value type
>>> information and actual type/size/flags initialization for maps.
>>
>> If I have an old bpf program and compiled it with new llvm, will it
>> work with new libbpf?
>
> You mean BPF programs that used previous incarnation of BTF-defined
> maps? No, they won't work. But we never released them, so I think it's
> ok to change them. Nothing should be using that except for selftests,
> which I fixed.
I see. This makes sense.
>
>>
>>
>>>
>>> Signed-off-by: Andrii Nakryiko <andriin@fb.com>
>>> ---
>
> <snip>
>
>>> diff --git a/tools/testing/selftests/bpf/bpf_helpers.h b/tools/testing/selftests/bpf/bpf_helpers.h
>>> index 1a5b1accf091..aa5ddf58c088 100644
>>> --- a/tools/testing/selftests/bpf/bpf_helpers.h
>>> +++ b/tools/testing/selftests/bpf/bpf_helpers.h
>>> @@ -8,6 +8,9 @@
>>> */
>>> #define SEC(NAME) __attribute__((section(NAME), used))
>>>
>>> +#define __int(name, val) int (*name)[val]
>>> +#define __type(name, val) val *name
>>> +
>>
>> I think we need these two in libbpf.
>
> Yes, but it's another story for another set of patches. We'll need to
> provide bpf_helpers as part of libbpf for inclusion into BPF programs,
> but there are a bunch of problems right now with existing
> bpf_heplers.h that prevents us from just copying it into libbpf. We'll
> need to resolve those first.
>
> But then again, there is no use of __int and __type for user-space
> programs, so for now it's ok.
OK. How about we put these two lines in an separate patch?
Thanks,
Song
^ permalink raw reply
* Re: [PATCH net-next 12/16] mlxsw: spectrum: PTP: Support timestamping on Spectrum-1
From: Petr Machata @ 2019-06-27 17:57 UTC (permalink / raw)
To: David Miller
Cc: idosch@idosch.org, netdev@vger.kernel.org, Jiri Pirko, mlxsw,
Ido Schimmel
In-Reply-To: <20190627.100427.16208207750306183.davem@davemloft.net>
David Miller <davem@davemloft.net> writes:
> From: Ido Schimmel <idosch@idosch.org>
> Date: Thu, 27 Jun 2019 16:52:55 +0300
>
>> + for (i = 0; i < num_rec; ++i) {
>
> Please use the more canonical "i++" here, thank you.
OK.
^ permalink raw reply
* Re: [PATCH net] net/ibmvnic: Report last valid speed and duplex values to ethtool
From: Andrew Lunn @ 2019-06-27 17:57 UTC (permalink / raw)
To: Thomas Falcon; +Cc: netdev, linuxppc-dev, bjking1, pradeep, dnbanerg
In-Reply-To: <1561655353-17114-1-git-send-email-tlfalcon@linux.ibm.com>
On Thu, Jun 27, 2019 at 12:09:13PM -0500, Thomas Falcon wrote:
> This patch resolves an issue with sensitive bonding modes
> that require valid speed and duplex settings to function
> properly. Currently, the adapter will report that device
> speed and duplex is unknown if the communication link
> with firmware is unavailable.
Dumb question. If you cannot communicate with the firmware, isn't the
device FUBAR? So setting the LACP port to disabled is the correct
things to do.
Andrew
^ permalink raw reply
* Re: [PATCH net-next v3 0/8] net: aquantia: implement vlan offloads
From: David Miller @ 2019-06-27 17:58 UTC (permalink / raw)
To: Igor.Russkikh; +Cc: netdev
In-Reply-To: <cover.1561552290.git.igor.russkikh@aquantia.com>
From: Igor Russkikh <Igor.Russkikh@aquantia.com>
Date: Wed, 26 Jun 2019 12:35:30 +0000
> This patchset introduces hardware VLAN offload support and also does some
> maintenance: we replace driver version with uts version string, add
> documentation file for atlantic driver, and update maintainers
> adding Igor as a maintainer.
>
> v3: shuffle doc sections, per Andrew's comments
>
> v2: updates in doc, gpl spdx tag cleanup
Series applied, thank you.
^ permalink raw reply
* Re: [PATCH V4 00/10] net: dsa: microchip: Convert to regmap
From: David Miller @ 2019-06-27 18:00 UTC (permalink / raw)
To: marex; +Cc: netdev, andrew, f.fainelli, Tristram.Ha, Woojung.Huh
In-Reply-To: <20190625234348.16246-1-marex@denx.de>
From: Marek Vasut <marex@denx.de>
Date: Wed, 26 Jun 2019 01:43:38 +0200
> This patchset converts KSZ9477 switch driver to regmap.
>
> This was tested with extra patches on KSZ8795. This was also tested
> on KSZ9477 on Microchip KSZ9477EVB board, which I now have.
>
> Signed-off-by: Marek Vasut <marex@denx.de>
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next 00/10] FDB, VLAN and PTP fixes for SJA1105 DSA
From: David Miller @ 2019-06-27 18:04 UTC (permalink / raw)
To: olteanv; +Cc: f.fainelli, vivien.didelot, andrew, netdev
In-Reply-To: <20190625233942.1946-1-olteanv@gmail.com>
From: Vladimir Oltean <olteanv@gmail.com>
Date: Wed, 26 Jun 2019 02:39:32 +0300
> This patchset is an assortment of fixes for the net-next version of the
> sja1105 DSA driver:
> - Avoid a kernel panic when the driver fails to probe or unregisters
> - Finish Arnd Bermann's idea of compiling PTP support as part of the
> main DSA driver and not separately
> - Better handling of initial port-based VLAN as well as VLANs for
> dsa_8021q FDB entries
> - Fix address learning for the SJA1105 P/Q/R/S family
> - Make static FDB entries persistent across switch resets
> - Fix reporting of statically-added FDB entries in 'bridge fdb show'
Series applied, thanks.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox