* Re: [PATCH v2 net-next 06/21] net: usb: aqc111: Introduce link management
From: Florian Fainelli @ 2018-11-14 22:53 UTC (permalink / raw)
To: Andrew Lunn, Igor Russkikh
Cc: David S . Miller, linux-usb@vger.kernel.org,
netdev@vger.kernel.org, Dmitry Bezrukov
In-Reply-To: <20181114211643.GF32305@lunn.ch>
On 11/14/18 1:16 PM, Andrew Lunn wrote:
>>> Thats again because of this product has tightly integrated MAC+Phy.
>>> MAC FW controls system interface and reports/alters link state
>>> as a joint state on copper and SIF (even in dpa direct phy mode).
>>>
>>> We can't extract phy api into a standalone fully functional phylib therefore.
>>> Also as far as I know this particular phy is not available in the wild.
>>
>> So the point is that MAC firmware is managing SERDES and system interface link.
>
> Linux can manage that SERDES link between the MAC and the PHY. There
> are two ways this can go:
>
> 1) You use phylib. When the PHY reports link, the adjust_link callback
> in the MAC is called. The phydev structure contains information about
> how you should configure the SERDES, SGMII, 2500Base-X, 5000Base-X. It
> works, but it is not so nice.
>
> 2) phylink gives you a much nicer API to do the same. Again, the PHY
> reports the link is up. phylink will then tell the MAC how to
> configure its end of the SERDES. The problem with phylink is that it
> expects a DT building. You don't have that, since this is a USB
> device. But you also don't need a lot of the features of phylink like
> SFPs, the i2c bus for the SFPs, GPIOs etc. So it should not be to hard
> to make this work without device tree.
>
> By using core linux code, we avoid bugs in firmware which nobody can
> fix. The Linux core code should be well tested and supported, but
> phylink is rather new, so might still have some corner cases.
>
> I also cannot imaging parts of the PHY driver will not be re-usable
> for other Aquantia PHYs. I have a board with an AQCS109 under my desk
> waiting for me to do something with it. I really would like a better
> PHY driver for it than the kernel currently has. Hopefully there is
> some code reuse possibilities here.
Even if the firmware is helping, there is still value in using PHYLINK
to report things to Linux as Andrew is saying in that you get a lot of
things for free: auto-negotiation results, link_ksetttings_{get,set} etc.
--
Florian
^ permalink raw reply
* Re: xfrm: policy: add inexact policy search tree infrastructure
From: Florian Westphal @ 2018-11-14 22:44 UTC (permalink / raw)
To: Colin Ian King
Cc: Florian Westphal, Steffen Klassert, Herbert Xu, David S. Miller,
netdev@vger.kernel.org
In-Reply-To: <f09a304d-54b3-b781-ec4c-e06dd3b3c7b6@canonical.com>
Colin Ian King <colin.king@canonical.com> wrote:
> Hi,
>
> Static analysis with CoverityScan found a potential issue with the commit:
>
> commit 6be3b0db6db82cf056a72cc18042048edd27f8ee
> Author: Florian Westphal <fw@strlen.de>
> Date: Wed Nov 7 23:00:37 2018 +0100
>
> xfrm: policy: add inexact policy search tree infrastructure
>
> It seems that pointer pol is set to NULL and then a check to see if it
> is non-null is used to set pol to tmp; howeverm this check is always
> going to be false because pol is always NULL.
Right. This is in the control-plane code to retrieve a policy
via netlink or PF_KEY.
> The issue is reported by CoverityScan as follows:
>
> Line
> 1658
> assignment: Assigning: pol = NULL.
> 1659 pol = NULL;
> 1660 for (i = 0; i < ARRAY_SIZE(cand.res); i++) {
> 1661 struct xfrm_policy *tmp;
> 1662
> 1663 tmp = __xfrm_policy_bysel_ctx(cand.res[i], mark,
> 1664 if_id, type, dir,
> 1665 sel, ctx);
>
> null: At condition pol, the value of pol must be NULL.
> dead_error_condition: The condition pol cannot be true.
>
> CID 1475480 (#1 of 1): Logically dead code
>
> (DEADCODE) dead_error_line: Execution cannot reach the expression
> tmp->pos < pol->pos inside this statement: if (tmp && pol && tmp->pos ....
>
> 1666 if (tmp && pol && tmp->pos < pol->pos)
> 1667 pol = tmp;
>
>
> I suspect this is not intentional and is probably a bug.
Right, bug. Would like to just break after first 'tmp != NULL' but
that might make us return a different policy than old linear search.
So we should update pol in case its NULL as well.
Steffen, let me know if you want an incremental fix or if you
prefer to squash this:
diff --git a/net/xfrm/xfrm_policy.c b/net/xfrm/xfrm_policy.c
--- a/net/xfrm/xfrm_policy.c
+++ b/net/xfrm/xfrm_policy.c
@@ -1663,7 +1663,10 @@ struct xfrm_policy *xfrm_policy_bysel_ctx(struct net *net, u32 mark, u32 if_id,
tmp = __xfrm_policy_bysel_ctx(cand.res[i], mark,
if_id, type, dir,
sel, ctx);
- if (tmp && pol && tmp->pos < pol->pos)
+ if (!tmp)
+ continue;
+
+ if (!pol || tmp->pos < pol->pol)
pol = tmp;
}
} else {
^ permalink raw reply
* re: xfrm: policy: add inexact policy search tree infrastructure
From: Colin Ian King @ 2018-11-14 22:26 UTC (permalink / raw)
To: Florian Westphal
Cc: Steffen Klassert, Herbert Xu, David S. Miller,
netdev@vger.kernel.org
Hi,
Static analysis with CoverityScan found a potential issue with the commit:
commit 6be3b0db6db82cf056a72cc18042048edd27f8ee
Author: Florian Westphal <fw@strlen.de>
Date: Wed Nov 7 23:00:37 2018 +0100
xfrm: policy: add inexact policy search tree infrastructure
It seems that pointer pol is set to NULL and then a check to see if it
is non-null is used to set pol to tmp; howeverm this check is always
going to be false because pol is always NULL.
The issue is reported by CoverityScan as follows:
Line
1658
assignment: Assigning: pol = NULL.
1659 pol = NULL;
1660 for (i = 0; i < ARRAY_SIZE(cand.res); i++) {
1661 struct xfrm_policy *tmp;
1662
1663 tmp = __xfrm_policy_bysel_ctx(cand.res[i], mark,
1664 if_id, type, dir,
1665 sel, ctx);
null: At condition pol, the value of pol must be NULL.
dead_error_condition: The condition pol cannot be true.
CID 1475480 (#1 of 1): Logically dead code
(DEADCODE) dead_error_line: Execution cannot reach the expression
tmp->pos < pol->pos inside this statement: if (tmp && pol && tmp->pos ....
1666 if (tmp && pol && tmp->pos < pol->pos)
1667 pol = tmp;
1668 }
I suspect this is not intentional and is probably a bug.
Colin
^ permalink raw reply
* Re: [RFC] Discuss about an new idea "Vsock over Virtio-net"
From: jiangyiwen @ 2018-11-15 8:38 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: kvm, virtualization, stefanha, netdev
In-Reply-To: <20181115025622-mutt-send-email-mst@kernel.org>
On 2018/11/15 16:10, Michael S. Tsirkin wrote:
> On Thu, Nov 15, 2018 at 03:38:15PM +0800, jiangyiwen wrote:
>> On 2018/11/15 15:04, Michael S. Tsirkin wrote:
>>> On Thu, Nov 15, 2018 at 11:56:03AM +0800, jiangyiwen wrote:
>>>> Hi Stefan, Michael, Jason and everyone,
>>>>
>>>> Several days ago, I discussed with jason about "Vsock over Virtio-net".
>>>> This idea has two advantages:
>>>> First, it can use many great features of virtio-net, like batching,
>>>> mergeable rx buffer and multiqueue, etc.
>>>> Second, it can reduce many duplicate codes and make it easy to be
>>>> maintained.
>>>
>>> I'm not sure I get the motivation. Which features of
>>> virtio net are relevant to vsock? The ones that you mention
>>> all seem to be mostly of use to the networking stack.
>>>
>>>
>>>> Before the implement, I want to discuss with everyone again, and
>>>> want to know everyone's suggestions.
>>>>
>>>> After the discussion, based on this point I will try to implement
>>>> this idea, but I am not familiar with the virtio-net, that is a
>>>> pity. :(
>>>>
>>>> -------------------------Simple idea------------------------------
>>>>
>>>> 1. The packet layout will become as follows:
>>>>
>>>> +---------------------------------+
>>>> | Virtio-net header |
>>>> |(struct virtio_net_hdr_mrg_rxbuf)|
>>>
>>> Which fields in virtio_net_hdr_mrg_rxbuf are of interest to vsock?
>>>
>>
>> Hi Michael,
>>
>> Yes, currently vsock has poor performance, first, it only support transport
>> small packet, in order to make the balance between performance and guest memory.
>>
>> In order to solve this problem, there are two features vsock can used,
>> mergeable rx buffer and multiqueue. Based on this, there are some shared
>> codes vsock can use.
>>
>> Thanks,
>> Yiwen.
>
> Supporting more queues with vsock is probably significantly
> less work than a completely new interface.
> For mergeable, as buffers are split arbitrarily, why can't you combine
> them within guest driver before sending them up the stack?
> Probably better than relying on host to do it.
>
Actually, I want to said the mergeable *rx* buffer, it cause the
default packet size of vsock is set to 4k. For tx buffer, it is
actually can be scattered in tx vq only need to modify very few codes.
In addition, I has already first version about vsock support mergeable
rx buffer and send patch to the VSOCK community, these codes are
revisited from virtio-net, and some codes are duplicated. Based on
this, we want to use virtio-net as transport of vsock. It can make
the vsock code easy to maintained.
Thanks.
>>>> +---------------------------------+
>>>> | Vsock header |
>>>> | (struct virtio_vsock_hdr) |
>>>> +---------------------------------+
>>>> | payload |
>>>> | (until end of packet) |
>>>> +---------------------------------+
>>>
>>> Thanks,
>>>
>>
>
> .
>
^ permalink raw reply
* [PATCH AUTOSEL 4.14 07/27] net: systemport: Protect stop from timeout
From: Sasha Levin @ 2018-11-14 22:24 UTC (permalink / raw)
To: stable, linux-kernel
Cc: Florian Fainelli, David S . Miller, Sasha Levin, netdev
In-Reply-To: <20181114222520.99926-1-sashal@kernel.org>
From: Florian Fainelli <f.fainelli@gmail.com>
[ Upstream commit 7cb6a2a2c72c1ed8f42fb01f1a661281b568dead ]
A timing hazard exists when the network interface is stopped that
allows a watchdog timeout to be processed by a separate core in
parallel. This creates the potential for the timeout handler to
wake the queues while the driver is shutting down, or access
registers after their clocks have been removed.
The more common case is that the watchdog timeout will produce a
warning message which doesn't lead to a crash. The chances of this
are greatly increased by the fact that bcm_sysport_netif_stop stops
the transmit queues which can easily precipitate a watchdog time-
out because of stale trans_start data in the queues.
This commit corrects the behavior by ensuring that the watchdog
timeout is disabled before enterring bcm_sysport_netif_stop. There
are currently only two users of the bcm_sysport_netif_stop function:
close and suspend.
The close case already handles the issue by exiting the RUNNING
state before invoking the driver close service.
The suspend case now performs the netif_device_detach to exit the
PRESENT state before the call to bcm_sysport_netif_stop rather than
after it.
These behaviors prevent any future scheduling of the driver timeout
service during the window. The netif_tx_stop_all_queues function
in bcm_sysport_netif_stop is replaced with netif_tx_disable to ensure
synchronization with any transmit or timeout threads that may
already be executing on other cores.
For symmetry, the netif_device_attach call upon resume is moved to
after the call to bcm_sysport_netif_start. Since it wakes the transmit
queues it is not necessary to invoke netif_tx_start_all_queues from
bcm_sysport_netif_start so it is moved into the driver open service.
Fixes: 40755a0fce17 ("net: systemport: add suspend and resume support")
Fixes: 80105befdb4b ("net: systemport: add Broadcom SYSTEMPORT Ethernet MAC driver")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/broadcom/bcmsysport.c | 15 +++++++--------
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bcmsysport.c b/drivers/net/ethernet/broadcom/bcmsysport.c
index 6e7f9a470ea1..45462557e51c 100644
--- a/drivers/net/ethernet/broadcom/bcmsysport.c
+++ b/drivers/net/ethernet/broadcom/bcmsysport.c
@@ -1774,9 +1774,6 @@ static void bcm_sysport_netif_start(struct net_device *dev)
intrl2_1_mask_clear(priv, 0xffffffff);
else
intrl2_0_mask_clear(priv, INTRL2_0_TDMA_MBDONE_MASK);
-
- /* Last call before we start the real business */
- netif_tx_start_all_queues(dev);
}
static void rbuf_init(struct bcm_sysport_priv *priv)
@@ -1922,6 +1919,8 @@ static int bcm_sysport_open(struct net_device *dev)
bcm_sysport_netif_start(dev);
+ netif_tx_start_all_queues(dev);
+
return 0;
out_clear_rx_int:
@@ -1945,7 +1944,7 @@ static void bcm_sysport_netif_stop(struct net_device *dev)
struct bcm_sysport_priv *priv = netdev_priv(dev);
/* stop all software from updating hardware */
- netif_tx_stop_all_queues(dev);
+ netif_tx_disable(dev);
napi_disable(&priv->napi);
phy_stop(dev->phydev);
@@ -2267,12 +2266,12 @@ static int bcm_sysport_suspend(struct device *d)
if (!netif_running(dev))
return 0;
+ netif_device_detach(dev);
+
bcm_sysport_netif_stop(dev);
phy_suspend(dev->phydev);
- netif_device_detach(dev);
-
/* Disable UniMAC RX */
umac_enable_set(priv, CMD_RX_EN, 0);
@@ -2356,8 +2355,6 @@ static int bcm_sysport_resume(struct device *d)
goto out_free_rx_ring;
}
- netif_device_attach(dev);
-
/* RX pipe enable */
topctrl_writel(priv, 0, RX_FLUSH_CNTL);
@@ -2402,6 +2399,8 @@ static int bcm_sysport_resume(struct device *d)
bcm_sysport_netif_start(dev);
+ netif_device_attach(dev);
+
return 0;
out_free_rx_ring:
--
2.17.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.14 02/27] netfilter: ipset: list:set: Decrease refcount synchronously on deletion and replace
From: Sasha Levin @ 2018-11-14 22:24 UTC (permalink / raw)
To: stable, linux-kernel
Cc: Stefano Brivio, Jozsef Kadlecsik, Pablo Neira Ayuso, Sasha Levin,
netfilter-devel, coreteam, netdev
In-Reply-To: <20181114222520.99926-1-sashal@kernel.org>
From: Stefano Brivio <sbrivio@redhat.com>
[ Upstream commit 439cd39ea136d2c026805264d58a91f36b6b64ca ]
Commit 45040978c899 ("netfilter: ipset: Fix set:list type crash
when flush/dump set in parallel") postponed decreasing set
reference counters to the RCU callback.
An 'ipset del' command can terminate before the RCU grace period
is elapsed, and if sets are listed before then, the reference
counter shown in userspace will be wrong:
# ipset create h hash:ip; ipset create l list:set; ipset add l
# ipset del l h; ipset list h
Name: h
Type: hash:ip
Revision: 4
Header: family inet hashsize 1024 maxelem 65536
Size in memory: 88
References: 1
Number of entries: 0
Members:
# sleep 1; ipset list h
Name: h
Type: hash:ip
Revision: 4
Header: family inet hashsize 1024 maxelem 65536
Size in memory: 88
References: 0
Number of entries: 0
Members:
Fix this by making the reference count update synchronous again.
As a result, when sets are listed, ip_set_name_byindex() might
now fetch a set whose reference count is already zero. Instead
of relying on the reference count to protect against concurrent
set renaming, grab ip_set_ref_lock as reader and copy the name,
while holding the same lock in ip_set_rename() as writer
instead.
Reported-by: Li Shuang <shuali@redhat.com>
Fixes: 45040978c899 ("netfilter: ipset: Fix set:list type crash when flush/dump set in parallel")
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Signed-off-by: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
include/linux/netfilter/ipset/ip_set.h | 2 +-
net/netfilter/ipset/ip_set_core.c | 23 +++++++++++------------
net/netfilter/ipset/ip_set_list_set.c | 17 +++++++++++------
3 files changed, 23 insertions(+), 19 deletions(-)
diff --git a/include/linux/netfilter/ipset/ip_set.h b/include/linux/netfilter/ipset/ip_set.h
index 8e42253e5d4d..91a533bd3eb1 100644
--- a/include/linux/netfilter/ipset/ip_set.h
+++ b/include/linux/netfilter/ipset/ip_set.h
@@ -312,7 +312,7 @@ enum {
extern ip_set_id_t ip_set_get_byname(struct net *net,
const char *name, struct ip_set **set);
extern void ip_set_put_byindex(struct net *net, ip_set_id_t index);
-extern const char *ip_set_name_byindex(struct net *net, ip_set_id_t index);
+extern void ip_set_name_byindex(struct net *net, ip_set_id_t index, char *name);
extern ip_set_id_t ip_set_nfnl_get_byindex(struct net *net, ip_set_id_t index);
extern void ip_set_nfnl_put(struct net *net, ip_set_id_t index);
diff --git a/net/netfilter/ipset/ip_set_core.c b/net/netfilter/ipset/ip_set_core.c
index 9d2ce1459cec..a3f1dc7cf538 100644
--- a/net/netfilter/ipset/ip_set_core.c
+++ b/net/netfilter/ipset/ip_set_core.c
@@ -668,21 +668,20 @@ ip_set_put_byindex(struct net *net, ip_set_id_t index)
EXPORT_SYMBOL_GPL(ip_set_put_byindex);
/* Get the name of a set behind a set index.
- * We assume the set is referenced, so it does exist and
- * can't be destroyed. The set cannot be renamed due to
- * the referencing either.
- *
+ * Set itself is protected by RCU, but its name isn't: to protect against
+ * renaming, grab ip_set_ref_lock as reader (see ip_set_rename()) and copy the
+ * name.
*/
-const char *
-ip_set_name_byindex(struct net *net, ip_set_id_t index)
+void
+ip_set_name_byindex(struct net *net, ip_set_id_t index, char *name)
{
- const struct ip_set *set = ip_set_rcu_get(net, index);
+ struct ip_set *set = ip_set_rcu_get(net, index);
BUG_ON(!set);
- BUG_ON(set->ref == 0);
- /* Referenced, so it's safe */
- return set->name;
+ read_lock_bh(&ip_set_ref_lock);
+ strncpy(name, set->name, IPSET_MAXNAMELEN);
+ read_unlock_bh(&ip_set_ref_lock);
}
EXPORT_SYMBOL_GPL(ip_set_name_byindex);
@@ -1128,7 +1127,7 @@ static int ip_set_rename(struct net *net, struct sock *ctnl,
if (!set)
return -ENOENT;
- read_lock_bh(&ip_set_ref_lock);
+ write_lock_bh(&ip_set_ref_lock);
if (set->ref != 0) {
ret = -IPSET_ERR_REFERENCED;
goto out;
@@ -1145,7 +1144,7 @@ static int ip_set_rename(struct net *net, struct sock *ctnl,
strncpy(set->name, name2, IPSET_MAXNAMELEN);
out:
- read_unlock_bh(&ip_set_ref_lock);
+ write_unlock_bh(&ip_set_ref_lock);
return ret;
}
diff --git a/net/netfilter/ipset/ip_set_list_set.c b/net/netfilter/ipset/ip_set_list_set.c
index 178d4eba013b..75d52aed6fdb 100644
--- a/net/netfilter/ipset/ip_set_list_set.c
+++ b/net/netfilter/ipset/ip_set_list_set.c
@@ -156,9 +156,7 @@ __list_set_del_rcu(struct rcu_head * rcu)
{
struct set_elem *e = container_of(rcu, struct set_elem, rcu);
struct ip_set *set = e->set;
- struct list_set *map = set->data;
- ip_set_put_byindex(map->net, e->id);
ip_set_ext_destroy(set, e);
kfree(e);
}
@@ -166,15 +164,21 @@ __list_set_del_rcu(struct rcu_head * rcu)
static inline void
list_set_del(struct ip_set *set, struct set_elem *e)
{
+ struct list_set *map = set->data;
+
set->elements--;
list_del_rcu(&e->list);
+ ip_set_put_byindex(map->net, e->id);
call_rcu(&e->rcu, __list_set_del_rcu);
}
static inline void
-list_set_replace(struct set_elem *e, struct set_elem *old)
+list_set_replace(struct ip_set *set, struct set_elem *e, struct set_elem *old)
{
+ struct list_set *map = set->data;
+
list_replace_rcu(&old->list, &e->list);
+ ip_set_put_byindex(map->net, old->id);
call_rcu(&old->rcu, __list_set_del_rcu);
}
@@ -306,7 +310,7 @@ list_set_uadd(struct ip_set *set, void *value, const struct ip_set_ext *ext,
INIT_LIST_HEAD(&e->list);
list_set_init_extensions(set, ext, e);
if (n)
- list_set_replace(e, n);
+ list_set_replace(set, e, n);
else if (next)
list_add_tail_rcu(&e->list, &next->list);
else if (prev)
@@ -497,6 +501,7 @@ list_set_list(const struct ip_set *set,
const struct list_set *map = set->data;
struct nlattr *atd, *nested;
u32 i = 0, first = cb->args[IPSET_CB_ARG0];
+ char name[IPSET_MAXNAMELEN];
struct set_elem *e;
int ret = 0;
@@ -515,8 +520,8 @@ list_set_list(const struct ip_set *set,
nested = ipset_nest_start(skb, IPSET_ATTR_DATA);
if (!nested)
goto nla_put_failure;
- if (nla_put_string(skb, IPSET_ATTR_NAME,
- ip_set_name_byindex(map->net, e->id)))
+ ip_set_name_byindex(map->net, e->id, name);
+ if (nla_put_string(skb, IPSET_ATTR_NAME, name))
goto nla_put_failure;
if (ip_set_put_extensions(skb, set, e, true))
goto nla_put_failure;
--
2.17.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.18 13/59] net: bcmgenet: protect stop from timeout
From: Sasha Levin @ 2018-11-14 22:22 UTC (permalink / raw)
To: stable, linux-kernel
Cc: Doug Berger, Florian Fainelli, David S . Miller, Sasha Levin,
netdev
In-Reply-To: <20181114222335.99339-1-sashal@kernel.org>
From: Doug Berger <opendmb@gmail.com>
[ Upstream commit 09e805d2570a3a94f13dd9c9ad2bcab23da76e09 ]
A timing hazard exists when the network interface is stopped that
allows a watchdog timeout to be processed by a separate core in
parallel. This creates the potential for the timeout handler to
wake the queues while the driver is shutting down, or access
registers after their clocks have been removed.
The more common case is that the watchdog timeout will produce a
warning message which doesn't lead to a crash. The chances of this
are greatly increased by the fact that bcmgenet_netif_stop stops
the transmit queues which can easily precipitate a watchdog time-
out because of stale trans_start data in the queues.
This commit corrects the behavior by ensuring that the watchdog
timeout is disabled before enterring bcmgenet_netif_stop. There
are currently only two users of the bcmgenet_netif_stop function:
close and suspend.
The close case already handles the issue by exiting the RUNNING
state before invoking the driver close service.
The suspend case now performs the netif_device_detach to exit the
PRESENT state before the call to bcmgenet_netif_stop rather than
after it.
These behaviors prevent any future scheduling of the driver timeout
service during the window. The netif_tx_stop_all_queues function
in bcmgenet_netif_stop is replaced with netif_tx_disable to ensure
synchronization with any transmit or timeout threads that may
already be executing on other cores.
For symmetry, the netif_device_attach call upon resume is moved to
after the call to bcmgenet_netif_start. Since it wakes the transmit
queues it is not necessary to invoke netif_tx_start_all_queues from
bcmgenet_netif_start so it is moved into the driver open service.
Fixes: 1c1008c793fa ("net: bcmgenet: add main driver file")
Signed-off-by: Doug Berger <opendmb@gmail.com>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/broadcom/genet/bcmgenet.c | 13 +++++++------
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/genet/bcmgenet.c b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
index 20c1681bb1af..2d6f090bf644 100644
--- a/drivers/net/ethernet/broadcom/genet/bcmgenet.c
+++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
@@ -2855,7 +2855,6 @@ static void bcmgenet_netif_start(struct net_device *dev)
umac_enable_set(priv, CMD_TX_EN | CMD_RX_EN, true);
- netif_tx_start_all_queues(dev);
bcmgenet_enable_tx_napi(priv);
/* Monitor link interrupts now */
@@ -2937,6 +2936,8 @@ static int bcmgenet_open(struct net_device *dev)
bcmgenet_netif_start(dev);
+ netif_tx_start_all_queues(dev);
+
return 0;
err_irq1:
@@ -2958,7 +2959,7 @@ static void bcmgenet_netif_stop(struct net_device *dev)
struct bcmgenet_priv *priv = netdev_priv(dev);
bcmgenet_disable_tx_napi(priv);
- netif_tx_stop_all_queues(dev);
+ netif_tx_disable(dev);
/* Disable MAC receive */
umac_enable_set(priv, CMD_RX_EN, false);
@@ -3620,13 +3621,13 @@ static int bcmgenet_suspend(struct device *d)
if (!netif_running(dev))
return 0;
+ netif_device_detach(dev);
+
bcmgenet_netif_stop(dev);
if (!device_may_wakeup(d))
phy_suspend(dev->phydev);
- netif_device_detach(dev);
-
/* Prepare the device for Wake-on-LAN and switch to the slow clock */
if (device_may_wakeup(d) && priv->wolopts) {
ret = bcmgenet_power_down(priv, GENET_POWER_WOL_MAGIC);
@@ -3700,8 +3701,6 @@ static int bcmgenet_resume(struct device *d)
/* Always enable ring 16 - descriptor ring */
bcmgenet_enable_dma(priv, dma_ctrl);
- netif_device_attach(dev);
-
if (!device_may_wakeup(d))
phy_resume(dev->phydev);
@@ -3710,6 +3709,8 @@ static int bcmgenet_resume(struct device *d)
bcmgenet_netif_start(dev);
+ netif_device_attach(dev);
+
return 0;
out_clk_disable:
--
2.17.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.18 12/59] net: dsa: microchip: initialize mutex before use
From: Sasha Levin @ 2018-11-14 22:22 UTC (permalink / raw)
To: stable, linux-kernel; +Cc: Tristram Ha, David S . Miller, Sasha Levin, netdev
In-Reply-To: <20181114222335.99339-1-sashal@kernel.org>
From: Tristram Ha <Tristram.Ha@microchip.com>
[ Upstream commit 284fb78ed7572117846f8e1d1d8e3dbfd16880c2 ]
Initialize mutex before use. Avoid kernel complaint when
CONFIG_DEBUG_LOCK_ALLOC is enabled.
Fixes: b987e98e50ab90e5 ("dsa: add DSA switch driver for Microchip KSZ9477")
Signed-off-by: Tristram Ha <Tristram.Ha@microchip.com>
Reviewed-by: Pavel Machek <pavel@ucw.cz>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/dsa/microchip/ksz_common.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/net/dsa/microchip/ksz_common.c b/drivers/net/dsa/microchip/ksz_common.c
index 7210c49b7922..c3103bdb6cf6 100644
--- a/drivers/net/dsa/microchip/ksz_common.c
+++ b/drivers/net/dsa/microchip/ksz_common.c
@@ -1108,11 +1108,6 @@ static int ksz_switch_init(struct ksz_device *dev)
{
int i;
- mutex_init(&dev->reg_mutex);
- mutex_init(&dev->stats_mutex);
- mutex_init(&dev->alu_mutex);
- mutex_init(&dev->vlan_mutex);
-
dev->ds->ops = &ksz_switch_ops;
for (i = 0; i < ARRAY_SIZE(ksz_switch_chips); i++) {
@@ -1197,6 +1192,11 @@ int ksz_switch_register(struct ksz_device *dev)
if (dev->pdata)
dev->chip_id = dev->pdata->chip_id;
+ mutex_init(&dev->reg_mutex);
+ mutex_init(&dev->stats_mutex);
+ mutex_init(&dev->alu_mutex);
+ mutex_init(&dev->vlan_mutex);
+
if (ksz_switch_detect(dev))
return -EINVAL;
--
2.17.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.18 10/59] bpf: fix bpf_prog_get_info_by_fd to return 0 func_lens for unpriv
From: Sasha Levin @ 2018-11-14 22:22 UTC (permalink / raw)
To: stable, linux-kernel
Cc: Daniel Borkmann, Sandipan Das, Song Liu, Alexei Starovoitov,
Sasha Levin, netdev
In-Reply-To: <20181114222335.99339-1-sashal@kernel.org>
From: Daniel Borkmann <daniel@iogearbox.net>
[ Upstream commit 28c2fae726bf5003cd209b0d5910a642af98316f ]
While dbecd7388476 ("bpf: get kernel symbol addresses via syscall")
zeroed info.nr_jited_ksyms in bpf_prog_get_info_by_fd() for queries
from unprivileged users, commit 815581c11cc2 ("bpf: get JITed image
lengths of functions via syscall") forgot about doing so and therefore
returns the #elems of the user set up buffer which is incorrect. It
also needs to indicate a info.nr_jited_func_lens of zero.
Fixes: 815581c11cc2 ("bpf: get JITed image lengths of functions via syscall")
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Cc: Sandipan Das <sandipan@linux.vnet.ibm.com>
Cc: Song Liu <songliubraving@fb.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
kernel/bpf/syscall.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
index a31a1ba0f8ea..482215292b0f 100644
--- a/kernel/bpf/syscall.c
+++ b/kernel/bpf/syscall.c
@@ -1896,6 +1896,7 @@ static int bpf_prog_get_info_by_fd(struct bpf_prog *prog,
info.jited_prog_len = 0;
info.xlated_prog_len = 0;
info.nr_jited_ksyms = 0;
+ info.nr_jited_func_lens = 0;
goto done;
}
--
2.17.1
^ permalink raw reply related
* Re: [RFC] Discuss about an new idea "Vsock over Virtio-net"
From: Jason Wang @ 2018-11-15 8:24 UTC (permalink / raw)
To: Michael S. Tsirkin, jiangyiwen; +Cc: virtualization, kvm, stefanha, netdev
In-Reply-To: <20181115015547-mutt-send-email-mst@kernel.org>
On 2018/11/15 下午3:04, Michael S. Tsirkin wrote:
> On Thu, Nov 15, 2018 at 11:56:03AM +0800, jiangyiwen wrote:
>> Hi Stefan, Michael, Jason and everyone,
>>
>> Several days ago, I discussed with jason about "Vsock over Virtio-net".
>> This idea has two advantages:
>> First, it can use many great features of virtio-net, like batching,
>> mergeable rx buffer and multiqueue, etc.
>> Second, it can reduce many duplicate codes and make it easy to be
>> maintained.
> I'm not sure I get the motivation. Which features of
> virtio net are relevant to vsock?
Vsock is just a L2 (and above) protocol from the view of the device. So
I think we should answer the question why we need two different paths
for networking traffic? Or what is the fundamental reason that makes
vsock does not go for virtio-net?
I agree they could be different type of devices but codes could be
shared in both guest and host (or even qemu) for not duplicating
features(bugs).
Thanks
> The ones that you mention
> all seem to be mostly of use to the networking stack.
>
>
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [RFC] Discuss about an new idea "Vsock over Virtio-net"
From: Jason Wang @ 2018-11-15 8:19 UTC (permalink / raw)
To: jiangyiwen, stefanha, stefanha, mst; +Cc: netdev, kvm, virtualization
In-Reply-To: <5BED162C.5070902@huawei.com>
On 2018/11/15 下午2:46, jiangyiwen wrote:
> On 2018/11/15 12:19, Jason Wang wrote:
>> On 2018/11/15 上午11:56, jiangyiwen wrote:
>>> Hi Stefan, Michael, Jason and everyone,
>>>
>>> Several days ago, I discussed with jason about "Vsock over Virtio-net".
>>> This idea has two advantages:
>>> First, it can use many great features of virtio-net, like batching,
>>> mergeable rx buffer and multiqueue, etc.
>>> Second, it can reduce many duplicate codes and make it easy to be
>>> maintained.
>>>
>>> Before the implement, I want to discuss with everyone again, and
>>> want to know everyone's suggestions.
>>>
>>> After the discussion, based on this point I will try to implement
>>> this idea, but I am not familiar with the virtio-net, that is a
>>> pity. :(
>>
>> I think we should have a new feature flag for this. E.g VIRTIO_NET_F_VSOCK. And host should fail the negotiation if guest doesn't support this to avoid confusion. When this feature is negotiated, we will use it only for VOSCK transport. This can simplify things somehow.
>>
>>
>>> -------------------------Simple idea------------------------------
>>>
>>> 1. The packet layout will become as follows:
>>>
>>> +---------------------------------+
>>> | Virtio-net header |
>>> |(struct virtio_net_hdr_mrg_rxbuf)|
>>> +---------------------------------+
>>> | Vsock header |
>>> | (struct virtio_vsock_hdr) |
>>> +---------------------------------+
>>> | payload |
>>> | (until end of packet) |
>>> +---------------------------------+
>>>
>>> 2. The Guest->Host basic code flow as follow:
>>> +------------+
>>> | Client |
>>> +------------+
>>> |
>>> |
>>> +------------------------------------------------------------------+
>>> |VSOCK Core Module |
>>> |ops->sendmsg; (vsock_stream_sendmsg) |
>>> | -> alloc_skb; /* it will packet a skb buffer, and include vsock |
>>> | * hdr and payload */ |
>>> | -> dev_queue_xmit(); /* it will call start_xmit(virtio-net.c) */|
>>> |vsock hdr and payload, and then call |
>>> +------------------------------------------------------------------+
>>
>> Note, if we've negotiated the feature, virtio-net driver must not use register_netdev to register it to network core. This can avoid lots of confusion.
> Hi Jason,
>
> You mean we should not register netdev if use vsock, and in order to
> avoid confusion, then I think whether we should keep vsock and export
> some virtio-net's functions that can be shared. In this way, first, vsock
> may keep existing architecture and will not affect virtio-net.
At least it needs new feature bits which will be a functional
duplication of virtio-net (e.g mrg_rxbuf).
> In addition,
> vsock doesn't need to use virtio_net header too, then it don't need to pack
> skb structure.
For mergeable rx buffer it need I think?
>
> Thanks,
> Yiwen.
>
>>
>>> |
>>> |
>>> +------------------------------------------------------------------+
>>> |Virtio-net Module |
>>> |start_xmit |
>>> | -> add virtio_net_hdr and pack sg in ring desc, notify Host |
>>> +------------------------------------------------------------------+
>>> |
>>> |
>>> +------------------------------------------------------------------+
>>> |Vhost-net Module |
>>> |handle_tx |
>>> | -> get tx buffer, skip virtio_net_hdr and call Vsock function. |
>>> | /* This point has some differences, vhost-net use ->sendmsg to |
>>> | * forward information, however vsock only need to notify server |
>>> | * that data ready. */ |
>>> +------------------------------------------------------------------+
>>
>> When VIRTIO_NET_F_VOSCK is negotiated, we know that it's a vsock transport, we can then forward it to vsock core.
>>
>>
>>> |
>>> |
>>> +------------------------------------------------------------------+
>>> |VSOCK Core Module |
>>> |alloc_pkt, copy skb data to pkt. |
>>> |add pkt to rx_queue and notify server to get data. |
>>> +------------------------------------------------------------------+
>>>
>>> 3. To Host->Guest
>>> I have a problem and difficult, mainly I know about virtio-net a little),
>>> because I have been doing work related with storage and file system.
>>>
>>> The problem as follows:
>>> we should monitor all of socket of vsock in handle_rx, when there are
>>> data coming, and copy data to vq desc. Vhost-net use ->recvmsg to
>>> get data, it is different with socket. To vsock, I think host will
>>> not call ->recvmsg when it need to send message to guest. To net,
>>> vhost-net only as forwarding layer.
>> Know not much here, but is it possible to have a vsock(tap) to be passed to vhost_net and let vhost call its recvmgs()? Bascially it was a socket on host as well I believe?
> For vsock, Host->Guest, it's code flow as follows:
> Server call send()
> -> sendmsg(); (vsock_stream_sendmsg)
> -> virtio_trasnport_send_pkt_info
> -> alloc pkt, add pkt to send_pkt_list, wake up vhost_worker
>
> Vhost_worker
> -> vhost_transport_send_pkt_work
> -> get pkt from send_pkt_list
> -> get vq input desc and then fill data to desc addr
> -> update used ring and then signal guest
>
> In the whole process, host don't call recvmsg() because it is a net device, and
> it also receives any messages.
If I understand this correctly, there's no a socket object on host that
represent vosck in guest? If yes, maybe we can invent one.
Thanks
>
> For vhost-net, I understand it is a tap device, so it can receive messages
> from other net device.
>
> This is my understanding, it may have some errors.
>
> Thanks.
>
>> If this doesn't work, we can have vsock specific receiving routine in vhost_net if VIRTIO_NET_F_VOSCK is negotiated.
>>
>> Generally, I think we should try out best to keep the exist sendmsg()/recvmsg() interfaces and only consider the alternatives if we meet some real blocker.
>>
>> Thanks
>>
>>
>> .
>>
>
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [RFC] Discuss about an new idea "Vsock over Virtio-net"
From: Michael S. Tsirkin @ 2018-11-15 8:10 UTC (permalink / raw)
To: jiangyiwen; +Cc: kvm, virtualization, stefanha, netdev
In-Reply-To: <5BED2267.8030306@huawei.com>
On Thu, Nov 15, 2018 at 03:38:15PM +0800, jiangyiwen wrote:
> On 2018/11/15 15:04, Michael S. Tsirkin wrote:
> > On Thu, Nov 15, 2018 at 11:56:03AM +0800, jiangyiwen wrote:
> >> Hi Stefan, Michael, Jason and everyone,
> >>
> >> Several days ago, I discussed with jason about "Vsock over Virtio-net".
> >> This idea has two advantages:
> >> First, it can use many great features of virtio-net, like batching,
> >> mergeable rx buffer and multiqueue, etc.
> >> Second, it can reduce many duplicate codes and make it easy to be
> >> maintained.
> >
> > I'm not sure I get the motivation. Which features of
> > virtio net are relevant to vsock? The ones that you mention
> > all seem to be mostly of use to the networking stack.
> >
> >
> >> Before the implement, I want to discuss with everyone again, and
> >> want to know everyone's suggestions.
> >>
> >> After the discussion, based on this point I will try to implement
> >> this idea, but I am not familiar with the virtio-net, that is a
> >> pity. :(
> >>
> >> -------------------------Simple idea------------------------------
> >>
> >> 1. The packet layout will become as follows:
> >>
> >> +---------------------------------+
> >> | Virtio-net header |
> >> |(struct virtio_net_hdr_mrg_rxbuf)|
> >
> > Which fields in virtio_net_hdr_mrg_rxbuf are of interest to vsock?
> >
>
> Hi Michael,
>
> Yes, currently vsock has poor performance, first, it only support transport
> small packet, in order to make the balance between performance and guest memory.
>
> In order to solve this problem, there are two features vsock can used,
> mergeable rx buffer and multiqueue. Based on this, there are some shared
> codes vsock can use.
>
> Thanks,
> Yiwen.
Supporting more queues with vsock is probably significantly
less work than a completely new interface.
For mergeable, as buffers are split arbitrarily, why can't you combine
them within guest driver before sending them up the stack?
Probably better than relying on host to do it.
> >> +---------------------------------+
> >> | Vsock header |
> >> | (struct virtio_vsock_hdr) |
> >> +---------------------------------+
> >> | payload |
> >> | (until end of packet) |
> >> +---------------------------------+
> >
> > Thanks,
> >
>
^ permalink raw reply
* Re: [RFC] Discuss about an new idea "Vsock over Virtio-net"
From: jiangyiwen @ 2018-11-15 7:38 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: kvm, virtualization, stefanha, netdev
In-Reply-To: <20181115015547-mutt-send-email-mst@kernel.org>
On 2018/11/15 15:04, Michael S. Tsirkin wrote:
> On Thu, Nov 15, 2018 at 11:56:03AM +0800, jiangyiwen wrote:
>> Hi Stefan, Michael, Jason and everyone,
>>
>> Several days ago, I discussed with jason about "Vsock over Virtio-net".
>> This idea has two advantages:
>> First, it can use many great features of virtio-net, like batching,
>> mergeable rx buffer and multiqueue, etc.
>> Second, it can reduce many duplicate codes and make it easy to be
>> maintained.
>
> I'm not sure I get the motivation. Which features of
> virtio net are relevant to vsock? The ones that you mention
> all seem to be mostly of use to the networking stack.
>
>
>> Before the implement, I want to discuss with everyone again, and
>> want to know everyone's suggestions.
>>
>> After the discussion, based on this point I will try to implement
>> this idea, but I am not familiar with the virtio-net, that is a
>> pity. :(
>>
>> -------------------------Simple idea------------------------------
>>
>> 1. The packet layout will become as follows:
>>
>> +---------------------------------+
>> | Virtio-net header |
>> |(struct virtio_net_hdr_mrg_rxbuf)|
>
> Which fields in virtio_net_hdr_mrg_rxbuf are of interest to vsock?
>
Hi Michael,
Yes, currently vsock has poor performance, first, it only support transport
small packet, in order to make the balance between performance and guest memory.
In order to solve this problem, there are two features vsock can used,
mergeable rx buffer and multiqueue. Based on this, there are some shared
codes vsock can use.
Thanks,
Yiwen.
>> +---------------------------------+
>> | Vsock header |
>> | (struct virtio_vsock_hdr) |
>> +---------------------------------+
>> | payload |
>> | (until end of packet) |
>> +---------------------------------+
>
> Thanks,
>
^ permalink raw reply
* Re: [PATCH v2 net-next 19/21] net: usb: aqc111: Add support for wake on LAN by MAGIC packet
From: Andrew Lunn @ 2018-11-14 21:30 UTC (permalink / raw)
To: Igor Russkikh
Cc: David S . Miller, linux-usb@vger.kernel.org,
netdev@vger.kernel.org, Dmitry Bezrukov
In-Reply-To: <3c322e27-06c7-69a1-cbe8-271741da0bb3@aquantia.com>
> We've considered that, but then thought about the following case:
>
> After such a sleep state where partner's capabilities were considered,
> user may move with the unit and replug it into different link partner with
> other, incompatible speed mask. That will anyway lead to wol link failure.
WOL for a nomadic device? Is that even a real use case?
Anyway, looking at the link partner capabilities is just really a
corner case, that the LP only supports 1G. Do such devices exist?
So skipping this is fine. But if you use phylib, you pretty much get
it for free if you want it.
Andrew
^ permalink raw reply
* Re: [PATCH v2 net-next 06/21] net: usb: aqc111: Introduce link management
From: Andrew Lunn @ 2018-11-14 21:16 UTC (permalink / raw)
To: Igor Russkikh
Cc: David S . Miller, linux-usb@vger.kernel.org,
netdev@vger.kernel.org, Dmitry Bezrukov
In-Reply-To: <6a92f825-576e-3826-66c7-791304661174@aquantia.com>
> > Thats again because of this product has tightly integrated MAC+Phy.
> > MAC FW controls system interface and reports/alters link state
> > as a joint state on copper and SIF (even in dpa direct phy mode).
> >
> > We can't extract phy api into a standalone fully functional phylib therefore.
> > Also as far as I know this particular phy is not available in the wild.
>
> So the point is that MAC firmware is managing SERDES and system interface link.
Linux can manage that SERDES link between the MAC and the PHY. There
are two ways this can go:
1) You use phylib. When the PHY reports link, the adjust_link callback
in the MAC is called. The phydev structure contains information about
how you should configure the SERDES, SGMII, 2500Base-X, 5000Base-X. It
works, but it is not so nice.
2) phylink gives you a much nicer API to do the same. Again, the PHY
reports the link is up. phylink will then tell the MAC how to
configure its end of the SERDES. The problem with phylink is that it
expects a DT building. You don't have that, since this is a USB
device. But you also don't need a lot of the features of phylink like
SFPs, the i2c bus for the SFPs, GPIOs etc. So it should not be to hard
to make this work without device tree.
By using core linux code, we avoid bugs in firmware which nobody can
fix. The Linux core code should be well tested and supported, but
phylink is rather new, so might still have some corner cases.
I also cannot imaging parts of the PHY driver will not be re-usable
for other Aquantia PHYs. I have a board with an AQCS109 under my desk
waiting for me to do something with it. I really would like a better
PHY driver for it than the kernel currently has. Hopefully there is
some code reuse possibilities here.
Andrew
^ permalink raw reply
* Re: [RFC] Discuss about an new idea "Vsock over Virtio-net"
From: jiangyiwen @ 2018-11-15 6:49 UTC (permalink / raw)
To: Jason Wang, stefanha, stefanha, mst; +Cc: netdev, kvm, virtualization
In-Reply-To: <5BED162C.5070902@huawei.com>
On 2018/11/15 14:46, jiangyiwen wrote:
> On 2018/11/15 12:19, Jason Wang wrote:
>>
>> On 2018/11/15 上午11:56, jiangyiwen wrote:
>>> Hi Stefan, Michael, Jason and everyone,
>>>
>>> Several days ago, I discussed with jason about "Vsock over Virtio-net".
>>> This idea has two advantages:
>>> First, it can use many great features of virtio-net, like batching,
>>> mergeable rx buffer and multiqueue, etc.
>>> Second, it can reduce many duplicate codes and make it easy to be
>>> maintained.
>>>
>>> Before the implement, I want to discuss with everyone again, and
>>> want to know everyone's suggestions.
>>>
>>> After the discussion, based on this point I will try to implement
>>> this idea, but I am not familiar with the virtio-net, that is a
>>> pity. :(
>>
>>
>> I think we should have a new feature flag for this. E.g VIRTIO_NET_F_VSOCK. And host should fail the negotiation if guest doesn't support this to avoid confusion. When this feature is negotiated, we will use it only for VOSCK transport. This can simplify things somehow.
>>
>>
>>> -------------------------Simple idea------------------------------
>>>
>>> 1. The packet layout will become as follows:
>>>
>>> +---------------------------------+
>>> | Virtio-net header |
>>> |(struct virtio_net_hdr_mrg_rxbuf)|
>>> +---------------------------------+
>>> | Vsock header |
>>> | (struct virtio_vsock_hdr) |
>>> +---------------------------------+
>>> | payload |
>>> | (until end of packet) |
>>> +---------------------------------+
>>>
>>> 2. The Guest->Host basic code flow as follow:
>>> +------------+
>>> | Client |
>>> +------------+
>>> |
>>> |
>>> +------------------------------------------------------------------+
>>> |VSOCK Core Module |
>>> |ops->sendmsg; (vsock_stream_sendmsg) |
>>> | -> alloc_skb; /* it will packet a skb buffer, and include vsock |
>>> | * hdr and payload */ |
>>> | -> dev_queue_xmit(); /* it will call start_xmit(virtio-net.c) */|
>>> |vsock hdr and payload, and then call |
>>> +------------------------------------------------------------------+
>>
>>
>> Note, if we've negotiated the feature, virtio-net driver must not use register_netdev to register it to network core. This can avoid lots of confusion.
>
> Hi Jason,
>
> You mean we should not register netdev if use vsock, and in order to
> avoid confusion, then I think whether we should keep vsock and export
> some virtio-net's functions that can be shared. In this way, first, vsock
> may keep existing architecture and will not affect virtio-net. In addition,
> vsock doesn't need to use virtio_net header too, then it don't need to pack
> skb structure.
>
> Thanks,
> Yiwen.
>
>>
>>
>>> |
>>> |
>>> +------------------------------------------------------------------+
>>> |Virtio-net Module |
>>> |start_xmit |
>>> | -> add virtio_net_hdr and pack sg in ring desc, notify Host |
>>> +------------------------------------------------------------------+
>>> |
>>> |
>>> +------------------------------------------------------------------+
>>> |Vhost-net Module |
>>> |handle_tx |
>>> | -> get tx buffer, skip virtio_net_hdr and call Vsock function. |
>>> | /* This point has some differences, vhost-net use ->sendmsg to |
>>> | * forward information, however vsock only need to notify server |
>>> | * that data ready. */ |
>>> +------------------------------------------------------------------+
>>
>>
>> When VIRTIO_NET_F_VOSCK is negotiated, we know that it's a vsock transport, we can then forward it to vsock core.
>>
>>
>>> |
>>> |
>>> +------------------------------------------------------------------+
>>> |VSOCK Core Module |
>>> |alloc_pkt, copy skb data to pkt. |
>>> |add pkt to rx_queue and notify server to get data. |
>>> +------------------------------------------------------------------+
>>>
>>> 3. To Host->Guest
>>> I have a problem and difficult, mainly I know about virtio-net a little),
>>> because I have been doing work related with storage and file system.
>>>
>>> The problem as follows:
>>> we should monitor all of socket of vsock in handle_rx, when there are
>>> data coming, and copy data to vq desc. Vhost-net use ->recvmsg to
>>> get data, it is different with socket. To vsock, I think host will
>>> not call ->recvmsg when it need to send message to guest. To net,
>>> vhost-net only as forwarding layer.
>>
>> Know not much here, but is it possible to have a vsock(tap) to be passed to vhost_net and let vhost call its recvmgs()? Bascially it was a socket on host as well I believe?
>
> For vsock, Host->Guest, it's code flow as follows:
> Server call send()
> -> sendmsg(); (vsock_stream_sendmsg)
> -> virtio_trasnport_send_pkt_info
> -> alloc pkt, add pkt to send_pkt_list, wake up vhost_worker
>
> Vhost_worker
> -> vhost_transport_send_pkt_work
> -> get pkt from send_pkt_list
> -> get vq input desc and then fill data to desc addr
> -> update used ring and then signal guest
>
> In the whole process, host don't call recvmsg() because it is a net device, and
> it also receives any messages.
Sorry, it is *not* a net device, it *does not* receive any messages.
Thanks.
>
> For vhost-net, I understand it is a tap device, so it can receive messages
> from other net device.
>
> This is my understanding, it may have some errors.
>
> Thanks.
>
>>
>> If this doesn't work, we can have vsock specific receiving routine in vhost_net if VIRTIO_NET_F_VOSCK is negotiated.
>>
>> Generally, I think we should try out best to keep the exist sendmsg()/recvmsg() interfaces and only consider the alternatives if we meet some real blocker.
>>
>> Thanks
>>
>>
>>>
>>
>> .
>>
>
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [RFC] Discuss about an new idea "Vsock over Virtio-net"
From: jiangyiwen @ 2018-11-15 6:46 UTC (permalink / raw)
To: Jason Wang, stefanha, stefanha, mst; +Cc: netdev, kvm, virtualization
In-Reply-To: <88eaf53b-b148-7b27-491a-30706398ae06@redhat.com>
On 2018/11/15 12:19, Jason Wang wrote:
>
> On 2018/11/15 上午11:56, jiangyiwen wrote:
>> Hi Stefan, Michael, Jason and everyone,
>>
>> Several days ago, I discussed with jason about "Vsock over Virtio-net".
>> This idea has two advantages:
>> First, it can use many great features of virtio-net, like batching,
>> mergeable rx buffer and multiqueue, etc.
>> Second, it can reduce many duplicate codes and make it easy to be
>> maintained.
>>
>> Before the implement, I want to discuss with everyone again, and
>> want to know everyone's suggestions.
>>
>> After the discussion, based on this point I will try to implement
>> this idea, but I am not familiar with the virtio-net, that is a
>> pity. :(
>
>
> I think we should have a new feature flag for this. E.g VIRTIO_NET_F_VSOCK. And host should fail the negotiation if guest doesn't support this to avoid confusion. When this feature is negotiated, we will use it only for VOSCK transport. This can simplify things somehow.
>
>
>> -------------------------Simple idea------------------------------
>>
>> 1. The packet layout will become as follows:
>>
>> +---------------------------------+
>> | Virtio-net header |
>> |(struct virtio_net_hdr_mrg_rxbuf)|
>> +---------------------------------+
>> | Vsock header |
>> | (struct virtio_vsock_hdr) |
>> +---------------------------------+
>> | payload |
>> | (until end of packet) |
>> +---------------------------------+
>>
>> 2. The Guest->Host basic code flow as follow:
>> +------------+
>> | Client |
>> +------------+
>> |
>> |
>> +------------------------------------------------------------------+
>> |VSOCK Core Module |
>> |ops->sendmsg; (vsock_stream_sendmsg) |
>> | -> alloc_skb; /* it will packet a skb buffer, and include vsock |
>> | * hdr and payload */ |
>> | -> dev_queue_xmit(); /* it will call start_xmit(virtio-net.c) */|
>> |vsock hdr and payload, and then call |
>> +------------------------------------------------------------------+
>
>
> Note, if we've negotiated the feature, virtio-net driver must not use register_netdev to register it to network core. This can avoid lots of confusion.
Hi Jason,
You mean we should not register netdev if use vsock, and in order to
avoid confusion, then I think whether we should keep vsock and export
some virtio-net's functions that can be shared. In this way, first, vsock
may keep existing architecture and will not affect virtio-net. In addition,
vsock doesn't need to use virtio_net header too, then it don't need to pack
skb structure.
Thanks,
Yiwen.
>
>
>> |
>> |
>> +------------------------------------------------------------------+
>> |Virtio-net Module |
>> |start_xmit |
>> | -> add virtio_net_hdr and pack sg in ring desc, notify Host |
>> +------------------------------------------------------------------+
>> |
>> |
>> +------------------------------------------------------------------+
>> |Vhost-net Module |
>> |handle_tx |
>> | -> get tx buffer, skip virtio_net_hdr and call Vsock function. |
>> | /* This point has some differences, vhost-net use ->sendmsg to |
>> | * forward information, however vsock only need to notify server |
>> | * that data ready. */ |
>> +------------------------------------------------------------------+
>
>
> When VIRTIO_NET_F_VOSCK is negotiated, we know that it's a vsock transport, we can then forward it to vsock core.
>
>
>> |
>> |
>> +------------------------------------------------------------------+
>> |VSOCK Core Module |
>> |alloc_pkt, copy skb data to pkt. |
>> |add pkt to rx_queue and notify server to get data. |
>> +------------------------------------------------------------------+
>>
>> 3. To Host->Guest
>> I have a problem and difficult, mainly I know about virtio-net a little),
>> because I have been doing work related with storage and file system.
>>
>> The problem as follows:
>> we should monitor all of socket of vsock in handle_rx, when there are
>> data coming, and copy data to vq desc. Vhost-net use ->recvmsg to
>> get data, it is different with socket. To vsock, I think host will
>> not call ->recvmsg when it need to send message to guest. To net,
>> vhost-net only as forwarding layer.
>
> Know not much here, but is it possible to have a vsock(tap) to be passed to vhost_net and let vhost call its recvmgs()? Bascially it was a socket on host as well I believe?
For vsock, Host->Guest, it's code flow as follows:
Server call send()
-> sendmsg(); (vsock_stream_sendmsg)
-> virtio_trasnport_send_pkt_info
-> alloc pkt, add pkt to send_pkt_list, wake up vhost_worker
Vhost_worker
-> vhost_transport_send_pkt_work
-> get pkt from send_pkt_list
-> get vq input desc and then fill data to desc addr
-> update used ring and then signal guest
In the whole process, host don't call recvmsg() because it is a net device, and
it also receives any messages.
For vhost-net, I understand it is a tap device, so it can receive messages
from other net device.
This is my understanding, it may have some errors.
Thanks.
>
> If this doesn't work, we can have vsock specific receiving routine in vhost_net if VIRTIO_NET_F_VOSCK is negotiated.
>
> Generally, I think we should try out best to keep the exist sendmsg()/recvmsg() interfaces and only consider the alternatives if we meet some real blocker.
>
> Thanks
>
>
>>
>
> .
>
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [PATCH net] net/sched: act_pedit: fix memory leak when IDR allocation fails
From: Cong Wang @ 2018-11-14 20:36 UTC (permalink / raw)
To: Davide Caratti
Cc: Jiri Pirko, David Miller, Vlad Buslov,
Linux Kernel Network Developers, Jamal Hadi Salim
In-Reply-To: <8ae2ff111546be071b461a0678939078353dff27.1542193853.git.dcaratti@redhat.com>
(Cc'ing Jamal)
On Wed, Nov 14, 2018 at 3:26 AM Davide Caratti <dcaratti@redhat.com> wrote:
>
> tcf_idr_check_alloc() can return a negative value, on allocation failures
> (-ENOMEM) or IDR exhaustion (-ENOSPC): don't leak keys_ex in these cases.
I think the comments above tcf_idr_check_alloc() need to improve too,
they imply tcf_idr_check_alloc() returns either 0 or 1.
Of course, this can be done with a separated patch.
>
> Fixes: 0190c1d452a9 ("net: sched: atomically check-allocate action")
> Signed-off-by: Davide Caratti <dcaratti@redhat.com>
I think your patch is correct.
Acked-by: Cong Wang <xiyou.wangcong@gmail.com>
^ permalink raw reply
* Re: [RFC v1 3/3] vxlan: handle underlay VRF changes
From: David Ahern @ 2018-11-14 20:04 UTC (permalink / raw)
To: Alexis Bauvin, roopa, nicolas.dichtel; +Cc: netdev, akherbouche
In-Reply-To: <20181114093104.93286-4-abauvin@scaleway.com>
On 11/14/18 1:31 AM, Alexis Bauvin wrote:
> diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
> index 7477b5510a04..188c0cdb8838 100644
> --- a/drivers/net/vxlan.c
> +++ b/drivers/net/vxlan.c
> @@ -208,6 +208,18 @@ static inline struct vxlan_rdst *first_remote_rtnl(struct vxlan_fdb *fdb)
> return list_first_entry(&fdb->remotes, struct vxlan_rdst, list);
> }
>
> +static int vxlan_is_in_l3mdev_chain(struct net_device *chain,
> + struct net_device *dev)
> +{
> + if (!chain)
> + return 0;
> +
> + if (chain->ifindex == dev->ifindex)
> + return 1;
> + return vxlan_is_in_l3mdev_chain(netdev_master_upper_dev_get(chain),
> + dev);
l3mdev_master_dev_rcu
^ permalink raw reply
* Re: [RFC v1 2/3] vxlan: add support for underlay in non-default VRF
From: David Ahern @ 2018-11-14 19:58 UTC (permalink / raw)
To: Alexis Bauvin, roopa, nicolas.dichtel; +Cc: netdev, akherbouche
In-Reply-To: <20181114093104.93286-3-abauvin@scaleway.com>
you are making this more specific than it needs to be ....
On 11/14/18 1:31 AM, Alexis Bauvin wrote:
> diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
> index 27bd586b94b0..7477b5510a04 100644
> --- a/drivers/net/vxlan.c
> +++ b/drivers/net/vxlan.c
> @@ -208,11 +208,23 @@ static inline struct vxlan_rdst *first_remote_rtnl(struct vxlan_fdb *fdb)
> return list_first_entry(&fdb->remotes, struct vxlan_rdst, list);
> }
>
> +static int vxlan_get_l3mdev(struct net *net, int ifindex)
> +{
> + struct net_device *dev;
> +
> + dev = __dev_get_by_index(net, ifindex);
> + while (dev && !netif_is_l3_master(dev))
> + dev = netdev_master_upper_dev_get(dev);
> +
> + return dev ? dev->ifindex : 0;
> +}
l3mdev_master_ifindex_by_index should work instead of defining this for
vxlan.
But I do not believe you need this function.
> +
> /* Find VXLAN socket based on network namespace, address family and UDP port
> * and enabled unshareable flags.
> */
> static struct vxlan_sock *vxlan_find_sock(struct net *net, sa_family_t family,
> - __be16 port, u32 flags)
> + __be16 port, u32 flags,
> + int l3mdev_ifindex)
> {
> struct vxlan_sock *vs;
>
> @@ -221,7 +233,8 @@ static struct vxlan_sock *vxlan_find_sock(struct net *net, sa_family_t family,
> hlist_for_each_entry_rcu(vs, vs_head(net, port), hlist) {
> if (inet_sk(vs->sock->sk)->inet_sport == port &&
> vxlan_get_sk_family(vs) == family &&
> - vs->flags == flags)
> + vs->flags == flags &&
> + vs->sock->sk->sk_bound_dev_if == l3mdev_ifindex)
Why not allow the vxlan socket to bind to any ifindex? In that case this
socket lookup follows what we do for tcp, udp and raw sockets, and you
don't need to call out vrf / l3mdev directly (ie.,
s/l3mdev_ifindex/ifindex/g) - it comes for free.
^ permalink raw reply
* linux-next: build failure after merge of the net tree
From: Stephen Rothwell @ 2018-11-15 6:02 UTC (permalink / raw)
To: David Miller, Networking
Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
Michal Kalderon
[-- Attachment #1: Type: text/plain, Size: 326 bytes --]
Hi all,
After merging the net tree, today's linux-next build (arm allmodconfig
(from KernelCI)) failed like this:
drivers/net/ethernet/qlogic/qed/qed_rdma.h:186:79: error: expected ';' before '}' token
Caused by commit
291d57f67d24 ("qed: Fix rdma_info structure allocation")
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [iproute PATCH] ip-address: Fix filtering by negated address flags
From: Stephen Hemminger @ 2018-11-14 19:29 UTC (permalink / raw)
To: Phil Sutter; +Cc: netdev
In-Reply-To: <20181114105251.GR6440@orbyte.nwl.cc>
On Wed, 14 Nov 2018 11:52:51 +0100
Phil Sutter <phil@nwl.cc> wrote:
> Hi Stephen,
>
> On Tue, Nov 13, 2018 at 02:47:59PM -0800, Stephen Hemminger wrote:
> > On Tue, 13 Nov 2018 16:12:01 +0100
> > Phil Sutter <phil@nwl.cc> wrote:
> >
> > > + if (arg[0] == '-') {
> > > + inv = true;
> > > + arg++;
> > > + }
> > The inverse logic needs to be moved into the loop handling filter names.
> >
> > Otherwise, you get weirdness like "-dynamic" being accepted and not
> > doing what was expected.
>
> I intentionally moved it there to allow for '-dynamic' and '-primary'
> as well. IMO this is consistent: 'dynamic' is the inverse of 'permanent'
> and 'primary' the inverse of 'secondary' but currently only '-permanent'
> and '-secondary' are allowed. With my patch applied, one may specify not
> only '-permanent' to get the same effect as 'dynamic' but also
> '-dynamic' to get the same effect as 'permanent'. Likewise for the other
> two. Did I miss something?
>
> > Also, please make sure the man page matches the code.
>
> Oh, right. Given the above is fine with you, I will add the man page
> change in v2.
>
> Thanks, Phil
I was thinking something like this which simplifies the logic.
diff --git a/ip/ipaddress.c b/ip/ipaddress.c
index cd8cc76a3473..3f1510383071 100644
--- a/ip/ipaddress.c
+++ b/ip/ipaddress.c
@@ -1212,37 +1212,34 @@ static void print_ifa_flags(FILE *fp, const struct ifaddrmsg *ifa,
static int get_filter(const char *arg)
{
unsigned int i;
+ bool inv = false;
/* Special cases */
if (strcmp(arg, "dynamic") == 0) {
- filter.flags &= ~IFA_F_PERMANENT;
- filter.flagmask |= IFA_F_PERMANENT;
+ arg = "-permanent";
} else if (strcmp(arg, "primary") == 0) {
- filter.flags &= ~IFA_F_SECONDARY;
- filter.flagmask |= IFA_F_SECONDARY;
- } else if (*arg == '-') {
- for (i = 0; i < ARRAY_SIZE(ifa_flag_names); i++) {
- if (strcmp(arg + 1, ifa_flag_names[i].name))
- continue;
+ arg = "-secondary";
+ }
- filter.flags &= ifa_flag_names[i].value;
- filter.flagmask |= ifa_flag_names[i].value;
- return 0;
- }
+ if (*arg == '-') {
+ inv = true;
+ ++arg;
+ }
- return -1;
- } else {
- for (i = 0; i < ARRAY_SIZE(ifa_flag_names); i++) {
- if (strcmp(arg, ifa_flag_names[i].name))
- continue;
+ for (i = 0; i < ARRAY_SIZE(ifa_flag_names); i++) {
+ if (strcmp(arg, ifa_flag_names[i].name))
+ continue;
+
+ if (inv) {
+ filter.flags &= ~ifa_flag_names[i].value;
+ filter.flagmask |= ifa_flag_names[i].value;
+ } else {
filter.flags |= ifa_flag_names[i].value;
filter.flagmask |= ifa_flag_names[i].value;
- return 0;
}
- return -1;
+ return 0;
}
-
- return 0;
+ return -1;
}
static int ifa_label_match_rta(int ifindex, const struct rtattr *rta)
^ permalink raw reply related
* Re: [iproute PATCH] ip-route: Fix nexthop encap parsing
From: Stephen Hemminger @ 2018-11-14 19:20 UTC (permalink / raw)
To: Phil Sutter; +Cc: netdev
In-Reply-To: <20181113123904.27880-1-phil@nwl.cc>
On Tue, 13 Nov 2018 13:39:04 +0100
Phil Sutter <phil@nwl.cc> wrote:
> When parsing nexthop parameters, a buffer of 4k bytes is provided. Yet,
> in lwt_parse_encap() and some functions called by it, buffer size was
> assumed to be 1k despite the actual size was provided. This led to
> spurious buffer size errors if the buffer was filled by previous nexthop
> parameters to exceed that 1k boundary.
>
> Fixes: 1e5293056a02c ("lwtunnel: Add encapsulation support to ip route")
> Fixes: 5866bddd9aa9e ("ila: Add support for ILA lwtunnels")
> Fixes: ed67f83806538 ("ila: Support for checksum neutral translation")
> Fixes: 86905c8f057c0 ("ila: support for configuring identifier and hook types")
> Fixes: b15f440e78373 ("lwt: BPF support for LWT")
> Signed-off-by: Phil Sutter <phil@nwl.cc>
Applied
^ permalink raw reply
* Re: [iproute PATCH] man: ip-route.8: Document nexthop limit
From: Stephen Hemminger @ 2018-11-14 19:20 UTC (permalink / raw)
To: Phil Sutter; +Cc: netdev
In-Reply-To: <20181112222101.9674-1-phil@nwl.cc>
On Mon, 12 Nov 2018 23:21:01 +0100
Phil Sutter <phil@nwl.cc> wrote:
> Add a note to 'nexthop' description stating the maximum number of
> nexthops per command and pointing at 'append' command as a workaround.
>
> Signed-off-by: Phil Sutter <phil@nwl.cc>
Applied
^ permalink raw reply
* [PATCH v5] net: phy: mdio-gpio: Fix working over slow can_sleep GPIOs
From: Martin Schiller @ 2018-11-15 5:24 UTC (permalink / raw)
To: andrew, sergei.shtylyov, f.fainelli
Cc: davem, netdev, linux-kernel, Martin Schiller
In-Reply-To: <20181114061703.11026-1-ms@dev.tdt.de>
Up until commit 7e5fbd1e0700 ("net: mdio-gpio: Convert to use gpiod
functions where possible"), the _cansleep variants of the gpio_ API was
used. After that commit and the change to gpiod_ API, the _cansleep()
was dropped. This then results in WARN_ON() when used with GPIO
devices which do sleep. Add back the _cansleep() to avoid this.
Fixes: 7e5fbd1e0700 ("net: mdio-gpio: Convert to use gpiod functions where possible")
Signed-off-by: Martin Schiller <ms@dev.tdt.de>
---
v5:
- reworked commit message
- added "Fixes:" tag
- based on DaveM net tree instead of mainline
v4:
- remove linewrap of kernel message
v3:
- modified commit summary
- fixed commit cites in commit message
- fixed line continuation
v2:
- fixed copy/paste bug in warning about slow GPIO pins
---
drivers/net/phy/mdio-gpio.c | 14 +++++++++-----
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/net/phy/mdio-gpio.c b/drivers/net/phy/mdio-gpio.c
index 33265747bf39..3a5a24daf384 100644
--- a/drivers/net/phy/mdio-gpio.c
+++ b/drivers/net/phy/mdio-gpio.c
@@ -63,7 +63,7 @@ static void mdio_dir(struct mdiobb_ctrl *ctrl, int dir)
* assume the pin serves as pull-up. If direction is
* output, the default value is high.
*/
- gpiod_set_value(bitbang->mdo, 1);
+ gpiod_set_value_cansleep(bitbang->mdo, 1);
return;
}
@@ -78,7 +78,7 @@ static int mdio_get(struct mdiobb_ctrl *ctrl)
struct mdio_gpio_info *bitbang =
container_of(ctrl, struct mdio_gpio_info, ctrl);
- return gpiod_get_value(bitbang->mdio);
+ return gpiod_get_value_cansleep(bitbang->mdio);
}
static void mdio_set(struct mdiobb_ctrl *ctrl, int what)
@@ -87,9 +87,9 @@ static void mdio_set(struct mdiobb_ctrl *ctrl, int what)
container_of(ctrl, struct mdio_gpio_info, ctrl);
if (bitbang->mdo)
- gpiod_set_value(bitbang->mdo, what);
+ gpiod_set_value_cansleep(bitbang->mdo, what);
else
- gpiod_set_value(bitbang->mdio, what);
+ gpiod_set_value_cansleep(bitbang->mdio, what);
}
static void mdc_set(struct mdiobb_ctrl *ctrl, int what)
@@ -97,7 +97,7 @@ static void mdc_set(struct mdiobb_ctrl *ctrl, int what)
struct mdio_gpio_info *bitbang =
container_of(ctrl, struct mdio_gpio_info, ctrl);
- gpiod_set_value(bitbang->mdc, what);
+ gpiod_set_value_cansleep(bitbang->mdc, what);
}
static const struct mdiobb_ops mdio_gpio_ops = {
@@ -162,6 +162,10 @@ static int mdio_gpio_probe(struct platform_device *pdev)
if (ret)
return ret;
+ if (gpiod_cansleep(bitbang->mdc) || gpiod_cansleep(bitbang->mdio) ||
+ gpiod_cansleep(bitbang->mdo))
+ dev_warn(&pdev->dev, "Slow GPIO pins might wreak havoc into MDIO bus timing");
+
if (pdev->dev.of_node) {
bus_id = of_alias_get_id(pdev->dev.of_node, "mdio-gpio");
if (bus_id < 0) {
--
2.11.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox