* Re: [patch net-next] net: sched: don't dump chains only held by actions
From: Jiri Pirko @ 2018-07-31 8:48 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Cong Wang, Linux Kernel Network Developers, David Miller,
Jamal Hadi Salim, mlxsw
In-Reply-To: <20180731010146.0706283a@cakuba.netronome.com>
Tue, Jul 31, 2018 at 10:01:46AM CEST, jakub.kicinski@netronome.com wrote:
>On Tue, 31 Jul 2018 08:32:58 +0200, Jiri Pirko wrote:
>> Mon, Jul 30, 2018 at 08:19:56PM CEST, xiyou.wangcong@gmail.com wrote:
>> >On Sun, Jul 29, 2018 at 12:54 AM Jiri Pirko <jiri@resnulli.us> wrote:
>> >>
>> >> Sat, Jul 28, 2018 at 07:39:36PM CEST, xiyou.wangcong@gmail.com wrote:
>> >> >On Sat, Jul 28, 2018 at 10:20 AM Cong Wang <xiyou.wangcong@gmail.com> wrote:
>> >> >>
>> >> >> On Fri, Jul 27, 2018 at 12:47 AM Jiri Pirko <jiri@resnulli.us> wrote:
>> >> >> >
>> >> >> > From: Jiri Pirko <jiri@mellanox.com>
>> >> >> >
>> >> >> > In case a chain is empty and not explicitly created by a user,
>> >> >> > such chain should not exist. The only exception is if there is
>> >> >> > an action "goto chain" pointing to it. In that case, don't show the
>> >> >> > chain in the dump. Track the chain references held by actions and
>> >> >> > use them to find out if a chain should or should not be shown
>> >> >> > in chain dump.
>> >> >> >
>> >> >> > Signed-off-by: Jiri Pirko <jiri@mellanox.com>
>> >> >>
>> >> >> Looks reasonable to me.
>> >> >>
>> >> >> Acked-by: Cong Wang <xiyou.wangcong@gmail.com>
>> >> >
>> >> >Hold on...
>> >> >
>> >> >If you increase the refcnt for a zombie chain on NEWCHAIN path,
>> >> >then it would become a non-zombie, this makes sense. However,
>> >> >if the action_refcnt gets increased again when another action uses it,
>> >> >it become a zombie again because refcnt==action_refcnt??
>> >>
>> >> No. action always increases both refcnt and action_refcnt
>> >
>> >Hmm, then the name zombie is confusing, with your definition all
>> >chains implicitly created by actions are zombies, unless touched
>> >by user explicitly. Please find a better name.
>>
>> Okay. Perhaps chain_inactive?
>
>FWIW to me active brings to mind that it's handling traffic. Brining in
>my suggestions from an off-list discussion:
>
>tcf_chain_act_refs_only() or tcf_chain_pure_act_target()
:/
>
>or maybe tcf_chain_has_no_filters() ?
That is not accurate, as explicitly created chain does not have any
filters too.
I think this is good:
tcf_chain_held_by_acts_only()
^ permalink raw reply
* Re: [PATCH net-next 2/2] virtio-net: get rid of unnecessary container of rq stats
From: Toshiaki Makita @ 2018-07-31 10:02 UTC (permalink / raw)
To: Jason Wang; +Cc: netdev, virtualization, linux-kernel, mst
In-Reply-To: <1533030219-9904-2-git-send-email-jasowang@redhat.com>
On 2018/07/31 18:43, Jason Wang wrote:
> We don't maintain tx counters in rx stats any more. There's no need
> for an extra container of rq stats.
>
> Cc: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
> Signed-off-by: Jason Wang <jasowang@redhat.com>
> ---
> drivers/net/virtio_net.c | 80 ++++++++++++++++++++++--------------------------
> 1 file changed, 36 insertions(+), 44 deletions(-)
>
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index 72d3f68..14f661c 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -87,7 +87,8 @@ struct virtnet_sq_stats {
> u64 kicks;
> };
>
> -struct virtnet_rq_stat_items {
> +struct virtnet_rq_stats {
> + struct u64_stats_sync syncp;
> u64 packets;
> u64 bytes;
> u64 drops;
> @@ -98,17 +99,8 @@ struct virtnet_rq_stat_items {
> u64 kicks;
> };
>
> -struct virtnet_rq_stats {
> - struct u64_stats_sync syncp;
> - struct virtnet_rq_stat_items items;
> -};
I'm not thinking removing sq stat is needed but even if it is I want to
keep virtnet_rq_stats to avoid allocating unnecessary u64_stats_syncp on
stack in virtnet_receive. I would just remove virtnet_rx_stats if necessary.
> -
> -struct virtnet_rx_stats {
> - struct virtnet_rq_stat_items rx;
> -};
> -
--
Toshiaki Makita
^ permalink raw reply
* Re: [PATCH net-next 1/2] virtio-net: correctly update XDP_TX counters
From: Toshiaki Makita @ 2018-07-31 9:57 UTC (permalink / raw)
To: Jason Wang; +Cc: netdev, virtualization, linux-kernel, mst
In-Reply-To: <1533030219-9904-1-git-send-email-jasowang@redhat.com>
On 2018/07/31 18:43, Jason Wang wrote:
> Commit 5b8f3c8d30a6 ("virtio_net: Add XDP related stats") tries to
> count TX XDP stats in virtnet_receive(). This will cause several
> issues:
>
> - virtnet_xdp_sq() was called without checking whether or not XDP is
> set. This may cause out of bound access when there's no enough txq
> for XDP.
> - Stats were updated even if there's no XDP/XDP_TX.>
> Fixing this by reusing virtnet_xdp_xmit() for XDP_TX which can counts
> TX XDP counter itself and remove the unnecessary tx stats embedded in
> rx stats.
Thanks for fixing this.
I wanted to avoid calling u64_stats_update_begin() (i.e. smp_wmb() in 32
bit systems) for every packet. So I'd like to keep sq stats in
virtnet_rx_stats.
--
Toshiaki Makita
^ permalink raw reply
* [PATCH net-next 2/2] virtio-net: get rid of unnecessary container of rq stats
From: Jason Wang @ 2018-07-31 9:43 UTC (permalink / raw)
To: mst, jasowang; +Cc: virtualization, netdev, linux-kernel, Toshiaki Makita
In-Reply-To: <1533030219-9904-1-git-send-email-jasowang@redhat.com>
We don't maintain tx counters in rx stats any more. There's no need
for an extra container of rq stats.
Cc: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
Signed-off-by: Jason Wang <jasowang@redhat.com>
---
drivers/net/virtio_net.c | 80 ++++++++++++++++++++++--------------------------
1 file changed, 36 insertions(+), 44 deletions(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 72d3f68..14f661c 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -87,7 +87,8 @@ struct virtnet_sq_stats {
u64 kicks;
};
-struct virtnet_rq_stat_items {
+struct virtnet_rq_stats {
+ struct u64_stats_sync syncp;
u64 packets;
u64 bytes;
u64 drops;
@@ -98,17 +99,8 @@ struct virtnet_rq_stat_items {
u64 kicks;
};
-struct virtnet_rq_stats {
- struct u64_stats_sync syncp;
- struct virtnet_rq_stat_items items;
-};
-
-struct virtnet_rx_stats {
- struct virtnet_rq_stat_items rx;
-};
-
#define VIRTNET_SQ_STAT(m) offsetof(struct virtnet_sq_stats, m)
-#define VIRTNET_RQ_STAT(m) offsetof(struct virtnet_rq_stat_items, m)
+#define VIRTNET_RQ_STAT(m) offsetof(struct virtnet_rq_stats, m)
static const struct virtnet_stat_desc virtnet_sq_stats_desc[] = {
{ "packets", VIRTNET_SQ_STAT(packets) },
@@ -617,7 +609,7 @@ static struct sk_buff *receive_small(struct net_device *dev,
void *buf, void *ctx,
unsigned int len,
unsigned int *xdp_xmit,
- struct virtnet_rx_stats *stats)
+ struct virtnet_rq_stats *stats)
{
struct sk_buff *skb;
struct bpf_prog *xdp_prog;
@@ -632,7 +624,7 @@ static struct sk_buff *receive_small(struct net_device *dev,
int err;
len -= vi->hdr_len;
- stats->rx.bytes += len;
+ stats->bytes += len;
rcu_read_lock();
xdp_prog = rcu_dereference(rq->xdp_prog);
@@ -674,7 +666,7 @@ static struct sk_buff *receive_small(struct net_device *dev,
xdp.rxq = &rq->xdp_rxq;
orig_data = xdp.data;
act = bpf_prog_run_xdp(xdp_prog, &xdp);
- stats->rx.xdp_packets++;
+ stats->xdp_packets++;
switch (act) {
case XDP_PASS:
@@ -683,7 +675,7 @@ static struct sk_buff *receive_small(struct net_device *dev,
len = xdp.data_end - xdp.data;
break;
case XDP_TX:
- stats->rx.xdp_tx++;
+ stats->xdp_tx++;
xdpf = convert_to_xdp_frame(&xdp);
if (unlikely(!xdpf))
goto err_xdp;
@@ -696,7 +688,7 @@ static struct sk_buff *receive_small(struct net_device *dev,
rcu_read_unlock();
goto xdp_xmit;
case XDP_REDIRECT:
- stats->rx.xdp_redirects++;
+ stats->xdp_redirects++;
err = xdp_do_redirect(dev, &xdp, xdp_prog);
if (err)
goto err_xdp;
@@ -730,8 +722,8 @@ static struct sk_buff *receive_small(struct net_device *dev,
err_xdp:
rcu_read_unlock();
- stats->rx.xdp_drops++;
- stats->rx.drops++;
+ stats->xdp_drops++;
+ stats->drops++;
put_page(page);
xdp_xmit:
return NULL;
@@ -742,19 +734,19 @@ static struct sk_buff *receive_big(struct net_device *dev,
struct receive_queue *rq,
void *buf,
unsigned int len,
- struct virtnet_rx_stats *stats)
+ struct virtnet_rq_stats *stats)
{
struct page *page = buf;
struct sk_buff *skb = page_to_skb(vi, rq, page, 0, len, PAGE_SIZE);
- stats->rx.bytes += len - vi->hdr_len;
+ stats->bytes += len - vi->hdr_len;
if (unlikely(!skb))
goto err;
return skb;
err:
- stats->rx.drops++;
+ stats->drops++;
give_pages(rq, page);
return NULL;
}
@@ -766,7 +758,7 @@ static struct sk_buff *receive_mergeable(struct net_device *dev,
void *ctx,
unsigned int len,
unsigned int *xdp_xmit,
- struct virtnet_rx_stats *stats)
+ struct virtnet_rq_stats *stats)
{
struct virtio_net_hdr_mrg_rxbuf *hdr = buf;
u16 num_buf = virtio16_to_cpu(vi->vdev, hdr->num_buffers);
@@ -779,7 +771,7 @@ static struct sk_buff *receive_mergeable(struct net_device *dev,
int err;
head_skb = NULL;
- stats->rx.bytes += len - vi->hdr_len;
+ stats->bytes += len - vi->hdr_len;
rcu_read_lock();
xdp_prog = rcu_dereference(rq->xdp_prog);
@@ -828,7 +820,7 @@ static struct sk_buff *receive_mergeable(struct net_device *dev,
xdp.rxq = &rq->xdp_rxq;
act = bpf_prog_run_xdp(xdp_prog, &xdp);
- stats->rx.xdp_packets++;
+ stats->xdp_packets++;
switch (act) {
case XDP_PASS:
@@ -853,7 +845,7 @@ static struct sk_buff *receive_mergeable(struct net_device *dev,
}
break;
case XDP_TX:
- stats->rx.xdp_tx++;
+ stats->xdp_tx++;
xdpf = convert_to_xdp_frame(&xdp);
if (unlikely(!xdpf))
goto err_xdp;
@@ -870,7 +862,7 @@ static struct sk_buff *receive_mergeable(struct net_device *dev,
rcu_read_unlock();
goto xdp_xmit;
case XDP_REDIRECT:
- stats->rx.xdp_redirects++;
+ stats->xdp_redirects++;
err = xdp_do_redirect(dev, &xdp, xdp_prog);
if (err) {
if (unlikely(xdp_page != page))
@@ -920,7 +912,7 @@ static struct sk_buff *receive_mergeable(struct net_device *dev,
goto err_buf;
}
- stats->rx.bytes += len;
+ stats->bytes += len;
page = virt_to_head_page(buf);
truesize = mergeable_ctx_to_truesize(ctx);
@@ -966,7 +958,7 @@ static struct sk_buff *receive_mergeable(struct net_device *dev,
err_xdp:
rcu_read_unlock();
- stats->rx.xdp_drops++;
+ stats->xdp_drops++;
err_skb:
put_page(page);
while (num_buf-- > 1) {
@@ -977,12 +969,12 @@ static struct sk_buff *receive_mergeable(struct net_device *dev,
dev->stats.rx_length_errors++;
break;
}
- stats->rx.bytes += len;
+ stats->bytes += len;
page = virt_to_head_page(buf);
put_page(page);
}
err_buf:
- stats->rx.drops++;
+ stats->drops++;
dev_kfree_skb(head_skb);
xdp_xmit:
return NULL;
@@ -991,7 +983,7 @@ static struct sk_buff *receive_mergeable(struct net_device *dev,
static void receive_buf(struct virtnet_info *vi, struct receive_queue *rq,
void *buf, unsigned int len, void **ctx,
unsigned int *xdp_xmit,
- struct virtnet_rx_stats *stats)
+ struct virtnet_rq_stats *stats)
{
struct net_device *dev = vi->dev;
struct sk_buff *skb;
@@ -1212,7 +1204,7 @@ static bool try_fill_recv(struct virtnet_info *vi, struct receive_queue *rq,
} while (rq->vq->num_free);
if (virtqueue_kick_prepare(rq->vq) && virtqueue_notify(rq->vq)) {
u64_stats_update_begin(&rq->stats.syncp);
- rq->stats.items.kicks++;
+ rq->stats.kicks++;
u64_stats_update_end(&rq->stats.syncp);
}
@@ -1290,7 +1282,7 @@ static int virtnet_receive(struct receive_queue *rq, int budget,
unsigned int *xdp_xmit)
{
struct virtnet_info *vi = rq->vq->vdev->priv;
- struct virtnet_rx_stats stats = {};
+ struct virtnet_rq_stats stats = {};
unsigned int len;
void *buf;
int i;
@@ -1298,16 +1290,16 @@ static int virtnet_receive(struct receive_queue *rq, int budget,
if (!vi->big_packets || vi->mergeable_rx_bufs) {
void *ctx;
- while (stats.rx.packets < budget &&
+ while (stats.packets < budget &&
(buf = virtqueue_get_buf_ctx(rq->vq, &len, &ctx))) {
receive_buf(vi, rq, buf, len, ctx, xdp_xmit, &stats);
- stats.rx.packets++;
+ stats.packets++;
}
} else {
- while (stats.rx.packets < budget &&
+ while (stats.packets < budget &&
(buf = virtqueue_get_buf(rq->vq, &len)) != NULL) {
receive_buf(vi, rq, buf, len, NULL, xdp_xmit, &stats);
- stats.rx.packets++;
+ stats.packets++;
}
}
@@ -1321,12 +1313,12 @@ static int virtnet_receive(struct receive_queue *rq, int budget,
size_t offset = virtnet_rq_stats_desc[i].offset;
u64 *item;
- item = (u64 *)((u8 *)&rq->stats.items + offset);
- *item += *(u64 *)((u8 *)&stats.rx + offset);
+ item = (u64 *)((u8 *)&rq->stats + offset);
+ *item += *(u64 *)((u8 *)&stats + offset);
}
u64_stats_update_end(&rq->stats.syncp);
- return stats.rx.packets;
+ return stats.packets;
}
static void free_old_xmit_skbs(struct send_queue *sq)
@@ -1686,9 +1678,9 @@ static void virtnet_stats(struct net_device *dev,
do {
start = u64_stats_fetch_begin_irq(&rq->stats.syncp);
- rpackets = rq->stats.items.packets;
- rbytes = rq->stats.items.bytes;
- rdrops = rq->stats.items.drops;
+ rpackets = rq->stats.packets;
+ rbytes = rq->stats.bytes;
+ rdrops = rq->stats.drops;
} while (u64_stats_fetch_retry_irq(&rq->stats.syncp, start));
tot->rx_packets += rpackets;
@@ -2078,7 +2070,7 @@ static void virtnet_get_ethtool_stats(struct net_device *dev,
for (i = 0; i < vi->curr_queue_pairs; i++) {
struct receive_queue *rq = &vi->rq[i];
- stats_base = (u8 *)&rq->stats.items;
+ stats_base = (u8 *)&rq->stats;
do {
start = u64_stats_fetch_begin_irq(&rq->stats.syncp);
for (j = 0; j < VIRTNET_RQ_STATS_LEN; j++) {
--
2.7.4
^ permalink raw reply related
* [PATCH net-next 1/2] virtio-net: correctly update XDP_TX counters
From: Jason Wang @ 2018-07-31 9:43 UTC (permalink / raw)
To: mst, jasowang; +Cc: virtualization, netdev, linux-kernel, Toshiaki Makita
Commit 5b8f3c8d30a6 ("virtio_net: Add XDP related stats") tries to
count TX XDP stats in virtnet_receive(). This will cause several
issues:
- virtnet_xdp_sq() was called without checking whether or not XDP is
set. This may cause out of bound access when there's no enough txq
for XDP.
- Stats were updated even if there's no XDP/XDP_TX.
Fixing this by reusing virtnet_xdp_xmit() for XDP_TX which can counts
TX XDP counter itself and remove the unnecessary tx stats embedded in
rx stats.
Reported-by: syzbot+604f8271211546f5b3c7@syzkaller.appspotmail.com
Fixes: 5b8f3c8d30a6 ("virtio_net: Add XDP related stats")
Cc: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
Signed-off-by: Jason Wang <jasowang@redhat.com>
---
drivers/net/virtio_net.c | 39 ++++-----------------------------------
1 file changed, 4 insertions(+), 35 deletions(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 1880c86..72d3f68 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -105,10 +105,6 @@ struct virtnet_rq_stats {
struct virtnet_rx_stats {
struct virtnet_rq_stat_items rx;
- struct {
- unsigned int xdp_tx;
- unsigned int xdp_tx_drops;
- } tx;
};
#define VIRTNET_SQ_STAT(m) offsetof(struct virtnet_sq_stats, m)
@@ -485,22 +481,6 @@ static struct send_queue *virtnet_xdp_sq(struct virtnet_info *vi)
return &vi->sq[qp];
}
-static int __virtnet_xdp_tx_xmit(struct virtnet_info *vi,
- struct xdp_frame *xdpf)
-{
- struct xdp_frame *xdpf_sent;
- struct send_queue *sq;
- unsigned int len;
-
- sq = virtnet_xdp_sq(vi);
-
- /* Free up any pending old buffers before queueing new ones. */
- while ((xdpf_sent = virtqueue_get_buf(sq->vq, &len)) != NULL)
- xdp_return_frame(xdpf_sent);
-
- return __virtnet_xdp_xmit_one(vi, sq, xdpf);
-}
-
static int virtnet_xdp_xmit(struct net_device *dev,
int n, struct xdp_frame **frames, u32 flags)
{
@@ -707,10 +687,8 @@ static struct sk_buff *receive_small(struct net_device *dev,
xdpf = convert_to_xdp_frame(&xdp);
if (unlikely(!xdpf))
goto err_xdp;
- stats->tx.xdp_tx++;
- err = __virtnet_xdp_tx_xmit(vi, xdpf);
- if (unlikely(err)) {
- stats->tx.xdp_tx_drops++;
+ err = virtnet_xdp_xmit(dev, 1, &xdpf, 0);
+ if (unlikely(err < 0)) {
trace_xdp_exception(vi->dev, xdp_prog, act);
goto err_xdp;
}
@@ -879,10 +857,8 @@ static struct sk_buff *receive_mergeable(struct net_device *dev,
xdpf = convert_to_xdp_frame(&xdp);
if (unlikely(!xdpf))
goto err_xdp;
- stats->tx.xdp_tx++;
- err = __virtnet_xdp_tx_xmit(vi, xdpf);
- if (unlikely(err)) {
- stats->tx.xdp_tx_drops++;
+ err = virtnet_xdp_xmit(dev, 1, &xdpf, 0);
+ if (unlikely(err < 0)) {
trace_xdp_exception(vi->dev, xdp_prog, act);
if (unlikely(xdp_page != page))
put_page(xdp_page);
@@ -1315,7 +1291,6 @@ static int virtnet_receive(struct receive_queue *rq, int budget,
{
struct virtnet_info *vi = rq->vq->vdev->priv;
struct virtnet_rx_stats stats = {};
- struct send_queue *sq;
unsigned int len;
void *buf;
int i;
@@ -1351,12 +1326,6 @@ static int virtnet_receive(struct receive_queue *rq, int budget,
}
u64_stats_update_end(&rq->stats.syncp);
- sq = virtnet_xdp_sq(vi);
- u64_stats_update_begin(&sq->stats.syncp);
- sq->stats.xdp_tx += stats.tx.xdp_tx;
- sq->stats.xdp_tx_drops += stats.tx.xdp_tx_drops;
- u64_stats_update_end(&sq->stats.syncp);
-
return stats.rx.packets;
}
--
2.7.4
^ permalink raw reply related
* Re: [PATCH] net: ethernet: realtek: r8169: Add spaces after commas coding style issue
From: Sohil Ladhani @ 2018-07-31 9:43 UTC (permalink / raw)
To: David Miller; +Cc: nic_swsd, netdev, linux-kernel
In-Reply-To: <20180729.131741.711465145442387927.davem@davemloft.net>
Hi David. Thanks for your inputs. I'm a kernel newbie and was just
following Greg's FOSDEM talk to submit my first patch. Will submit
further patches to net-next tree.
On Mon, Jul 30, 2018 at 1:47 AM, David Miller <davem@davemloft.net> wrote:
> From: Sohil Ladhani <supertakumi86@gmail.com>
> Date: Sat, 28 Jul 2018 14:32:21 +0530
>
>> Fixed a coding style issue
>>
>> Signed-off-by: Sohil Ladhani <supertakumi86@gmail.com>
>
> This doesn't apply to the current net-next tree.
^ permalink raw reply
* Re: [patch net-next] net: sched: don't dump chains only held by actions
From: Jakub Kicinski @ 2018-07-31 8:01 UTC (permalink / raw)
To: Jiri Pirko
Cc: Cong Wang, Linux Kernel Network Developers, David Miller,
Jamal Hadi Salim, mlxsw
In-Reply-To: <20180731063258.GA2154@nanopsycho>
On Tue, 31 Jul 2018 08:32:58 +0200, Jiri Pirko wrote:
> Mon, Jul 30, 2018 at 08:19:56PM CEST, xiyou.wangcong@gmail.com wrote:
> >On Sun, Jul 29, 2018 at 12:54 AM Jiri Pirko <jiri@resnulli.us> wrote:
> >>
> >> Sat, Jul 28, 2018 at 07:39:36PM CEST, xiyou.wangcong@gmail.com wrote:
> >> >On Sat, Jul 28, 2018 at 10:20 AM Cong Wang <xiyou.wangcong@gmail.com> wrote:
> >> >>
> >> >> On Fri, Jul 27, 2018 at 12:47 AM Jiri Pirko <jiri@resnulli.us> wrote:
> >> >> >
> >> >> > From: Jiri Pirko <jiri@mellanox.com>
> >> >> >
> >> >> > In case a chain is empty and not explicitly created by a user,
> >> >> > such chain should not exist. The only exception is if there is
> >> >> > an action "goto chain" pointing to it. In that case, don't show the
> >> >> > chain in the dump. Track the chain references held by actions and
> >> >> > use them to find out if a chain should or should not be shown
> >> >> > in chain dump.
> >> >> >
> >> >> > Signed-off-by: Jiri Pirko <jiri@mellanox.com>
> >> >>
> >> >> Looks reasonable to me.
> >> >>
> >> >> Acked-by: Cong Wang <xiyou.wangcong@gmail.com>
> >> >
> >> >Hold on...
> >> >
> >> >If you increase the refcnt for a zombie chain on NEWCHAIN path,
> >> >then it would become a non-zombie, this makes sense. However,
> >> >if the action_refcnt gets increased again when another action uses it,
> >> >it become a zombie again because refcnt==action_refcnt??
> >>
> >> No. action always increases both refcnt and action_refcnt
> >
> >Hmm, then the name zombie is confusing, with your definition all
> >chains implicitly created by actions are zombies, unless touched
> >by user explicitly. Please find a better name.
>
> Okay. Perhaps chain_inactive?
FWIW to me active brings to mind that it's handling traffic. Brining in
my suggestions from an off-list discussion:
tcf_chain_act_refs_only() or tcf_chain_pure_act_target()
or maybe tcf_chain_has_no_filters() ?
^ permalink raw reply
* Re: [PATCH v3] Add BPF_SYNCHRONIZE_MAP_TO_MAP_REFERENCES bpf(2) command
From: Daniel Colascione @ 2018-07-31 9:36 UTC (permalink / raw)
To: Daniel Borkmann
Cc: Jakub Kicinski, Joel Fernandes, linux-kernel, Tim Murray, netdev,
Alexei Starovoitov, Lorenzo Colitti, Chenbo Feng,
Mathieu Desnoyers, Alexei Starovoitov
In-Reply-To: <67423232-be56-fd47-06e6-394812c2b918@iogearbox.net>
On Tue, Jul 31, 2018 at 1:34 AM, Daniel Borkmann <daniel@iogearbox.net> wrote:
> On 07/31/2018 02:33 AM, Daniel Colascione wrote:
>> On Mon, Jul 30, 2018 at 5:26 PM, Jakub Kicinski
>> <jakub.kicinski@netronome.com> wrote:
>>> On Mon, 30 Jul 2018 03:25:43 -0700, Daniel Colascione wrote:
>>>> On Mon, Jul 30, 2018 at 3:04 AM, Daniel Borkmann <daniel@iogearbox.net> wrote:
>>>>> Hmm, I don't think such UAPI as above is future-proof. In case we would want
>>>>> a similar mechanism in future for other maps, we would need a whole new bpf
>>>>> command or reuse BPF_SYNCHRONIZE_MAP_TO_MAP_REFERENCES as a workaround though
>>>>> the underlying map may not even be a map-to-map. Additionally, we don't have
>>>>> any map object at hand in the above, so we couldn't make any finer grained
>>>>> decisions either. Something like below would be more suitable and leaves room
>>>>> for extending this further in future.
>>>>
>>>> YAGNI. Your proposed mechanism doesn't add anything under the current
>>>> implementation.
>>>
>>> FWIW in case of HW offload targeting a particular map may allow users
>>> to avoid a potentially slow sync with all the devices on the system.
>>
>> Sure. But such a thing doesn't exist right now (right?), and we can
>> add that more-efficient-in-that-one-case BPF interface when it lands.
>> I'd rather keep things simple for now.
>
> I don't see a reason why that is even more complicated.
Both the API and the implementation are much more complicated in the
per-map ops version: just look at the patch size. The size argument
isn't necessarily a dealbreaker, but I still don't see what the extra
code size and complexity is buying.
> An API command name
> such as BPF_SYNCHRONIZE_MAP_TO_MAP_REFERENCES is simply non-generic, and
> exposes specific map details (here: map-in-map) into the UAPI whereas it
> should reside within a specific implementation instead similar to other ops
> we have for maps.
But synchronize isn't conceptually a command that applies to a
specific map. It waits on all references. Did you address my point
about your proposed map-specific interface requiring redundant
synchronize_rcu calls in the case where we swap multiple maps and want
to wait for all the references to drain? Under my proposal, you'd just
BPF_SYNCHRONIZE_WHATEVER and call schedule_rcu once. Under your
proposal, we'd make it a per-map operation, so we'd issue one
synchronize_rcu per map.
> If in future other maps would be added that would have
> similar mechanisms of inner objects they return to the BPF program, we'll
> be adding yet another command just for this.
And that's why my personal preference is to just calling this thing
BPF_SYNCHRONIZE, which I'd define to wait for all such "inner
objects". Alexei is the one who asked for the very specific naming, I
believe.
Anyway, we have a very simple patch that we could apply today. It
addresses a real need, and it doesn't preclude adding something more
specific later, when we know we need it. Besides, it's not as if
adding a BPF command is particularly expensive.
> Also, union bpf_attr is extensible,
> e.g. additional members could be added in future whenever needed for this
> subcommand instead of forcing it to NULL as done here.
We fail with EINVAL when attr != NULL now, which means that we can
safely accept a non-NULL attr-based subcommand later without breaking
anyone. The interface is already extensible.
> All I'm saying is to
> keep it generic so it can be extended later.
Sure, but no more extensible than it has to be. Prematurely-added
extension points tend to cause trouble later.
^ permalink raw reply
* Re: [PATCH net-next 0/3] xsk: improvements to RX queue check and replace
From: Daniel Borkmann @ 2018-07-31 7:50 UTC (permalink / raw)
To: Jakub Kicinski, davem, alexei.starovoitov
Cc: netdev, oss-drivers, bjorn.topel
In-Reply-To: <20180731034353.3774-1-jakub.kicinski@netronome.com>
On 07/31/2018 05:43 AM, Jakub Kicinski wrote:
> Hi!
>
> First 3 patches of my recent RFC. The first one make the check against
> real_num_rx_queues slightly more reliable, while the latter two redefine
> XDP_QUERY_XSK_UMEM slightly to disallow replacing UMEM in the driver at
> the stack level.
>
> I'm not sure where this lays on the bpf vs net trees scale, but there
> should be no conflicts with either tree.
I'm fine either way, in any case, series looks good to me:
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
> Jakub Kicinski (3):
> net: update real_num_rx_queues even when !CONFIG_SYSFS
> xsk: refactor xdp_umem_assign_dev()
> xsk: don't allow umem replace at stack level
>
> include/linux/netdevice.h | 10 +++---
> net/xdp/xdp_umem.c | 70 +++++++++++++++++++++++----------------
> 2 files changed, 47 insertions(+), 33 deletions(-)
>
^ permalink raw reply
* Re: [PATCH v2 bpf-next 0/4] Support bpf_get_socket_cookie in more prog types
From: Daniel Borkmann @ 2018-07-31 7:35 UTC (permalink / raw)
To: Andrey Ignatov, netdev; +Cc: ast, yhs, brakmo, kernel-team
In-Reply-To: <cover.1532996972.git.rdna@fb.com>
On 07/31/2018 02:42 AM, Andrey Ignatov wrote:
> v1->v2:
> - simplify attach_type guessing logic in selftest.
>
> This patch set adds support to call bpf_get_socket_cookie() helper from two
> more program types:
> * BPF_PROG_TYPE_CGROUP_SOCK_ADDR;
> * BPF_PROG_TYPE_SOCK_OPS.
>
> Patch 1 adds kernel support and provides more details.
> Patch 2 syncs UAPI changes to tools/.
> Patch 3 adds missing helper to bpf_helpers.h.
> Patch 4 adds selftest for new functionality.
>
>
> Andrey Ignatov (4):
> bpf: Support bpf_get_socket_cookie in more prog types
> bpf: Sync bpf.h to tools/
> selftests/bpf: Add bpf_get_socket_cookie to bpf_helpers.h
> selftests/bpf: Test for get_socket_cookie
Applied to bpf-next, thanks Andrey!
^ permalink raw reply
* Re: [PATCH 3/4] dt-bindings: net: phy: mscc: vsc8531: fix missing "/bits/ 8" in example
From: Quentin Schulz @ 2018-07-31 9:11 UTC (permalink / raw)
To: Andrew Lunn
Cc: f.fainelli, davem, robh+dt, mark.rutland, devicetree, netdev,
alexandre.belloni, linux-kernel, thomas.petazzoni
In-Reply-To: <20180730135813.GH13198@lunn.ch>
[-- Attachment #1: Type: text/plain, Size: 2229 bytes --]
Hi Andrew,
On Mon, Jul 30, 2018 at 03:58:13PM +0200, Andrew Lunn wrote:
> On Mon, Jul 30, 2018 at 03:02:35PM +0200, Quentin Schulz wrote:
> > The "vsc8531,led-N-mode" property is read as a u8 in the driver and
> > there aren't a lot of modes anyway.
> >
> > Without the "/bits/ 8" in front of the value of the property, the
> > value is stored as an u32 resulting in of_read_property_u8 to always
> > return 0.
>
> Hi Quentin
>
> on big endian systems. I'm expect this worked on little endian ARM. I
> think the development work was done on a hacked RPi, if i remember
> correctly.
>
> >
> > Fix the example so that people using the property can actually use it.
> >
> > Signed-off-by: Quentin Schulz <quentin.schulz@bootlin.com>
> > ---
> > Documentation/devicetree/bindings/net/mscc-phy-vsc8531.txt | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/net/mscc-phy-vsc8531.txt b/Documentation/devicetree/bindings/net/mscc-phy-vsc8531.txt
> > index 664d9d0543fc..4c7d1d384df0 100644
> > --- a/Documentation/devicetree/bindings/net/mscc-phy-vsc8531.txt
> > +++ b/Documentation/devicetree/bindings/net/mscc-phy-vsc8531.txt
> > @@ -63,6 +63,6 @@ Example:
> > compatible = "ethernet-phy-id0007.0570";
> > vsc8531,vddmac = <3300>;
> > vsc8531,edge-slowdown = <7>;
> > - vsc8531,led-0-mode = <LINK_1000_ACTIVITY>;
> > - vsc8531,led-1-mode = <LINK_100_ACTIVITY>;
> > + vsc8531,led-0-mode = /bits/ 8 <LINK_1000_ACTIVITY>;
> > + vsc8531,led-1-mode = /bits/ 8 <LINK_100_ACTIVITY>;
>
> I don't know the device tree language well enough...
>
> Would this work?
>
> vsc8531,led-1-mode = < /bits/ 8 LINK_100_ACTIVITY>;
>
> If so, you can make it part of the #define.
It does not compile unfortunately. According to the documentation of
DTC[1], /bits/ 8 should prefix the value/array so I guess we're out of
luck for using the same define in the kernel and DTS if we want to
abstract this prefix.
Quentin
[1] https://git.kernel.org/pub/scm/utils/dtc/dtc.git/tree/Documentation/dts-format.txt#n46
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [PATCH net-next 3/3] qed: Add Multi-TC RoCE support
From: Denis Bolotin @ 2018-07-31 7:26 UTC (permalink / raw)
To: davem, netdev; +Cc: Denis Bolotin, Ariel Elior
In-Reply-To: <20180731072608.2976-1-denis.bolotin@cavium.com>
RoCE qps use a pair of physical queues (pq) received from the Queue Manager
(QM) - an offload queue (OFLD) and a low latency queue (LLT). The QM block
creates a pq for each TC, and allows RoCE qps to ask for a pq with a
specific TC. As a result, qps with different VLAN priorities can be mapped
to different TCs, and employ features such as PFC and ETS.
Signed-off-by: Denis Bolotin <denis.bolotin@cavium.com>
Signed-off-by: Ariel Elior <ariel.elior@cavium.com>
---
drivers/net/ethernet/qlogic/qed/qed.h | 10 ++-
drivers/net/ethernet/qlogic/qed/qed_dev.c | 104 +++++++++++++++++++++++++----
drivers/net/ethernet/qlogic/qed/qed_roce.c | 61 ++++++++++++-----
3 files changed, 143 insertions(+), 32 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qed/qed.h b/drivers/net/ethernet/qlogic/qed/qed.h
index f916f13..a60e1c8 100644
--- a/drivers/net/ethernet/qlogic/qed/qed.h
+++ b/drivers/net/ethernet/qlogic/qed/qed.h
@@ -338,6 +338,9 @@ struct qed_hw_info {
u8 offload_tc;
bool offload_tc_set;
+ bool multi_tc_roce_en;
+#define IS_QED_MULTI_TC_ROCE(p_hwfn) (((p_hwfn)->hw_info.multi_tc_roce_en))
+
u32 concrete_fid;
u16 opaque_fid;
u16 ovlan;
@@ -400,8 +403,8 @@ struct qed_qm_info {
u16 start_pq;
u8 start_vport;
u16 pure_lb_pq;
- u16 offload_pq;
- u16 low_latency_pq;
+ u16 first_ofld_pq;
+ u16 first_llt_pq;
u16 pure_ack_pq;
u16 ooo_pq;
u16 first_vf_pq;
@@ -882,11 +885,14 @@ void qed_set_fw_mac_addr(__le16 *fw_msb,
#define PQ_FLAGS_OFLD (BIT(5))
#define PQ_FLAGS_VFS (BIT(6))
#define PQ_FLAGS_LLT (BIT(7))
+#define PQ_FLAGS_MTC (BIT(8))
/* physical queue index for cm context intialization */
u16 qed_get_cm_pq_idx(struct qed_hwfn *p_hwfn, u32 pq_flags);
u16 qed_get_cm_pq_idx_mcos(struct qed_hwfn *p_hwfn, u8 tc);
u16 qed_get_cm_pq_idx_vf(struct qed_hwfn *p_hwfn, u16 vf);
+u16 qed_get_cm_pq_idx_ofld_mtc(struct qed_hwfn *p_hwfn, u8 tc);
+u16 qed_get_cm_pq_idx_llt_mtc(struct qed_hwfn *p_hwfn, u8 tc);
#define QED_LEADING_HWFN(dev) (&dev->hwfns[0])
diff --git a/drivers/net/ethernet/qlogic/qed/qed_dev.c b/drivers/net/ethernet/qlogic/qed/qed_dev.c
index e7900ec..34302ce 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_dev.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_dev.c
@@ -215,6 +215,8 @@ static u32 qed_get_pq_flags(struct qed_hwfn *p_hwfn)
break;
case QED_PCI_ETH_ROCE:
flags |= PQ_FLAGS_MCOS | PQ_FLAGS_OFLD | PQ_FLAGS_LLT;
+ if (IS_QED_MULTI_TC_ROCE(p_hwfn))
+ flags |= PQ_FLAGS_MTC;
break;
case QED_PCI_ETH_IWARP:
flags |= PQ_FLAGS_MCOS | PQ_FLAGS_ACK | PQ_FLAGS_OOO |
@@ -241,6 +243,16 @@ u16 qed_init_qm_get_num_vfs(struct qed_hwfn *p_hwfn)
p_hwfn->cdev->p_iov_info->total_vfs : 0;
}
+static u8 qed_init_qm_get_num_mtc_tcs(struct qed_hwfn *p_hwfn)
+{
+ u32 pq_flags = qed_get_pq_flags(p_hwfn);
+
+ if (!(PQ_FLAGS_MTC & pq_flags))
+ return 1;
+
+ return qed_init_qm_get_num_tcs(p_hwfn);
+}
+
#define NUM_DEFAULT_RLS 1
u16 qed_init_qm_get_num_pf_rls(struct qed_hwfn *p_hwfn)
@@ -282,8 +294,11 @@ u16 qed_init_qm_get_num_pqs(struct qed_hwfn *p_hwfn)
(!!(PQ_FLAGS_MCOS & pq_flags)) *
qed_init_qm_get_num_tcs(p_hwfn) +
(!!(PQ_FLAGS_LB & pq_flags)) + (!!(PQ_FLAGS_OOO & pq_flags)) +
- (!!(PQ_FLAGS_ACK & pq_flags)) + (!!(PQ_FLAGS_OFLD & pq_flags)) +
- (!!(PQ_FLAGS_LLT & pq_flags)) +
+ (!!(PQ_FLAGS_ACK & pq_flags)) +
+ (!!(PQ_FLAGS_OFLD & pq_flags)) *
+ qed_init_qm_get_num_mtc_tcs(p_hwfn) +
+ (!!(PQ_FLAGS_LLT & pq_flags)) *
+ qed_init_qm_get_num_mtc_tcs(p_hwfn) +
(!!(PQ_FLAGS_VFS & pq_flags)) * qed_init_qm_get_num_vfs(p_hwfn);
}
@@ -474,9 +489,9 @@ static u16 *qed_init_qm_get_idx_from_flags(struct qed_hwfn *p_hwfn,
case PQ_FLAGS_ACK:
return &qm_info->pure_ack_pq;
case PQ_FLAGS_OFLD:
- return &qm_info->offload_pq;
+ return &qm_info->first_ofld_pq;
case PQ_FLAGS_LLT:
- return &qm_info->low_latency_pq;
+ return &qm_info->first_llt_pq;
case PQ_FLAGS_VFS:
return &qm_info->first_vf_pq;
default:
@@ -525,6 +540,43 @@ u16 qed_get_cm_pq_idx_vf(struct qed_hwfn *p_hwfn, u16 vf)
return qed_get_cm_pq_idx(p_hwfn, PQ_FLAGS_VFS) + vf;
}
+static u16 qed_get_cm_pq_offset_mtc(struct qed_hwfn *p_hwfn, u8 tc)
+{
+ u16 pq_offset = tc;
+ u8 num_tcs;
+
+ /* Verify that the pq returned is within pqs range */
+ num_tcs = qed_init_qm_get_num_mtc_tcs(p_hwfn);
+ if (pq_offset >= num_tcs) {
+ DP_ERR(p_hwfn,
+ "pq_offset %d must be smaller than %d (tc %d)\n",
+ pq_offset, num_tcs, tc);
+ return 0;
+ }
+
+ return pq_offset;
+}
+
+u16 qed_get_cm_pq_idx_ofld_mtc(struct qed_hwfn *p_hwfn, u8 tc)
+{
+ u16 first_ofld_pq, pq_offset;
+
+ first_ofld_pq = qed_get_cm_pq_idx(p_hwfn, PQ_FLAGS_OFLD);
+ pq_offset = qed_get_cm_pq_offset_mtc(p_hwfn, tc);
+
+ return first_ofld_pq + pq_offset;
+}
+
+u16 qed_get_cm_pq_idx_llt_mtc(struct qed_hwfn *p_hwfn, u8 tc)
+{
+ u16 first_llt_pq, pq_offset;
+
+ first_llt_pq = qed_get_cm_pq_idx(p_hwfn, PQ_FLAGS_LLT);
+ pq_offset = qed_get_cm_pq_offset_mtc(p_hwfn, tc);
+
+ return first_llt_pq + pq_offset;
+}
+
/* Functions for creating specific types of pqs */
static void qed_init_qm_lb_pq(struct qed_hwfn *p_hwfn)
{
@@ -560,6 +612,20 @@ static void qed_init_qm_pure_ack_pq(struct qed_hwfn *p_hwfn)
PQ_INIT_SHARE_VPORT);
}
+static void qed_init_qm_mtc_pqs(struct qed_hwfn *p_hwfn)
+{
+ u8 num_tcs = qed_init_qm_get_num_mtc_tcs(p_hwfn);
+ struct qed_qm_info *qm_info = &p_hwfn->qm_info;
+ u8 tc;
+
+ /* override pq's TC if offload TC is set */
+ for (tc = 0; tc < num_tcs; tc++)
+ qed_init_qm_pq(p_hwfn, qm_info,
+ qed_is_offload_tc_set(p_hwfn) ?
+ qed_get_offload_tc(p_hwfn) : tc,
+ PQ_INIT_SHARE_VPORT);
+}
+
static void qed_init_qm_offload_pq(struct qed_hwfn *p_hwfn)
{
struct qed_qm_info *qm_info = &p_hwfn->qm_info;
@@ -568,8 +634,7 @@ static void qed_init_qm_offload_pq(struct qed_hwfn *p_hwfn)
return;
qed_init_qm_set_idx(p_hwfn, PQ_FLAGS_OFLD, qm_info->num_pqs);
- qed_init_qm_pq(p_hwfn, qm_info, qed_get_offload_tc(p_hwfn),
- PQ_INIT_SHARE_VPORT);
+ qed_init_qm_mtc_pqs(p_hwfn);
}
static void qed_init_qm_low_latency_pq(struct qed_hwfn *p_hwfn)
@@ -580,8 +645,7 @@ static void qed_init_qm_low_latency_pq(struct qed_hwfn *p_hwfn)
return;
qed_init_qm_set_idx(p_hwfn, PQ_FLAGS_LLT, qm_info->num_pqs);
- qed_init_qm_pq(p_hwfn, qm_info, qed_get_offload_tc(p_hwfn),
- PQ_INIT_SHARE_VPORT);
+ qed_init_qm_mtc_pqs(p_hwfn);
}
static void qed_init_qm_mcos_pqs(struct qed_hwfn *p_hwfn)
@@ -664,12 +728,19 @@ static int qed_init_qm_sanity(struct qed_hwfn *p_hwfn)
return -EINVAL;
}
- if (qed_init_qm_get_num_pqs(p_hwfn) > RESC_NUM(p_hwfn, QED_PQ)) {
- DP_ERR(p_hwfn, "requested amount of pqs exceeds resource\n");
- return -EINVAL;
+ if (qed_init_qm_get_num_pqs(p_hwfn) <= RESC_NUM(p_hwfn, QED_PQ))
+ return 0;
+
+ if (QED_IS_ROCE_PERSONALITY(p_hwfn)) {
+ p_hwfn->hw_info.multi_tc_roce_en = 0;
+ DP_NOTICE(p_hwfn,
+ "multi-tc roce was disabled to reduce requested amount of pqs\n");
+ if (qed_init_qm_get_num_pqs(p_hwfn) <= RESC_NUM(p_hwfn, QED_PQ))
+ return 0;
}
- return 0;
+ DP_ERR(p_hwfn, "requested amount of pqs exceeds resource\n");
+ return -EINVAL;
}
static void qed_dp_init_qm_params(struct qed_hwfn *p_hwfn)
@@ -683,11 +754,13 @@ static void qed_dp_init_qm_params(struct qed_hwfn *p_hwfn)
/* top level params */
DP_VERBOSE(p_hwfn,
NETIF_MSG_HW,
- "qm init top level params: start_pq %d, start_vport %d, pure_lb_pq %d, offload_pq %d, pure_ack_pq %d\n",
+ "qm init top level params: start_pq %d, start_vport %d, pure_lb_pq %d, offload_pq %d, llt_pq %d, pure_ack_pq %d\n",
qm_info->start_pq,
qm_info->start_vport,
qm_info->pure_lb_pq,
- qm_info->offload_pq, qm_info->pure_ack_pq);
+ qm_info->first_ofld_pq,
+ qm_info->first_llt_pq,
+ qm_info->pure_ack_pq);
DP_VERBOSE(p_hwfn,
NETIF_MSG_HW,
"ooo_pq %d, first_vf_pq %d, num_pqs %d, num_vf_pqs %d, num_vports %d, max_phys_tcs_per_port %d\n",
@@ -2920,6 +2993,9 @@ static void qed_get_eee_caps(struct qed_hwfn *p_hwfn, struct qed_ptt *p_ptt)
p_hwfn->hw_info.personality = protocol;
}
+ if (QED_IS_ROCE_PERSONALITY(p_hwfn))
+ p_hwfn->hw_info.multi_tc_roce_en = 1;
+
p_hwfn->hw_info.num_hw_tc = NUM_PHYS_TCS_4PORT_K2;
p_hwfn->hw_info.num_active_tc = 1;
diff --git a/drivers/net/ethernet/qlogic/qed/qed_roce.c b/drivers/net/ethernet/qlogic/qed/qed_roce.c
index b5ce158..184fa03 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_roce.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_roce.c
@@ -44,8 +44,10 @@
#include <linux/slab.h>
#include <linux/spinlock.h>
#include <linux/string.h>
+#include <linux/if_vlan.h>
#include "qed.h"
#include "qed_cxt.h"
+#include "qed_dcbx.h"
#include "qed_hsi.h"
#include "qed_hw.h"
#include "qed_init_ops.h"
@@ -231,16 +233,40 @@ static void qed_roce_set_real_cid(struct qed_hwfn *p_hwfn, u32 cid)
spin_unlock_bh(&p_hwfn->p_rdma_info->lock);
}
+static u8 qed_roce_get_qp_tc(struct qed_hwfn *p_hwfn, struct qed_rdma_qp *qp)
+{
+ u8 pri = 0, tc = 0;
+ int rc;
+
+ if (qp->vlan_id) {
+ pri = (qp->vlan_id & VLAN_PRIO_MASK) >> VLAN_PRIO_SHIFT;
+
+ /* Get the TC mapped to the VLAN priority */
+ rc = qed_dcbx_get_priority_tc(p_hwfn, pri, &tc);
+ if (rc)
+ DP_NOTICE(p_hwfn,
+ "qp icid %u: qed_dcbx_get_priority_tc failed\n",
+ qp->icid);
+ }
+
+ DP_VERBOSE(p_hwfn, QED_MSG_SP,
+ "qp icid %u tc: %u (vlan priority %s)\n",
+ qp->icid, tc, qp->vlan_id ? "enabled" : "disabled");
+
+ return tc;
+}
+
static int qed_roce_sp_create_responder(struct qed_hwfn *p_hwfn,
struct qed_rdma_qp *qp)
{
struct roce_create_qp_resp_ramrod_data *p_ramrod;
+ u16 regular_latency_queue, low_latency_queue;
struct qed_sp_init_data init_data;
enum roce_flavor roce_flavor;
struct qed_spq_entry *p_ent;
- u16 regular_latency_queue;
enum protocol_type proto;
int rc;
+ u8 tc;
DP_VERBOSE(p_hwfn, QED_MSG_RDMA, "icid = %08x\n", qp->icid);
@@ -324,12 +350,17 @@ static int qed_roce_sp_create_responder(struct qed_hwfn *p_hwfn,
p_ramrod->cq_cid = cpu_to_le32((p_hwfn->hw_info.opaque_fid << 16) |
qp->rq_cq_id);
- regular_latency_queue = qed_get_cm_pq_idx(p_hwfn, PQ_FLAGS_OFLD);
-
+ tc = qed_roce_get_qp_tc(p_hwfn, qp);
+ regular_latency_queue = qed_get_cm_pq_idx_ofld_mtc(p_hwfn, tc);
+ low_latency_queue = qed_get_cm_pq_idx_llt_mtc(p_hwfn, tc);
+ DP_VERBOSE(p_hwfn, QED_MSG_SP,
+ "qp icid %u pqs: regular_latency %u low_latency %u\n",
+ qp->icid, regular_latency_queue - CM_TX_PQ_BASE,
+ low_latency_queue - CM_TX_PQ_BASE);
p_ramrod->regular_latency_phy_queue =
cpu_to_le16(regular_latency_queue);
p_ramrod->low_latency_phy_queue =
- cpu_to_le16(regular_latency_queue);
+ cpu_to_le16(low_latency_queue);
p_ramrod->dpi = cpu_to_le16(qp->dpi);
@@ -345,11 +376,6 @@ static int qed_roce_sp_create_responder(struct qed_hwfn *p_hwfn,
qp->stats_queue;
rc = qed_spq_post(p_hwfn, p_ent, NULL);
-
- DP_VERBOSE(p_hwfn, QED_MSG_RDMA,
- "rc = %d regular physical queue = 0x%x\n", rc,
- regular_latency_queue);
-
if (rc)
goto err;
@@ -375,12 +401,13 @@ static int qed_roce_sp_create_requester(struct qed_hwfn *p_hwfn,
struct qed_rdma_qp *qp)
{
struct roce_create_qp_req_ramrod_data *p_ramrod;
+ u16 regular_latency_queue, low_latency_queue;
struct qed_sp_init_data init_data;
enum roce_flavor roce_flavor;
struct qed_spq_entry *p_ent;
- u16 regular_latency_queue;
enum protocol_type proto;
int rc;
+ u8 tc;
DP_VERBOSE(p_hwfn, QED_MSG_RDMA, "icid = %08x\n", qp->icid);
@@ -453,12 +480,17 @@ static int qed_roce_sp_create_requester(struct qed_hwfn *p_hwfn,
p_ramrod->cq_cid =
cpu_to_le32((p_hwfn->hw_info.opaque_fid << 16) | qp->sq_cq_id);
- regular_latency_queue = qed_get_cm_pq_idx(p_hwfn, PQ_FLAGS_OFLD);
-
+ tc = qed_roce_get_qp_tc(p_hwfn, qp);
+ regular_latency_queue = qed_get_cm_pq_idx_ofld_mtc(p_hwfn, tc);
+ low_latency_queue = qed_get_cm_pq_idx_llt_mtc(p_hwfn, tc);
+ DP_VERBOSE(p_hwfn, QED_MSG_SP,
+ "qp icid %u pqs: regular_latency %u low_latency %u\n",
+ qp->icid, regular_latency_queue - CM_TX_PQ_BASE,
+ low_latency_queue - CM_TX_PQ_BASE);
p_ramrod->regular_latency_phy_queue =
cpu_to_le16(regular_latency_queue);
p_ramrod->low_latency_phy_queue =
- cpu_to_le16(regular_latency_queue);
+ cpu_to_le16(low_latency_queue);
p_ramrod->dpi = cpu_to_le16(qp->dpi);
@@ -471,9 +503,6 @@ static int qed_roce_sp_create_requester(struct qed_hwfn *p_hwfn,
qp->stats_queue;
rc = qed_spq_post(p_hwfn, p_ent, NULL);
-
- DP_VERBOSE(p_hwfn, QED_MSG_RDMA, "rc = %d\n", rc);
-
if (rc)
goto err;
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH bpf-next] nfp: fix variable dereferenced before check in nfp_app_ctrl_rx_raw()
From: Daniel Borkmann @ 2018-07-31 7:29 UTC (permalink / raw)
To: Jakub Kicinski, alexei.starovoitov; +Cc: netdev, oss-drivers
In-Reply-To: <20180731033315.2430-1-jakub.kicinski@netronome.com>
On 07/31/2018 05:33 AM, Jakub Kicinski wrote:
> 'app' is dereferenced before used for the devlink trace point.
> In case FW is buggy and sends a control message to a VF queue
> we should make sure app is not NULL.
>
> Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
> Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
> Reviewed-by: Dirk van der Merwe <dirk.vandermerwe@netronome.com>
Applied to bpf-next, thanks Jakub!
^ permalink raw reply
* [PATCH net-next 2/3] qed: Add a flag which indicates if offload TC is set
From: Denis Bolotin @ 2018-07-31 7:26 UTC (permalink / raw)
To: davem, netdev; +Cc: Denis Bolotin, Ariel Elior
In-Reply-To: <20180731072608.2976-1-denis.bolotin@cavium.com>
Distinguish not set offload_tc from offload_tc 0 and add getters and
setters.
Signed-off-by: Denis Bolotin <denis.bolotin@cavium.com>
Signed-off-by: Ariel Elior <ariel.elior@cavium.com>
---
drivers/net/ethernet/qlogic/qed/qed.h | 3 +++
drivers/net/ethernet/qlogic/qed/qed_dcbx.c | 2 +-
drivers/net/ethernet/qlogic/qed/qed_dev.c | 32 +++++++++++++++++++++++++-----
drivers/net/ethernet/qlogic/qed/qed_mcp.c | 3 ++-
4 files changed, 33 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qed/qed.h b/drivers/net/ethernet/qlogic/qed/qed.h
index 1dfaccd..f916f13 100644
--- a/drivers/net/ethernet/qlogic/qed/qed.h
+++ b/drivers/net/ethernet/qlogic/qed/qed.h
@@ -336,6 +336,7 @@ struct qed_hw_info {
*/
u8 num_active_tc;
u8 offload_tc;
+ bool offload_tc_set;
u32 concrete_fid;
u16 opaque_fid;
@@ -921,4 +922,6 @@ void qed_get_protocol_stats(struct qed_dev *cdev,
int qed_mfw_fill_tlv_data(struct qed_hwfn *hwfn,
enum qed_mfw_tlv_type type,
union qed_mfw_tlv_data *tlv_data);
+
+void qed_hw_info_set_offload_tc(struct qed_hw_info *p_info, u8 tc);
#endif /* _QED_H */
diff --git a/drivers/net/ethernet/qlogic/qed/qed_dcbx.c b/drivers/net/ethernet/qlogic/qed/qed_dcbx.c
index 00891cc..f939944 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_dcbx.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_dcbx.c
@@ -208,7 +208,7 @@ static bool qed_dcbx_roce_v2_tlv(u32 app_info_bitmap, u16 proto_id, bool ieee)
/* QM reconf data */
if (p_info->personality == personality)
- p_info->offload_tc = tc;
+ qed_hw_info_set_offload_tc(p_info, tc);
}
/* Update app protocol data and hw_info fields with the TLV info */
diff --git a/drivers/net/ethernet/qlogic/qed/qed_dev.c b/drivers/net/ethernet/qlogic/qed/qed_dev.c
index 37817b3..e7900ec 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_dev.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_dev.c
@@ -394,7 +394,25 @@ static void qed_init_qm_advance_vport(struct qed_hwfn *p_hwfn)
/* defines for pq init */
#define PQ_INIT_DEFAULT_WRR_GROUP 1
#define PQ_INIT_DEFAULT_TC 0
-#define PQ_INIT_OFLD_TC (p_hwfn->hw_info.offload_tc)
+
+void qed_hw_info_set_offload_tc(struct qed_hw_info *p_info, u8 tc)
+{
+ p_info->offload_tc = tc;
+ p_info->offload_tc_set = true;
+}
+
+static bool qed_is_offload_tc_set(struct qed_hwfn *p_hwfn)
+{
+ return p_hwfn->hw_info.offload_tc_set;
+}
+
+static u32 qed_get_offload_tc(struct qed_hwfn *p_hwfn)
+{
+ if (qed_is_offload_tc_set(p_hwfn))
+ return p_hwfn->hw_info.offload_tc;
+
+ return PQ_INIT_DEFAULT_TC;
+}
static void qed_init_qm_pq(struct qed_hwfn *p_hwfn,
struct qed_qm_info *qm_info,
@@ -538,7 +556,8 @@ static void qed_init_qm_pure_ack_pq(struct qed_hwfn *p_hwfn)
return;
qed_init_qm_set_idx(p_hwfn, PQ_FLAGS_ACK, qm_info->num_pqs);
- qed_init_qm_pq(p_hwfn, qm_info, PQ_INIT_OFLD_TC, PQ_INIT_SHARE_VPORT);
+ qed_init_qm_pq(p_hwfn, qm_info, qed_get_offload_tc(p_hwfn),
+ PQ_INIT_SHARE_VPORT);
}
static void qed_init_qm_offload_pq(struct qed_hwfn *p_hwfn)
@@ -549,7 +568,8 @@ static void qed_init_qm_offload_pq(struct qed_hwfn *p_hwfn)
return;
qed_init_qm_set_idx(p_hwfn, PQ_FLAGS_OFLD, qm_info->num_pqs);
- qed_init_qm_pq(p_hwfn, qm_info, PQ_INIT_OFLD_TC, PQ_INIT_SHARE_VPORT);
+ qed_init_qm_pq(p_hwfn, qm_info, qed_get_offload_tc(p_hwfn),
+ PQ_INIT_SHARE_VPORT);
}
static void qed_init_qm_low_latency_pq(struct qed_hwfn *p_hwfn)
@@ -560,7 +580,8 @@ static void qed_init_qm_low_latency_pq(struct qed_hwfn *p_hwfn)
return;
qed_init_qm_set_idx(p_hwfn, PQ_FLAGS_LLT, qm_info->num_pqs);
- qed_init_qm_pq(p_hwfn, qm_info, PQ_INIT_OFLD_TC, PQ_INIT_SHARE_VPORT);
+ qed_init_qm_pq(p_hwfn, qm_info, qed_get_offload_tc(p_hwfn),
+ PQ_INIT_SHARE_VPORT);
}
static void qed_init_qm_mcos_pqs(struct qed_hwfn *p_hwfn)
@@ -601,7 +622,8 @@ static void qed_init_qm_rl_pqs(struct qed_hwfn *p_hwfn)
qed_init_qm_set_idx(p_hwfn, PQ_FLAGS_RLS, qm_info->num_pqs);
for (pf_rls_idx = 0; pf_rls_idx < num_pf_rls; pf_rls_idx++)
- qed_init_qm_pq(p_hwfn, qm_info, PQ_INIT_OFLD_TC, PQ_INIT_PF_RL);
+ qed_init_qm_pq(p_hwfn, qm_info, qed_get_offload_tc(p_hwfn),
+ PQ_INIT_PF_RL);
}
static void qed_init_qm_pq_params(struct qed_hwfn *p_hwfn)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_mcp.c b/drivers/net/ethernet/qlogic/qed/qed_mcp.c
index 96a67ef..8956d7f 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_mcp.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_mcp.c
@@ -1551,7 +1551,8 @@ void qed_mcp_read_ufp_config(struct qed_hwfn *p_hwfn, struct qed_ptt *p_ptt)
if (p_hwfn->ufp_info.mode == QED_UFP_MODE_VNIC_BW) {
p_hwfn->qm_info.ooo_tc = p_hwfn->ufp_info.tc;
- p_hwfn->hw_info.offload_tc = p_hwfn->ufp_info.tc;
+ qed_hw_info_set_offload_tc(&p_hwfn->hw_info,
+ p_hwfn->ufp_info.tc);
qed_qm_reconf(p_hwfn, p_ptt);
} else if (p_hwfn->ufp_info.mode == QED_UFP_MODE_ETS) {
--
1.8.3.1
^ permalink raw reply related
* [PATCH net-next 1/3] qed: Add DCBX API - qed_dcbx_get_priority_tc()
From: Denis Bolotin @ 2018-07-31 7:26 UTC (permalink / raw)
To: davem, netdev; +Cc: Denis Bolotin, Ariel Elior
In-Reply-To: <20180731072608.2976-1-denis.bolotin@cavium.com>
The API receives a priority and looks for the TC it is mapped to in the
operational DCBX configuration.
Signed-off-by: Denis Bolotin <denis.bolotin@cavium.com>
Signed-off-by: Ariel Elior <ariel.elior@cavium.com>
---
drivers/net/ethernet/qlogic/qed/qed_dcbx.c | 27 +++++++++++++++++++++++++++
drivers/net/ethernet/qlogic/qed/qed_dcbx.h | 2 ++
2 files changed, 29 insertions(+)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_dcbx.c b/drivers/net/ethernet/qlogic/qed/qed_dcbx.c
index 12b4c2a..00891cc 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_dcbx.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_dcbx.c
@@ -1277,6 +1277,33 @@ int qed_dcbx_get_config_params(struct qed_hwfn *p_hwfn,
return 0;
}
+int qed_dcbx_get_priority_tc(struct qed_hwfn *p_hwfn, u8 pri, u8 *p_tc)
+{
+ struct qed_dcbx_get *dcbx_info;
+ int rc;
+
+ if (pri >= QED_MAX_PFC_PRIORITIES) {
+ DP_ERR(p_hwfn, "Invalid priority %d\n", pri);
+ return -EINVAL;
+ }
+
+ dcbx_info = kzalloc(sizeof(*dcbx_info), GFP_KERNEL);
+ if (!dcbx_info)
+ return -ENOMEM;
+
+ rc = qed_dcbx_query_params(p_hwfn, dcbx_info,
+ QED_DCBX_OPERATIONAL_MIB);
+ if (rc) {
+ kfree(dcbx_info);
+ return rc;
+ }
+
+ *p_tc = dcbx_info->operational.params.ets_pri_tc_tbl[pri];
+ kfree(dcbx_info);
+
+ return 0;
+}
+
static struct qed_dcbx_get *qed_dcbnl_get_dcbx(struct qed_hwfn *hwfn,
enum qed_mib_read_type type)
{
diff --git a/drivers/net/ethernet/qlogic/qed/qed_dcbx.h b/drivers/net/ethernet/qlogic/qed/qed_dcbx.h
index 5feb90e..9425d55 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_dcbx.h
+++ b/drivers/net/ethernet/qlogic/qed/qed_dcbx.h
@@ -111,6 +111,8 @@ struct qed_dcbx_mib_meta_data {
int qed_dcbx_config_params(struct qed_hwfn *,
struct qed_ptt *, struct qed_dcbx_set *, bool);
+
+int qed_dcbx_get_priority_tc(struct qed_hwfn *p_hwfn, u8 pri, u8 *p_tc);
#endif
/* QED local interface routines */
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH] rt2x00: remove redundant functions rt2x00mac_sta_{add/remove}
From: Kalle Valo @ 2018-07-31 7:28 UTC (permalink / raw)
To: YueHaibing
Cc: davem, sgruszka, helmut.schaa, linux-kernel, netdev,
linux-wireless, YueHaibing
In-Reply-To: <20180727130549.12980-1-yuehaibing@huawei.com>
YueHaibing <yuehaibing@huawei.com> wrote:
> Only rt2800 subdriver of rt2x00 implement sta_add() and sta_remove(),
> rt2x00mac_sta_add and rt2x00mac_sta_remove has no callers after
> commit 9c87758cf089 ("rt2x00: call sta_add/remove directly in rt2800").
> So can be removed.
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
> Acked-by: Stanislaw Gruszka <sgruszka@redhat.com>
Patch applied to wireless-drivers-next.git, thanks.
24ebfcbdd1ba rt2x00: remove redundant functions rt2x00mac_sta_{add/remove}
--
https://patchwork.kernel.org/patch/10547141/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH bpf-next] lwt_bpf: remove unnecessary rcu_read_lock in run_lwt_bpf
From: Daniel Borkmann @ 2018-07-31 7:27 UTC (permalink / raw)
To: Taehee Yoo, ast; +Cc: netdev
In-Reply-To: <20180730132259.6338-1-ap420073@gmail.com>
On 07/30/2018 03:22 PM, Taehee Yoo wrote:
> run_lwt_bpf is called by bpf_{input/output/xmit}.
> These functions are already protected by rcu_read_lock.
> because lwtunnel_{input/output/xmit} holds rcu_read_lock
> and then calls bpf_{input/output/xmit}.
> So that rcu_read_lock in the run_lwt_bpf is unnecessary.
>
> Signed-off-by: Taehee Yoo <ap420073@gmail.com>
Applied to bpf-next, thanks Taehee!
^ permalink raw reply
* [PATCH net-next 0/3] Add Multi-TC RoCE support
From: Denis Bolotin @ 2018-07-31 7:26 UTC (permalink / raw)
To: davem, netdev; +Cc: Denis Bolotin
Hi Dave,
This patch series adds support for multiple concurrent traffic classes for RoCE.
The first three patches enable the required parts of the driver to learn the TC
configuration, and the last one makes use of it to enable the feature.
Please consider applying this to net-next.
(Re-sending to netdev@vger.kernel.org after sending to wrong address)
Denis Bolotin (3):
qed: Add DCBX API - qed_dcbx_get_priority_tc()
qed: Add a flag which indicates if offload TC is set
qed: Add Multi-TC RoCE support
drivers/net/ethernet/qlogic/qed/qed.h | 13 ++-
drivers/net/ethernet/qlogic/qed/qed_dcbx.c | 29 ++++++-
drivers/net/ethernet/qlogic/qed/qed_dcbx.h | 2 +
drivers/net/ethernet/qlogic/qed/qed_dev.c | 128 +++++++++++++++++++++++++----
drivers/net/ethernet/qlogic/qed/qed_mcp.c | 3 +-
drivers/net/ethernet/qlogic/qed/qed_roce.c | 61 ++++++++++----
6 files changed, 201 insertions(+), 35 deletions(-)
--
1.8.3.1
^ permalink raw reply
* Re: [PATCH bpf-next v3] bpf: add End.DT6 action to bpf_lwt_seg6_action helper
From: Daniel Borkmann @ 2018-07-31 7:25 UTC (permalink / raw)
To: Mathieu Xhonneux, netdev; +Cc: alexei.starovoitov
In-Reply-To: <20180726021040.28240-1-m.xhonneux@gmail.com>
On 07/26/2018 04:10 AM, Mathieu Xhonneux wrote:
> The seg6local LWT provides the End.DT6 action, which allows to
> decapsulate an outer IPv6 header containing a Segment Routing Header
> (SRH), full specification is available here:
>
> https://tools.ietf.org/html/draft-filsfils-spring-srv6-network-programming-05
>
> This patch adds this action now to the seg6local BPF
> interface. Since it is not mandatory that the inner IPv6 header also
> contains a SRH, seg6_bpf_srh_state has been extended with a pointer to
> a possible SRH of the outermost IPv6 header. This helps assessing if the
> validation must be triggered or not, and avoids some calls to
> ipv6_find_hdr.
>
> v3: s/1/true, s/0/false for boolean values
> v2: - changed true/false -> 1/0
> - preempt_enable no longer called in first conditional block
>
> Signed-off-by: Mathieu Xhonneux <m.xhonneux@gmail.com>
Applied to bpf-next, thanks Mathieu!
^ permalink raw reply
* Re: [PATCH 03/10] atmel: hide unused procfs helpers
From: Kalle Valo @ 2018-07-31 7:21 UTC (permalink / raw)
To: YueHaibing; +Cc: simon, linux-kernel, netdev, linux-wireless, davem, YueHaibing
In-Reply-To: <20180713064658.10340-1-yuehaibing@huawei.com>
YueHaibing <yuehaibing@huawei.com> wrote:
> When CONFIG_PROC_FS isn't set, gcc warning this:
>
> drivers/net/wireless/atmel/atmel.c:1402:12: warning: ‘atmel_proc_show’ defined but not used [-Wunused-function]
> static int atmel_proc_show(struct seq_file *m, void *v)
> ^
> fix this by adding #ifdef around it.
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Patch applied to wireless-drivers-next.git, thanks.
8b8f3278d241 atmel: hide unused procfs helpers
--
https://patchwork.kernel.org/patch/10522647/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [RFC bpf-next 0/6] net: xsk: minor improvements around queue handling
From: Björn Töpel @ 2018-07-31 7:15 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Alexei Starovoitov, Daniel Borkmann, Jesper Dangaard Brouer,
Björn Töpel, Karlsson, Magnus, oss-drivers, Netdev,
Ilias Apalodimas, Francois Ozog, MykytaI Iziumtsev
In-Reply-To: <20180730194904.08b13423@cakuba.netronome.com>
Den tis 31 juli 2018 kl 04:49 skrev Jakub Kicinski
<jakub.kicinski@netronome.com>:
>
> On Mon, 30 Jul 2018 14:49:32 +0200, Björn Töpel wrote:
> > Den tors 26 juli 2018 kl 23:44 skrev Jakub Kicinski:
> > >
> > > Hi!
> >
> > Thanks for spending your time on this, Jakub. I'm (temporarily) back
> > for a week, so you can expect faster replies now...
> >
> > > This set tries to make the core take care of error checking for the
> > > drivers. In particular making sure that the AF_XDP UMEM is not installed
> > > on queues which don't exist (or are disabled) and that changing queue
> > > (AKA ethtool channel) count cannot disable queues with active AF_XDF
> > > zero-copy sockets.
> > >
> > > I'm sending as an RFC because I'm not entirely sure what the desired
> > > behaviour is here. Is it Okay to install AF_XDP on queues which don't
> > > exist? I presume not?
> >
> > Your presumption is correct. The idea with the
> > real_num_rx_queues/real_num_tx_queues check in xsk_bind, is to bail
> > out if the queue doesn't exist at bind call. Note that we *didn't* add
> > any code to avoid the bound queue from being removed via set channel
> > (your patch 6). Our idea was that if you remove a queue, the ingress
> > frames would simply stop flowing, and the queue config change checking
> > was "out-of-band".
> >
> > I think I prefer your approach, i.e. not allowing the channels/queues
> > to change if they're bound to an AF_XDP socket. However, your
> > xdp_umem_query used in ethtool only works for ZC enabled drivers, not
> > for the existing non-ZC/copy case. If we'd like to go the route of
> > disabling ethtool_set_channels for an AF_XDP enabled queue this
> > functionality needs to move the query into netdev core, so we have a
> > consistent behavior.
>
> Agreed. There seems to be no notification for changing the number of
> queues and therefore no very clean way to solve this today.
I'm probably lacking some history here; Has there been any past
efforts in making channels/queues a "kernel object"? Would it make
sense to add notifications for queue changes analogous to netdev
changes?
> The last
> two patches are more of a courtesy to the drivers, to simplify the
> data structure for holding the UMEMs.
>
> I could argue that driver and stack are not really apples to apples.
> Much like Generic XDP, the skb-based AF_XDP is basically a development
> tool and last-resort fallback.
Hmm... I partially agree. Let me think about it a bit more.
> For TX driver will most likely allocate
> separate queues, while skb-based will use the stack's queues. These
> are actually different queues. Stack will also fallback to other queue
> in __netdev_pick_tx() if number of queues changes.
>
Yup, ideally the driver will use a dedicated queue. We had some
thoughts on hijacking the skb Tx queue, and route the stack egress
packets elsewhere, but it ended up way too messy.
> But yes, preferably skb-based and ZC should behave the same..
>
> > > Are the AF_XDP queue_ids referring to TX queues
> > > as well as RX queues in case of the driver? I presume not?
> >
> > We've had a lot of discussions about this internally. Ideally, we'd
> > like to give driver implementors the most freedom, and not enforcing a
> > certain queue scheme for Tx.
>
> You say freedom I hear diverging implementations and per-driver
> checks in user space ;-)
>
Yeah. :-) Well, for the i40e ZC implementation, the Tx queue id was
not equal to Rx queue id, so to answer your question: "Correct, the
queue id refer to Rx."
> Practically speaking unless you take the xmit lock there is little
> chance of reusing stack's TX queues, so you'd have to allocate a
> separate queue one way or the other.. At which point the number of
> stack's TX queues has no bearing on AF_XDP ZC.
>
Yup, you're right.
> > OTOH it makes it weird for the userland
> > application *not* to have the same id, e.g. if a userland application
> > would like to get stats or configure the AF_XDP bound Tx queue --
> > which id is it? Should the Tx queue id for an xsk be exposed in
> > sysfs?
>
> I'd not go there.
>
Honestly, me neither. I need to think more about to expose the Tx
queue pulls/knobs for a control plane.
> > If the id is *not* the same, would it be OK to change the number of
> > channels and Tx would continue to operate correctly? A related
> > question; An xsk with *only* Tx, should it be constrained by the
> > number of (enabled) Rx queues?
>
> Good question, are drivers even supposed to care about tx-only/rx-only?
> From driver's perspective rx-only socket will simply never have
> anything to transmit, and tx-only socket will never successfully
> xdp_do_redirect(). So IMHO - yes, tx-only XSK still only cares about
> RX queues, driver doesn't know no RX will ever happen. The fact that
> user has to populate the FILL queue on a tx-only socket may be counter
> intuitive to many...
>
Not allowing tx-only/rx-only definitely makes it easier. Many NICs,
however, have non-symmetrical # of Tx/Rx queues. Scenarios where one
would have #txq >> #rxq would then be hard to support. Again this
could be worked around with virtual netdevs, so maybe it makes sense
to keep the socket layer simple.
> I was considering proposing a change to drop the *x-only option in the
> net tree, I don't really see much use for it :S And it potentially
> creates weird corner cases.
>
> > I'd be happy to hear some more opinions/thoughts on this...
>
> +1
>
> > > Should we try to prevent disabling queues which have non zero-copy
> > > sockets installed as well? :S
> > >
> >
> > Yes, the ZC/non-ZC case must be consistent IMO. See comment above.
> >
> > > Anyway, if any of those patches seem useful and reasonable, please
> > > let me know I will repost as non-RFC.
> > >
> >
> > I definitely think patch 2 and 3 (and probably 1) should go as
> > non-RFC!
>
> Thanks Björn, I will submit the first three!
>
Thanks! I've already taken them for a spin and acked them!
Björn
> > Thanks for spotting that we're not holding the rtnl lock when checking
> > the # queues (patch 4)!
> >
> > Björn
^ permalink raw reply
* Re: Issue with driver i40e stat strings count mismatch
From: Stefan Assmann @ 2018-07-31 7:05 UTC (permalink / raw)
To: Jesper Dangaard Brouer, Jeff Kirsher
Cc: Björn Töpel, alexander.h.duyck@intel.com,
intel-wired-lan, netdev@vger.kernel.org
In-Reply-To: <20180710131721.657e55a5@redhat.com>
On 10.07.2018 13:17, Jesper Dangaard Brouer wrote:
> Hi Intel-fokes,
>
> Your i40e driver have issues with it's ethtool stats. A warning
> triggers at drivers/net/ethernet/intel/i40e/i40e_ethtool.c line 1907
> (see splash below) in func i40e_get_stat_strings().
Hi Jesper,
I ran into the same issue. Here's my proposed fix.
>From 46c74c25496bab06712641c7b2b6b34e365397a2 Mon Sep 17 00:00:00 2001
From: Stefan Assmann <sassmann@kpanic.de>
Date: Mon, 30 Jul 2018 21:38:43 +0200
Subject: [PATCH] i40e: fix i40e_get_stat_strings strings count warning
The current code calculates p - data, which results in a negative value.
Therefore the WARN_ONCE condition will always be true.
Fix this by calculating data - p instead.
Fixes: 9b10df596bd4 ("i40e: use WARN_ONCE to replace the commented BUG_ON size check")
Signed-off-by: Stefan Assmann <sassmann@kpanic.de>
---
drivers/net/ethernet/intel/i40e/i40e_ethtool.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_ethtool.c b/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
index 6947a2a571cb..5d670f4ce5ac 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
@@ -1903,7 +1903,7 @@ static void i40e_get_stat_strings(struct net_device *netdev, u8 *data)
data += ETH_GSTRING_LEN;
}
- WARN_ONCE(p - data != i40e_get_stats_count(netdev) * ETH_GSTRING_LEN,
+ WARN_ONCE(data - p != i40e_get_stats_count(netdev) * ETH_GSTRING_LEN,
"stat strings count mismatch!");
}
--
2.17.1
>
> [ 5077.779518] ------------[ cut here ]------------
> [ 5077.784493] stat strings count mismatch!
> [ 5077.784529] WARNING: CPU: 0 PID: 2293 at drivers/net/ethernet/intel/i40e/i40e_ethtool.c:1907 i40e_get_strings+0x477/0x4b0 [i40e]
> [ 5077.800941] Modules linked in: act_gact cls_u32 sch_ingress xt_tcpudp iptable_raw ip_tables x_tables tun nfnetlink bridge stp llc bpfilter sunrpc coretemp kvm_intel kvm irqbypass intel_cstate intel_uncore intel_rapl_perf pcspkr i2c_i801 wmi ipmi_si ipmi_devintf ipmi_msghandler acpi_pad sch_fq_codel ixgbe mlx5_core mlxfw i40e devlink hid_generic igb mdio i2c_algo_bit ptp sd_mod i2c_core pps_core [last unloaded: x_tables]
> [ 5077.839833] CPU: 0 PID: 2293 Comm: ethtool Not tainted 4.18.0-rc3-net-next-EdwardCree01+ #484
> [ 5077.848962] Hardware name: Supermicro Super Server/X10SRi-F, BIOS 2.0a 08/01/2016
> [ 5077.857049] RIP: 0010:i40e_get_strings+0x477/0x4b0 [i40e]
> [ 5077.862776] Code: 98 49 39 c4 0f 84 2e fc ff ff 80 3d b3 da 03 00 00 0f 85 21 fc ff ff 48 c7 c7 24 42 19 a0 c6 05 9f da 03 00 01 e8 e9 9c ee e0 <0f> 0b e9 07 fc ff ff 48 83 c4 10 48 c7 c1 80 01 19 a0 be 20 00 00
> [ 5077.882506] RSP: 0018:ffffc90003af3c18 EFLAGS: 00010296
> [ 5077.888063] RAX: 000000000000001c RBX: ffffc90003ce1440 RCX: 0000000000000006
> [ 5077.895528] RDX: 0000000000000007 RSI: 0000000000000096 RDI: ffff88087ca15530
> [ 5077.902991] RBP: ffffc90003ce1440 R08: 000000000000001c R09: 0000000000000411
> [ 5077.910453] R10: 000fffffffe00000 R11: ffffffff82a4e66d R12: ffffffffffffcbc0
> [ 5077.917913] R13: ffff88087c50f000 R14: 0000000000000008 R15: ffffffffa0199620
> [ 5077.925376] FS: 00007f7a84bcb740(0000) GS:ffff88087ca00000(0000) knlGS:0000000000000000
> [ 5077.934061] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 5077.940133] CR2: 000055c7d709b000 CR3: 000000081acd0004 CR4: 00000000003606f0
> [ 5077.947609] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [ 5077.955070] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> [ 5077.962531] Call Trace:
> [ 5077.965309] dev_ethtool+0xf4e/0x2430
> [ 5077.969305] ? get_page_from_freelist+0x2bb/0x1240
> [ 5077.974428] ? dev_ioctl+0x1e9/0x3c0
> [ 5077.978332] dev_ioctl+0x1e9/0x3c0
> [ 5077.982062] sock_do_ioctl+0xa8/0x140
> [ 5077.986057] ? sock_ioctl+0x1c0/0x300
> [ 5077.990051] sock_ioctl+0x1c0/0x300
> [ 5077.993864] ? __handle_mm_fault+0xa82/0xfd0
> [ 5077.998462] ? do_vfs_ioctl+0x8d/0x5e0
> [ 5078.002550] do_vfs_ioctl+0x8d/0x5e0
> [ 5078.006456] ? handle_mm_fault+0xd0/0x210
> [ 5078.010790] ksys_ioctl+0x70/0x80
> [ 5078.014429] __x64_sys_ioctl+0x16/0x20
> [ 5078.018505] do_syscall_64+0x42/0xf0
> [ 5078.022411] entry_SYSCALL_64_after_hwframe+0x44/0xa9
> [ 5078.027789] RIP: 0033:0x7f7a84394dc7
> [ 5078.031703] Code: b3 66 90 48 8b 05 d9 00 2d 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d a9 00 2d 00 f7 d8 64 89 01 48
> [ 5078.051437] RSP: 002b:00007ffd64d68338 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
> [ 5078.059596] RAX: ffffffffffffffda RBX: 000055c7d7099260 RCX: 00007f7a84394dc7
> [ 5078.067062] RDX: 00007ffd64d684e0 RSI: 0000000000008946 RDI: 0000000000000003
> [ 5078.074524] RBP: 00007ffd64d684d0 R08: ffffffffffffffb0 R09: 000055c7d7099260
> [ 5078.081986] R10: 0000000000000000 R11: 0000000000000246 R12: 00000000000001a2
> [ 5078.089447] R13: 0000000000000001 R14: 0000000000000000 R15: 00007ffd64d684e0
> [ 5078.096911] ---[ end trace faf82a00c0d8b6b1 ]---
>
> $ gdb ./drivers/net/ethernet/intel/i40e/i40e.ko
> [...]
> Reading symbols from ./drivers/net/ethernet/intel/i40e/i40e.ko...done.
> (gdb) list *(i40e_get_strings)+0x477
> 0x17787 is in i40e_get_strings (drivers/net/ethernet/intel/i40e/i40e_ethtool.c:1906).
> 1901 snprintf(data, ETH_GSTRING_LEN,
> 1902 "port.rx_priority_%u_xon_2_xoff", i);
> 1903 data += ETH_GSTRING_LEN;
> 1904 }
> 1905
> 1906 WARN_ONCE(p - data != i40e_get_stats_count(netdev) * ETH_GSTRING_LEN,
> 1907 "stat strings count mismatch!");
> 1908 }
> 1909
> 1910 static void i40e_get_priv_flag_strings(struct net_device *netdev, u8 *data)
>
^ permalink raw reply related
* Re: [PATCH] net/wireless/atmel: fix defined but not used warning
From: Kalle Valo @ 2018-07-31 7:05 UTC (permalink / raw)
To: Randy Dunlap
Cc: Simon Kelley, linux-wireless, David Miller,
netdev@vger.kernel.org
In-Reply-To: <d6ed90e1-c41e-d5b6-c892-ea5e1e6ad7e6@infradead.org>
Randy Dunlap <rdunlap@infradead.org> wrote:
> From: Randy Dunlap <rdunlap@infradead.org>
>
> Fix a build warning in drivers/net/wireless/atmel/ when CONFIG_PROC_FS
> is not enabled by marking the unused function as __maybe_unused.
>
> ../drivers/net/wireless/atmel/atmel.c:1402:12: warning: 'atmel_proc_show' defined but not used [-Wunused-function]
>
> Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
> Cc: Simon Kelley <simon@thekelleys.org.uk>
> Cc: linux-wireless@vger.kernel.org
> Cc: Kalle Valo <kvalo@codeaurora.org>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: netdev@vger.kernel.org
I'll drop this as I take Yue's version instead.
Patch set to Changes Requested.
--
https://patchwork.kernel.org/patch/10512913/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH v3] Add BPF_SYNCHRONIZE_MAP_TO_MAP_REFERENCES bpf(2) command
From: Daniel Borkmann @ 2018-07-31 8:34 UTC (permalink / raw)
To: Daniel Colascione, Jakub Kicinski
Cc: Joel Fernandes, linux-kernel, Tim Murray, netdev,
Alexei Starovoitov, Lorenzo Colitti, Chenbo Feng,
Mathieu Desnoyers, Alexei Starovoitov
In-Reply-To: <CAKOZuesNnY8oKimMk+gnUppMgZt92F+razSZCSfHu=xfq+snGg@mail.gmail.com>
On 07/31/2018 02:33 AM, Daniel Colascione wrote:
> On Mon, Jul 30, 2018 at 5:26 PM, Jakub Kicinski
> <jakub.kicinski@netronome.com> wrote:
>> On Mon, 30 Jul 2018 03:25:43 -0700, Daniel Colascione wrote:
>>> On Mon, Jul 30, 2018 at 3:04 AM, Daniel Borkmann <daniel@iogearbox.net> wrote:
>>>> Hmm, I don't think such UAPI as above is future-proof. In case we would want
>>>> a similar mechanism in future for other maps, we would need a whole new bpf
>>>> command or reuse BPF_SYNCHRONIZE_MAP_TO_MAP_REFERENCES as a workaround though
>>>> the underlying map may not even be a map-to-map. Additionally, we don't have
>>>> any map object at hand in the above, so we couldn't make any finer grained
>>>> decisions either. Something like below would be more suitable and leaves room
>>>> for extending this further in future.
>>>
>>> YAGNI. Your proposed mechanism doesn't add anything under the current
>>> implementation.
>>
>> FWIW in case of HW offload targeting a particular map may allow users
>> to avoid a potentially slow sync with all the devices on the system.
>
> Sure. But such a thing doesn't exist right now (right?), and we can
> add that more-efficient-in-that-one-case BPF interface when it lands.
> I'd rather keep things simple for now.
I don't see a reason why that is even more complicated. An API command name
such as BPF_SYNCHRONIZE_MAP_TO_MAP_REFERENCES is simply non-generic, and
exposes specific map details (here: map-in-map) into the UAPI whereas it
should reside within a specific implementation instead similar to other ops
we have for maps. If in future other maps would be added that would have
similar mechanisms of inner objects they return to the BPF program, we'll
be adding yet another command just for this. Also, union bpf_attr is extensible,
e.g. additional members could be added in future whenever needed for this
subcommand instead of forcing it to NULL as done here. E.g. having a high-level
one like bpf(BPF_MAP_WAIT, { .map_fd = fd }) could later on also cover the
use-case from Jakub by adding an 'event' member into union bpf_attr where we
could add other map specific wakeups for user space while the current default
of 0 would be BPF_MAP_WAIT_PENDING_REFS (or the like). All I'm saying is to
keep it generic so it can be extended later.
^ permalink raw reply
* KASAN: use-after-free Read in refcount_sub_and_test
From: syzbot @ 2018-07-31 8:22 UTC (permalink / raw)
To: davem, kuznet, linux-kernel, netdev, syzkaller-bugs, yoshfuji
Hello,
syzbot found the following crash on:
HEAD commit: 61f4b23769f0 netlink: Don't shift with UB on nlk->ngroups
git tree: net
console output: https://syzkaller.appspot.com/x/log.txt?x=16ed5cf0400000
kernel config: https://syzkaller.appspot.com/x/.config?x=ffb4428fdc82f93b
dashboard link: https://syzkaller.appspot.com/bug?extid=8c17db54fd0c0a2ee849
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
Unfortunately, I don't have any reproducer for this crash yet.
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+8c17db54fd0c0a2ee849@syzkaller.appspotmail.com
device lo left promiscuous mode
==================================================================
BUG: KASAN: use-after-free in atomic_read
include/asm-generic/atomic-instrumented.h:21 [inline]
BUG: KASAN: use-after-free in refcount_sub_and_test+0x9a/0x350
lib/refcount.c:179
Read of size 4 at addr ffff8801d96d2844 by task syz-executor1/4479
CPU: 0 PID: 4479 Comm: syz-executor1 Not tainted 4.18.0-rc6+ #34
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1c9/0x2b4 lib/dump_stack.c:113
print_address_description+0x6c/0x20b mm/kasan/report.c:256
kasan_report_error mm/kasan/report.c:354 [inline]
kasan_report.cold.7+0x242/0x2fe mm/kasan/report.c:412
check_memory_region_inline mm/kasan/kasan.c:260 [inline]
check_memory_region+0x13e/0x1b0 mm/kasan/kasan.c:267
kasan_check_read+0x11/0x20 mm/kasan/kasan.c:272
atomic_read include/asm-generic/atomic-instrumented.h:21 [inline]
refcount_sub_and_test+0x9a/0x350 lib/refcount.c:179
refcount_dec_and_test+0x1a/0x20 lib/refcount.c:212
fib6_metrics_release+0x4f/0x90 net/ipv6/ip6_fib.c:178
fib6_drop_pcpu_from net/ipv6/ip6_fib.c:899 [inline]
fib6_purge_rt+0x5ec/0x7f0 net/ipv6/ip6_fib.c:934
fib6_del_route net/ipv6/ip6_fib.c:1784 [inline]
fib6_del+0xc11/0x1310 net/ipv6/ip6_fib.c:1815
fib6_clean_node+0x3ee/0x5e0 net/ipv6/ip6_fib.c:1976
fib6_walk_continue+0x4b1/0x8e0 net/ipv6/ip6_fib.c:1899
fib6_walk+0x95/0xf0 net/ipv6/ip6_fib.c:1947
fib6_clean_tree+0x1ea/0x360 net/ipv6/ip6_fib.c:2024
__fib6_clean_all+0x21c/0x420 net/ipv6/ip6_fib.c:2040
fib6_clean_all+0x27/0x30 net/ipv6/ip6_fib.c:2051
rt6_sync_down_dev net/ipv6/route.c:4083 [inline]
rt6_disable_ip+0x111/0x7e0 net/ipv6/route.c:4088
addrconf_ifdown+0x16f/0x1670 net/ipv6/addrconf.c:3650
addrconf_notify+0x6e9/0x27f0 net/ipv6/addrconf.c:3575
notifier_call_chain+0x180/0x390 kernel/notifier.c:93
__raw_notifier_call_chain kernel/notifier.c:394 [inline]
raw_notifier_call_chain+0x2d/0x40 kernel/notifier.c:401
call_netdevice_notifiers_info+0x3f/0x90 net/core/dev.c:1735
call_netdevice_notifiers net/core/dev.c:1753 [inline]
dev_close_many+0x447/0x8d0 net/core/dev.c:1505
rollback_registered_many+0x52b/0xef0 net/core/dev.c:7452
rollback_registered+0x1e9/0x420 net/core/dev.c:7517
unregister_netdevice_queue+0x32f/0x660 net/core/dev.c:8561
unregister_netdevice include/linux/netdevice.h:2548 [inline]
__tun_detach+0x11d1/0x15e0 drivers/net/tun.c:727
tun_detach drivers/net/tun.c:744 [inline]
tun_chr_close+0xe3/0x180 drivers/net/tun.c:3271
__fput+0x355/0x8b0 fs/file_table.c:209
____fput+0x15/0x20 fs/file_table.c:243
task_work_run+0x1ec/0x2a0 kernel/task_work.c:113
exit_task_work include/linux/task_work.h:22 [inline]
do_exit+0x1b08/0x2750 kernel/exit.c:865
do_group_exit+0x177/0x440 kernel/exit.c:968
__do_sys_exit_group kernel/exit.c:979 [inline]
__se_sys_exit_group kernel/exit.c:977 [inline]
__x64_sys_exit_group+0x3e/0x50 kernel/exit.c:977
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x456a09
Code: Bad RIP value.
RSP: 002b:00007fffa8ff4908 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7
RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 0000000000456a09
RDX: 00000000004104e0 RSI: 0000000000a44bd0 RDI: 0000000000000045
RBP: 00000000004c1904 R08: 000000000000000b R09: 0000000000000000
R10: 0000000001445940 R11: 0000000000000246 R12: 0000000001446940
R13: 0000000000000000 R14: 000000000000057e R15: badc0ffeebadface
Allocated by task 28651:
save_stack+0x43/0xd0 mm/kasan/kasan.c:448
set_track mm/kasan/kasan.c:460 [inline]
kasan_kmalloc+0xc4/0xe0 mm/kasan/kasan.c:553
kmem_cache_alloc_trace+0x152/0x780 mm/slab.c:3620
kmalloc include/linux/slab.h:513 [inline]
kzalloc include/linux/slab.h:707 [inline]
fib6_metric_set+0x163/0x2c0 net/ipv6/ip6_fib.c:645
fib6_add_rt2node+0xe36/0x27f0 net/ipv6/ip6_fib.c:1000
fib6_add+0xaae/0x14d0 net/ipv6/ip6_fib.c:1308
__ip6_ins_rt+0x54/0x80 net/ipv6/route.c:1163
ip6_route_add+0x6d/0xc0 net/ipv6/route.c:3171
addrconf_prefix_route.isra.48+0x51d/0x720 net/ipv6/addrconf.c:2347
inet6_addr_modify net/ipv6/addrconf.c:4627 [inline]
inet6_rtm_newaddr+0x112e/0x1b50 net/ipv6/addrconf.c:4743
rtnetlink_rcv_msg+0x46e/0xc30 net/core/rtnetlink.c:4665
netlink_rcv_skb+0x172/0x440 net/netlink/af_netlink.c:2453
rtnetlink_rcv+0x1c/0x20 net/core/rtnetlink.c:4683
netlink_unicast_kernel net/netlink/af_netlink.c:1315 [inline]
netlink_unicast+0x5a0/0x760 net/netlink/af_netlink.c:1341
netlink_sendmsg+0xa18/0xfd0 net/netlink/af_netlink.c:1906
sock_sendmsg_nosec net/socket.c:642 [inline]
sock_sendmsg+0xd5/0x120 net/socket.c:652
___sys_sendmsg+0x7fd/0x930 net/socket.c:2126
__sys_sendmsg+0x11d/0x290 net/socket.c:2164
__do_sys_sendmsg net/socket.c:2173 [inline]
__se_sys_sendmsg net/socket.c:2171 [inline]
__x64_sys_sendmsg+0x78/0xb0 net/socket.c:2171
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
Freed by task 4479:
save_stack+0x43/0xd0 mm/kasan/kasan.c:448
set_track mm/kasan/kasan.c:460 [inline]
__kasan_slab_free+0x11a/0x170 mm/kasan/kasan.c:521
kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528
__cache_free mm/slab.c:3498 [inline]
kfree+0xd9/0x260 mm/slab.c:3813
fib6_metrics_release+0x77/0x90 net/ipv6/ip6_fib.c:179
fib6_drop_pcpu_from net/ipv6/ip6_fib.c:899 [inline]
fib6_purge_rt+0x5ec/0x7f0 net/ipv6/ip6_fib.c:934
fib6_del_route net/ipv6/ip6_fib.c:1784 [inline]
fib6_del+0xc11/0x1310 net/ipv6/ip6_fib.c:1815
fib6_clean_node+0x3ee/0x5e0 net/ipv6/ip6_fib.c:1976
fib6_walk_continue+0x4b1/0x8e0 net/ipv6/ip6_fib.c:1899
fib6_walk+0x95/0xf0 net/ipv6/ip6_fib.c:1947
fib6_clean_tree+0x1ea/0x360 net/ipv6/ip6_fib.c:2024
__fib6_clean_all+0x21c/0x420 net/ipv6/ip6_fib.c:2040
fib6_clean_all+0x27/0x30 net/ipv6/ip6_fib.c:2051
rt6_sync_down_dev net/ipv6/route.c:4083 [inline]
rt6_disable_ip+0x111/0x7e0 net/ipv6/route.c:4088
addrconf_ifdown+0x16f/0x1670 net/ipv6/addrconf.c:3650
addrconf_notify+0x6e9/0x27f0 net/ipv6/addrconf.c:3575
notifier_call_chain+0x180/0x390 kernel/notifier.c:93
__raw_notifier_call_chain kernel/notifier.c:394 [inline]
raw_notifier_call_chain+0x2d/0x40 kernel/notifier.c:401
call_netdevice_notifiers_info+0x3f/0x90 net/core/dev.c:1735
call_netdevice_notifiers net/core/dev.c:1753 [inline]
dev_close_many+0x447/0x8d0 net/core/dev.c:1505
rollback_registered_many+0x52b/0xef0 net/core/dev.c:7452
rollback_registered+0x1e9/0x420 net/core/dev.c:7517
unregister_netdevice_queue+0x32f/0x660 net/core/dev.c:8561
unregister_netdevice include/linux/netdevice.h:2548 [inline]
__tun_detach+0x11d1/0x15e0 drivers/net/tun.c:727
tun_detach drivers/net/tun.c:744 [inline]
tun_chr_close+0xe3/0x180 drivers/net/tun.c:3271
__fput+0x355/0x8b0 fs/file_table.c:209
____fput+0x15/0x20 fs/file_table.c:243
task_work_run+0x1ec/0x2a0 kernel/task_work.c:113
exit_task_work include/linux/task_work.h:22 [inline]
do_exit+0x1b08/0x2750 kernel/exit.c:865
do_group_exit+0x177/0x440 kernel/exit.c:968
__do_sys_exit_group kernel/exit.c:979 [inline]
__se_sys_exit_group kernel/exit.c:977 [inline]
__x64_sys_exit_group+0x3e/0x50 kernel/exit.c:977
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
The buggy address belongs to the object at ffff8801d96d2800
which belongs to the cache kmalloc-96 of size 96
The buggy address is located 68 bytes inside of
96-byte region [ffff8801d96d2800, ffff8801d96d2860)
The buggy address belongs to the page:
page:ffffea000765b480 count:1 mapcount:0 mapping:ffff8801dac004c0
index:0xffff8801d96d2700
flags: 0x2fffc0000000100(slab)
raw: 02fffc0000000100 ffffea0006c46348 ffffea0006d0d288 ffff8801dac004c0
raw: ffff8801d96d2700 ffff8801d96d2000 0000000100000003 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff8801d96d2700: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
ffff8801d96d2780: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
> ffff8801d96d2800: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
^
ffff8801d96d2880: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
ffff8801d96d2900: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
==================================================================
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
syzbot.
^ 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