* [PATCH 1/5] net: hns3: remove unnecessary devm_kfree
From: Barry Song @ 2020-06-18 1:02 UTC (permalink / raw)
To: davem, kuba
Cc: yisen.zhuang, salil.mehta, netdev, linyunsheng, linux-kernel,
linuxarm, Barry Song
In-Reply-To: <20200618010211.75840-1-song.bao.hua@hisilicon.com>
since we are using device-managed function, it is unnecessary
to free in probe.
Signed-off-by: Barry Song <song.bao.hua@hisilicon.com>
---
drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
index b14f2abc2425..1817d7f2e5f6 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
@@ -2097,10 +2097,8 @@ static int hns3_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
pci_set_drvdata(pdev, ae_dev);
ret = hnae3_register_ae_dev(ae_dev);
- if (ret) {
- devm_kfree(&pdev->dev, ae_dev);
+ if (ret)
pci_set_drvdata(pdev, NULL);
- }
return ret;
}
@@ -2157,7 +2155,6 @@ static void hns3_shutdown(struct pci_dev *pdev)
struct hnae3_ae_dev *ae_dev = pci_get_drvdata(pdev);
hnae3_unregister_ae_dev(ae_dev);
- devm_kfree(&pdev->dev, ae_dev);
pci_set_drvdata(pdev, NULL);
if (system_state == SYSTEM_POWER_OFF)
--
2.23.0
^ permalink raw reply related
* [PATCH 2/5] net: hns3: pointer type of buffer should be void
From: Barry Song @ 2020-06-18 1:02 UTC (permalink / raw)
To: davem, kuba
Cc: yisen.zhuang, salil.mehta, netdev, linyunsheng, linux-kernel,
linuxarm, Barry Song
In-Reply-To: <20200618010211.75840-1-song.bao.hua@hisilicon.com>
Move the type of buffer address from unsigned char to void
Signed-off-by: Barry Song <song.bao.hua@hisilicon.com>
---
drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 2 +-
drivers/net/ethernet/hisilicon/hns3/hns3_enet.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
index 1817d7f2e5f6..61b5a849b162 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
@@ -3070,7 +3070,7 @@ static int hns3_handle_rx_bd(struct hns3_enet_ring *ring)
return -ENXIO;
if (!skb)
- ring->va = (unsigned char *)desc_cb->buf + desc_cb->page_offset;
+ ring->va = desc_cb->buf + desc_cb->page_offset;
/* Prefetch first cache line of first page
* Idea is to cache few bytes of the header of the packet. Our L1 Cache
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.h b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.h
index 66cd4395f781..9f64077ee834 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.h
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.h
@@ -407,7 +407,7 @@ struct hns3_enet_ring {
u32 pull_len; /* head length for current packet */
u32 frag_num;
- unsigned char *va; /* first buffer address for current packet */
+ void *va; /* first buffer address for current packet */
u32 flag; /* ring attribute */
--
2.23.0
^ permalink raw reply related
* [PATCH 3/5] net: hns3: rename buffer-related functions
From: Barry Song @ 2020-06-18 1:02 UTC (permalink / raw)
To: davem, kuba
Cc: yisen.zhuang, salil.mehta, netdev, linyunsheng, linux-kernel,
linuxarm, Barry Song
In-Reply-To: <20200618010211.75840-1-song.bao.hua@hisilicon.com>
This is for improving the readability.
Signed-off-by: Barry Song <song.bao.hua@hisilicon.com>
---
drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
index 61b5a849b162..3cd2216e49b9 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
@@ -2405,7 +2405,7 @@ static int hns3_alloc_desc(struct hns3_enet_ring *ring)
return 0;
}
-static int hns3_reserve_buffer_map(struct hns3_enet_ring *ring,
+static int hns3_alloc_and_map_buffer(struct hns3_enet_ring *ring,
struct hns3_desc_cb *cb)
{
int ret;
@@ -2426,9 +2426,9 @@ static int hns3_reserve_buffer_map(struct hns3_enet_ring *ring,
return ret;
}
-static int hns3_alloc_buffer_attach(struct hns3_enet_ring *ring, int i)
+static int hns3_alloc_and_attach_buffer(struct hns3_enet_ring *ring, int i)
{
- int ret = hns3_reserve_buffer_map(ring, &ring->desc_cb[i]);
+ int ret = hns3_alloc_and_map_buffer(ring, &ring->desc_cb[i]);
if (ret)
return ret;
@@ -2444,7 +2444,7 @@ static int hns3_alloc_ring_buffers(struct hns3_enet_ring *ring)
int i, j, ret;
for (i = 0; i < ring->desc_num; i++) {
- ret = hns3_alloc_buffer_attach(ring, i);
+ ret = hns3_alloc_and_attach_buffer(ring, i);
if (ret)
goto out_buffer_fail;
}
@@ -2590,7 +2590,7 @@ static void hns3_nic_alloc_rx_buffers(struct hns3_enet_ring *ring,
hns3_reuse_buffer(ring, ring->next_to_use);
} else {
- ret = hns3_reserve_buffer_map(ring, &res_cbs);
+ ret = hns3_alloc_and_map_buffer(ring, &res_cbs);
if (ret) {
u64_stats_update_begin(&ring->syncp);
ring->stats.sw_err_cnt++;
@@ -4184,7 +4184,7 @@ static int hns3_clear_rx_ring(struct hns3_enet_ring *ring)
* stack, so we need to replace the buffer here.
*/
if (!ring->desc_cb[ring->next_to_use].reuse_flag) {
- ret = hns3_reserve_buffer_map(ring, &res_cbs);
+ ret = hns3_alloc_and_map_buffer(ring, &res_cbs);
if (ret) {
u64_stats_update_begin(&ring->syncp);
ring->stats.sw_err_cnt++;
--
2.23.0
^ permalink raw reply related
* [PATCH 4/5] net: hns3: replace disable_irq by IRQ_NOAUTOEN flag
From: Barry Song @ 2020-06-18 1:02 UTC (permalink / raw)
To: davem, kuba
Cc: yisen.zhuang, salil.mehta, netdev, linyunsheng, linux-kernel,
linuxarm, Barry Song
In-Reply-To: <20200618010211.75840-1-song.bao.hua@hisilicon.com>
disable_irq() after request_irq() is still risk as there is a chance irq
can come after request_irq() and before disable_irq().
this should be done by IRQ_NOAUTOEN flag.
Signed-off-by: Barry Song <song.bao.hua@hisilicon.com>
---
drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
index 3cd2216e49b9..1330820152fa 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
@@ -8,6 +8,7 @@
#include <linux/cpu_rmap.h>
#endif
#include <linux/if_vlan.h>
+#include <linux/irq.h>
#include <linux/ip.h>
#include <linux/ipv6.h>
#include <linux/module.h>
@@ -154,6 +155,7 @@ static int hns3_nic_init_irq(struct hns3_nic_priv *priv)
tqp_vectors->name[HNAE3_INT_NAME_LEN - 1] = '\0';
+ irq_set_status_flags(tqp_vectors->vector_irq, IRQ_NOAUTOEN);
ret = request_irq(tqp_vectors->vector_irq, hns3_irq_handle, 0,
tqp_vectors->name, tqp_vectors);
if (ret) {
@@ -163,8 +165,6 @@ static int hns3_nic_init_irq(struct hns3_nic_priv *priv)
return ret;
}
- disable_irq(tqp_vectors->vector_irq);
-
irq_set_affinity_hint(tqp_vectors->vector_irq,
&tqp_vectors->affinity_mask);
--
2.23.0
^ permalink raw reply related
* [PATCH 5/5] net: hns3: streaming dma buffer sync between cpu and device
From: Barry Song @ 2020-06-18 1:02 UTC (permalink / raw)
To: davem, kuba
Cc: yisen.zhuang, salil.mehta, netdev, linyunsheng, linux-kernel,
linuxarm, Barry Song
In-Reply-To: <20200618010211.75840-1-song.bao.hua@hisilicon.com>
Right now they are empty functions for our SoC since hardware can keep
cache coherent, but it is still good to align with streaming DMA APIs
as device drivers should not make an assumption of SoC.
Reviewed-by: Yunsheng Lin <linyunsheng@huawei.com>
Signed-off-by: Barry Song <song.bao.hua@hisilicon.com>
---
.../net/ethernet/hisilicon/hns3/hns3_enet.c | 18 +++++++++++++++++-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
index 1330820152fa..b319a766889f 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
@@ -2473,6 +2473,11 @@ static void hns3_reuse_buffer(struct hns3_enet_ring *ring, int i)
ring->desc[i].addr = cpu_to_le64(ring->desc_cb[i].dma +
ring->desc_cb[i].page_offset);
ring->desc[i].rx.bd_base_info = 0;
+
+ dma_sync_single_for_device(ring_to_dev(ring),
+ ring->desc_cb[i].dma + ring->desc_cb[i].page_offset,
+ hns3_buf_size(ring),
+ DMA_FROM_DEVICE);
}
static void hns3_nic_reclaim_desc(struct hns3_enet_ring *ring, int head,
@@ -2918,6 +2923,11 @@ static int hns3_add_frag(struct hns3_enet_ring *ring)
skb = ring->tail_skb;
}
+ dma_sync_single_for_cpu(ring_to_dev(ring),
+ desc_cb->dma + desc_cb->page_offset,
+ hns3_buf_size(ring),
+ DMA_FROM_DEVICE);
+
hns3_nic_reuse_page(skb, ring->frag_num++, ring, 0, desc_cb);
trace_hns3_rx_desc(ring);
ring_ptr_move_fw(ring, next_to_clean);
@@ -3069,9 +3079,15 @@ static int hns3_handle_rx_bd(struct hns3_enet_ring *ring)
if (unlikely(!(bd_base_info & BIT(HNS3_RXD_VLD_B))))
return -ENXIO;
- if (!skb)
+ if (!skb) {
ring->va = desc_cb->buf + desc_cb->page_offset;
+ dma_sync_single_for_cpu(ring_to_dev(ring),
+ desc_cb->dma + desc_cb->page_offset,
+ hns3_buf_size(ring),
+ DMA_FROM_DEVICE);
+ }
+
/* Prefetch first cache line of first page
* Idea is to cache few bytes of the header of the packet. Our L1 Cache
* line size is 64B so need to prefetch twice to make it 128B. But in
--
2.23.0
^ permalink raw reply related
* [PATCH AUTOSEL 5.7 335/388] geneve: change from tx_error to tx_dropped on missing metadata
From: Sasha Levin @ 2020-06-18 1:07 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: Jiri Benc, David S . Miller, Sasha Levin, netdev
In-Reply-To: <20200618010805.600873-1-sashal@kernel.org>
From: Jiri Benc <jbenc@redhat.com>
[ Upstream commit 9d149045b3c0e44c049cdbce8a64e19415290017 ]
If the geneve interface is in collect_md (external) mode, it can't send any
packets submitted directly to its net interface, as such packets won't have
metadata attached. This is expected.
However, the kernel itself sends some packets to the interface, most
notably, IPv6 DAD, IPv6 multicast listener reports, etc. This is not wrong,
as tunnel metadata can be specified in routing table (although technically,
that has never worked for IPv6, but hopefully will be fixed eventually) and
then the interface must correctly participate in IPv6 housekeeping.
The problem is that any such attempt increases the tx_error counter. Just
bringing up a geneve interface with IPv6 enabled is enough to see a number
of tx_errors. That causes confusion among users, prompting them to find
a network error where there is none.
Change the counter used to tx_dropped. That better conveys the meaning
(there's nothing wrong going on, just some packets are getting dropped) and
hopefully will make admins panic less.
Signed-off-by: Jiri Benc <jbenc@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/geneve.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/net/geneve.c b/drivers/net/geneve.c
index 6b461be1820b..75266580b586 100644
--- a/drivers/net/geneve.c
+++ b/drivers/net/geneve.c
@@ -987,9 +987,10 @@ static netdev_tx_t geneve_xmit(struct sk_buff *skb, struct net_device *dev)
if (geneve->collect_md) {
info = skb_tunnel_info(skb);
if (unlikely(!info || !(info->mode & IP_TUNNEL_INFO_TX))) {
- err = -EINVAL;
netdev_dbg(dev, "no tunnel metadata\n");
- goto tx_error;
+ dev_kfree_skb(skb);
+ dev->stats.tx_dropped++;
+ return NETDEV_TX_OK;
}
} else {
info = &geneve->info;
@@ -1006,7 +1007,7 @@ static netdev_tx_t geneve_xmit(struct sk_buff *skb, struct net_device *dev)
if (likely(!err))
return NETDEV_TX_OK;
-tx_error:
+
dev_kfree_skb(skb);
if (err == -ELOOP)
--
2.25.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.7 334/388] bpf: Fix an error code in check_btf_func()
From: Sasha Levin @ 2020-06-18 1:07 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Dan Carpenter, Daniel Borkmann, Song Liu, Sasha Levin, netdev,
bpf
In-Reply-To: <20200618010805.600873-1-sashal@kernel.org>
From: Dan Carpenter <dan.carpenter@oracle.com>
[ Upstream commit e7ed83d6fa1a00d0f2ad0327e73d3ea9e7ea8de1 ]
This code returns success if the "info_aux" allocation fails but it
should return -ENOMEM.
Fixes: 8c1b6e69dcc1 ("bpf: Compare BTF types of functions arguments with actual types")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Song Liu <songliubraving@fb.com>
Link: https://lore.kernel.org/bpf/20200604085436.GA943001@mwanda
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
kernel/bpf/verifier.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index efe14cf24bc6..739d9ba3ba6b 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -7366,7 +7366,7 @@ static int check_btf_func(struct bpf_verifier_env *env,
const struct btf *btf;
void __user *urecord;
u32 prev_offset = 0;
- int ret = 0;
+ int ret = -ENOMEM;
nfuncs = attr->func_info_cnt;
if (!nfuncs)
--
2.25.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.7 368/388] bpf, sockhash: Synchronize delete from bucket list on map free
From: Sasha Levin @ 2020-06-18 1:07 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Jakub Sitnicki, Eric Dumazet, Alexei Starovoitov, John Fastabend,
Sasha Levin, netdev, bpf
In-Reply-To: <20200618010805.600873-1-sashal@kernel.org>
From: Jakub Sitnicki <jakub@cloudflare.com>
[ Upstream commit 75e68e5bf2c7fa9d3e874099139df03d5952a3e1 ]
We can end up modifying the sockhash bucket list from two CPUs when a
sockhash is being destroyed (sock_hash_free) on one CPU, while a socket
that is in the sockhash is unlinking itself from it on another CPU
it (sock_hash_delete_from_link).
This results in accessing a list element that is in an undefined state as
reported by KASAN:
| ==================================================================
| BUG: KASAN: wild-memory-access in sock_hash_free+0x13c/0x280
| Write of size 8 at addr dead000000000122 by task kworker/2:1/95
|
| CPU: 2 PID: 95 Comm: kworker/2:1 Not tainted 5.7.0-rc7-02961-ge22c35ab0038-dirty #691
| Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014
| Workqueue: events bpf_map_free_deferred
| Call Trace:
| dump_stack+0x97/0xe0
| ? sock_hash_free+0x13c/0x280
| __kasan_report.cold+0x5/0x40
| ? mark_lock+0xbc1/0xc00
| ? sock_hash_free+0x13c/0x280
| kasan_report+0x38/0x50
| ? sock_hash_free+0x152/0x280
| sock_hash_free+0x13c/0x280
| bpf_map_free_deferred+0xb2/0xd0
| ? bpf_map_charge_finish+0x50/0x50
| ? rcu_read_lock_sched_held+0x81/0xb0
| ? rcu_read_lock_bh_held+0x90/0x90
| process_one_work+0x59a/0xac0
| ? lock_release+0x3b0/0x3b0
| ? pwq_dec_nr_in_flight+0x110/0x110
| ? rwlock_bug.part.0+0x60/0x60
| worker_thread+0x7a/0x680
| ? _raw_spin_unlock_irqrestore+0x4c/0x60
| kthread+0x1cc/0x220
| ? process_one_work+0xac0/0xac0
| ? kthread_create_on_node+0xa0/0xa0
| ret_from_fork+0x24/0x30
| ==================================================================
Fix it by reintroducing spin-lock protected critical section around the
code that removes the elements from the bucket on sockhash free.
To do that we also need to defer processing of removed elements, until out
of atomic context so that we can unlink the socket from the map when
holding the sock lock.
Fixes: 90db6d772f74 ("bpf, sockmap: Remove bucket->lock from sock_{hash|map}_free")
Reported-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: Jakub Sitnicki <jakub@cloudflare.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Acked-by: John Fastabend <john.fastabend@gmail.com>
Link: https://lore.kernel.org/bpf/20200607205229.2389672-3-jakub@cloudflare.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/core/sock_map.c | 23 +++++++++++++++++++++--
1 file changed, 21 insertions(+), 2 deletions(-)
diff --git a/net/core/sock_map.c b/net/core/sock_map.c
index 7edbf1e92457..050bfac97cfb 100644
--- a/net/core/sock_map.c
+++ b/net/core/sock_map.c
@@ -1006,6 +1006,7 @@ static void sock_hash_free(struct bpf_map *map)
{
struct bpf_htab *htab = container_of(map, struct bpf_htab, map);
struct bpf_htab_bucket *bucket;
+ struct hlist_head unlink_list;
struct bpf_htab_elem *elem;
struct hlist_node *node;
int i;
@@ -1017,13 +1018,31 @@ static void sock_hash_free(struct bpf_map *map)
synchronize_rcu();
for (i = 0; i < htab->buckets_num; i++) {
bucket = sock_hash_select_bucket(htab, i);
- hlist_for_each_entry_safe(elem, node, &bucket->head, node) {
- hlist_del_rcu(&elem->node);
+
+ /* We are racing with sock_hash_delete_from_link to
+ * enter the spin-lock critical section. Every socket on
+ * the list is still linked to sockhash. Since link
+ * exists, psock exists and holds a ref to socket. That
+ * lets us to grab a socket ref too.
+ */
+ raw_spin_lock_bh(&bucket->lock);
+ hlist_for_each_entry(elem, &bucket->head, node)
+ sock_hold(elem->sk);
+ hlist_move_list(&bucket->head, &unlink_list);
+ raw_spin_unlock_bh(&bucket->lock);
+
+ /* Process removed entries out of atomic context to
+ * block for socket lock before deleting the psock's
+ * link to sockhash.
+ */
+ hlist_for_each_entry_safe(elem, node, &unlink_list, node) {
+ hlist_del(&elem->node);
lock_sock(elem->sk);
rcu_read_lock();
sock_map_unref(elem->sk, elem);
rcu_read_unlock();
release_sock(elem->sk);
+ sock_put(elem->sk);
sock_hash_free_elem(htab, elem);
}
}
--
2.25.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.7 371/388] libbpf: Handle GCC noreturn-turned-volatile quirk
From: Sasha Levin @ 2020-06-18 1:07 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Andrii Nakryiko, Jean-Philippe Brucker, Daniel Borkmann,
Sasha Levin, netdev, bpf, clang-built-linux
In-Reply-To: <20200618010805.600873-1-sashal@kernel.org>
From: Andrii Nakryiko <andriin@fb.com>
[ Upstream commit 32022fd97ed34f6812802bf1288db27c313576f4 ]
Handle a GCC quirk of emitting extra volatile modifier in DWARF (and
subsequently preserved in BTF by pahole) for function pointers marked as
__attribute__((noreturn)). This was the way to mark such functions before GCC
2.5 added noreturn attribute. Drop such func_proto modifiers, similarly to how
it's done for array (also to handle GCC quirk/bug).
Such volatile attribute is emitted by GCC only, so existing selftests can't
express such test. Simple repro is like this (compiled with GCC + BTF
generated by pahole):
struct my_struct {
void __attribute__((noreturn)) (*fn)(int);
};
struct my_struct a;
Without this fix, output will be:
struct my_struct {
voidvolatile (*fn)(int);
};
With the fix:
struct my_struct {
void (*fn)(int);
};
Fixes: 351131b51c7a ("libbpf: add btf_dump API for BTF-to-C conversion")
Reported-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
Signed-off-by: Andrii Nakryiko <andriin@fb.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Tested-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
Link: https://lore.kernel.org/bpf/20200610052335.2862559-1-andriin@fb.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
tools/lib/bpf/btf_dump.c | 33 ++++++++++++++++++++++++---------
1 file changed, 24 insertions(+), 9 deletions(-)
diff --git a/tools/lib/bpf/btf_dump.c b/tools/lib/bpf/btf_dump.c
index 0c28ee82834b..653dbbe2e366 100644
--- a/tools/lib/bpf/btf_dump.c
+++ b/tools/lib/bpf/btf_dump.c
@@ -1137,6 +1137,20 @@ static void btf_dump_emit_mods(struct btf_dump *d, struct id_stack *decl_stack)
}
}
+static void btf_dump_drop_mods(struct btf_dump *d, struct id_stack *decl_stack)
+{
+ const struct btf_type *t;
+ __u32 id;
+
+ while (decl_stack->cnt) {
+ id = decl_stack->ids[decl_stack->cnt - 1];
+ t = btf__type_by_id(d->btf, id);
+ if (!btf_is_mod(t))
+ return;
+ decl_stack->cnt--;
+ }
+}
+
static void btf_dump_emit_name(const struct btf_dump *d,
const char *name, bool last_was_ptr)
{
@@ -1235,14 +1249,7 @@ static void btf_dump_emit_type_chain(struct btf_dump *d,
* a const/volatile modifier for array, so we are
* going to silently skip them here.
*/
- while (decls->cnt) {
- next_id = decls->ids[decls->cnt - 1];
- next_t = btf__type_by_id(d->btf, next_id);
- if (btf_is_mod(next_t))
- decls->cnt--;
- else
- break;
- }
+ btf_dump_drop_mods(d, decls);
if (decls->cnt == 0) {
btf_dump_emit_name(d, fname, last_was_ptr);
@@ -1270,7 +1277,15 @@ static void btf_dump_emit_type_chain(struct btf_dump *d,
__u16 vlen = btf_vlen(t);
int i;
- btf_dump_emit_mods(d, decls);
+ /*
+ * GCC emits extra volatile qualifier for
+ * __attribute__((noreturn)) function pointers. Clang
+ * doesn't do it. It's a GCC quirk for backwards
+ * compatibility with code written for GCC <2.5. So,
+ * similarly to extra qualifiers for array, just drop
+ * them, instead of handling them.
+ */
+ btf_dump_drop_mods(d, decls);
if (decls->cnt) {
btf_dump_printf(d, " (");
btf_dump_emit_type_chain(d, decls, fname, lvl);
--
2.25.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.4 076/266] net: dsa: lantiq_gswip: fix and improve the unsupported interface error
From: Sasha Levin @ 2020-06-18 1:13 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Martin Blumenstingl, Hauke Mehrtens, David S . Miller,
Sasha Levin, netdev
In-Reply-To: <20200618011631.604574-1-sashal@kernel.org>
From: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
[ Upstream commit 4d3da2d8d91f66988a829a18a0ce59945e8ae4fb ]
While trying to use the lantiq_gswip driver on one of my boards I made
a mistake when specifying the phy-mode (because the out-of-tree driver
wants phy-mode "gmii" or "mii" for the internal PHYs). In this case the
following error is printed multiple times:
Unsupported interface: 3
While it gives at least a hint at what may be wrong it is not very user
friendly. Print the human readable phy-mode and also which port is
configured incorrectly (this hardware supports ports 0..6) to improve
the cases where someone made a mistake.
Fixes: 14fceff4771e51 ("net: dsa: Add Lantiq / Intel DSA driver for vrx200")
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Acked-by: Hauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/dsa/lantiq_gswip.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/dsa/lantiq_gswip.c b/drivers/net/dsa/lantiq_gswip.c
index a69c9b9878b7..636966e93517 100644
--- a/drivers/net/dsa/lantiq_gswip.c
+++ b/drivers/net/dsa/lantiq_gswip.c
@@ -1451,7 +1451,8 @@ static void gswip_phylink_validate(struct dsa_switch *ds, int port,
unsupported:
bitmap_zero(supported, __ETHTOOL_LINK_MODE_MASK_NBITS);
- dev_err(ds->dev, "Unsupported interface: %d\n", state->interface);
+ dev_err(ds->dev, "Unsupported interface '%s' for port %d\n",
+ phy_modes(state->interface), port);
return;
}
--
2.25.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.4 265/266] iavf: fix speed reporting over virtchnl
From: Sasha Levin @ 2020-06-18 1:16 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Brett Creeley, Sergey Nemov, Paul Greenwalt, Tony Nguyen,
Jeff Kirsher, Sasha Levin, intel-wired-lan, netdev
In-Reply-To: <20200618011631.604574-1-sashal@kernel.org>
From: Brett Creeley <brett.creeley@intel.com>
[ Upstream commit e0ef26fbe2b0c62f42ba7667076dc38b693b6fb8 ]
Link speeds are communicated over virtchnl using an enum
virtchnl_link_speed. Currently, the highest link speed is 40Gbps which
leaves us unable to reflect some speeds that an ice VF is capable of.
This causes link speed to be misreported on the iavf driver.
Allow for communicating link speeds using Mbps so that the proper speed can
be reported for an ice VF. Moving away from the enum allows us to
communicate future speed changes without requiring a new enum to be added.
In order to support communicating link speeds over virtchnl in Mbps the
following functionality was added:
- Added u32 link_speed_mbps in the iavf_adapter structure.
- Added the macro ADV_LINK_SUPPORT(_a) to determine if the VF
driver supports communicating link speeds in Mbps.
- Added the function iavf_get_vpe_link_status() to fill the
correct link_status in the event_data union based on the
ADV_LINK_SUPPORT(_a) macro.
- Added the function iavf_set_adapter_link_speed_from_vpe()
to determine whether or not to fill the u32 link_speed_mbps or
enum virtchnl_link_speed link_speed field in the iavf_adapter
structure based on the ADV_LINK_SUPPORT(_a) macro.
- Do not free vf_res in iavf_init_get_resources() as vf_res will be
accessed in iavf_get_link_ksettings(); memset to 0 instead. This
memory is subsequently freed in iavf_remove().
Fixes: 7c710869d64e ("ice: Add handlers for VF netdevice operations")
Signed-off-by: Brett Creeley <brett.creeley@intel.com>
Signed-off-by: Sergey Nemov <sergey.nemov@intel.com>
Signed-off-by: Paul Greenwalt <paul.greenwalt@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/intel/iavf/iavf.h | 14 +++
.../net/ethernet/intel/iavf/iavf_ethtool.c | 14 ++-
drivers/net/ethernet/intel/iavf/iavf_main.c | 25 ++++--
.../net/ethernet/intel/iavf/iavf_virtchnl.c | 88 ++++++++++++++++---
4 files changed, 120 insertions(+), 21 deletions(-)
diff --git a/drivers/net/ethernet/intel/iavf/iavf.h b/drivers/net/ethernet/intel/iavf/iavf.h
index bd1b1ed323f4..6b9117a350fa 100644
--- a/drivers/net/ethernet/intel/iavf/iavf.h
+++ b/drivers/net/ethernet/intel/iavf/iavf.h
@@ -87,6 +87,10 @@ struct iavf_vsi {
#define IAVF_HLUT_ARRAY_SIZE ((IAVF_VFQF_HLUT_MAX_INDEX + 1) * 4)
#define IAVF_MBPS_DIVISOR 125000 /* divisor to convert to Mbps */
+#define IAVF_VIRTCHNL_VF_RESOURCE_SIZE (sizeof(struct virtchnl_vf_resource) + \
+ (IAVF_MAX_VF_VSI * \
+ sizeof(struct virtchnl_vsi_resource)))
+
/* MAX_MSIX_Q_VECTORS of these are allocated,
* but we only use one per queue-specific vector.
*/
@@ -306,6 +310,14 @@ struct iavf_adapter {
bool netdev_registered;
bool link_up;
enum virtchnl_link_speed link_speed;
+ /* This is only populated if the VIRTCHNL_VF_CAP_ADV_LINK_SPEED is set
+ * in vf_res->vf_cap_flags. Use ADV_LINK_SUPPORT macro to determine if
+ * this field is valid. This field should be used going forward and the
+ * enum virtchnl_link_speed above should be considered the legacy way of
+ * storing/communicating link speeds.
+ */
+ u32 link_speed_mbps;
+
enum virtchnl_ops current_op;
#define CLIENT_ALLOWED(_a) ((_a)->vf_res ? \
(_a)->vf_res->vf_cap_flags & \
@@ -322,6 +334,8 @@ struct iavf_adapter {
VIRTCHNL_VF_OFFLOAD_RSS_PF)))
#define VLAN_ALLOWED(_a) ((_a)->vf_res->vf_cap_flags & \
VIRTCHNL_VF_OFFLOAD_VLAN)
+#define ADV_LINK_SUPPORT(_a) ((_a)->vf_res->vf_cap_flags & \
+ VIRTCHNL_VF_CAP_ADV_LINK_SPEED)
struct virtchnl_vf_resource *vf_res; /* incl. all VSIs */
struct virtchnl_vsi_resource *vsi_res; /* our LAN VSI */
struct virtchnl_version_info pf_version;
diff --git a/drivers/net/ethernet/intel/iavf/iavf_ethtool.c b/drivers/net/ethernet/intel/iavf/iavf_ethtool.c
index dad3eec8ccd8..758bef02a2a8 100644
--- a/drivers/net/ethernet/intel/iavf/iavf_ethtool.c
+++ b/drivers/net/ethernet/intel/iavf/iavf_ethtool.c
@@ -278,7 +278,18 @@ static int iavf_get_link_ksettings(struct net_device *netdev,
ethtool_link_ksettings_zero_link_mode(cmd, supported);
cmd->base.autoneg = AUTONEG_DISABLE;
cmd->base.port = PORT_NONE;
- /* Set speed and duplex */
+ cmd->base.duplex = DUPLEX_FULL;
+
+ if (ADV_LINK_SUPPORT(adapter)) {
+ if (adapter->link_speed_mbps &&
+ adapter->link_speed_mbps < U32_MAX)
+ cmd->base.speed = adapter->link_speed_mbps;
+ else
+ cmd->base.speed = SPEED_UNKNOWN;
+
+ return 0;
+ }
+
switch (adapter->link_speed) {
case IAVF_LINK_SPEED_40GB:
cmd->base.speed = SPEED_40000;
@@ -306,7 +317,6 @@ static int iavf_get_link_ksettings(struct net_device *netdev,
default:
break;
}
- cmd->base.duplex = DUPLEX_FULL;
return 0;
}
diff --git a/drivers/net/ethernet/intel/iavf/iavf_main.c b/drivers/net/ethernet/intel/iavf/iavf_main.c
index 8e16be960e96..bacc5fb7eba2 100644
--- a/drivers/net/ethernet/intel/iavf/iavf_main.c
+++ b/drivers/net/ethernet/intel/iavf/iavf_main.c
@@ -1756,17 +1756,17 @@ static int iavf_init_get_resources(struct iavf_adapter *adapter)
struct net_device *netdev = adapter->netdev;
struct pci_dev *pdev = adapter->pdev;
struct iavf_hw *hw = &adapter->hw;
- int err = 0, bufsz;
+ int err;
WARN_ON(adapter->state != __IAVF_INIT_GET_RESOURCES);
/* aq msg sent, awaiting reply */
if (!adapter->vf_res) {
- bufsz = sizeof(struct virtchnl_vf_resource) +
- (IAVF_MAX_VF_VSI *
- sizeof(struct virtchnl_vsi_resource));
- adapter->vf_res = kzalloc(bufsz, GFP_KERNEL);
- if (!adapter->vf_res)
+ adapter->vf_res = kzalloc(IAVF_VIRTCHNL_VF_RESOURCE_SIZE,
+ GFP_KERNEL);
+ if (!adapter->vf_res) {
+ err = -ENOMEM;
goto err;
+ }
}
err = iavf_get_vf_config(adapter);
if (err == IAVF_ERR_ADMIN_QUEUE_NO_WORK) {
@@ -2036,7 +2036,7 @@ static void iavf_disable_vf(struct iavf_adapter *adapter)
iavf_reset_interrupt_capability(adapter);
iavf_free_queues(adapter);
iavf_free_q_vectors(adapter);
- kfree(adapter->vf_res);
+ memset(adapter->vf_res, 0, IAVF_VIRTCHNL_VF_RESOURCE_SIZE);
iavf_shutdown_adminq(&adapter->hw);
adapter->netdev->flags &= ~IFF_UP;
clear_bit(__IAVF_IN_CRITICAL_TASK, &adapter->crit_section);
@@ -2487,6 +2487,16 @@ static int iavf_validate_tx_bandwidth(struct iavf_adapter *adapter,
{
int speed = 0, ret = 0;
+ if (ADV_LINK_SUPPORT(adapter)) {
+ if (adapter->link_speed_mbps < U32_MAX) {
+ speed = adapter->link_speed_mbps;
+ goto validate_bw;
+ } else {
+ dev_err(&adapter->pdev->dev, "Unknown link speed\n");
+ return -EINVAL;
+ }
+ }
+
switch (adapter->link_speed) {
case IAVF_LINK_SPEED_40GB:
speed = 40000;
@@ -2510,6 +2520,7 @@ static int iavf_validate_tx_bandwidth(struct iavf_adapter *adapter,
break;
}
+validate_bw:
if (max_tx_rate > speed) {
dev_err(&adapter->pdev->dev,
"Invalid tx rate specified\n");
diff --git a/drivers/net/ethernet/intel/iavf/iavf_virtchnl.c b/drivers/net/ethernet/intel/iavf/iavf_virtchnl.c
index 1ab9cb339acb..9655318803b7 100644
--- a/drivers/net/ethernet/intel/iavf/iavf_virtchnl.c
+++ b/drivers/net/ethernet/intel/iavf/iavf_virtchnl.c
@@ -139,7 +139,8 @@ int iavf_send_vf_config_msg(struct iavf_adapter *adapter)
VIRTCHNL_VF_OFFLOAD_ENCAP |
VIRTCHNL_VF_OFFLOAD_ENCAP_CSUM |
VIRTCHNL_VF_OFFLOAD_REQ_QUEUES |
- VIRTCHNL_VF_OFFLOAD_ADQ;
+ VIRTCHNL_VF_OFFLOAD_ADQ |
+ VIRTCHNL_VF_CAP_ADV_LINK_SPEED;
adapter->current_op = VIRTCHNL_OP_GET_VF_RESOURCES;
adapter->aq_required &= ~IAVF_FLAG_AQ_GET_CONFIG;
@@ -918,6 +919,8 @@ void iavf_disable_vlan_stripping(struct iavf_adapter *adapter)
iavf_send_pf_msg(adapter, VIRTCHNL_OP_DISABLE_VLAN_STRIPPING, NULL, 0);
}
+#define IAVF_MAX_SPEED_STRLEN 13
+
/**
* iavf_print_link_message - print link up or down
* @adapter: adapter structure
@@ -927,37 +930,99 @@ void iavf_disable_vlan_stripping(struct iavf_adapter *adapter)
static void iavf_print_link_message(struct iavf_adapter *adapter)
{
struct net_device *netdev = adapter->netdev;
- char *speed = "Unknown ";
+ int link_speed_mbps;
+ char *speed;
if (!adapter->link_up) {
netdev_info(netdev, "NIC Link is Down\n");
return;
}
+ speed = kcalloc(1, IAVF_MAX_SPEED_STRLEN, GFP_KERNEL);
+ if (!speed)
+ return;
+
+ if (ADV_LINK_SUPPORT(adapter)) {
+ link_speed_mbps = adapter->link_speed_mbps;
+ goto print_link_msg;
+ }
+
switch (adapter->link_speed) {
case IAVF_LINK_SPEED_40GB:
- speed = "40 G";
+ link_speed_mbps = SPEED_40000;
break;
case IAVF_LINK_SPEED_25GB:
- speed = "25 G";
+ link_speed_mbps = SPEED_25000;
break;
case IAVF_LINK_SPEED_20GB:
- speed = "20 G";
+ link_speed_mbps = SPEED_20000;
break;
case IAVF_LINK_SPEED_10GB:
- speed = "10 G";
+ link_speed_mbps = SPEED_10000;
break;
case IAVF_LINK_SPEED_1GB:
- speed = "1000 M";
+ link_speed_mbps = SPEED_1000;
break;
case IAVF_LINK_SPEED_100MB:
- speed = "100 M";
+ link_speed_mbps = SPEED_100;
break;
default:
+ link_speed_mbps = SPEED_UNKNOWN;
break;
}
- netdev_info(netdev, "NIC Link is Up %sbps Full Duplex\n", speed);
+print_link_msg:
+ if (link_speed_mbps > SPEED_1000) {
+ if (link_speed_mbps == SPEED_2500)
+ snprintf(speed, IAVF_MAX_SPEED_STRLEN, "2.5 Gbps");
+ else
+ /* convert to Gbps inline */
+ snprintf(speed, IAVF_MAX_SPEED_STRLEN, "%d %s",
+ link_speed_mbps / 1000, "Gbps");
+ } else if (link_speed_mbps == SPEED_UNKNOWN) {
+ snprintf(speed, IAVF_MAX_SPEED_STRLEN, "%s", "Unknown Mbps");
+ } else {
+ snprintf(speed, IAVF_MAX_SPEED_STRLEN, "%u %s",
+ link_speed_mbps, "Mbps");
+ }
+
+ netdev_info(netdev, "NIC Link is Up Speed is %s Full Duplex\n", speed);
+ kfree(speed);
+}
+
+/**
+ * iavf_get_vpe_link_status
+ * @adapter: adapter structure
+ * @vpe: virtchnl_pf_event structure
+ *
+ * Helper function for determining the link status
+ **/
+static bool
+iavf_get_vpe_link_status(struct iavf_adapter *adapter,
+ struct virtchnl_pf_event *vpe)
+{
+ if (ADV_LINK_SUPPORT(adapter))
+ return vpe->event_data.link_event_adv.link_status;
+ else
+ return vpe->event_data.link_event.link_status;
+}
+
+/**
+ * iavf_set_adapter_link_speed_from_vpe
+ * @adapter: adapter structure for which we are setting the link speed
+ * @vpe: virtchnl_pf_event structure that contains the link speed we are setting
+ *
+ * Helper function for setting iavf_adapter link speed
+ **/
+static void
+iavf_set_adapter_link_speed_from_vpe(struct iavf_adapter *adapter,
+ struct virtchnl_pf_event *vpe)
+{
+ if (ADV_LINK_SUPPORT(adapter))
+ adapter->link_speed_mbps =
+ vpe->event_data.link_event_adv.link_speed;
+ else
+ adapter->link_speed = vpe->event_data.link_event.link_speed;
}
/**
@@ -1187,12 +1252,11 @@ void iavf_virtchnl_completion(struct iavf_adapter *adapter,
if (v_opcode == VIRTCHNL_OP_EVENT) {
struct virtchnl_pf_event *vpe =
(struct virtchnl_pf_event *)msg;
- bool link_up = vpe->event_data.link_event.link_status;
+ bool link_up = iavf_get_vpe_link_status(adapter, vpe);
switch (vpe->event) {
case VIRTCHNL_EVENT_LINK_CHANGE:
- adapter->link_speed =
- vpe->event_data.link_event.link_speed;
+ iavf_set_adapter_link_speed_from_vpe(adapter, vpe);
/* we've already got the right link status, bail */
if (adapter->link_up == link_up)
--
2.25.1
^ permalink raw reply related
* Re: [net-next PATCH 1/5 v2] net: dsa: tag_rtl4_a: Implement Realtek 4 byte A tag
From: Andrew Lunn @ 2020-06-18 1:25 UTC (permalink / raw)
To: Linus Walleij
Cc: Vivien Didelot, Florian Fainelli, netdev, DENG Qingfang,
Mauri Sandberg
In-Reply-To: <20200617083132.1847234-1-linus.walleij@linaro.org>
On Wed, Jun 17, 2020 at 10:31:28AM +0200, Linus Walleij wrote:
> This implements the known parts of the Realtek 4 byte
> tag protocol version 0xA, as found in the RTL8366RB
> DSA switch.
Hi Linus
David likes to have a 0/X patch which contains the big picture for the
patchset. It gets used for the merge commit he makes for the patchset.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* [PATCH AUTOSEL 4.4 51/60] net: sunrpc: Fix off-by-one issues in 'rpc_ntop6'
From: Sasha Levin @ 2020-06-18 1:29 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Fedor Tokarev, Anna Schumaker, Sasha Levin, linux-nfs, netdev
In-Reply-To: <20200618013004.610532-1-sashal@kernel.org>
From: Fedor Tokarev <ftokarev@gmail.com>
[ Upstream commit 118917d696dc59fd3e1741012c2f9db2294bed6f ]
Fix off-by-one issues in 'rpc_ntop6':
- 'snprintf' returns the number of characters which would have been
written if enough space had been available, excluding the terminating
null byte. Thus, a return value of 'sizeof(scopebuf)' means that the
last character was dropped.
- 'strcat' adds a terminating null byte to the string, thus if len ==
buflen, the null byte is written past the end of the buffer.
Signed-off-by: Fedor Tokarev <ftokarev@gmail.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/sunrpc/addr.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/sunrpc/addr.c b/net/sunrpc/addr.c
index 2e0a6f92e563..8391c2785550 100644
--- a/net/sunrpc/addr.c
+++ b/net/sunrpc/addr.c
@@ -81,11 +81,11 @@ static size_t rpc_ntop6(const struct sockaddr *sap,
rc = snprintf(scopebuf, sizeof(scopebuf), "%c%u",
IPV6_SCOPE_DELIMITER, sin6->sin6_scope_id);
- if (unlikely((size_t)rc > sizeof(scopebuf)))
+ if (unlikely((size_t)rc >= sizeof(scopebuf)))
return 0;
len += rc;
- if (unlikely(len > buflen))
+ if (unlikely(len >= buflen))
return 0;
strcat(buf, scopebuf);
--
2.25.1
^ permalink raw reply related
* Re: [net-next PATCH 4/5 v2] net: dsa: rtl8366: VLAN 0 as disable tagging
From: Andrew Lunn @ 2020-06-18 1:31 UTC (permalink / raw)
To: Linus Walleij
Cc: Vivien Didelot, Florian Fainelli, netdev, DENG Qingfang,
Mauri Sandberg
In-Reply-To: <20200617083132.1847234-4-linus.walleij@linaro.org>
On Wed, Jun 17, 2020 at 10:31:31AM +0200, Linus Walleij wrote:
> The code in net/8021q/vlan.c, vlan_device_event() sets
> VLAN 0 for a VLAN-capable ethernet device when it
> comes up.
>
> Since the RTL8366 DSA switches must have a VLAN and
> PVID set up for any packets to come through we have
> already set up default VLAN for each port as part of
> bringing the switch online.
>
> Make sure that setting VLAN 0 has the same effect
> and does not try to actually tell the hardware to use
> VLAN 0 on the port because that will not work.
>
> Cc: DENG Qingfang <dqfext@gmail.com>
> Cc: Mauri Sandberg <sandberg@mailfence.com>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* [PATCH AUTOSEL 4.4 17/60] yam: fix possible memory leak in yam_init_driver
From: Sasha Levin @ 2020-06-18 1:29 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Wang Hai, Hulk Robot, David S . Miller, Sasha Levin, linux-hams,
netdev
In-Reply-To: <20200618013004.610532-1-sashal@kernel.org>
From: Wang Hai <wanghai38@huawei.com>
[ Upstream commit 98749b7188affbf2900c2aab704a8853901d1139 ]
If register_netdev(dev) fails, free_netdev(dev) needs
to be called, otherwise a memory leak will occur.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Wang Hai <wanghai38@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/hamradio/yam.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/hamradio/yam.c b/drivers/net/hamradio/yam.c
index 1a4729c36aa4..623e4225e7c8 100644
--- a/drivers/net/hamradio/yam.c
+++ b/drivers/net/hamradio/yam.c
@@ -1160,6 +1160,7 @@ static int __init yam_init_driver(void)
err = register_netdev(dev);
if (err) {
printk(KERN_WARNING "yam: cannot register net device %s\n", dev->name);
+ free_netdev(dev);
goto error;
}
yam_devs[i] = dev;
--
2.25.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.9 66/80] net: sunrpc: Fix off-by-one issues in 'rpc_ntop6'
From: Sasha Levin @ 2020-06-18 1:28 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Fedor Tokarev, Anna Schumaker, Sasha Levin, linux-nfs, netdev
In-Reply-To: <20200618012819.609778-1-sashal@kernel.org>
From: Fedor Tokarev <ftokarev@gmail.com>
[ Upstream commit 118917d696dc59fd3e1741012c2f9db2294bed6f ]
Fix off-by-one issues in 'rpc_ntop6':
- 'snprintf' returns the number of characters which would have been
written if enough space had been available, excluding the terminating
null byte. Thus, a return value of 'sizeof(scopebuf)' means that the
last character was dropped.
- 'strcat' adds a terminating null byte to the string, thus if len ==
buflen, the null byte is written past the end of the buffer.
Signed-off-by: Fedor Tokarev <ftokarev@gmail.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/sunrpc/addr.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/sunrpc/addr.c b/net/sunrpc/addr.c
index 2e0a6f92e563..8391c2785550 100644
--- a/net/sunrpc/addr.c
+++ b/net/sunrpc/addr.c
@@ -81,11 +81,11 @@ static size_t rpc_ntop6(const struct sockaddr *sap,
rc = snprintf(scopebuf, sizeof(scopebuf), "%c%u",
IPV6_SCOPE_DELIMITER, sin6->sin6_scope_id);
- if (unlikely((size_t)rc > sizeof(scopebuf)))
+ if (unlikely((size_t)rc >= sizeof(scopebuf)))
return 0;
len += rc;
- if (unlikely(len > buflen))
+ if (unlikely(len >= buflen))
return 0;
strcat(buf, scopebuf);
--
2.25.1
^ permalink raw reply related
* Re: [net-next PATCH 5/5 v2] net: dsa: rtl8366: Use top VLANs for default
From: Andrew Lunn @ 2020-06-18 1:42 UTC (permalink / raw)
To: Linus Walleij
Cc: Vivien Didelot, Florian Fainelli, netdev, DENG Qingfang,
Mauri Sandberg
In-Reply-To: <20200617083132.1847234-5-linus.walleij@linaro.org>
On Wed, Jun 17, 2020 at 10:31:32AM +0200, Linus Walleij wrote:
> The RTL8366 DSA switches will not work unless we set
> up a default VLAN for each port. We are currently using
> e.g. VLAN 1..6 for a 5-port switch as default VLANs.
>
> This is not very helpful for users, move it to allocate
> the top VLANs for default instead, for example on
> RTL8366RB there are 16 VLANs so instead of using
> VLAN 1..6 as default use VLAN 10..15 so VLAN 1
> thru VLAN 9 is available for users.
>
> Cc: DENG Qingfang <dqfext@gmail.com>
> Cc: Mauri Sandberg <sandberg@mailfence.com>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> ChangeLog v1->v2:
> - Rebase on v5.8-rc1.
> ---
> drivers/net/dsa/rtl8366.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/dsa/rtl8366.c b/drivers/net/dsa/rtl8366.c
> index 7f0691a6da13..4e7562b41598 100644
> --- a/drivers/net/dsa/rtl8366.c
> +++ b/drivers/net/dsa/rtl8366.c
> @@ -260,8 +260,8 @@ static int rtl8366_set_default_vlan_and_pvid(struct realtek_smi *smi,
> u16 vid;
> int ret;
>
> - /* This is the reserved default VLAN for this port */
> - vid = port + 1;
> + /* Use the top VLANs for per-port default VLAN */
> + vid = smi->num_vlan_mc - smi->num_ports + port;
Hi Linus
I've not looked at the whole driver much, but i'm surprised the change
is this small. Is there any checks when user space ask for a VLAN to
be added to a port to see if it is already in use an return -EBUSY or
-EINVAL or something?
Andrew
^ permalink raw reply
* Re: [net-next PATCH 3/5 v2] net: dsa: rtl8366: Split out default VLAN config
From: Andrew Lunn @ 2020-06-18 1:29 UTC (permalink / raw)
To: Linus Walleij
Cc: Vivien Didelot, Florian Fainelli, netdev, DENG Qingfang,
Mauri Sandberg
In-Reply-To: <20200617083132.1847234-3-linus.walleij@linaro.org>
On Wed, Jun 17, 2020 at 10:31:30AM +0200, Linus Walleij wrote:
> We loop over the ports to initialize the default VLAN
> and PVID for each port. As we need to reuse the
> code to reinitialize a single port, break out the
> function rtl8366_set_default_vlan_and_pvid().
>
> Cc: DENG Qingfang <dqfext@gmail.com>
> Cc: Mauri Sandberg <sandberg@mailfence.com>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* [PATCH] [net/sched] Fix null pointer deref skb in tc_ctl_action
From: Gaurav Singh @ 2020-06-18 1:43 UTC (permalink / raw)
To: gaurav1086, Jamal Hadi Salim, Cong Wang, Jiri Pirko,
David S. Miller, Jakub Kicinski, open list:TC subsystem,
open list
Add null check for skb
Signed-off-by: Gaurav Singh <gaurav1086@gmail.com>
---
net/sched/act_api.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/net/sched/act_api.c b/net/sched/act_api.c
index 8ac7eb0a8309..fd584821d75a 100644
--- a/net/sched/act_api.c
+++ b/net/sched/act_api.c
@@ -1473,9 +1473,12 @@ static const struct nla_policy tcaa_policy[TCA_ROOT_MAX + 1] = {
static int tc_ctl_action(struct sk_buff *skb, struct nlmsghdr *n,
struct netlink_ext_ack *extack)
{
+ if (!skb)
+ return 0;
+
struct net *net = sock_net(skb->sk);
struct nlattr *tca[TCA_ROOT_MAX + 1];
- u32 portid = skb ? NETLINK_CB(skb).portid : 0;
+ u32 portid = NETLINK_CB(skb).portid;
int ret = 0, ovr = 0;
if ((n->nlmsg_type != RTM_GETACTION) &&
--
2.17.1
^ permalink raw reply related
* Re: [PATCH net-next v7 1/6] dt-bindings: net: Add tx and rx internal delays
From: Andrew Lunn @ 2020-06-18 1:43 UTC (permalink / raw)
To: Dan Murphy
Cc: f.fainelli, hkallweit1, davem, robh, netdev, linux-kernel,
devicetree
In-Reply-To: <20200617182019.6790-2-dmurphy@ti.com>
On Wed, Jun 17, 2020 at 01:20:14PM -0500, Dan Murphy wrote:
> tx-internal-delays and rx-internal-delays are a common setting for RGMII
> capable devices.
>
> These properties are used when the phy-mode or phy-controller is set to
> rgmii-id, rgmii-rxid or rgmii-txid. These modes indicate to the
> controller that the PHY will add the internal delay for the connection.
>
> Signed-off-by: Dan Murphy <dmurphy@ti.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* [PATCH AUTOSEL 4.9 24/80] yam: fix possible memory leak in yam_init_driver
From: Sasha Levin @ 2020-06-18 1:27 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Wang Hai, Hulk Robot, David S . Miller, Sasha Levin, linux-hams,
netdev
In-Reply-To: <20200618012819.609778-1-sashal@kernel.org>
From: Wang Hai <wanghai38@huawei.com>
[ Upstream commit 98749b7188affbf2900c2aab704a8853901d1139 ]
If register_netdev(dev) fails, free_netdev(dev) needs
to be called, otherwise a memory leak will occur.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Wang Hai <wanghai38@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/hamradio/yam.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/hamradio/yam.c b/drivers/net/hamradio/yam.c
index aaff07c10058..a453b82d1077 100644
--- a/drivers/net/hamradio/yam.c
+++ b/drivers/net/hamradio/yam.c
@@ -1160,6 +1160,7 @@ static int __init yam_init_driver(void)
err = register_netdev(dev);
if (err) {
printk(KERN_WARNING "yam: cannot register net device %s\n", dev->name);
+ free_netdev(dev);
goto error;
}
yam_devs[i] = dev;
--
2.25.1
^ permalink raw reply related
* Re: [Patch net] cgroup: fix cgroup_sk_alloc() for sk_clone_lock()
From: Zefan Li @ 2020-06-18 1:44 UTC (permalink / raw)
To: Cong Wang, netdev
Cc: Cameron Berkenpas, Peter Geis, Lu Fengqi, Daniël Sonck,
Daniel Borkmann, Tejun Heo, Roman Gushchin
In-Reply-To: <20200616180352.18602-1-xiyou.wangcong@gmail.com>
Cc: Roman Gushchin <guro@fb.com>
Thanks for fixing this.
On 2020/6/17 2:03, Cong Wang wrote:
> When we clone a socket in sk_clone_lock(), its sk_cgrp_data is
> copied, so the cgroup refcnt must be taken too. And, unlike the
> sk_alloc() path, sock_update_netprioidx() is not called here.
> Therefore, it is safe and necessary to grab the cgroup refcnt
> even when cgroup_sk_alloc is disabled.
>
> sk_clone_lock() is in BH context anyway, the in_interrupt()
> would terminate this function if called there. And for sk_alloc()
> skcd->val is always zero. So it's safe to factor out the code
> to make it more readable.
>
> Fixes: 090e28b229af92dc5b ("netprio_cgroup: Fix unlimited memory leak of v2 cgroups")
but I don't think the bug was introduced by this commit, because there
are already calls to cgroup_sk_alloc_disable() in write_priomap() and
write_classid(), which can be triggered by writing to ifpriomap or
classid in cgroupfs. This commit just made it much easier to happen
with systemd invovled.
I think it's 4bfc0bb2c60e2f4c ("bpf: decouple the lifetime of cgroup_bpf from cgroup itself"),
which added cgroup_bpf_get() in cgroup_sk_alloc().
> Reported-by: Cameron Berkenpas <cam@neo-zeon.de>
> Reported-by: Peter Geis <pgwipeout@gmail.com>
> Reported-by: Lu Fengqi <lufq.fnst@cn.fujitsu.com>
> Reported-by: Daniël Sonck <dsonck92@gmail.com>
> Tested-by: Cameron Berkenpas <cam@neo-zeon.de>
> Cc: Daniel Borkmann <daniel@iogearbox.net>
> Cc: Zefan Li <lizefan@huawei.com>
> Cc: Tejun Heo <tj@kernel.org>
> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
> ---
^ permalink raw reply
* [PATCH AUTOSEL 4.14 096/108] geneve: change from tx_error to tx_dropped on missing metadata
From: Sasha Levin @ 2020-06-18 1:25 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: Jiri Benc, David S . Miller, Sasha Levin, netdev
In-Reply-To: <20200618012600.608744-1-sashal@kernel.org>
From: Jiri Benc <jbenc@redhat.com>
[ Upstream commit 9d149045b3c0e44c049cdbce8a64e19415290017 ]
If the geneve interface is in collect_md (external) mode, it can't send any
packets submitted directly to its net interface, as such packets won't have
metadata attached. This is expected.
However, the kernel itself sends some packets to the interface, most
notably, IPv6 DAD, IPv6 multicast listener reports, etc. This is not wrong,
as tunnel metadata can be specified in routing table (although technically,
that has never worked for IPv6, but hopefully will be fixed eventually) and
then the interface must correctly participate in IPv6 housekeeping.
The problem is that any such attempt increases the tx_error counter. Just
bringing up a geneve interface with IPv6 enabled is enough to see a number
of tx_errors. That causes confusion among users, prompting them to find
a network error where there is none.
Change the counter used to tx_dropped. That better conveys the meaning
(there's nothing wrong going on, just some packets are getting dropped) and
hopefully will make admins panic less.
Signed-off-by: Jiri Benc <jbenc@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/geneve.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/net/geneve.c b/drivers/net/geneve.c
index 6d3fa36b1616..3c9f8770f7e7 100644
--- a/drivers/net/geneve.c
+++ b/drivers/net/geneve.c
@@ -915,9 +915,10 @@ static netdev_tx_t geneve_xmit(struct sk_buff *skb, struct net_device *dev)
if (geneve->collect_md) {
info = skb_tunnel_info(skb);
if (unlikely(!info || !(info->mode & IP_TUNNEL_INFO_TX))) {
- err = -EINVAL;
netdev_dbg(dev, "no tunnel metadata\n");
- goto tx_error;
+ dev_kfree_skb(skb);
+ dev->stats.tx_dropped++;
+ return NETDEV_TX_OK;
}
} else {
info = &geneve->info;
@@ -934,7 +935,7 @@ static netdev_tx_t geneve_xmit(struct sk_buff *skb, struct net_device *dev)
if (likely(!err))
return NETDEV_TX_OK;
-tx_error:
+
dev_kfree_skb(skb);
if (err == -ELOOP)
--
2.25.1
^ permalink raw reply related
* Re: [net-next PATCH 2/5 v2] net: dsa: rtl8366rb: Support the CPU DSA tag
From: Andrew Lunn @ 2020-06-18 1:27 UTC (permalink / raw)
To: Linus Walleij
Cc: Vivien Didelot, Florian Fainelli, netdev, DENG Qingfang,
Mauri Sandberg
In-Reply-To: <20200617083132.1847234-2-linus.walleij@linaro.org>
On Wed, Jun 17, 2020 at 10:31:29AM +0200, Linus Walleij wrote:
> This activates the support to use the CPU tag to properly
> direct ingress traffic to the right port.
>
> Bit 15 in register RTL8368RB_CPU_CTRL_REG can be set to
> 1 to disable the insertion of the CPU tag which is what
> the code currently does. The bit 15 define calls this
> setting RTL8368RB_CPU_INSTAG which is confusing since the
> iverse meaning is implied: programmers may think that
inverse
> setting this bit to 1 will *enable* inserting the tag
> rather than disablinbg it, so rename this setting in
disabling
> bit 15 to RTL8368RB_CPU_NO_TAG which is more to the
> point.
>
> After this e.g. ping works out-of-the-box with the
> RTL8366RB.
>
> Cc: DENG Qingfang <dqfext@gmail.com>
> Cc: Mauri Sandberg <sandberg@mailfence.com>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* [PATCH AUTOSEL 4.14 082/108] net: sunrpc: Fix off-by-one issues in 'rpc_ntop6'
From: Sasha Levin @ 2020-06-18 1:25 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Fedor Tokarev, Anna Schumaker, Sasha Levin, linux-nfs, netdev
In-Reply-To: <20200618012600.608744-1-sashal@kernel.org>
From: Fedor Tokarev <ftokarev@gmail.com>
[ Upstream commit 118917d696dc59fd3e1741012c2f9db2294bed6f ]
Fix off-by-one issues in 'rpc_ntop6':
- 'snprintf' returns the number of characters which would have been
written if enough space had been available, excluding the terminating
null byte. Thus, a return value of 'sizeof(scopebuf)' means that the
last character was dropped.
- 'strcat' adds a terminating null byte to the string, thus if len ==
buflen, the null byte is written past the end of the buffer.
Signed-off-by: Fedor Tokarev <ftokarev@gmail.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/sunrpc/addr.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/sunrpc/addr.c b/net/sunrpc/addr.c
index 2e0a6f92e563..8391c2785550 100644
--- a/net/sunrpc/addr.c
+++ b/net/sunrpc/addr.c
@@ -81,11 +81,11 @@ static size_t rpc_ntop6(const struct sockaddr *sap,
rc = snprintf(scopebuf, sizeof(scopebuf), "%c%u",
IPV6_SCOPE_DELIMITER, sin6->sin6_scope_id);
- if (unlikely((size_t)rc > sizeof(scopebuf)))
+ if (unlikely((size_t)rc >= sizeof(scopebuf)))
return 0;
len += rc;
- if (unlikely(len > buflen))
+ if (unlikely(len >= buflen))
return 0;
strcat(buf, scopebuf);
--
2.25.1
^ permalink raw reply related
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