* Re: [PATCH v5 bpf-next 0/4] capture integers in BTF type info for map defs
From: Edward Cree @ 2019-07-09 20:27 UTC (permalink / raw)
To: Daniel Borkmann, Andrii Nakryiko, andrii.nakryiko, kernel-team,
ast, netdev, bpf
In-Reply-To: <86f8f511-655c-bf9e-8d78-f2e3f65efdb9@iogearbox.net>
On 05/07/2019 22:15, Daniel Borkmann wrote:
> On 07/05/2019 05:50 PM, Andrii Nakryiko wrote:
>> This patch set implements an update to how BTF-defined maps are specified. The
>> change is in how integer attributes, e.g., type, max_entries, map_flags, are
>> specified: now they are captured as part of map definition struct's BTF type
>> information (using array dimension), eliminating the need for compile-time
>> data initialization and keeping all the metadata in one place.
>>
>> All existing selftests that were using BTF-defined maps are updated, along
>> with some other selftests, that were switched to new syntax.
BTW is this changing the BTF format spec, and if so why isn't it accompanied by
a patch to Documentation/bpf/btf.rst? It looks like that doc still talks about
BPF_ANNOTATE_KV_PAIR, which seems to be long gone.
-Ed
^ permalink raw reply
* Re: WARNING: refcount bug in nr_insert_socket
From: syzbot @ 2019-07-09 20:22 UTC (permalink / raw)
To: davem, linux-hams, linux-kernel, netdev, ralf, syzkaller-bugs,
xiyou.wangcong
In-Reply-To: <0000000000000595ea058d411c35@google.com>
syzbot has bisected this bug to:
commit c8c8218ec5af5d2598381883acbefbf604e56b5e
Author: Cong Wang <xiyou.wangcong@gmail.com>
Date: Thu Jun 27 21:30:58 2019 +0000
netrom: fix a memory leak in nr_rx_frame()
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=1677f227a00000
start commit: 4608a726 Add linux-next specific files for 20190709
git tree: linux-next
final crash: https://syzkaller.appspot.com/x/report.txt?x=1577f227a00000
console output: https://syzkaller.appspot.com/x/log.txt?x=1177f227a00000
kernel config: https://syzkaller.appspot.com/x/.config?x=7a02e36d356a9a17
dashboard link: https://syzkaller.appspot.com/bug?extid=ec1fd464d849d91c3665
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=16b47be8600000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=15172e7ba00000
Reported-by: syzbot+ec1fd464d849d91c3665@syzkaller.appspotmail.com
Fixes: c8c8218ec5af ("netrom: fix a memory leak in nr_rx_frame()")
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
^ permalink raw reply
* Re: [PATCH] [net-next] net: dsa: vsc73xx: fix NET_DSA and OF dependencies
From: David Miller @ 2019-07-09 20:20 UTC (permalink / raw)
To: arnd
Cc: andrew, vivien.didelot, f.fainelli, paweldembicki, linus.walleij,
netdev, linux-kernel
In-Reply-To: <20190709185626.3275510-1-arnd@arndb.de>
From: Arnd Bergmann <arnd@arndb.de>
Date: Tue, 9 Jul 2019 20:55:55 +0200
> The restructuring of the driver got the dependencies wrong: without
> CONFIG_NET_DSA we get this build failure:
>
> WARNING: unmet direct dependencies detected for NET_DSA_VITESSE_VSC73XX
> Depends on [n]: NETDEVICES [=y] && HAVE_NET_DSA [=y] && OF [=y] && NET_DSA [=n]
> Selected by [m]:
> - NET_DSA_VITESSE_VSC73XX_PLATFORM [=m] && NETDEVICES [=y] && HAVE_NET_DSA [=y] && HAS_IOMEM [=y]
>
> ERROR: "dsa_unregister_switch" [drivers/net/dsa/vitesse-vsc73xx-core.ko] undefined!
> ERROR: "dsa_switch_alloc" [drivers/net/dsa/vitesse-vsc73xx-core.ko] undefined!
> ERROR: "dsa_register_switch" [drivers/net/dsa/vitesse-vsc73xx-core.ko] undefined!
>
> Add the appropriate dependencies.
>
> Fixes: 95711cd5f0b4 ("net: dsa: vsc73xx: Split vsc73xx driver")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Applied, thanks Arnd.
^ permalink raw reply
* RE: [PATCH] tipc: ensure skb->lock is initialised
From: Jon Maloy @ 2019-07-09 20:15 UTC (permalink / raw)
To: Eric Dumazet, Chris Packham, ying.xue@windriver.com,
davem@davemloft.net
Cc: netdev@vger.kernel.org, tipc-discussion@lists.sourceforge.net,
linux-kernel@vger.kernel.org
In-Reply-To: <ef9a2ec1-1413-e8f9-1193-d53cf8ee52ba@gmail.com>
> -----Original Message-----
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Sent: 9-Jul-19 09:46
> To: Jon Maloy <jon.maloy@ericsson.com>; Eric Dumazet
> <eric.dumazet@gmail.com>; Chris Packham
> <Chris.Packham@alliedtelesis.co.nz>; ying.xue@windriver.com;
> davem@davemloft.net
> Cc: netdev@vger.kernel.org; tipc-discussion@lists.sourceforge.net; linux-
> kernel@vger.kernel.org
> Subject: Re: [PATCH] tipc: ensure skb->lock is initialised
>
>
>
> On 7/9/19 3:25 PM, Jon Maloy wrote:
[...]
> > TIPC is using the list lock at message reception within the scope of
> tipc_sk_rcv()/tipc_skb_peek_port(), so it is fundamental that the lock always
> is correctly initialized.
>
> Where is the lock acquired, why was it only acquired by queue purge and not
> normal dequeues ???
It is acquired twice:
- First, in tipc_sk_rcv()->tipc_skb_peek_port(), to peek into one or more queue members and read their destination port number.
- Second, in tipc_sk_rcv()->tipc_sk_enqueue()->tipc_skb_dequeue() to unlink a list member from the queue.
> >>
> > [...]
> >>
> >> tipc_link_xmit() for example never acquires the spinlock, yet uses
> >> skb_peek() and __skb_dequeue()
> >
> >
> > You should look at tipc_node_xmit instead. Node local messages are
> > sent directly to tipc_sk_rcv(), and never go through tipc_link_xmit()
>
> tipc_node_xmit() calls tipc_link_xmit() eventually, right ?
No.
tipc_link_xmit() is called only for messages with a non-local destination. Otherwise, tipc_node_xmit() sends node local messages directly to the destination socket via tipc_sk_rcv().
The argument 'xmitq' becomes 'inputq' in tipc_sk_rcv() and 'list' in tipc_skb_peek_port(), since those functions don't distinguish between local and node external incoming messages.
>
> Please show me where the head->lock is acquired, and why it needed.
The argument 'inputq' to tipc_sk_rcv() may come from two sources:
1) As an aggregated member of each tipc_node::tipc_link_entry. This queue is needed to guarantee sequential delivery of messages from the node/link layer to the socket layer. In this case, there may be buffers for multiple destination sockets in the same queue, and we may have multiple concurrent tipc_sk_rcv() jobs working that queue. So, the lock is needed both for adding (in link.c::tipc_data_input()), peeking and removing buffers.
2) The case you have been looking at, where it is created as 'xmitq' on the stack by a local socket. Here, the lock is not strictly needed, as you have observed. But to reduce code duplication we have chosen to let the code in tipc_sk_rcv() handle both types of queues uniformly, i.e., as if they all contain buffers with potentially multiple destination sockets, worked on by multiple concurrent calls. This requires that the lock is initialized even for this type of queue. We have seen no measurable performance difference between this 'generic' reception algorithm and a tailor-made ditto for local messages only, while the amount of saved code is significant.
>
> If this is mandatory, then more fixes are needed than just initializing the lock
> for lockdep purposes.
It is not only for lockdep purposes, -it is essential. But please provide details about where you see that more fixes are needed.
BR
///jon
^ permalink raw reply
* Re: [PATCH v2 0/4] Fix hang of Armada 8040 SoC in orion-mdio
From: David Miller @ 2019-07-09 20:03 UTC (permalink / raw)
To: josua; +Cc: netdev, josua.mayer
In-Reply-To: <20190709130101.5160-1-josua@solid-run.com>
From: josua@solid-run.com
Date: Tue, 9 Jul 2019 15:00:57 +0200
> From: Josua Mayer <josua.mayer@jm0.eu>
>
> With a modular kernel as configured by Debian a hang was observed with
> the Armada 8040 SoC in the Clearfog GT and Macchiatobin boards.
>
> The 8040 SoC actually requires four clocks to be enabled for the mdio
> interface to function. All 4 clocks are already specified in
> armada-cp110.dtsi. It has however been missed that the orion-mdio driver
> only supports enabling up to three clocks.
>
> This patch-set allows the orion-mdio driver to handle four clocks and
> adds a warning when more clocks are specified to prevent this particular
> oversight in the future.
>
> Changes since v1:
> - fixed condition for priting the warning (Andrew Lunn)
> - rephrased commit description for deferred probing (Andrew Lunn)
> - fixed compiler warnings (kbuild test robot)
Series applied, thanks Josua.
^ permalink raw reply
* Re: [PATCH bpf-next v3] virtio_net: add XDP meta data support
From: Daniel Borkmann @ 2019-07-09 20:03 UTC (permalink / raw)
To: Jason Wang, Yuya Kusakabe
Cc: ast, davem, hawk, jakub.kicinski, john.fastabend, kafai, mst,
netdev, songliubraving, yhs
In-Reply-To: <eb955137-11d5-13b2-683a-6a2e8425d792@redhat.com>
On 07/09/2019 05:04 AM, Jason Wang wrote:
> On 2019/7/9 上午6:38, Daniel Borkmann wrote:
>> On 07/02/2019 04:11 PM, Yuya Kusakabe wrote:
>>> On 7/2/19 5:33 PM, Jason Wang wrote:
>>>> On 2019/7/2 下午4:16, Yuya Kusakabe wrote:
>>>>> This adds XDP meta data support to both receive_small() and
>>>>> receive_mergeable().
>>>>>
>>>>> Fixes: de8f3a83b0a0 ("bpf: add meta pointer for direct access")
>>>>> Signed-off-by: Yuya Kusakabe <yuya.kusakabe@gmail.com>
>>>>> ---
>>>>> v3:
>>>>> - fix preserve the vnet header in receive_small().
>>>>> v2:
>>>>> - keep copy untouched in page_to_skb().
>>>>> - preserve the vnet header in receive_small().
>>>>> - fix indentation.
>>>>> ---
>>>>> drivers/net/virtio_net.c | 45 +++++++++++++++++++++++++++-------------
>>>>> 1 file changed, 31 insertions(+), 14 deletions(-)
>>>>>
>>>>> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
>>>>> index 4f3de0ac8b0b..03a1ae6fe267 100644
>>>>> --- a/drivers/net/virtio_net.c
>>>>> +++ b/drivers/net/virtio_net.c
>>>>> @@ -371,7 +371,7 @@ static struct sk_buff *page_to_skb(struct virtnet_info *vi,
>>>>> struct receive_queue *rq,
>>>>> struct page *page, unsigned int offset,
>>>>> unsigned int len, unsigned int truesize,
>>>>> - bool hdr_valid)
>>>>> + bool hdr_valid, unsigned int metasize)
>>>>> {
>>>>> struct sk_buff *skb;
>>>>> struct virtio_net_hdr_mrg_rxbuf *hdr;
>>>>> @@ -393,7 +393,7 @@ static struct sk_buff *page_to_skb(struct virtnet_info *vi,
>>>>> else
>>>>> hdr_padded_len = sizeof(struct padded_vnet_hdr);
>>>>> - if (hdr_valid)
>>>>> + if (hdr_valid && !metasize)
>>>>> memcpy(hdr, p, hdr_len);
>>>>> len -= hdr_len;
>>>>> @@ -405,6 +405,11 @@ static struct sk_buff *page_to_skb(struct virtnet_info *vi,
>>>>> copy = skb_tailroom(skb);
>>>>> skb_put_data(skb, p, copy);
>>>>> + if (metasize) {
>>>>> + __skb_pull(skb, metasize);
>>>>> + skb_metadata_set(skb, metasize);
>>>>> + }
>>>>> +
>>>>> len -= copy;
>>>>> offset += copy;
>>>>> @@ -644,6 +649,7 @@ static struct sk_buff *receive_small(struct net_device *dev,
>>>>> unsigned int delta = 0;
>>>>> struct page *xdp_page;
>>>>> int err;
>>>>> + unsigned int metasize = 0;
>>>>> len -= vi->hdr_len;
>>>>> stats->bytes += len;
>>>>> @@ -683,10 +689,13 @@ static struct sk_buff *receive_small(struct net_device *dev,
>>>>> xdp.data_hard_start = buf + VIRTNET_RX_PAD + vi->hdr_len;
>>>>> xdp.data = xdp.data_hard_start + xdp_headroom;
>>>>> - xdp_set_data_meta_invalid(&xdp);
>>>>> xdp.data_end = xdp.data + len;
>>>>> + xdp.data_meta = xdp.data;
>>>>> xdp.rxq = &rq->xdp_rxq;
>>>>> orig_data = xdp.data;
>>>>> + /* Copy the vnet header to the front of data_hard_start to avoid
>>>>> + * overwriting by XDP meta data */
>>>>> + memcpy(xdp.data_hard_start - vi->hdr_len, xdp.data - vi->hdr_len, vi->hdr_len);
>> I'm not fully sure if I'm following this one correctly, probably just missing
>> something. Isn't the vnet header based on how we set up xdp.data_hard_start
>> earlier already in front of it? Wouldn't we copy invalid data from xdp.data -
>> vi->hdr_len into the vnet header at that point (given there can be up to 256
>> bytes of headroom between the two)? If it's relative to xdp.data and headroom
>> is >0, then BPF prog could otherwise mangle this; something doesn't add up to
>> me here. Could you clarify? Thx
>
> Vnet headr sits just in front of xdp.data not xdp.data_hard_start. So it could be overwrote by metadata, that's why we need a copy here.
For the current code, you can adjust the xdp.data with a positive/negative offset
already via bpf_xdp_adjust_head() helper. If vnet headr sits just in front of
xdp.data, couldn't this be overridden today as well then? Anyway, just wondering
how this is handled differently?
Thanks,
Daniel
^ permalink raw reply
* Re: [PATCH] net: netsec: start using buffers if page_pool registration succeeded
From: David Miller @ 2019-07-09 20:00 UTC (permalink / raw)
To: ilias.apalodimas; +Cc: netdev, jaswinder.singh
In-Reply-To: <1562675753-26160-1-git-send-email-ilias.apalodimas@linaro.org>
From: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Date: Tue, 9 Jul 2019 15:35:53 +0300
> The current driver starts using page_pool buffers before calling
> xdp_rxq_info_reg_mem_model(). Start using the buffers after the
> registration succeeded, so we won't have to call
> page_pool_request_shutdown() in case of failure
>
> Fixes: 5c67bf0ec4d0 ("net: netsec: Use page_pool API")
> Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] vhost: fix null pointer dereference in vhost_del_umem_range
From: David Miller @ 2019-07-09 19:58 UTC (permalink / raw)
To: kda; +Cc: mst, jasowang, kvm, netdev
In-Reply-To: <20190709114251.24662-1-dkirjanov@suse.com>
From: Denis Kirjanov <kda@linux-powerpc.org>
Date: Tue, 9 Jul 2019 13:42:51 +0200
> @@ -962,7 +962,8 @@ static void vhost_del_umem_range(struct vhost_umem *umem,
>
> while ((node = vhost_umem_interval_tree_iter_first(&umem->umem_tree,
> start, end)))
> - vhost_umem_free(umem, node);
> + if (node)
> + vhost_umem_free(umem, node);
If 'node' is NULL we will not be in the body of the loop as per
the while() condition.
How did you test this?
^ permalink raw reply
* RE: [RESEND PATCH iproute2 net-next] devlink: Introduce PCI PF and VF port flavour and attribute
From: Parav Pandit @ 2019-07-09 19:49 UTC (permalink / raw)
To: Parav Pandit, netdev@vger.kernel.org
Cc: Saeed Mahameed, jakub.kicinski@netronome.com, Jiri Pirko
In-Reply-To: <20190701183017.25407-1-parav@mellanox.com>
> -----Original Message-----
> From: netdev-owner@vger.kernel.org <netdev-owner@vger.kernel.org> On
> Behalf Of Parav Pandit
> Sent: Tuesday, July 2, 2019 12:00 AM
> To: netdev@vger.kernel.org
> Cc: Saeed Mahameed <saeedm@mellanox.com>;
> jakub.kicinski@netronome.com; Jiri Pirko <jiri@mellanox.com>; Parav Pandit
> <parav@mellanox.com>
> Subject: [RESEND PATCH iproute2 net-next] devlink: Introduce PCI PF and VF
> port flavour and attribute
>
> Introduce PCI PF and VF port flavour and port attributes such as PF number
> and VF number.
>
> $ devlink port show
> pci/0000:05:00.0/0: type eth netdev eth0 flavour pcipf pfnum 0
> pci/0000:05:00.0/1: type eth netdev eth1 flavour pcivf pfnum 0 vfnum 0
> pci/0000:05:00.0/2: type eth netdev eth2 flavour pcivf pfnum 0 vfnum 1
>
> Acked-by: Jiri Pirko <jiri@mellanox.com>
> Signed-off-by: Parav Pandit <parav@mellanox.com>
> ---
> devlink/devlink.c | 23 +++++++++++++++++++++++
> include/uapi/linux/devlink.h | 11 +++++++++++
> 2 files changed, 34 insertions(+)
>
I will resend this patch with updated kernel commit id for the uapi, possibly once unrelated patch [1] is merged, just to avoid merge conflict.
[1] https://patchwork.ozlabs.org/patch/1129927/
^ permalink raw reply
* [linux-next:master 13028/13492] drivers/net/ethernet/ti/davinci_cpdma.c:725:5: sparse: sparse: symbol 'cpdma_chan_split_pool' was not declared. Should it be static?
From: kbuild test robot @ 2019-07-09 19:32 UTC (permalink / raw)
To: Ivan Khoronzhuk
Cc: kbuild-all, Grygorii Strashko, Andrew Lunn, Ilias Apalodimas,
linux-omap, netdev, linux-kernel
tree: https://kernel.googlesource.com/pub/scm/linux/kernel/git/next/linux-next.git master
head: 4608a726c66807c27bc7d91bdf8a288254e29985
commit: 962fb618909ef64e0c89af5b79ba0fed910b78e3 [13028/13492] net: ethernet: ti: davinci_cpdma: allow desc split while down
reproduce:
# apt-get install sparse
# sparse version: v0.6.1-rc1-7-g2b96cd8-dirty
git checkout 962fb618909ef64e0c89af5b79ba0fed910b78e3
make ARCH=x86_64 allmodconfig
make C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__'
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>
sparse warnings: (new ones prefixed by >>)
>> drivers/net/ethernet/ti/davinci_cpdma.c:725:5: sparse: sparse: symbol 'cpdma_chan_split_pool' was not declared. Should it be static?
Please review and possibly fold the followup patch.
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
^ permalink raw reply
* [RFC PATCH linux-next] net: ethernet: ti: davinci_cpdma: cpdma_chan_split_pool() can be static
From: kbuild test robot @ 2019-07-09 19:32 UTC (permalink / raw)
To: Ivan Khoronzhuk
Cc: kbuild-all, Grygorii Strashko, Andrew Lunn, Ilias Apalodimas,
linux-omap, netdev, linux-kernel
In-Reply-To: <201907100329.bQl3UgMB%lkp@intel.com>
Fixes: 962fb618909e ("net: ethernet: ti: davinci_cpdma: allow desc split while down")
Signed-off-by: kbuild test robot <lkp@intel.com>
---
davinci_cpdma.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/ti/davinci_cpdma.c b/drivers/net/ethernet/ti/davinci_cpdma.c
index 0ca2a1a..1f6065b 100644
--- a/drivers/net/ethernet/ti/davinci_cpdma.c
+++ b/drivers/net/ethernet/ti/davinci_cpdma.c
@@ -722,7 +722,7 @@ static void cpdma_chan_set_descs(struct cpdma_ctlr *ctlr,
* cpdma_chan_split_pool - Splits ctrl pool between all channels.
* Has to be called under ctlr lock
*/
-int cpdma_chan_split_pool(struct cpdma_ctlr *ctlr)
+static int cpdma_chan_split_pool(struct cpdma_ctlr *ctlr)
{
int tx_per_ch_desc = 0, rx_per_ch_desc = 0;
int free_rx_num = 0, free_tx_num = 0;
^ permalink raw reply related
* [RFC PATCH net-next 3/3] net: use listified RX for handling GRO_NORMAL skbs
From: Edward Cree @ 2019-07-09 19:29 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Eric Dumazet
In-Reply-To: <7920e85c-439e-0622-46f8-0602cf37e306@solarflare.com>
When GRO decides not to coalesce a packet, in napi_frags_finish(), instead
of passing it to the stack immediately, place it on a list in the napi
struct. Then, at flush time (napi_complete_done() or napi_poll()), call
netif_receive_skb_list_internal() on the list. We'd like to do that in
napi_gro_flush(), but it's not called if !napi->gro_bitmask, so we have to
do it in the callers instead. (There are a handful of drivers that call
napi_gro_flush() themselves, but it's not clear why, or whether this will
affect them.)
Because a full 64 packets is an inefficiently large batch, also consume the
list whenever it exceeds gro_normal_batch, a new net/core sysctl that
defaults to 8.
Signed-off-by: Edward Cree <ecree@solarflare.com>
---
include/linux/netdevice.h | 3 +++
net/core/dev.c | 32 ++++++++++++++++++++++++++++++--
net/core/sysctl_net_core.c | 8 ++++++++
3 files changed, 41 insertions(+), 2 deletions(-)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 88292953aa6f..55ac223553f8 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -332,6 +332,8 @@ struct napi_struct {
struct net_device *dev;
struct gro_list gro_hash[GRO_HASH_BUCKETS];
struct sk_buff *skb;
+ struct list_head rx_list; /* Pending GRO_NORMAL skbs */
+ int rx_count; /* length of rx_list */
struct hrtimer timer;
struct list_head dev_list;
struct hlist_node napi_hash_node;
@@ -4239,6 +4241,7 @@ extern int dev_weight_rx_bias;
extern int dev_weight_tx_bias;
extern int dev_rx_weight;
extern int dev_tx_weight;
+extern int gro_normal_batch;
bool netdev_has_upper_dev(struct net_device *dev, struct net_device *upper_dev);
struct net_device *netdev_upper_get_next_dev_rcu(struct net_device *dev,
diff --git a/net/core/dev.c b/net/core/dev.c
index fc676b2610e3..4b6f2ec67fbc 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -3963,6 +3963,8 @@ int dev_weight_rx_bias __read_mostly = 1; /* bias for backlog weight */
int dev_weight_tx_bias __read_mostly = 1; /* bias for output_queue quota */
int dev_rx_weight __read_mostly = 64;
int dev_tx_weight __read_mostly = 64;
+/* Maximum number of GRO_NORMAL skbs to batch up for list-RX */
+int gro_normal_batch __read_mostly = 8;
/* Called with irq disabled */
static inline void ____napi_schedule(struct softnet_data *sd,
@@ -5742,6 +5744,26 @@ struct sk_buff *napi_get_frags(struct napi_struct *napi)
}
EXPORT_SYMBOL(napi_get_frags);
+/* Pass the currently batched GRO_NORMAL SKBs up to the stack. */
+static void gro_normal_list(struct napi_struct *napi)
+{
+ if (!napi->rx_count)
+ return;
+ netif_receive_skb_list_internal(&napi->rx_list);
+ INIT_LIST_HEAD(&napi->rx_list);
+ napi->rx_count = 0;
+}
+
+/* Queue one GRO_NORMAL SKB up for list processing. If batch size exceeded,
+ * pass the whole batch up to the stack.
+ */
+static void gro_normal_one(struct napi_struct *napi, struct sk_buff *skb)
+{
+ list_add_tail(&skb->list, &napi->rx_list);
+ if (++napi->rx_count >= gro_normal_batch)
+ gro_normal_list(napi);
+}
+
static gro_result_t napi_frags_finish(struct napi_struct *napi,
struct sk_buff *skb,
gro_result_t ret)
@@ -5751,8 +5773,8 @@ static gro_result_t napi_frags_finish(struct napi_struct *napi,
case GRO_HELD:
__skb_push(skb, ETH_HLEN);
skb->protocol = eth_type_trans(skb, skb->dev);
- if (ret == GRO_NORMAL && netif_receive_skb_internal(skb))
- ret = GRO_DROP;
+ if (ret == GRO_NORMAL)
+ gro_normal_one(napi, skb);
break;
case GRO_DROP:
@@ -6029,6 +6051,8 @@ bool napi_complete_done(struct napi_struct *n, int work_done)
NAPIF_STATE_IN_BUSY_POLL)))
return false;
+ gro_normal_list(n);
+
if (n->gro_bitmask) {
unsigned long timeout = 0;
@@ -6267,6 +6291,8 @@ void netif_napi_add(struct net_device *dev, struct napi_struct *napi,
napi->timer.function = napi_watchdog;
init_gro_hash(napi);
napi->skb = NULL;
+ INIT_LIST_HEAD(&napi->rx_list);
+ napi->rx_count = 0;
napi->poll = poll;
if (weight > NAPI_POLL_WEIGHT)
netdev_err_once(dev, "%s() called with weight %d\n", __func__,
@@ -6363,6 +6389,8 @@ static int napi_poll(struct napi_struct *n, struct list_head *repoll)
goto out_unlock;
}
+ gro_normal_list(n);
+
if (n->gro_bitmask) {
/* flush too old packets
* If HZ < 1000, flush all packets.
diff --git a/net/core/sysctl_net_core.c b/net/core/sysctl_net_core.c
index f9204719aeee..dba52f53eace 100644
--- a/net/core/sysctl_net_core.c
+++ b/net/core/sysctl_net_core.c
@@ -569,6 +569,14 @@ static struct ctl_table net_core_table[] = {
.mode = 0644,
.proc_handler = proc_do_static_key,
},
+ {
+ .procname = "gro_normal_batch",
+ .data = &gro_normal_batch,
+ .maxlen = sizeof(unsigned int),
+ .mode = 0644,
+ .proc_handler = proc_dointvec_minmax,
+ .extra1 = &one,
+ },
{ }
};
^ permalink raw reply related
* [RFC PATCH net-next 2/3] sfc: falcon: don't score irq moderation points for GRO
From: Edward Cree @ 2019-07-09 19:29 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Eric Dumazet
In-Reply-To: <7920e85c-439e-0622-46f8-0602cf37e306@solarflare.com>
Same rationale as for sfc, except that this wasn't performance-tested.
Signed-off-by: Edward Cree <ecree@solarflare.com>
---
drivers/net/ethernet/sfc/falcon/rx.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/sfc/falcon/rx.c b/drivers/net/ethernet/sfc/falcon/rx.c
index fd850d3d8ec0..05ea3523890a 100644
--- a/drivers/net/ethernet/sfc/falcon/rx.c
+++ b/drivers/net/ethernet/sfc/falcon/rx.c
@@ -424,7 +424,6 @@ ef4_rx_packet_gro(struct ef4_channel *channel, struct ef4_rx_buffer *rx_buf,
unsigned int n_frags, u8 *eh)
{
struct napi_struct *napi = &channel->napi_str;
- gro_result_t gro_result;
struct ef4_nic *efx = channel->efx;
struct sk_buff *skb;
@@ -460,9 +459,7 @@ ef4_rx_packet_gro(struct ef4_channel *channel, struct ef4_rx_buffer *rx_buf,
skb_record_rx_queue(skb, channel->rx_queue.core_index);
- gro_result = napi_gro_frags(napi);
- if (gro_result != GRO_DROP)
- channel->irq_mod_score += 2;
+ napi_gro_frags(napi);
}
/* Allocate and construct an SKB around page fragments */
^ permalink raw reply related
* [RFC PATCH net-next 1/3] sfc: don't score irq moderation points for GRO
From: Edward Cree @ 2019-07-09 19:28 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Eric Dumazet
In-Reply-To: <7920e85c-439e-0622-46f8-0602cf37e306@solarflare.com>
We already scored points when handling the RX event, no-one else does this,
and looking at the history it appears this was originally meant to only
score on merges, not on GRO_NORMAL. Moreover, it gets in the way of
changing GRO to not immediately pass GRO_NORMAL skbs to the stack.
Performance testing with four TCP streams received on a single CPU (where
throughput was line rate of 9.4Gbps in all tests) showed a 13.7% reduction
in RX CPU usage (n=6, p=0.03).
Signed-off-by: Edward Cree <ecree@solarflare.com>
---
drivers/net/ethernet/sfc/rx.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/sfc/rx.c b/drivers/net/ethernet/sfc/rx.c
index d5db045535d3..85ec07f5a674 100644
--- a/drivers/net/ethernet/sfc/rx.c
+++ b/drivers/net/ethernet/sfc/rx.c
@@ -412,7 +412,6 @@ efx_rx_packet_gro(struct efx_channel *channel, struct efx_rx_buffer *rx_buf,
unsigned int n_frags, u8 *eh)
{
struct napi_struct *napi = &channel->napi_str;
- gro_result_t gro_result;
struct efx_nic *efx = channel->efx;
struct sk_buff *skb;
@@ -449,9 +448,7 @@ efx_rx_packet_gro(struct efx_channel *channel, struct efx_rx_buffer *rx_buf,
skb_record_rx_queue(skb, channel->rx_queue.core_index);
- gro_result = napi_gro_frags(napi);
- if (gro_result != GRO_DROP)
- channel->irq_mod_score += 2;
+ napi_gro_frags(napi);
}
/* Allocate and construct an SKB around page fragments */
^ permalink raw reply related
* [RFC PATCH net-next 0/3] net: batched receive in GRO path
From: Edward Cree @ 2019-07-09 19:27 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Eric Dumazet
This series listifies part of GRO processing, in a manner which allows those
packets which are not GROed (i.e. for which dev_gro_receive returns
GRO_NORMAL) to be passed on to the listified regular receive path.
dev_gro_receive() itself is not listified, nor the per-protocol GRO
callback, since GRO's need to hold packets on lists under napi->gro_hash
makes keeping the packets on other lists awkward, and since the GRO control
block state of held skbs can refer only to one 'new' skb at a time.
Instead, when napi_frags_finish() handles a GRO_NORMAL result, stash the skb
onto a list in the napi struct, which is received at the end of the napi
poll or when its length exceeds the (new) sysctl net.core.gro_normal_batch.
Unlike my previous design ([1]), this does not require changes in drivers,
and also does not prevent the re-use of napi->skb after GRO_MERGED_FREE or
GRO_DROP.
Performance figures with this series, collected on a back-to-back pair of
Solarflare sfn8522-r2 NICs with 120-second NetPerf tests. In the stats,
sample size n for old and new code is 6 runs each; p is from a Welch t-test.
Tests were run both with GRO enabled and disabled, the latter simulating
uncoalesceable packets (e.g. due to IP or TCP options). The receive side
(which was the device under test) had the NetPerf process pinned to one CPU,
and the device interrupts pinned to a second CPU. CPU utilisation figures
(used in cases of line-rate performance) are summed across all CPUs.
Where not specified (as batch=), net.core.gro_normal_batch was set to 8.
The net-next baseline used for these tests was commit 7d30a7f6424e.
TCP 4 streams, GRO on: all results line rate (9.415Gbps)
net-next: 210.3% cpu
after #1: 181.5% cpu (-13.7%, p=0.031 vs net-next)
after #3: 191.7% cpu (- 8.9%, p=0.102 vs net-next)
TCP 4 streams, GRO off:
after #1: 7.785 Gbps
after #3: 8.387 Gbps (+ 7.7%, p=0.215 vs #1, but note *)
TCP 1 stream, GRO on: all results line rate & ~200% cpu.
TCP 1 stream, GRO off:
after #1: 6.444 Gbps
after #3: 7.363 Gbps (+14.3%, p=0.003 vs #1)
batch=16: 7.199 Gbps
batch= 4: 7.354 Gbps
batch= 0: 5.899 Gbps
TCP 100 RR, GRO off:
net-next: 995.083 us
after #1: 969.167 us (- 2.6%, p=0.204 vs net-next)
after #3: 976.433 us (- 1.9%, p=0.254 vs net-next)
(*) These tests produced a mixture of line-rate and below-line-rate results,
meaning that statistically speaking the results were 'censored' by the
upper bound, and were thus not normally distributed, making a Welch t-test
mathematically invalid. I therefore also calculated estimators according
to [2], which gave the following:
after #1: 8.155 Gbps
after #3: 8.716 Gbps (+ 6.9%, p=0.291 vs #1)
(though my procedure for determining ν wasn't mathematically well-founded
either, so take that p-value with a grain of salt).
Conclusion:
* Patch #1 is a fairly unambiguous improvement.
* Patch #3 has no statistically significant effect when GRO is active.
* Any effect of patch #3 on latency is within statistical noise.
* When GRO is inactive, patch #3 improves bandwidth, though for multiple
streams the effect is smaller (possibly owing to the line-rate limit).
* The optimal batch size for this setup appears to be around 8.
* Setting the batch size to zero gives worse performance than before the
patch; perhaps a static key is needed?
* Drivers which, unlike sfc, pass UDP traffic to GRO would expect to see a
benefit from gaining access to batching.
Notes for future thought: in principle if we passed the napi pointer to
napi_gro_complete(), it could add its superframe skb to napi->rx_list,
rather than immediately netif_receive_skb_internal()ing it. Without that
I'm not sure if there's a possibility of OoO between normal and GROed SKBs
on the same flow.
[1]: http://patchwork.ozlabs.org/cover/997844/
[2]: Cohen 1959, doi: 10.1080/00401706.1959.10489859
Edward Cree (3):
sfc: don't score irq moderation points for GRO
sfc: falcon: don't score irq moderation points for GRO
net: use listified RX for handling GRO_NORMAL skbs
drivers/net/ethernet/sfc/falcon/rx.c | 5 +----
drivers/net/ethernet/sfc/rx.c | 5 +----
include/linux/netdevice.h | 3 +++
net/core/dev.c | 32 ++++++++++++++++++++++++++--
net/core/sysctl_net_core.c | 8 +++++++
5 files changed, 43 insertions(+), 10 deletions(-)
^ permalink raw reply
* RE: [PATCH net-next v6 0/5] devlink: Introduce PCI PF, VF ports and attributes
From: Parav Pandit @ 2019-07-09 19:21 UTC (permalink / raw)
To: David Miller, jakub.kicinski@netronome.com
Cc: jiri@resnulli.us, netdev@vger.kernel.org, Jiri Pirko,
Saeed Mahameed
In-Reply-To: <20190709.120336.1987683013901804676.davem@davemloft.net>
Hi Dave,
> -----Original Message-----
> From: David Miller <davem@davemloft.net>
> Sent: Wednesday, July 10, 2019 12:34 AM
> To: jakub.kicinski@netronome.com
> Cc: jiri@resnulli.us; Parav Pandit <parav@mellanox.com>;
> netdev@vger.kernel.org; Jiri Pirko <jiri@mellanox.com>; Saeed Mahameed
> <saeedm@mellanox.com>
> Subject: Re: [PATCH net-next v6 0/5] devlink: Introduce PCI PF, VF ports and
> attributes
>
> From: Jakub Kicinski <jakub.kicinski@netronome.com>
> Date: Tue, 9 Jul 2019 11:20:58 -0700
>
> > On Tue, 9 Jul 2019 08:17:11 +0200, Jiri Pirko wrote:
> >> >But I'll leave it to Jiri and Dave to decide if its worth a respin
> >> >:) Functionally I think this is okay.
> >>
> >> I'm happy with the set as it is right now.
> >
> > To be clear, I am happy enough as well. Hence the review tag.
>
> Series applied, thanks everyone.
>
> >> Anyway, if you want your concerns to be addresses, you should write
> >> them to the appropriate code. This list is hard to follow.
> >
> > Sorry, I was trying to be concise.
>
> Jiri et al., if Jakub put forth the time and effort to make the list and give you
> feedback you can put forth the effort to go through the list and address his
> feedback with follow-up patches. You cannot dictate how people give
> feedback to your changes, thank you.
I will be happy to write follow up patches.
mostly in kernel 5.4, I will be adding mdev (mediated device) port flavour as discussed in past.
I will possibly write up follow up patch or two before posting them or have it in that series, as it will extend this devlink code further.
^ permalink raw reply
* Re: [PATCH net-next v4 0/3] net: stmmac: Some improvements and a fix
From: David Miller @ 2019-07-09 19:20 UTC (permalink / raw)
To: Jose.Abreu
Cc: netdev, Joao.Pinto, peppe.cavallaro, alexandre.torgue,
mcoquelin.stm32, maxime.ripard, wens, linux-stm32,
linux-arm-kernel, linux-kernel
In-Reply-To: <cover.1562659012.git.joabreu@synopsys.com>
From: Jose Abreu <Jose.Abreu@synopsys.com>
Date: Tue, 9 Jul 2019 10:02:57 +0200
> Some performace improvements (01/03 and 03/03) and a fix (02/03),
> all for -next.
Series applied, thanks Jose.
^ permalink raw reply
* Re: [PATCH net-next] bnxt_en: Add page_pool_destroy() during RX ring cleanup.
From: David Miller @ 2019-07-09 19:18 UTC (permalink / raw)
To: michael.chan; +Cc: netdev, ilias.apalodimas, gospo
In-Reply-To: <1562658607-30048-1-git-send-email-michael.chan@broadcom.com>
From: Michael Chan <michael.chan@broadcom.com>
Date: Tue, 9 Jul 2019 03:50:07 -0400
> Add page_pool_destroy() in bnxt_free_rx_rings() during normal RX ring
> cleanup, as Ilias has informed us that the following commit has been
> merged:
>
> 1da4bbeffe41 ("net: core: page_pool: add user refcnt and reintroduce page_pool_destroy")
>
> The special error handling code to call page_pool_free() can now be
> removed. bnxt_free_rx_rings() will always be called during normal
> shutdown or any error paths.
>
> Fixes: 322b87ca55f2 ("bnxt_en: add page_pool support")
> Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org>
> Cc: Andy Gospodarek <gospo@broadcom.com>
> Signed-off-by: Michael Chan <michael.chan@broadcom.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next v6 0/4] net/sched: Introduce tc connection tracking
From: David Miller @ 2019-07-09 19:14 UTC (permalink / raw)
To: paulb
Cc: jiri, roid, yossiku, ozsh, marcelo.leitner, netdev, aconole,
wangzhike, ronye, nst-kernel, john.hurley, simon.horman, jpettit
In-Reply-To: <1562657451-20819-1-git-send-email-paulb@mellanox.com>
From: Paul Blakey <paulb@mellanox.com>
Date: Tue, 9 Jul 2019 10:30:47 +0300
> This patch series add connection tracking capabilities in tc sw datapath.
> It does so via a new tc action, called act_ct, and new tc flower classifier matching
> on conntrack state, mark and label.
...
Ok, I applied this, but two things:
1) You owe Cong Wang an explanation, a real detailed one, about the L2
vs L3 design of this feature. I did not see you address his feedback,
but if you did I apologize.
2) Because the MPLS changes went in first, TCA_ID_CT ended up in a
different spot in the enumeration and therefore the value is
different.
Thanks.
^ permalink raw reply
* Re: [PATCH v3 net-next 19/19] ionic: Add basic devlink interface
From: Shannon Nelson @ 2019-07-09 19:13 UTC (permalink / raw)
To: Jiri Pirko; +Cc: netdev
In-Reply-To: <20190709065620.GJ2282@nanopsycho.orion>
On 7/8/19 11:56 PM, Jiri Pirko wrote:
> Tue, Jul 09, 2019 at 12:58:00AM CEST, snelson@pensando.io wrote:
>> On 7/8/19 1:03 PM, Jiri Pirko wrote:
>>> Mon, Jul 08, 2019 at 09:58:09PM CEST, snelson@pensando.io wrote:
>>>> On 7/8/19 12:34 PM, Jiri Pirko wrote:
>>>>> Mon, Jul 08, 2019 at 09:25:32PM CEST, snelson@pensando.io wrote:
>>>>>> +
>>>>>> +static const struct devlink_ops ionic_dl_ops = {
>>>>>> + .info_get = ionic_dl_info_get,
>>>>>> +};
>>>>>> +
>>>>>> +int ionic_devlink_register(struct ionic *ionic)
>>>>>> +{
>>>>>> + struct devlink *dl;
>>>>>> + struct ionic **ip;
>>>>>> + int err;
>>>>>> +
>>>>>> + dl = devlink_alloc(&ionic_dl_ops, sizeof(struct ionic *));
>>>>> Oups. Something is wrong with your flow. The devlink alloc is allocating
>>>>> the structure that holds private data (per-device data) for you. This is
>>>>> misuse :/
>>>>>
>>>>> You are missing one parent device struct apparently.
>>>>>
>>>>> Oh, I think I see something like it. The unused "struct ionic_devlink".
>>>> If I'm not mistaken, the alloc is only allocating enough for a pointer, not
>>>> the whole per device struct, and a few lines down from here the pointer to
>>>> the new devlink struct is assigned to ionic->dl. This was based on what I
>>>> found in the qed driver's qed_devlink_register(), and it all seems to work.
>>> I'm not saying your code won't work. What I say is that you should have
>>> a struct for device that would be allocated by devlink_alloc()
>> Is there a particular reason why? I appreciate that devlink_alloc() can give
>> you this device specific space, just as alloc_etherdev_mq() can, but is there
> Yes. Devlink manipulates with the whole device. However,
> alloc_etherdev_mq() allocates only net_device. These are 2 different
> things. devlink port relates 1:1 to net_device. However, devlink
> instance can have multiple ports. What I say is do it correctly.
So what you are saying is that anyone who wants to add even the smallest
devlink feature to their driver needs to rework their basic device
memory setup to do it the devlink way. I can see where some folks may
have a problem with this.
>
>
>> a specific reason why this should be used instead of setting up simply a
>> pointer to a space that has already been allocated? There are several
>> drivers that are using it the way I've setup here, which happened to be the
>> first examples I followed - are they doing something different that makes
>> this valid for them?
> Nope. I'll look at that and fix.
>
>
>>> The ionic struct should be associated with devlink_port. That you are
>>> missing too.
>> We don't support any of devlink_port features at this point, just the simple
>> device information.
> No problem, you can still register devlink_port. You don't have to do
> much in order to do so.
Is there any write-up to help guide developers new to devlink in using
the interface correctly? I haven't found much yet, but perhaps I've
missed something. The manpages are somewhat useful in showing what the
user might do, but they really don't help much in guiding the developer
through these details.
sln
^ permalink raw reply
* Reminder: 29 open syzbot bugs in bluetooth subsystem
From: Eric Biggers @ 2019-07-09 19:07 UTC (permalink / raw)
To: linux-bluetooth, netdev, Marcel Holtmann, Johan Hedberg,
David S. Miller, Loic Poulain, Benjamin Herrenschmidt,
Ben Young Tae Kim
Cc: linux-kernel, syzkaller-bugs
[This email was generated by a script. Let me know if you have any suggestions
to make it better, or if you want it re-generated with the latest status.]
Of the currently open syzbot reports against the upstream kernel, I've manually
marked 29 of them as possibly being bugs in the bluetooth subsystem. I've
listed these reports below, sorted by an algorithm that tries to list first the
reports most likely to be still valid, important, and actionable.
Of these 29 bugs, 5 were seen in mainline in the last week.
Of these 29 bugs, 4 were bisected to commits from the following people:
Loic Poulain <loic.poulain@intel.com>
Benjamin Herrenschmidt <benh@kernel.crashing.org>
Ben Young Tae Kim <ytkim@qca.qualcomm.com>
If you believe a bug is no longer valid, please close the syzbot report by
sending a '#syz fix', '#syz dup', or '#syz invalid' command in reply to the
original thread, as explained at https://goo.gl/tpsmEJ#status
If you believe I misattributed a bug to the bluetooth subsystem, please let me
know, and if possible forward the report to the correct people or mailing list.
Here are the bugs:
--------------------------------------------------------------------------------
Title: WARNING: refcount bug in kobject_get
Last occurred: 5 days ago
Reported: 302 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=06c8522152c9325bf0f1a3dc5b33d1b95a47431f
Original thread: https://lkml.kernel.org/lkml/00000000000037743205757f33ac@google.com/T/#u
This bug has a C reproducer.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+b74b8b6e712f33454561@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/00000000000037743205757f33ac@google.com
--------------------------------------------------------------------------------
Title: WARNING in kernfs_get
Last occurred: 0 days ago
Reported: 302 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=b52dec65c1aaaec9b3893458b13a3304303de321
Original thread: https://lkml.kernel.org/lkml/000000000000f921ae05757f567c@google.com/T/#u
This bug has a C reproducer.
The original thread for this bug received 1 reply, 251 days ago.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+3dcb532381f98c86aeb1@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000f921ae05757f567c@google.com
--------------------------------------------------------------------------------
Title: BUG: MAX_LOCKDEP_CHAIN_HLOCKS too low!
Last occurred: 0 days ago
Reported: 125 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=381cb436fe60dc03d7fd2a092b46d7f09542a72a
Original thread: https://lkml.kernel.org/lkml/000000000000b7fd51058370d0d9@google.com/T/#u
This bug has a C reproducer.
syzbot has bisected this bug, but I think the bisection result is incorrect.
The original thread for this bug received 1 reply, 88 days ago.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+91fd909b6e62ebe06131@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000b7fd51058370d0d9@google.com
--------------------------------------------------------------------------------
Title: WARNING in tty_set_termios
Last occurred: 7 days ago
Reported: 177 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=2410d22f1d8e5984217329dd0884b01d99e3e48d
Original thread: https://lkml.kernel.org/lkml/000000000000bcd434057f4eb905@google.com/T/#u
This bug has a C reproducer.
This bug was bisected to:
commit 162f812f23bab583f5d514ca0e4df67797ac9cdf
Author: Loic Poulain <loic.poulain@intel.com>
Date: Mon Sep 19 14:29:27 2016 +0000
Bluetooth: hci_uart: Add Marvell support
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+a950165cbb86bdd023a4@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000bcd434057f4eb905@google.com
--------------------------------------------------------------------------------
Title: KASAN: use-after-free Read in hci_cmd_timeout
Last occurred: 6 days ago
Reported: 63 days ago
Branches: Mainline
Dashboard link: https://syzkaller.appspot.com/bug?id=cb23ebfc8f304f510fb717cb783fe8b496c7ffb1
Original thread: https://lkml.kernel.org/lkml/00000000000035c756058848954a@google.com/T/#u
This bug has a C reproducer.
No one has replied to the original thread for this bug yet.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+19a9f729f05272857487@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/00000000000035c756058848954a@google.com
--------------------------------------------------------------------------------
Title: WARNING: refcount bug in kobject_add_internal
Last occurred: 8 days ago
Reported: 8 days ago
Branches: Mainline
Dashboard link: https://syzkaller.appspot.com/bug?id=1d709c7eaa63a2bf50387e15d8c0173acc9c9972
Original thread: https://lkml.kernel.org/lkml/0000000000009b1944058ca3e4a8@google.com/T/#u
This bug has a C reproducer.
This bug was bisected to:
commit 726e41097920a73e4c7c33385dcc0debb1281e18
Author: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: Tue Jul 10 00:29:10 2018 +0000
drivers: core: Remove glue dirs from sysfs earlier
The original thread for this bug has received 2 replies; the last was 7 days
ago.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+32259bb9bc1a487ad206@syzkaller.appspotmail.com
If you send any email or patch for this bug, please reply to the original
thread, which had activity only 7 days ago. For the git send-email command to
use, or tips on how to reply if the thread isn't in your mailbox, see the "Reply
instructions" at https://lkml.kernel.org/r/0000000000009b1944058ca3e4a8@google.com
--------------------------------------------------------------------------------
Title: memory leak in get_device_parent
Last occurred: 7 days ago
Reported: 42 days ago
Branches: Mainline
Dashboard link: https://syzkaller.appspot.com/bug?id=63d2295ec374cc088d03cc83ad9c7a372a3d02e9
Original thread: https://lkml.kernel.org/lkml/0000000000009b950f0589e804b3@google.com/T/#u
This bug has a C reproducer.
No one has replied to the original thread for this bug yet.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+02e97e2ad931a981e568@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/0000000000009b950f0589e804b3@google.com
--------------------------------------------------------------------------------
Title: KASAN: use-after-free Read in rfcomm_dlc_exists
Last occurred: 7 days ago
Reported: 350 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=93ca265e594ab40b3d0e819cf24ba39e75d71fd6
Original thread: https://lkml.kernel.org/lkml/00000000000026c18a0571b9b0de@google.com/T/#u
Unfortunately, this bug does not have a reproducer.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+728bead095cef3335bb6@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/00000000000026c18a0571b9b0de@google.com
--------------------------------------------------------------------------------
Title: KASAN: use-after-free Read in kfree_skb (3)
Last occurred: 16 days ago
Reported: 63 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=db842327c655eab57b1755f661f1ab677d94e0bb
Original thread: https://lkml.kernel.org/lkml/0000000000002f9ef4058848f26d@google.com/T/#u
This bug has a C reproducer.
syzbot has bisected this bug, but I think the bisection result is incorrect.
No one has replied to the original thread for this bug yet.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+dcb1305dd05699c40640@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/0000000000002f9ef4058848f26d@google.com
--------------------------------------------------------------------------------
Title: general protection fault in kernfs_add_one
Last occurred: 10 days ago
Reported: 296 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=c10f2ca5722a78c613e9ccd45af7877f5debf0ad
Original thread: https://lkml.kernel.org/lkml/000000000000bf6bd30575fec528@google.com/T/#u
This bug has a C reproducer.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+db1637662f412ac0d556@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000bf6bd30575fec528@google.com
--------------------------------------------------------------------------------
Title: general protection fault in skb_put
Last occurred: 12 days ago
Reported: 155 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=9abc0fdcdea0effb7b27984dbc1f336155cdad3f
Original thread: https://lkml.kernel.org/lkml/000000000000b9e68e0581142f19@google.com/T/#u
This bug has a C reproducer.
syzbot has bisected this bug, but I think the bisection result is incorrect.
The original thread for this bug received 4 replies; the last was 118 days ago.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+65788f9af9d54844389e@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000b9e68e0581142f19@google.com
--------------------------------------------------------------------------------
Title: memory leak in h4_recv_buf
Last occurred: 9 days ago
Reported: 15 days ago
Branches: Mainline
Dashboard link: https://syzkaller.appspot.com/bug?id=32811c498b542bcef1950494eed33021cc91fd5f
Original thread: https://lkml.kernel.org/lkml/0000000000006b1779058c0cbdda@google.com/T/#u
This bug has a C reproducer.
No one has replied to the original thread for this bug yet.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+97388eb9d31b997fe1d0@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/0000000000006b1779058c0cbdda@google.com
--------------------------------------------------------------------------------
Title: KASAN: slab-out-of-bounds Read in hci_event_packet
Last occurred: 11 days ago
Reported: 183 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=d708485af9edc3af35f3b4d554e827c6c8bf6b0f
Original thread: https://lkml.kernel.org/lkml/000000000000696949057ee26e44@google.com/T/#u
This bug has a C reproducer.
syzbot has bisected this bug, but I think the bisection result is incorrect.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+cec7a50c412a2c03f8f5@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000696949057ee26e44@google.com
--------------------------------------------------------------------------------
Title: WARNING in kernfs_create_dir_ns
Last occurred: 10 days ago
Reported: 10 days ago
Branches: Mainline
Dashboard link: https://syzkaller.appspot.com/bug?id=5124d1a0fef7e16146c1f5ea164ad3ddbdb3bb10
Original thread: https://lkml.kernel.org/lkml/0000000000003ec128058c7624ec@google.com/T/#u
This bug has a C reproducer.
The original thread for this bug has received 2 replies; the last was 21 hours
ago.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+38f5d5cf7ae88c46b11a@syzkaller.appspotmail.com
If you send any email or patch for this bug, please reply to the original
thread, which had activity only 21 hours ago. For the git send-email command to
use, or tips on how to reply if the thread isn't in your mailbox, see the "Reply
instructions" at https://lkml.kernel.org/r/0000000000003ec128058c7624ec@google.com
--------------------------------------------------------------------------------
Title: general protection fault in qca_setup
Last occurred: 148 days ago
Reported: 148 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=62aaa13b8b6bba7f5bca8c0defef34b9a1623135
Original thread: https://lkml.kernel.org/lkml/0000000000002996510581a1487e@google.com/T/#u
This bug has a C reproducer.
This bug was bisected to:
commit 0ff252c1976da5d80db1377eb39b551931e61826
Author: Ben Young Tae Kim <ytkim@qca.qualcomm.com>
Date: Mon Aug 10 21:24:17 2015 +0000
Bluetooth: hciuart: Add support QCA chipset for UART
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+8c0dbf8843bb75efaa05@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/0000000000002996510581a1487e@google.com
--------------------------------------------------------------------------------
Title: BUG: unable to handle kernel NULL pointer dereference in hci_uart_set_flow_control
Last occurred: 110 days ago
Reported: 110 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=1b42faa2848963564a5b1b7f8c837ea7b55ffa50
Original thread: https://lkml.kernel.org/lkml/00000000000017690505849d6b3c@google.com/T/#u
This bug has a C reproducer.
This bug was bisected to:
commit 162f812f23bab583f5d514ca0e4df67797ac9cdf
Author: Loic Poulain <loic.poulain@intel.com>
Date: Mon Sep 19 14:29:27 2016 +0000
Bluetooth: hci_uart: Add Marvell support
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+79337b501d6aa974d0f6@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/00000000000017690505849d6b3c@google.com
--------------------------------------------------------------------------------
Title: KMSAN: uninit-value in hci_event_packet
Last occurred: 73 days ago
Reported: 86 days ago
Branches: Mainline (with KMSAN patches)
Dashboard link: https://syzkaller.appspot.com/bug?id=fac3d7b25f0e5f3899e4b0dcec32bb3177c95718
Original thread: https://lkml.kernel.org/lkml/0000000000005bb0ae05867271c1@google.com/T/#u
This bug has a C reproducer.
No one has replied to the original thread for this bug yet.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+4918ee47ac82d51de00d@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/0000000000005bb0ae05867271c1@google.com
--------------------------------------------------------------------------------
Title: KASAN: use-after-free Write in hci_sock_release
Last occurred: 186 days ago
Reported: 259 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=47befb59c610a69f024db20b927dea80c88fc045
Original thread: https://lkml.kernel.org/lkml/0000000000003692760578e651dd@google.com/T/#u
This bug has a C reproducer.
syzbot has bisected this bug, but I think the bisection result is incorrect.
The original thread for this bug received 3 replies; the last was 106 days ago.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+b364ed862aa07c74bc62@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/0000000000003692760578e651dd@google.com
--------------------------------------------------------------------------------
Title: KASAN: slab-out-of-bounds Read in bacpy
Last occurred: 68 days ago
Reported: 183 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=3acd1155d48a5acc5d76711568b04926945a6885
Original thread: https://lkml.kernel.org/lkml/0000000000008a1bce057ede3d13@google.com/T/#u
This bug has a C reproducer.
syzbot has bisected this bug, but I think the bisection result is incorrect.
The original thread for this bug received 6 replies; the last was 111 days ago.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+660883c56e2fa65d4497@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/0000000000008a1bce057ede3d13@google.com
--------------------------------------------------------------------------------
Title: general protection fault in idr_remove
Last occurred: 12 days ago
Reported: 146 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=669469483cd7be33607ad681073484750f6f4c60
Original thread: https://lkml.kernel.org/lkml/00000000000023a7e70581b71894@google.com/T/#u
Unfortunately, this bug does not have a reproducer.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+3d07f0ffd652af4f49e6@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/00000000000023a7e70581b71894@google.com
--------------------------------------------------------------------------------
Title: WARNING: ODEBUG bug in rfcomm_dlc_free
Last occurred: 61 days ago
Reported: 343 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=97b7072a02091741ffc58f97884ab91565fd97ce
Original thread: https://lkml.kernel.org/lkml/00000000000086f39e057245c3ac@google.com/T/#u
This bug has a C reproducer.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+1f6d4ad860c650c2f215@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/00000000000086f39e057245c3ac@google.com
--------------------------------------------------------------------------------
Title: INFO: trying to register non-static key in hci_uart_send_frame
Last occurred: 82 days ago
Reported: 130 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=8aa05f314c1391e788221378935286690d49f482
Original thread: https://lkml.kernel.org/lkml/0000000000001913600582f91f5b@google.com/T/#u
Unfortunately, this bug does not have a reproducer.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+a8587ba69fc78395d947@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/0000000000001913600582f91f5b@google.com
--------------------------------------------------------------------------------
Title: KASAN: use-after-free Read in rfcomm_dlc_open (2)
Last occurred: 49 days ago
Reported: 77 days ago
Branches: net and net-next
Dashboard link: https://syzkaller.appspot.com/bug?id=19321b91aa70d43289d580eb8cbf21e6aecef64f
Original thread: https://lkml.kernel.org/lkml/000000000000876c89058734fc71@google.com/T/#u
Unfortunately, this bug does not have a reproducer.
No one has replied to the original thread for this bug yet.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+0b0fd24d40f358830891@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000876c89058734fc71@google.com
--------------------------------------------------------------------------------
Title: WARNING in kernfs_activate
Last occurred: 84 days ago
Reported: 63 days ago
Branches: Mainline
Dashboard link: https://syzkaller.appspot.com/bug?id=059379fb4ac22ac01d4f2d658aaa6043ff021f42
Original thread: https://lkml.kernel.org/lkml/000000000000fd5e300588491545@google.com/T/#u
Unfortunately, this bug does not have a reproducer.
No one has replied to the original thread for this bug yet.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+1202f8882e4f4881d814@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000fd5e300588491545@google.com
--------------------------------------------------------------------------------
Title: INFO: trying to register non-static key in hci_uart_flush
Last occurred: 148 days ago
Reported: 148 days ago
Branches: Mainline
Dashboard link: https://syzkaller.appspot.com/bug?id=9b359a901fde7f3eacc17249cbd613d35612e9aa
Original thread: https://lkml.kernel.org/lkml/0000000000006941590581a15637@google.com/T/#u
Unfortunately, this bug does not have a reproducer.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+e8cd9d8b4dfedf394390@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/0000000000006941590581a15637@google.com
--------------------------------------------------------------------------------
Title: WARNING: ODEBUG bug in hci_uart_tty_close
Last occurred: 142 days ago
Reported: 141 days ago
Branches: Mainline
Dashboard link: https://syzkaller.appspot.com/bug?id=94b6786a5d26079c82301b2ec235ca4717884f4e
Original thread: https://lkml.kernel.org/lkml/0000000000005455bf058225e9c0@google.com/T/#u
Unfortunately, this bug does not have a reproducer.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+9fd324c8c2176a6022d3@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/0000000000005455bf058225e9c0@google.com
--------------------------------------------------------------------------------
Title: general protection fault in rfcomm_dlc_exists
Last occurred: 67 days ago
Reported: 63 days ago
Branches: net-next
Dashboard link: https://syzkaller.appspot.com/bug?id=1c4e5c426ab13696077aa6d0c67596e074605ffd
Original thread: https://lkml.kernel.org/lkml/0000000000009c83b005884900cf@google.com/T/#u
Unfortunately, this bug does not have a reproducer.
No one has replied to the original thread for this bug yet.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+362be51217ce29d215bc@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/0000000000009c83b005884900cf@google.com
--------------------------------------------------------------------------------
Title: general protection fault in rfcomm_dlc_open
Last occurred: 68 days ago
Reported: 63 days ago
Branches: net-next
Dashboard link: https://syzkaller.appspot.com/bug?id=05e856115d50ca3d56e1fbea58b612a78877be65
Unfortunately, this bug does not have a reproducer.
For some reason the syzbot dashboard doesn't contain a link to the original
thread for this bug, so my script couldn't provide a link to it in this
reminder. Try searching for the bug title.
--------------------------------------------------------------------------------
Title: WARNING in lockdep_register_key
Last occurred: 113 days ago
Reported: 129 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=5f34c586def64408fb57ee0fd898da67efda36c3
Original thread: https://lkml.kernel.org/lkml/000000000000baab660583172b5c@google.com/T/#u
Unfortunately, this bug does not have a reproducer.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+072814ec793ff1946da1@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000baab660583172b5c@google.com
^ permalink raw reply
* Re: [PATCH v3 net-next 19/19] ionic: Add basic devlink interface
From: Shannon Nelson @ 2019-07-09 19:06 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: netdev
In-Reply-To: <20190708182654.72446be5@cakuba.netronome.com>
On 7/8/19 6:26 PM, Jakub Kicinski wrote:
> On Mon, 8 Jul 2019 12:25:32 -0700, Shannon Nelson wrote:
>> Add a devlink interface for access to information that isn't
>> normally available through ethtool or the iplink interface.
>>
>> Example:
>> $ ./devlink -j -p dev info pci/0000:b6:00.0
>> {
>> "info": {
>> "pci/0000:b6:00.0": {
>> "driver": "ionic",
>> "serial_number": "FLM18420073",
>> "versions": {
>> "fixed": {
>> "fw_version": "0.11.0-50",
> Hm. Fixed is for hardware components. Seeing FW version reported as
> fixed seems counter intuitive. You probably want "running"?
Sure.
>
>> "fw_status": "0x1",
> I don't think this is the right interface to report status-like
> information. Perhaps devlink health reporters?
>
>> "fw_heartbeat": "0x716ce",
> Ditto, perhaps best to report it in health stuff?
I haven't dug too far into the health stuff, but on the surface it looks
like a lot of infrastructure for a couple of simple values. I'm tempted
to put them back into debugfs for the moment rather than add that much
more interface goo.
>
>> "asic_type": "0x0",
>> "asic_rev": "0x0"
> These seem like legit "fixed" versions 👍
>
>> }
>> }
>> }
>> }
>> }
>>
>> Signed-off-by: Shannon Nelson <snelson@pensando.io>
> Isn't this a new patch? Perhaps you'd be best off upstreaming the
> first batch of support and add features later? It'd be easier on
> reviewers so we don't have to keep re-checking the first 16 patches..
Yes, and I commented about this in v2 notes: in the tension between
trying to address comments, keep the line count down, keep the basic
feature set, and keep the patches self-consistent and simple, I added
this one patch for the devlink goodies that were requested. At least the
total line count went down.
sln
^ permalink raw reply
* Re: [PATCH net-next v6 0/5] devlink: Introduce PCI PF, VF ports and attributes
From: David Miller @ 2019-07-09 19:03 UTC (permalink / raw)
To: jakub.kicinski; +Cc: jiri, parav, netdev, jiri, saeedm
In-Reply-To: <20190709112058.7ffe61d3@cakuba.netronome.com>
From: Jakub Kicinski <jakub.kicinski@netronome.com>
Date: Tue, 9 Jul 2019 11:20:58 -0700
> On Tue, 9 Jul 2019 08:17:11 +0200, Jiri Pirko wrote:
>> >But I'll leave it to Jiri and Dave to decide if its worth a respin :)
>> >Functionally I think this is okay.
>>
>> I'm happy with the set as it is right now.
>
> To be clear, I am happy enough as well. Hence the review tag.
Series applied, thanks everyone.
>> Anyway, if you want your concerns to be addresses, you should write
>> them to the appropriate code. This list is hard to follow.
>
> Sorry, I was trying to be concise.
Jiri et al., if Jakub put forth the time and effort to make the list
and give you feedback you can put forth the effort to go through the
list and address his feedback with follow-up patches. You cannot
dictate how people give feedback to your changes, thank you.
^ permalink raw reply
* [PATCH] [net-next] net: dsa: vsc73xx: fix NET_DSA and OF dependencies
From: Arnd Bergmann @ 2019-07-09 18:55 UTC (permalink / raw)
To: Andrew Lunn, Vivien Didelot, Florian Fainelli, David S. Miller
Cc: Arnd Bergmann, Pawel Dembicki, Linus Walleij, netdev,
linux-kernel
The restructuring of the driver got the dependencies wrong: without
CONFIG_NET_DSA we get this build failure:
WARNING: unmet direct dependencies detected for NET_DSA_VITESSE_VSC73XX
Depends on [n]: NETDEVICES [=y] && HAVE_NET_DSA [=y] && OF [=y] && NET_DSA [=n]
Selected by [m]:
- NET_DSA_VITESSE_VSC73XX_PLATFORM [=m] && NETDEVICES [=y] && HAVE_NET_DSA [=y] && HAS_IOMEM [=y]
ERROR: "dsa_unregister_switch" [drivers/net/dsa/vitesse-vsc73xx-core.ko] undefined!
ERROR: "dsa_switch_alloc" [drivers/net/dsa/vitesse-vsc73xx-core.ko] undefined!
ERROR: "dsa_register_switch" [drivers/net/dsa/vitesse-vsc73xx-core.ko] undefined!
Add the appropriate dependencies.
Fixes: 95711cd5f0b4 ("net: dsa: vsc73xx: Split vsc73xx driver")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/net/dsa/Kconfig | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/net/dsa/Kconfig b/drivers/net/dsa/Kconfig
index cf9dbd15dd2d..f6232ce8481f 100644
--- a/drivers/net/dsa/Kconfig
+++ b/drivers/net/dsa/Kconfig
@@ -111,6 +111,8 @@ config NET_DSA_VITESSE_VSC73XX
config NET_DSA_VITESSE_VSC73XX_SPI
tristate "Vitesse VSC7385/7388/7395/7398 SPI mode support"
+ depends on OF
+ depends on NET_DSA
depends on SPI
select NET_DSA_VITESSE_VSC73XX
---help---
@@ -119,6 +121,8 @@ config NET_DSA_VITESSE_VSC73XX_SPI
config NET_DSA_VITESSE_VSC73XX_PLATFORM
tristate "Vitesse VSC7385/7388/7395/7398 Platform mode support"
+ depends on OF
+ depends on NET_DSA
depends on HAS_IOMEM
select NET_DSA_VITESSE_VSC73XX
---help---
--
2.20.0
^ permalink raw reply related
* Re: WARNING in mark_chain_precision
From: Andrii Nakryiko @ 2019-07-09 18:55 UTC (permalink / raw)
To: syzbot
Cc: aaron.f.brown, Alexei Starovoitov, bpf, Daniel Borkmann,
David S. Miller, hawk, intel-wired-lan, Jakub Kicinski,
jeffrey.t.kirsher, john fastabend, Martin Lau, open list,
Networking, sasha.neftin, Song Liu, syzkaller-bugs, xdp-newbies,
Yonghong Song
In-Reply-To: <000000000000a94981058d37f1a4@google.com>
Original reproducer is almost identical to the one that is fixed by
https://patchwork.ozlabs.org/patch/1129479/.
bpf_prog_free_deferred bug that's undeterministically exposed after
this fix seems to be the cause of a bunch of other bug reports and is
not related to verifier precision tracking.
#syz dup: WARNING in __mark_chain_precision
^ 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