* [PATCH net-next 5/5] net: Replace ip_ra_lock with per-net mutex
From: Kirill Tkhai @ 2018-03-15 13:20 UTC (permalink / raw)
To: davem, yoshfuji, edumazet, yanhaishuang, nikolay, yotamg, soheil,
ktkhai, avagin, nicolas.dichtel, ebiederm, fw, roman.kapl, netdev,
xiyou.wangcong, dvyukov, andreyknvl
In-Reply-To: <152111892326.30586.3742839588131331286.stgit@localhost.localdomain>
Since ra_chain is per-net, we may use per-net mutexes
to protect them in ip_ra_control(). This improves
scalability.
Signed-off-by: Kirill Tkhai <ktkhai@virtuozzo.com>
---
include/net/netns/ipv4.h | 1 +
net/core/net_namespace.c | 1 +
net/ipv4/ip_sockglue.c | 15 ++++++---------
3 files changed, 8 insertions(+), 9 deletions(-)
diff --git a/include/net/netns/ipv4.h b/include/net/netns/ipv4.h
index 23c208fcf1a0..7295429732c6 100644
--- a/include/net/netns/ipv4.h
+++ b/include/net/netns/ipv4.h
@@ -50,6 +50,7 @@ struct netns_ipv4 {
struct ipv4_devconf *devconf_all;
struct ipv4_devconf *devconf_dflt;
struct ip_ra_chain *ra_chain;
+ struct mutex ra_mutex;
#ifdef CONFIG_IP_MULTIPLE_TABLES
struct fib_rules_ops *rules_ops;
bool fib_has_custom_rules;
diff --git a/net/core/net_namespace.c b/net/core/net_namespace.c
index c340d5cfbdec..95ba2c53bd9a 100644
--- a/net/core/net_namespace.c
+++ b/net/core/net_namespace.c
@@ -301,6 +301,7 @@ static __net_init int setup_net(struct net *net, struct user_namespace *user_ns)
net->user_ns = user_ns;
idr_init(&net->netns_ids);
spin_lock_init(&net->nsid_lock);
+ mutex_init(&net->ipv4.ra_mutex);
list_for_each_entry(ops, &pernet_list, list) {
error = ops_init(ops, net);
diff --git a/net/ipv4/ip_sockglue.c b/net/ipv4/ip_sockglue.c
index f36d35fe924b..5ad2d8ed3a3f 100644
--- a/net/ipv4/ip_sockglue.c
+++ b/net/ipv4/ip_sockglue.c
@@ -322,9 +322,6 @@ int ip_cmsg_send(struct sock *sk, struct msghdr *msg, struct ipcm_cookie *ipc,
return 0;
}
-static DEFINE_SPINLOCK(ip_ra_lock);
-
-
static void ip_ra_destroy_rcu(struct rcu_head *head)
{
struct ip_ra_chain *ra = container_of(head, struct ip_ra_chain, rcu);
@@ -345,21 +342,21 @@ int ip_ra_control(struct sock *sk, unsigned char on,
new_ra = on ? kmalloc(sizeof(*new_ra), GFP_KERNEL) : NULL;
- spin_lock_bh(&ip_ra_lock);
+ mutex_lock(&net->ipv4.ra_mutex);
for (rap = &net->ipv4.ra_chain;
(ra = rcu_dereference_protected(*rap,
- lockdep_is_held(&ip_ra_lock))) != NULL;
+ lockdep_is_held(&net->ipv4.ra_mutex))) != NULL;
rap = &ra->next) {
if (ra->sk == sk) {
if (on) {
- spin_unlock_bh(&ip_ra_lock);
+ mutex_unlock(&net->ipv4.ra_mutex);
kfree(new_ra);
return -EADDRINUSE;
}
/* dont let ip_call_ra_chain() use sk again */
ra->sk = NULL;
RCU_INIT_POINTER(*rap, ra->next);
- spin_unlock_bh(&ip_ra_lock);
+ mutex_unlock(&net->ipv4.ra_mutex);
if (ra->destructor)
ra->destructor(sk);
@@ -374,7 +371,7 @@ int ip_ra_control(struct sock *sk, unsigned char on,
}
}
if (!new_ra) {
- spin_unlock_bh(&ip_ra_lock);
+ mutex_unlock(&net->ipv4.ra_mutex);
return -ENOBUFS;
}
new_ra->sk = sk;
@@ -383,7 +380,7 @@ int ip_ra_control(struct sock *sk, unsigned char on,
RCU_INIT_POINTER(new_ra->next, ra);
rcu_assign_pointer(*rap, new_ra);
sock_hold(sk);
- spin_unlock_bh(&ip_ra_lock);
+ mutex_unlock(&net->ipv4.ra_mutex);
return 0;
}
^ permalink raw reply related
* [PATCH net-next 4/5] net: Make ip_ra_chain per struct net
From: Kirill Tkhai @ 2018-03-15 13:20 UTC (permalink / raw)
To: davem, yoshfuji, edumazet, yanhaishuang, nikolay, yotamg, soheil,
ktkhai, avagin, nicolas.dichtel, ebiederm, fw, roman.kapl, netdev,
xiyou.wangcong, dvyukov, andreyknvl
In-Reply-To: <152111892326.30586.3742839588131331286.stgit@localhost.localdomain>
This is optimization, which makes ip_call_ra_chain()
iterate less sockets to find the sockets it's looking for.
Signed-off-by: Kirill Tkhai <ktkhai@virtuozzo.com>
---
include/net/ip.h | 13 +++++++++++--
include/net/netns/ipv4.h | 1 +
net/ipv4/ip_input.c | 5 ++---
net/ipv4/ip_sockglue.c | 15 ++-------------
4 files changed, 16 insertions(+), 18 deletions(-)
diff --git a/include/net/ip.h b/include/net/ip.h
index fe63ba95d12b..d53b5a9eae34 100644
--- a/include/net/ip.h
+++ b/include/net/ip.h
@@ -91,6 +91,17 @@ static inline int inet_sdif(struct sk_buff *skb)
return 0;
}
+/* Special input handler for packets caught by router alert option.
+ They are selected only by protocol field, and then processed likely
+ local ones; but only if someone wants them! Otherwise, router
+ not running rsvpd will kill RSVP.
+
+ It is user level problem, what it will make with them.
+ I have no idea, how it will masquearde or NAT them (it is joke, joke :-)),
+ but receiver should be enough clever f.e. to forward mtrace requests,
+ sent to multicast group to reach destination designated router.
+ */
+
struct ip_ra_chain {
struct ip_ra_chain __rcu *next;
struct sock *sk;
@@ -101,8 +112,6 @@ struct ip_ra_chain {
struct rcu_head rcu;
};
-extern struct ip_ra_chain __rcu *ip_ra_chain;
-
/* IP flags. */
#define IP_CE 0x8000 /* Flag: "Congestion" */
#define IP_DF 0x4000 /* Flag: "Don't Fragment" */
diff --git a/include/net/netns/ipv4.h b/include/net/netns/ipv4.h
index 3a970e429ab6..23c208fcf1a0 100644
--- a/include/net/netns/ipv4.h
+++ b/include/net/netns/ipv4.h
@@ -49,6 +49,7 @@ struct netns_ipv4 {
#endif
struct ipv4_devconf *devconf_all;
struct ipv4_devconf *devconf_dflt;
+ struct ip_ra_chain *ra_chain;
#ifdef CONFIG_IP_MULTIPLE_TABLES
struct fib_rules_ops *rules_ops;
bool fib_has_custom_rules;
diff --git a/net/ipv4/ip_input.c b/net/ipv4/ip_input.c
index 57fc13c6ab2b..7582713dd18f 100644
--- a/net/ipv4/ip_input.c
+++ b/net/ipv4/ip_input.c
@@ -159,7 +159,7 @@ bool ip_call_ra_chain(struct sk_buff *skb)
struct net_device *dev = skb->dev;
struct net *net = dev_net(dev);
- for (ra = rcu_dereference(ip_ra_chain); ra; ra = rcu_dereference(ra->next)) {
+ for (ra = rcu_dereference(net->ipv4.ra_chain); ra; ra = rcu_dereference(ra->next)) {
struct sock *sk = ra->sk;
/* If socket is bound to an interface, only report
@@ -167,8 +167,7 @@ bool ip_call_ra_chain(struct sk_buff *skb)
*/
if (sk && inet_sk(sk)->inet_num == protocol &&
(!sk->sk_bound_dev_if ||
- sk->sk_bound_dev_if == dev->ifindex) &&
- net_eq(sock_net(sk), net)) {
+ sk->sk_bound_dev_if == dev->ifindex)) {
if (ip_is_fragment(ip_hdr(skb))) {
if (ip_defrag(net, skb, IP_DEFRAG_CALL_RA_CHAIN))
return true;
diff --git a/net/ipv4/ip_sockglue.c b/net/ipv4/ip_sockglue.c
index bf5f44b27b7e..f36d35fe924b 100644
--- a/net/ipv4/ip_sockglue.c
+++ b/net/ipv4/ip_sockglue.c
@@ -322,18 +322,6 @@ int ip_cmsg_send(struct sock *sk, struct msghdr *msg, struct ipcm_cookie *ipc,
return 0;
}
-
-/* Special input handler for packets caught by router alert option.
- They are selected only by protocol field, and then processed likely
- local ones; but only if someone wants them! Otherwise, router
- not running rsvpd will kill RSVP.
-
- It is user level problem, what it will make with them.
- I have no idea, how it will masquearde or NAT them (it is joke, joke :-)),
- but receiver should be enough clever f.e. to forward mtrace requests,
- sent to multicast group to reach destination designated router.
- */
-struct ip_ra_chain __rcu *ip_ra_chain;
static DEFINE_SPINLOCK(ip_ra_lock);
@@ -350,6 +338,7 @@ int ip_ra_control(struct sock *sk, unsigned char on,
{
struct ip_ra_chain *ra, *new_ra;
struct ip_ra_chain __rcu **rap;
+ struct net *net = sock_net(sk);
if (sk->sk_type != SOCK_RAW || inet_sk(sk)->inet_num == IPPROTO_RAW)
return -EINVAL;
@@ -357,7 +346,7 @@ int ip_ra_control(struct sock *sk, unsigned char on,
new_ra = on ? kmalloc(sizeof(*new_ra), GFP_KERNEL) : NULL;
spin_lock_bh(&ip_ra_lock);
- for (rap = &ip_ra_chain;
+ for (rap = &net->ipv4.ra_chain;
(ra = rcu_dereference_protected(*rap,
lockdep_is_held(&ip_ra_lock))) != NULL;
rap = &ra->next) {
^ permalink raw reply related
* [PATCH net-next 3/5] net: Move IP_ROUTER_ALERT out of lock_sock(sk)
From: Kirill Tkhai @ 2018-03-15 13:20 UTC (permalink / raw)
To: davem, yoshfuji, edumazet, yanhaishuang, nikolay, yotamg, soheil,
ktkhai, avagin, nicolas.dichtel, ebiederm, fw, roman.kapl, netdev,
xiyou.wangcong, dvyukov, andreyknvl
In-Reply-To: <152111892326.30586.3742839588131331286.stgit@localhost.localdomain>
ip_ra_control() does not need sk_lock. Who are the another
users of ip_ra_chain? ip_mroute_setsockopt() doesn't take
sk_lock, while parallel IP_ROUTER_ALERT syscalls are
synchronized by ip_ra_lock. So, we may move this command
out of sk_lock.
Signed-off-by: Kirill Tkhai <ktkhai@virtuozzo.com>
---
net/ipv4/ip_sockglue.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/net/ipv4/ip_sockglue.c b/net/ipv4/ip_sockglue.c
index b7bac7351409..bf5f44b27b7e 100644
--- a/net/ipv4/ip_sockglue.c
+++ b/net/ipv4/ip_sockglue.c
@@ -646,6 +646,8 @@ static int do_ip_setsockopt(struct sock *sk, int level,
/* If optlen==0, it is equivalent to val == 0 */
+ if (optname == IP_ROUTER_ALERT)
+ return ip_ra_control(sk, val ? 1 : 0, NULL);
if (ip_mroute_opt(optname))
return ip_mroute_setsockopt(sk, optname, optval, optlen);
@@ -1156,9 +1158,6 @@ static int do_ip_setsockopt(struct sock *sk, int level,
goto e_inval;
inet->mc_all = val;
break;
- case IP_ROUTER_ALERT:
- err = ip_ra_control(sk, val ? 1 : 0, NULL);
- break;
case IP_FREEBIND:
if (optlen < 1)
^ permalink raw reply related
* [PATCH net-next 2/5] net: Revert "ipv4: fix a deadlock in ip_ra_control"
From: Kirill Tkhai @ 2018-03-15 13:20 UTC (permalink / raw)
To: davem, yoshfuji, edumazet, yanhaishuang, nikolay, yotamg, soheil,
ktkhai, avagin, nicolas.dichtel, ebiederm, fw, roman.kapl, netdev,
xiyou.wangcong, dvyukov, andreyknvl
In-Reply-To: <152111892326.30586.3742839588131331286.stgit@localhost.localdomain>
This reverts commit 1215e51edad1.
Since raw_close() is used on every RAW socket destruction,
the changes made by 1215e51edad1 scale sadly. This clearly
seen on endless unshare(CLONE_NEWNET) test, and cleanup_net()
kwork spends a lot of time waiting for rtnl_lock() introduced
by this commit.
Next patches in series will rework this in another way,
so now we revert 1215e51edad1. Also, it doesn't seen
mrtsock_destruct() takes sk_lock, and the comment to the commit
does not show the actual stack dump. So, there is a question
did we really need in it.
Signed-off-by: Kirill Tkhai <ktkhai@virtuozzo.com>
---
net/ipv4/ip_sockglue.c | 1 -
net/ipv4/ipmr.c | 11 +++++++++--
net/ipv4/raw.c | 2 --
3 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/net/ipv4/ip_sockglue.c b/net/ipv4/ip_sockglue.c
index be7c3b71914d..b7bac7351409 100644
--- a/net/ipv4/ip_sockglue.c
+++ b/net/ipv4/ip_sockglue.c
@@ -594,7 +594,6 @@ static bool setsockopt_needs_rtnl(int optname)
case MCAST_LEAVE_GROUP:
case MCAST_LEAVE_SOURCE_GROUP:
case MCAST_UNBLOCK_SOURCE:
- case IP_ROUTER_ALERT:
return true;
}
return false;
diff --git a/net/ipv4/ipmr.c b/net/ipv4/ipmr.c
index d752a70855d8..f6be5db16da2 100644
--- a/net/ipv4/ipmr.c
+++ b/net/ipv4/ipmr.c
@@ -1399,7 +1399,7 @@ static void mrtsock_destruct(struct sock *sk)
struct net *net = sock_net(sk);
struct mr_table *mrt;
- ASSERT_RTNL();
+ rtnl_lock();
ipmr_for_each_table(mrt, net) {
if (sk == rtnl_dereference(mrt->mroute_sk)) {
IPV4_DEVCONF_ALL(net, MC_FORWARDING)--;
@@ -1411,6 +1411,7 @@ static void mrtsock_destruct(struct sock *sk)
mroute_clean_tables(mrt, false);
}
}
+ rtnl_unlock();
}
/* Socket options and virtual interface manipulation. The whole
@@ -1475,8 +1476,13 @@ int ip_mroute_setsockopt(struct sock *sk, int optname, char __user *optval,
if (sk != rcu_access_pointer(mrt->mroute_sk)) {
ret = -EACCES;
} else {
+ /* We need to unlock here because mrtsock_destruct takes
+ * care of rtnl itself and we can't change that due to
+ * the IP_ROUTER_ALERT setsockopt which runs without it.
+ */
+ rtnl_unlock();
ret = ip_ra_control(sk, 0, NULL);
- goto out_unlock;
+ goto out;
}
break;
case MRT_ADD_VIF:
@@ -1588,6 +1594,7 @@ int ip_mroute_setsockopt(struct sock *sk, int optname, char __user *optval,
}
out_unlock:
rtnl_unlock();
+out:
return ret;
}
diff --git a/net/ipv4/raw.c b/net/ipv4/raw.c
index 54648d20bf0f..720bef7da2f6 100644
--- a/net/ipv4/raw.c
+++ b/net/ipv4/raw.c
@@ -711,9 +711,7 @@ static void raw_close(struct sock *sk, long timeout)
/*
* Raw sockets may have direct kernel references. Kill them.
*/
- rtnl_lock();
ip_ra_control(sk, 0, NULL);
- rtnl_unlock();
sk_common_release(sk);
}
^ permalink raw reply related
* [PATCH net-next 1/5] net: Revert "ipv4: get rid of ip_ra_lock"
From: Kirill Tkhai @ 2018-03-15 13:20 UTC (permalink / raw)
To: davem, yoshfuji, edumazet, yanhaishuang, nikolay, yotamg, soheil,
ktkhai, avagin, nicolas.dichtel, ebiederm, fw, roman.kapl, netdev,
xiyou.wangcong, dvyukov, andreyknvl
In-Reply-To: <152111892326.30586.3742839588131331286.stgit@localhost.localdomain>
This reverts commit ba3f571d5dde. The commit was made
after 1215e51edad1 "ipv4: fix a deadlock in ip_ra_control",
and killed ip_ra_lock, which became useless after rtnl_lock()
made used to destroy every raw ipv4 socket. This scales
very bad, and next patch in series reverts 1215e51edad1.
ip_ra_lock will be used again.
Signed-off-by: Kirill Tkhai <ktkhai@virtuozzo.com>
---
net/ipv4/ip_sockglue.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/ip_sockglue.c b/net/ipv4/ip_sockglue.c
index 74c962b9b09c..be7c3b71914d 100644
--- a/net/ipv4/ip_sockglue.c
+++ b/net/ipv4/ip_sockglue.c
@@ -334,6 +334,7 @@ int ip_cmsg_send(struct sock *sk, struct msghdr *msg, struct ipcm_cookie *ipc,
sent to multicast group to reach destination designated router.
*/
struct ip_ra_chain __rcu *ip_ra_chain;
+static DEFINE_SPINLOCK(ip_ra_lock);
static void ip_ra_destroy_rcu(struct rcu_head *head)
@@ -355,17 +356,21 @@ int ip_ra_control(struct sock *sk, unsigned char on,
new_ra = on ? kmalloc(sizeof(*new_ra), GFP_KERNEL) : NULL;
+ spin_lock_bh(&ip_ra_lock);
for (rap = &ip_ra_chain;
- (ra = rtnl_dereference(*rap)) != NULL;
+ (ra = rcu_dereference_protected(*rap,
+ lockdep_is_held(&ip_ra_lock))) != NULL;
rap = &ra->next) {
if (ra->sk == sk) {
if (on) {
+ spin_unlock_bh(&ip_ra_lock);
kfree(new_ra);
return -EADDRINUSE;
}
/* dont let ip_call_ra_chain() use sk again */
ra->sk = NULL;
RCU_INIT_POINTER(*rap, ra->next);
+ spin_unlock_bh(&ip_ra_lock);
if (ra->destructor)
ra->destructor(sk);
@@ -379,14 +384,17 @@ int ip_ra_control(struct sock *sk, unsigned char on,
return 0;
}
}
- if (!new_ra)
+ if (!new_ra) {
+ spin_unlock_bh(&ip_ra_lock);
return -ENOBUFS;
+ }
new_ra->sk = sk;
new_ra->destructor = destructor;
RCU_INIT_POINTER(new_ra->next, ra);
rcu_assign_pointer(*rap, new_ra);
sock_hold(sk);
+ spin_unlock_bh(&ip_ra_lock);
return 0;
}
^ permalink raw reply related
* [PATCH net-next 0/5] Rework ip_ra_chain protection
From: Kirill Tkhai @ 2018-03-15 13:19 UTC (permalink / raw)
To: davem, yoshfuji, edumazet, yanhaishuang, nikolay, yotamg, soheil,
ktkhai, avagin, nicolas.dichtel, ebiederm, fw, roman.kapl, netdev,
xiyou.wangcong, dvyukov, andreyknvl
Commit 1215e51edad1 "ipv4: fix a deadlock in ip_ra_control"
made rtnl_lock() be used in raw_close(). This function is called
on every RAW socket destruction, so that rtnl_mutex is taken
every time. This scales very sadly. I observe cleanup_net()
spending a lot of time in rtnl_lock() and raw_close() is one
of the biggest rtnl user (since we have percpu net->ipv4.icmp_sk).
Another problem is that commit does not explain actual call path
mrtsock_destruct() takes sk lock and the way to deadlock.
But there is no sk lock taking is visible in mrtsock_destruct().
So, it is a question does we need it at all.
This patchset reworks the locking: reverts the problem commit
and its descendant, and introduces rtnl-independent locking.
This may have a continuation, and someone may work on killing
rtnl_lock() in mrtsock_destruct() in the future.
Thanks,
Kirill
---
Kirill Tkhai (5):
net: Revert "ipv4: get rid of ip_ra_lock"
net: Revert "ipv4: fix a deadlock in ip_ra_control"
net: Move IP_ROUTER_ALERT out of lock_sock(sk)
net: Make ip_ra_chain per struct net
net: Replace ip_ra_lock with per-net mutex
include/net/ip.h | 13 +++++++++++--
include/net/netns/ipv4.h | 2 ++
net/core/net_namespace.c | 1 +
net/ipv4/ip_input.c | 5 ++---
net/ipv4/ip_sockglue.c | 34 +++++++++++++---------------------
net/ipv4/ipmr.c | 11 +++++++++--
net/ipv4/raw.c | 2 --
7 files changed, 38 insertions(+), 30 deletions(-)
--
Signed-off-by: Kirill Tkhai <ktkhai@virtuozzo.com>
^ permalink raw reply
* Inphi IN112525 PHY
From: Vicenţiu Galanopulo @ 2018-03-15 13:19 UTC (permalink / raw)
To: netdev@vger.kernel.org
Hi Everyone,
We have a new board which is to be released this year, which has a Inphi IN112525 PHY. We are currently developing under kernel 4.9 and using the xgmac_mdio driver for the MDIO bus. The long term plan is to have a Inphi kernel PHY driver upstream, but right now we want to make it work for 4.9.
Our problem is that:
The Inphi PHY has a vendor specific address space for accessing the C45 MDIO registers - MMD30 address space - starting from 0x1E.
I noticed that during the probing of the MDIO bus, in phy_device.c, get_phy_c45_ids(), it first searches for non-zero Devices In package, with the dev_addr = 1.
After that, device zero (dev_addr = 0) is probed ("Device zero is reserved for 802.3 c45 complied PHYs[.]") as a special case for Cortina CS4315/CS4340 PHY.
Since the dev_addr for our Inphi PHY is 0x1E, it never gets found and the PHY driver doesn't get registered.
My colleagues have proposed a solution in which another property could be added in the PHY device tree node, that would contain the device address (dev_addr).
This would imply some minor changes in phy_device.c , in get_phy_c45_ids(), but the benefit of this would be that it should work for other PHY vendors which decide to have a non-standard MDIO register set address.
I have a patch ready for this, but we would like to know if this is right way to go about this.
Please share your thoughts on this.
All the best,
Vicentiu
^ permalink raw reply
* Re: [PATCH 11/16] treewide: simplify Kconfig dependencies for removed archs
From: Kalle Valo @ 2018-03-15 12:54 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arch-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-block-u79uwXL29TY76Z2rM5mHXA,
linux-ide-u79uwXL29TY76Z2rM5mHXA,
linux-input-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
linux-pwm-u79uwXL29TY76Z2rM5mHXA,
linux-rtc-u79uwXL29TY76Z2rM5mHXA,
linux-spi-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
linux-watchdog-u79uwXL29TY76Z2rM5mHXA,
linux-fsdevel-u79uwXL29TY76Z2rM5mHXA,
linux-mm-Bw31MaZKKs3YtjvyW6yDsg
In-Reply-To: <20180314144614.1632190-1-arnd-r2nGTMty4D4@public.gmane.org>
Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> writes:
> A lot of Kconfig symbols have architecture specific dependencies.
> In those cases that depend on architectures we have already removed,
> they can be omitted.
>
> Signed-off-by: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
[...]
> drivers/net/wireless/cisco/Kconfig | 2 +-
Acked-by: Kalle Valo <kvalo-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
--
Kalle Valo
^ permalink raw reply
* [PATCH net] mlxsw: spectrum_buffers: Set a minimum quota for CPU port traffic
From: Ido Schimmel @ 2018-03-15 12:49 UTC (permalink / raw)
To: netdev; +Cc: davem, jiri, eddies, alexpe, mlxsw, Ido Schimmel
In commit 9ffcc3725f09 ("mlxsw: spectrum: Allow packets to be trapped
from any PG") I fixed a problem where packets could not be trapped to
the CPU due to exceeded shared buffer quotas. The mentioned commit
explains the problem in detail.
The problem was fixed by assigning a minimum quota for the CPU port and
the traffic class used for scheduling traffic to the CPU.
However, commit 117b0dad2d54 ("mlxsw: Create a different trap group list
for each device") assigned different traffic classes to different
packet types and rendered the fix useless.
Fix the problem by assigning a minimum quota for the CPU port and all
the traffic classes that are currently in use.
Fixes: 117b0dad2d54 ("mlxsw: Create a different trap group list for each device")
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Reported-by: Eddie Shklaer <eddies@mellanox.com>
Tested-by: Eddie Shklaer <eddies@mellanox.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
---
Please consider the patch for -stable. Thanks!
---
drivers/net/ethernet/mellanox/mlxsw/spectrum_buffers.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_buffers.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum_buffers.c
index 93728c694e6d..0a9adc5962fb 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_buffers.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_buffers.c
@@ -385,13 +385,13 @@ static const struct mlxsw_sp_sb_cm mlxsw_sp_sb_cms_egress[] = {
static const struct mlxsw_sp_sb_cm mlxsw_sp_cpu_port_sb_cms[] = {
MLXSW_SP_CPU_PORT_SB_CM,
+ MLXSW_SP_SB_CM(MLXSW_PORT_MAX_MTU, 0, 0),
+ MLXSW_SP_SB_CM(MLXSW_PORT_MAX_MTU, 0, 0),
+ MLXSW_SP_SB_CM(MLXSW_PORT_MAX_MTU, 0, 0),
+ MLXSW_SP_SB_CM(MLXSW_PORT_MAX_MTU, 0, 0),
+ MLXSW_SP_SB_CM(MLXSW_PORT_MAX_MTU, 0, 0),
MLXSW_SP_CPU_PORT_SB_CM,
- MLXSW_SP_CPU_PORT_SB_CM,
- MLXSW_SP_CPU_PORT_SB_CM,
- MLXSW_SP_CPU_PORT_SB_CM,
- MLXSW_SP_CPU_PORT_SB_CM,
- MLXSW_SP_CPU_PORT_SB_CM,
- MLXSW_SP_SB_CM(10000, 0, 0),
+ MLXSW_SP_SB_CM(MLXSW_PORT_MAX_MTU, 0, 0),
MLXSW_SP_CPU_PORT_SB_CM,
MLXSW_SP_CPU_PORT_SB_CM,
MLXSW_SP_CPU_PORT_SB_CM,
--
2.14.3
^ permalink raw reply related
* Re: [PATCH] net: dev_forward_skb(): Scrub packet's per-netns info only when crossing netns
From: Shmulik Ladkani @ 2018-03-15 12:50 UTC (permalink / raw)
To: Daniel Borkmann
Cc: Liran Alon, davem, netdev, linux-kernel, idan.brown, Yuval Shaia
In-Reply-To: <a673c689-ec30-61f6-9238-6b1773788201@iogearbox.net>
Hi,
On Thu, 15 Mar 2018 12:56:13 +0100 Daniel Borkmann <daniel@iogearbox.net> wrote:
> On 03/15/2018 10:21 AM, Shmulik Ladkani wrote:
> >
> > Regarding veth xmit, it does makes sense to preserve the fields if not
> > crossing netns. This is also the case when one uses tc mirred.
> >
> > Regarding bpf redirect, well, it depends on the expectations of each bpf
> > program.
> > I'd argue that preserving the fields (at least the mark field) in the
> > *non* xnet makes sense and provides more information and therefore more
> > capabilities; Alas this might change behavior already being relied on.
> >
> > Maybe Daniel can comment on the matter.
>
> Overall I think it might be nice to not need scrubbing skb in such cases,
> although my concern would be that this has potential to break existing
> setups when they would expect mark being zero on other veth peer in any
> case since it's the behavior for a long time already. The safer option
> would be to have some sort of explicit opt-in e.g. on link creation to let
> the skb->mark pass through unscrubbed. This would definitely be a useful
> option e.g. when mark is set in the netns facing veth via clsact/egress
> on xmit and when the container is unprivileged anyway.
For the veth xmit case, an opt-in flag which disables mark scrubbing in
the *non* xnet veth-pair seems reasonable.
But what about bpf_redirect BPF_F_INGRESS, in setups not invovling
containers?
Currently bpf_redirect is implemented using dev_forward_skb which
*fully* scrubs the skb, even if the target device is on same netns as
skb->dev is.
One might use ebpf programs that perform BPF_F_INGRESS bpf_redirect, for
example for demuxing skbs arriving on some "master" device into various
"slave" devices using specialized critiria.
It would be beneficial to have the mark preserved when skb is injected
to the slave device's rx path (especially when it's on the same netns).
Liran's patch fixes this - but at the cost of changing existing behavior
for BPF_F_INGRESS users (formerly: fully scrubbed; post patch: scrubbed
only if xnet).
I wonder, do you know of implementations that actually RELY on the fact
that BPF_F_INGRESS actually clears the mark, in the *non* xnet case?
Regards,
Shmulik
^ permalink raw reply
* Re: [PATCH] net: dev_forward_skb(): Scrub packet's per-netns info only when crossing netns
From: Liran Alon @ 2018-03-15 12:23 UTC (permalink / raw)
To: daniel
Cc: netdev, shmulik.ladkani, davem, linux-kernel, yuval.shaia,
idan.brown
----- daniel@iogearbox.net wrote:
> On 03/15/2018 10:21 AM, Shmulik Ladkani wrote:
> > Regarding the premise of this commit, this "reduces" the
> > ipvs/orphan/mark scrubbing in the following *non* xnet situations:
> >
> > 1. mac2vlan port xmit to other macvlan ports in Bridge Mode
> > 2. similarly for ipvlan
> > 3. veth xmit
> > 4. l2tp_eth_dev_recv
> > 5. bpf redirect/clone_redirect ingress actions
> >
> > Regarding l2tp recv, this commit seems to align the srubbing
> behavior
> > with ip tunnels (full scrub only if crossing netns, see
> ip_tunnel_rcv).
> >
> > Regarding veth xmit, it does makes sense to preserve the fields if
> not
> > crossing netns. This is also the case when one uses tc mirred.
> >
> > Regarding bpf redirect, well, it depends on the expectations of each
> bpf
> > program.
> > I'd argue that preserving the fields (at least the mark field) in
> the
> > *non* xnet makes sense and provides more information and therefore
> more
> > capabilities; Alas this might change behavior already being relied
> on.
> >
> > Maybe Daniel can comment on the matter.
>
> Overall I think it might be nice to not need scrubbing skb in such
> cases,
> although my concern would be that this has potential to break
> existing
> setups when they would expect mark being zero on other veth peer in
> any
> case since it's the behavior for a long time already. The safer
> option
> would be to have some sort of explicit opt-in e.g. on link creation to
> let
> the skb->mark pass through unscrubbed. This would definitely be a
> useful
> option e.g. when mark is set in the netns facing veth via
> clsact/egress
> on xmit and when the container is unprivileged anyway.
>
> Thanks,
> Daniel
I see your point in regards to backwards comparability.
However, not scrubbing skb when it cross netns via some kernel functions compared to
others is basically a bug which could easily break with a little bit of more refactoring.
Therefore, it seems a bit weird to me to from now on, we will force
every user on link creation to consider that once there was a bug leading
to this weird behavior on specific netdevs.
Thus, I suggest to maybe control this via a global /proc/sys/net file instead.
-Liran
^ permalink raw reply
* Re: [PATCH 05/47] net: remove cris etrax ethernet driver
From: Jesper Nilsson @ 2018-03-15 12:19 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-kernel, David S. Miller, Greg Kroah-Hartman,
Florian Fainelli, Quentin Monnet, Daniel Borkmann, Jakub Kicinski,
Amir Levy, Gerard Garcia, netdev
In-Reply-To: <20180314153603.3127932-6-arnd@arndb.de>
On Wed, Mar 14, 2018 at 04:35:18PM +0100, Arnd Bergmann wrote:
> The cris architecture is getting removed, so we don't need the
> ethernet driver any more either.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Jesper Nilsson <jesper.nilsson@axis.com>
> ---
> drivers/net/Makefile | 1 -
> drivers/net/cris/Makefile | 1 -
> drivers/net/cris/eth_v10.c | 1742 --------------------------------------------
> 3 files changed, 1744 deletions(-)
> delete mode 100644 drivers/net/cris/Makefile
> delete mode 100644 drivers/net/cris/eth_v10.c
>
> diff --git a/drivers/net/Makefile b/drivers/net/Makefile
> index 04c3b747812c..91e67e375dd4 100644
> --- a/drivers/net/Makefile
> +++ b/drivers/net/Makefile
> @@ -40,7 +40,6 @@ obj-$(CONFIG_ARCNET) += arcnet/
> obj-$(CONFIG_DEV_APPLETALK) += appletalk/
> obj-$(CONFIG_CAIF) += caif/
> obj-$(CONFIG_CAN) += can/
> -obj-$(CONFIG_ETRAX_ETHERNET) += cris/
> obj-$(CONFIG_NET_DSA) += dsa/
> obj-$(CONFIG_ETHERNET) += ethernet/
> obj-$(CONFIG_FDDI) += fddi/
> diff --git a/drivers/net/cris/Makefile b/drivers/net/cris/Makefile
> deleted file mode 100644
> index b4e8932227b6..000000000000
> diff --git a/drivers/net/cris/eth_v10.c b/drivers/net/cris/eth_v10.c
> deleted file mode 100644
> index 8b1a859f5140..000000000000
> --
> 2.9.0
/^JN - Jesper Nilsson
--
Jesper Nilsson -- jesper.nilsson@axis.com
^ permalink raw reply
* Re: [PATCH] net: dev_forward_skb(): Scrub packet's per-netns info only when crossing netns
From: Liran Alon @ 2018-03-15 12:14 UTC (permalink / raw)
To: shmulik.ladkani
Cc: netdev, daniel, davem, linux-kernel, yuval.shaia, idan.brown
----- shmulik.ladkani@gmail.com wrote:
> Hi,
>
> On Tue, 13 Mar 2018 17:07:22 +0200 Liran Alon <liran.alon@oracle.com>
> wrote:
> > Before this commit, dev_forward_skb() always cleared packet's
> > per-network-namespace info. Even if the packet doesn't cross
> > network namespaces.
> >
> > The comment above dev_forward_skb() describes that this is done
> > because the receiving device may be in another network namespace.
> > However, this case can easily be tested for and therefore we can
> > scrub packet's per-network-namespace info only when receiving
> device
> > is indeed in another network namespace.
> >
> > Therefore, this commit changes ____dev_forward_skb() to tell
> > skb_scrub_packet() that skb has crossed network-namespace only in
> case
> > transmitting device (skb->dev) network namespace is different then
> > receiving device (dev) network namespace.
>
> Assuming the premise of this commit is correct, note it may not act
> as
> intended for xnet situation in ipvlan_process_multicast, snip:
>
> nskb->dev = ipvlan->dev;
> if (tx_pkt)
> ret = dev_forward_skb(ipvlan->dev, nskb);
> else
> ret = netif_rx(nskb);
>
> as 'dev' gets already assigned to nskb prior dev_forward_skb (hence
> in
> ____dev_forward_skb both dev and skb->dev are the same).
> Fortunately every ipvlan_multicast_enqueue call is preceded by a
> forced
> scrub; It would be future-proof to not assign nskb->dev in the
> dev_forward_skb case (assign it only in the netif_rx case).
I agree. Nice catch.
skb->dev will later get assigned in eth_type_trans() called from __dev_forward_skb().
I will do this small change in a separate patch before this patch.
(In v2 of this series)
>
>
> Regarding the premise of this commit, this "reduces" the
> ipvs/orphan/mark scrubbing in the following *non* xnet situations:
>
> 1. mac2vlan port xmit to other macvlan ports in Bridge Mode
> 2. similarly for ipvlan
> 3. veth xmit
> 4. l2tp_eth_dev_recv
> 5. bpf redirect/clone_redirect ingress actions
>
> Regarding l2tp recv, this commit seems to align the srubbing behavior
> with ip tunnels (full scrub only if crossing netns, see
> ip_tunnel_rcv).
>
> Regarding veth xmit, it does makes sense to preserve the fields if
> not
> crossing netns. This is also the case when one uses tc mirred.
>
> Regarding bpf redirect, well, it depends on the expectations of each
> bpf
> program.
> I'd argue that preserving the fields (at least the mark field) in the
> *non* xnet makes sense and provides more information and therefore
> more
> capabilities; Alas this might change behavior already being relied
> on.
I now noticed that a similar change was done in the past in
commit 8a83a00b0735 ("net: maintain namespace isolation
between vlan and real device"). Commit changed dev_forward_skb() from always
setting skb->mark=0 to do this only in case we cross netns.
However, a later commit: 59b9997baba5 ("Revert "net: maintain namespace
isolation between vlan and real device") seems to later reverted that change.
But I think that the regression issue mentioned in the revert isn't
related to the change proposed by this commit.
Please correct me if I'm missing something.
>
> Maybe Daniel can comment on the matter.
>
> Regards,
> Shmulik
^ permalink raw reply
* [PATCH net-next] cxgb4: Fix queue free path of ULD drivers
From: Ganesh Goudar @ 2018-03-15 12:04 UTC (permalink / raw)
To: netdev, davem
Cc: nirranjan, indranil, venkatesh, Arjun Vynipadath, Casey Leedom,
Ganesh Goudhar
From: Arjun Vynipadath <arjun@chelsio.com>
Setting sge_uld_rxq_info to NULL in free_queues_uld().
We are referencing sge_uld_rxq_info in cxgb_up(). This
will fix a panic when interface is brought up after a
ULDq creation failure.
Fixes: 94cdb8bb993a (cxgb4: Add support for dynamic allocation
of resources for ULD)
Signed-off-by: Arjun Vynipadath <arjun@chelsio.com>
Signed-off-by: Casey Leedom <leedom@chelsio.com>
Signed-off-by: Ganesh Goudhar <ganeshgr@chelsio.com>
---
drivers/net/ethernet/chelsio/cxgb4/cxgb4_uld.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_uld.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_uld.c
index 6b5fea4..2d82714 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_uld.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_uld.c
@@ -342,6 +342,7 @@ static void free_queues_uld(struct adapter *adap, unsigned int uld_type)
{
struct sge_uld_rxq_info *rxq_info = adap->sge.uld_rxq_info[uld_type];
+ adap->sge.uld_rxq_info[uld_type] = NULL;
kfree(rxq_info->rspq_id);
kfree(rxq_info->uldrxq);
kfree(rxq_info);
--
2.1.0
^ permalink raw reply related
* Re: [PATCH] net: dev_forward_skb(): Scrub packet's per-netns info only when crossing netns
From: Daniel Borkmann @ 2018-03-15 11:56 UTC (permalink / raw)
To: Shmulik Ladkani, Liran Alon
Cc: davem, netdev, linux-kernel, idan.brown, Yuval Shaia
In-Reply-To: <20180315112150.58586758@halley>
On 03/15/2018 10:21 AM, Shmulik Ladkani wrote:
> Hi,
>
> On Tue, 13 Mar 2018 17:07:22 +0200 Liran Alon <liran.alon@oracle.com> wrote:
>> Before this commit, dev_forward_skb() always cleared packet's
>> per-network-namespace info. Even if the packet doesn't cross
>> network namespaces.
>>
>> The comment above dev_forward_skb() describes that this is done
>> because the receiving device may be in another network namespace.
>> However, this case can easily be tested for and therefore we can
>> scrub packet's per-network-namespace info only when receiving device
>> is indeed in another network namespace.
>>
>> Therefore, this commit changes ____dev_forward_skb() to tell
>> skb_scrub_packet() that skb has crossed network-namespace only in case
>> transmitting device (skb->dev) network namespace is different then
>> receiving device (dev) network namespace.
>
> Assuming the premise of this commit is correct, note it may not act as
> intended for xnet situation in ipvlan_process_multicast, snip:
>
> nskb->dev = ipvlan->dev;
> if (tx_pkt)
> ret = dev_forward_skb(ipvlan->dev, nskb);
> else
> ret = netif_rx(nskb);
>
> as 'dev' gets already assigned to nskb prior dev_forward_skb (hence in
> ____dev_forward_skb both dev and skb->dev are the same).
> Fortunately every ipvlan_multicast_enqueue call is preceded by a forced
> scrub; It would be future-proof to not assign nskb->dev in the
> dev_forward_skb case (assign it only in the netif_rx case).
>
>
> Regarding the premise of this commit, this "reduces" the
> ipvs/orphan/mark scrubbing in the following *non* xnet situations:
>
> 1. mac2vlan port xmit to other macvlan ports in Bridge Mode
> 2. similarly for ipvlan
> 3. veth xmit
> 4. l2tp_eth_dev_recv
> 5. bpf redirect/clone_redirect ingress actions
>
> Regarding l2tp recv, this commit seems to align the srubbing behavior
> with ip tunnels (full scrub only if crossing netns, see ip_tunnel_rcv).
>
> Regarding veth xmit, it does makes sense to preserve the fields if not
> crossing netns. This is also the case when one uses tc mirred.
>
> Regarding bpf redirect, well, it depends on the expectations of each bpf
> program.
> I'd argue that preserving the fields (at least the mark field) in the
> *non* xnet makes sense and provides more information and therefore more
> capabilities; Alas this might change behavior already being relied on.
>
> Maybe Daniel can comment on the matter.
Overall I think it might be nice to not need scrubbing skb in such cases,
although my concern would be that this has potential to break existing
setups when they would expect mark being zero on other veth peer in any
case since it's the behavior for a long time already. The safer option
would be to have some sort of explicit opt-in e.g. on link creation to let
the skb->mark pass through unscrubbed. This would definitely be a useful
option e.g. when mark is set in the netns facing veth via clsact/egress
on xmit and when the container is unprivileged anyway.
Thanks,
Daniel
^ permalink raw reply
* [PATCH net-next] rds: tcp: must use spin_lock_irq* and not spin_lock_bh with rds_tcp_conn_lock
From: Sowmini Varadhan @ 2018-03-15 10:54 UTC (permalink / raw)
To: netdev, sowmini.varadhan; +Cc: davem, sowmini.varadhan, santosh.shilimkar
rds_tcp_connection allocation/free management has the potential to be
called from __rds_conn_create after IRQs have been disabled, so
spin_[un]lock_bh cannot be used with rds_tcp_conn_lock.
Bottom-halves that need to synchronize for critical sections protected
by rds_tcp_conn_lock should instead use rds_destroy_pending() correctly.
Reported-by: syzbot+c68e51bb5e699d3f8d91@syzkaller.appspotmail.com
Fixes: ebeeb1ad9b8a ("rds: tcp: use rds_destroy_pending() to synchronize
netns/module teardown and rds connection/workq management")
Signed-off-by: Sowmini Varadhan <sowmini.varadhan@oracle.com>
---
net/rds/tcp.c | 17 +++++++++--------
1 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/net/rds/tcp.c b/net/rds/tcp.c
index eb04e7f..08ea9cd 100644
--- a/net/rds/tcp.c
+++ b/net/rds/tcp.c
@@ -272,13 +272,14 @@ static int rds_tcp_laddr_check(struct net *net, __be32 addr)
static void rds_tcp_conn_free(void *arg)
{
struct rds_tcp_connection *tc = arg;
+ unsigned long flags;
rdsdebug("freeing tc %p\n", tc);
- spin_lock_bh(&rds_tcp_conn_lock);
+ spin_lock_irqsave(&rds_tcp_conn_lock, flags);
if (!tc->t_tcp_node_detached)
list_del(&tc->t_tcp_node);
- spin_unlock_bh(&rds_tcp_conn_lock);
+ spin_unlock_irqrestore(&rds_tcp_conn_lock, flags);
kmem_cache_free(rds_tcp_conn_slab, tc);
}
@@ -308,13 +309,13 @@ static int rds_tcp_conn_alloc(struct rds_connection *conn, gfp_t gfp)
rdsdebug("rds_conn_path [%d] tc %p\n", i,
conn->c_path[i].cp_transport_data);
}
- spin_lock_bh(&rds_tcp_conn_lock);
+ spin_lock_irq(&rds_tcp_conn_lock);
for (i = 0; i < RDS_MPATH_WORKERS; i++) {
tc = conn->c_path[i].cp_transport_data;
tc->t_tcp_node_detached = false;
list_add_tail(&tc->t_tcp_node, &rds_tcp_conn_list);
}
- spin_unlock_bh(&rds_tcp_conn_lock);
+ spin_unlock_irq(&rds_tcp_conn_lock);
fail:
if (ret) {
for (j = 0; j < i; j++)
@@ -527,7 +528,7 @@ static void rds_tcp_kill_sock(struct net *net)
rtn->rds_tcp_listen_sock = NULL;
rds_tcp_listen_stop(lsock, &rtn->rds_tcp_accept_w);
- spin_lock_bh(&rds_tcp_conn_lock);
+ spin_lock_irq(&rds_tcp_conn_lock);
list_for_each_entry_safe(tc, _tc, &rds_tcp_conn_list, t_tcp_node) {
struct net *c_net = read_pnet(&tc->t_cpath->cp_conn->c_net);
@@ -540,7 +541,7 @@ static void rds_tcp_kill_sock(struct net *net)
tc->t_tcp_node_detached = true;
}
}
- spin_unlock_bh(&rds_tcp_conn_lock);
+ spin_unlock_irq(&rds_tcp_conn_lock);
list_for_each_entry_safe(tc, _tc, &tmp_list, t_tcp_node)
rds_conn_destroy(tc->t_cpath->cp_conn);
}
@@ -588,7 +589,7 @@ static void rds_tcp_sysctl_reset(struct net *net)
{
struct rds_tcp_connection *tc, *_tc;
- spin_lock_bh(&rds_tcp_conn_lock);
+ spin_lock_irq(&rds_tcp_conn_lock);
list_for_each_entry_safe(tc, _tc, &rds_tcp_conn_list, t_tcp_node) {
struct net *c_net = read_pnet(&tc->t_cpath->cp_conn->c_net);
@@ -598,7 +599,7 @@ static void rds_tcp_sysctl_reset(struct net *net)
/* reconnect with new parameters */
rds_conn_path_drop(tc->t_cpath, false);
}
- spin_unlock_bh(&rds_tcp_conn_lock);
+ spin_unlock_irq(&rds_tcp_conn_lock);
}
static int rds_tcp_skbuf_handler(struct ctl_table *ctl, int write,
--
1.7.1
^ permalink raw reply related
* Re: [PATCH v3 net 0/5] tcp: fixes to non-SACK TCP
From: Ilpo Järvinen @ 2018-03-15 11:13 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, Yuchung Cheng, Neal Cardwell, Sergei Shtylyov
In-Reply-To: <CANn89iJK5dQDiAKORfAhood-KAVKHGwO9FguZvh17tVKDLi-Lg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3836 bytes --]
On Tue, 13 Mar 2018, Eric Dumazet wrote:
> On Tue, Mar 13, 2018 at 3:25 AM, Ilpo Jᅵrvinen
> <ilpo.jarvinen@helsinki.fi> wrote:
> > Here is a series of fixes to issues that occur when SACK is not
> > enabled for a TCP connection. These are not fixes to just some
> > remote corner cases of recovery but many/almost all recoveries
> > without SACK will be impacted by one (or even more than one) of
> > them. The sender-side changes (1-4) are not mainly, if any, to
> > improve performance (throughput) but address correctness
> > (congestion control responses should not get incorrectly
> > reverted) and burstiness (that may cause additional problems
> > later as some of the packets in such bursts may get dropped
> > needing again to resort to loss recovery that is likely
> > similarly bursty).
>
> GRO (or similar) adoption a long time ago (not only by linux) had a
> serious impact on non SACK flow.
> Should we also disable GRO by default ?
> (my answer is no, just in case someone wonders)
>
> I am sorry, but I am still not convinced by your patches, trying to
> give a wrong incentive to people keeping their prehistoric stacks,
> that have serious problems on wifi anyway, and or middle boxes
> "aggregating/compressing ACKS"
So now you think that I'm against high perf enhancements (even after
having written some bits of them)?
However, I think that in case somebody disables something that is enabled
by default, be it SACK, GRO, timestamps, etc., TCP he/she will get should
still make sense (and that regardless of some middleboxes trying hard to
break otherwise working stuff). But I guess you don't agree here(?) and
would perhaps even want to remove ability to disable them? Although
obviously that wouldn't even work with non-SACK (unless RST or so starts
to get used but even that could be worked-around unfortunately).
Also, I'm somewhat confused your position here. On one hand you said that
tests should be added to regression tests to avoid breaking these non-SACK
cases again implying that things should be fixed and on the other hand you
seem to say that non-SACK must be left broken?
> The last patch is particularly problematic in my opinion, you have not
> provided packetdrill tests to prove there was no danger.
Can that even be done? Proving absence of danger with packetdrill?
AFAIK that kind of proofs are available only with formal verification.
> It seems you leave to us the task of dealing with possible issues,
> only added a bold changelog.
Heh, I tried to add details to the changelog because you explicitly said
I should and now you fault me on doing that :-). Also, you're leaving out
the detail that I tried to understand the condition that worried you and
found out that the code already disallows any shrinking of advertized
window for duplicate ACKs (but I guess there just might have been some
miscommunication between us given that your last reply to 5/5
v1 made no sense to me).
> Since the bugs you claim to fix are at least 10 years old, and your
> fixes are far from being trivial,
> please wait our packetdrill regression tests being published.
> This should happen in less than one month I believe, in time for linux-4.17
>
> Note that the publication of the updated packetdrill and test suite is
> not an easy task,
> since we accumulated a lot of hacks both in kernel to cope with timer
> slacks and in packetdrill
> for various experimental or private features that are not yet in
> upstream kernels.
>
> So we are cleaning all this, and will be happy to help you if you need.
I slightly disagree on the trivial bit here as I think it's trivial to
see the changes only affect non-SACK flows (of which you seem to say you
don't care if they're broken as that gives incentive to use SACK). But
then I'm not too worried about waiting a month.
--
i.
^ permalink raw reply
* Re: [PATCH v6 0/6] staging: Introduce DPAA2 Ethernet Switch driver
From: Dan Carpenter @ 2018-03-15 10:56 UTC (permalink / raw)
To: Andrew Lunn, laurentiu.tudor, stuyoder
Cc: devel, arnd, gregkh, alexandru.marginean, agraf, linux-kernel,
Razvan Stefanescu, ioana.ciornei, netdev
In-Reply-To: <20180314234437.GD16379@lunn.ch>
On Thu, Mar 15, 2018 at 12:44:37AM +0100, Andrew Lunn wrote:
> On Wed, Mar 14, 2018 at 10:55:52AM -0500, Razvan Stefanescu wrote:
> > This patchset introduces the Ethernet Switch Driver for Freescale/NXP SoCs
> > with DPAA2 (DataPath Acceleration Architecture v2). The driver manages
> > switch objects discovered on the fsl-mc bus. A description of the driver
> > can be found in the associated README file.
>
> Hi Greg
>
> This code has much better quality than the usual stuff in staging. I
> see no reason not to merge it.
Yeah. It seems pretty decent. Stuart, Laurentiu, care to comment?
Meanwhile, netdev and DaveM aren't even on the CC list and they're the
ones to ultimately decide.
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH] xfrm: fix rcu_read_unlock usage in xfrm_local_error
From: Steffen Klassert @ 2018-03-15 10:48 UTC (permalink / raw)
To: Taehee Yoo; +Cc: davem, netdev
In-Reply-To: <20180313082607.19409-1-ap420073@gmail.com>
On Tue, Mar 13, 2018 at 05:26:07PM +0900, Taehee Yoo wrote:
> In the xfrm_local_error, rcu_read_unlock should be called when afinfo
> is not NULL. because xfrm_state_get_afinfo calls rcu_read_unlock
> if afinfo is NULL.
>
> Signed-off-by: Taehee Yoo <ap420073@gmail.com>
Can you please add a 'Fixes:' tag, so that it can be
correctly backported to the stable trees?
Thanks!
^ permalink raw reply
* Re: [PATCH 00/16] remove eight obsolete architectures
From: Arnd Bergmann @ 2018-03-15 10:42 UTC (permalink / raw)
To: Hannes Reinecke
Cc: linux-arch, linux-block, linux-fbdev, linux-watchdog,
open list:DOCUMENTATION, Networking, linux-usb, linux-wireless,
Linux Kernel Mailing List, linux-pwm, linux-spi, David Howells,
IDE-ML, dri-devel, open list:HID CORE LAYER,
Linux FS-devel Mailing List, Linux-MM, linux-rtc
In-Reply-To: <6c9d075c-d7a8-72a5-9b2d-af1feaa06c6c@suse.de>
On Thu, Mar 15, 2018 at 10:59 AM, Hannes Reinecke <hare@suse.de> wrote:
> On 03/15/2018 10:42 AM, David Howells wrote:
>> Do we have anything left that still implements NOMMU?
>>
> RISC-V ?
> (evil grin :-)
Is anyone producing a chip that includes enough of the Privileged ISA spec
to have things like system calls, but not the MMU parts?
I thought at least initially the kernel only supports hardware that has a rather
complete feature set.
Arnd
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* [RFC PATCH] hns: hns_ae_get_stats_strings() can be static
From: kbuild test robot @ 2018-03-15 10:10 UTC (permalink / raw)
To: Ben Hutchings; +Cc: kbuild-all, Yisen Zhuang, Salil Mehta, netdev
In-Reply-To: <20180313234113.GH8564@decadent.org.uk>
Fixes: 1316dd7b461c ("hns: Clean up string operations")
Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
---
hns_ae_adapt.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c b/drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c
index 638476aa..aa89e46 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c
@@ -692,7 +692,7 @@ void hns_ae_get_stats(struct hnae_handle *handle, u64 *data)
hns_dsaf_get_stats(vf_cb->dsaf_dev, p, vf_cb->port_index);
}
-void hns_ae_get_stats_strings(struct hnae_handle *handle, u8 *data)
+static void hns_ae_get_stats_strings(struct hnae_handle *handle, u8 *data)
{
int port;
int idx;
@@ -724,7 +724,7 @@ void hns_ae_get_stats_strings(struct hnae_handle *handle, u8 *data)
hns_dsaf_get_stats_strings(p, port, dsaf_dev);
}
-int hns_ae_get_stats_count(struct hnae_handle *handle)
+static int hns_ae_get_stats_count(struct hnae_handle *handle)
{
u32 sset_count = 0;
struct hns_mac_cb *mac_cb;
^ permalink raw reply related
* Re: [PATCH 2/2] hns: Clean up string operations
From: kbuild test robot @ 2018-03-15 10:10 UTC (permalink / raw)
To: Ben Hutchings; +Cc: kbuild-all, Yisen Zhuang, Salil Mehta, netdev
In-Reply-To: <20180313234113.GH8564@decadent.org.uk>
Hi Ben,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on v4.16-rc4]
[also build test WARNING on next-20180314]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Ben-Hutchings/hns-Fix-string-set-validation-in-ethtool-string-operations/20180315-082407
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__
sparse warnings: (new ones prefixed by >>)
drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c:73:20: sparse: symbol 'hns_ae_get_handle' was not declared. Should it be static?
drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c:332:6: sparse: symbol 'hns_ae_stop' was not declared. Should it be static?
drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c:360:6: sparse: symbol 'hns_ae_toggle_ring_irq' was not declared. Should it be static?
drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c:580:6: sparse: symbol 'hns_ae_update_stats' was not declared. Should it be static?
drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c:663:6: sparse: symbol 'hns_ae_get_stats' was not declared. Should it be static?
>> drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c:695:6: sparse: symbol 'hns_ae_get_stats_strings' was not declared. Should it be static?
>> drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c:727:5: sparse: symbol 'hns_ae_get_stats_count' was not declared. Should it be static?
drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c:773:6: sparse: symbol 'hns_ae_update_led_status' was not declared. Should it be static?
drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c:785:5: sparse: symbol 'hns_ae_cpld_set_led_id' was not declared. Should it be static?
drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c:797:6: sparse: symbol 'hns_ae_get_regs' was not declared. Should it be static?
drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c:822:5: sparse: symbol 'hns_ae_get_regs_len' 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
* Re: [PATCH RFC 0/7] net: phy: patch series aiming to improve few aspects of phylib
From: Geert Uytterhoeven @ 2018-03-15 10:07 UTC (permalink / raw)
To: Heiner Kallweit
Cc: Florian Fainelli, Andrew Lunn, Geert Uytterhoeven,
netdev@vger.kernel.org
In-Reply-To: <421476ed-03c7-63a0-44a4-c6d9c7702647@gmail.com>
Hi Heiner,
On Wed, Mar 14, 2018 at 9:10 PM, Heiner Kallweit <hkallweit1@gmail.com> wrote:
> This patch series aims to tackle few issues with phylib:
>
> - address issues with patch series [1] (smsc911x + phylib changes)
> - make phy_stop synchronous
> - get rid of phy_start/stop_machine and handle it in phy_start/phy_stop
> - in mdio_suspend consider runtime pm state of mdio bus parent
> - consider more WOL conditions when deciding whether PHY is allowed to
> suspend
> - only resume phy after system suspend if needed
>
> [1] https://www.mail-archive.com/netdev@vger.kernel.org/msg196061.html
>
> It works fine here but other NIC drivers may use phylib differently.
> Therefore I'd appreciate feedback and more testing.
>
> I could think of some subsequent patches, e.g. phy_error() could be
> reduced to calling phy_stop() and printing an error message
> (today it silently sets the PHY state to PHY_HALTED).
>
> Heiner Kallweit (7):
> net: phy: unconditionally resume and re-enable interrupts in phy_start
> net: phy: improve checking for when PHY is allowed to suspend
> net: phy: resume PHY only if needed in mdio_bus_phy_suspend
> net: phy: remove phy_start_machine
> net: phy: make phy_stop synchronous
> net: phy: use new function phy_stop_suspending in mdio_bus_phy_suspend
> net: phy: remove phy_stop_machine
Thanks for your series!
I've gave this a try on a few machines, incl. r8a73a4/ape6evm and
sh73a0/kzm9g, which have smsc911x Ethernet chips on a power-managed bus.
On both machines it crashes during system suspend, which means the smsc911c's
registers are accessed while the device is suspended:
PM: suspend entry (deep)
PM: Syncing filesystems ... done.
Freezing user space processes ... (elapsed 0.001 seconds) done.
OOM killer disabled.
Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
PM: suspend devices took 0.130 seconds
Disabling non-boot CPUs ...
Unhandled fault: imprecise external abort (0x1406) at 0x000ce408
pgd = f4465d7b
[000ce408] *pgd=00000000
Internal error: : 1406 [#1] SMP ARM
Modules linked in:
CPU: 1 PID: 20 Comm: kworker/1:1 Not tainted
4.16.0-rc5-kzm9g-00470-g319cfb3643965f46-dirty #1030
Hardware name: Generic SH73A0 (Flattened Device Tree)
Workqueue: events linkwatch_event
PC is at __smsc911x_reg_read+0x1c/0x60
LR is at smsc911x_tx_get_txstatus+0x2c/0x7c
pc : [<c03eefd4>] lr : [<c03ef820>] psr: 20010093
sp : df51bd38 ip : df51bce0 fp : 00000000
r10: 00000000 r9 : 00000000 r8 : c0909b58
r7 : a0010013 r6 : df636e08 r5 : df636dc0 r4 : df636800
r3 : e0903000 r2 : 00000001 r1 : e0903080 r0 : 00000000
Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment none
Control: 10c5387d Table: 5ee4004a DAC: 00000051
Process kworker/1:1 (pid: 20, stack limit = 0x1e2af6bb)
Stack: (0xdf51bd38 to 0xdf51c000)
bd20: c03efb14 df636800
bd40: df636dc0 c063c198 df51bdb0 c03efa80 c03efb14 df636800 df636800 c03efb20
bd60: c03efb14 dec5e8f4 df636800 c063c198 df51bdb0 c04b4494 dec5e8f0 dec4ea80
bd80: df636800 c04d7c28 dec4ea80 df636800 dec5e800 c04d3d68 0000002a 00000000
bda0: c04d3990 c020af0c df400a80 00000000 00000000 00000000 00000000 00000000
bdc0: 00000000 00000000 00000050 00000000 df51be03 c04a5828 00000580 c04a5758
bde0: dec4ea80 000004db 014000c0 c0908448 00000001 c04a58a0 df51be03 c04d14e0
be00: 00000000 3cef0b86 c04d13bc dec4ea80 df636800 00000010 00000000 00000000
be20: df636800 00000000 c0931b44 c04d73c0 00000000 00000000 00000000 00000000
be40: 00000000 00000000 00000000 ffffffff 014000c0 df636800 c0931ad8 df51bed4
be60: c0931ad8 c04d7468 014000c0 00000000 00000000 c014404c c0908448 c0908448
be80: df636800 c04d7534 014000c0 00000000 00000000 014000c0 c0908448 c04b9d8c
bea0: df636800 00000000 00000000 3cef0b86 c0931b44 df636800 c0931b44 c04d8854
bec0: df636aac c04d8b10 df51bf2c c0908448 00000000 df51bed4 df51bed4 3cef0b86
bee0: df51bf2c df50dc80 c0931ad8 dfbdaac0 df51bf2c dfbddd00 00000000 00000001
bf00: 00000000 c04d8b98 c04d8b74 c013cc8c 00000001 00000000 c013cc14 c013d214
bf20: c0908448 00000000 00000004 c0931ad8 00000000 00000000 c075f7d9 3cef0b86
bf40: c0905900 df50dc80 dfbdaac0 dfbdaac0 df51a000 dfbdaaf4 c0905900 df50dc98
bf60: 00000008 c013d4b0 df518540 df50de80 df5110c0 00000000 df491eb0 df50dc80
bf80: c013d1e4 df50deb8 00000000 c014293c df5110c0 c014281c 00000000 00000000
bfa0: 00000000 00000000 00000000 c01010b4 00000000 00000000 00000000 00000000
bfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
bfe0: 00000000 00000000 00000000 00000000 00000013 00000000 7fdfffff fff7fdff
[<c03eefd4>] (__smsc911x_reg_read) from [<c03ef820>]
(smsc911x_tx_get_txstatus+0x2c/0x7c)
[<c03ef820>] (smsc911x_tx_get_txstatus) from [<c03efa80>]
(smsc911x_tx_update_txcounters+0x14/0xa8)
[<c03efa80>] (smsc911x_tx_update_txcounters) from [<c03efb20>]
(smsc911x_get_stats+0xc/0x58)
[<c03efb20>] (smsc911x_get_stats) from [<c04b4494>] (dev_get_stats+0x58/0xa8)
[<c04b4494>] (dev_get_stats) from [<c04d7c28>] (rtnl_fill_stats+0x38/0x118)
[<c04d7c28>] (rtnl_fill_stats) from [<c04d3d68>]
(rtnl_fill_ifinfo.constprop.12+0x6a8/0x105c)
[<c04d3d68>] (rtnl_fill_ifinfo.constprop.12) from [<c04d73c0>]
(rtmsg_ifinfo_build_skb+0x7c/0xd0)
[<c04d73c0>] (rtmsg_ifinfo_build_skb) from [<c04d7468>]
(rtmsg_ifinfo_event.part.6+0x28/0x4c)
[<c04d7468>] (rtmsg_ifinfo_event.part.6) from [<c04d7534>]
(rtmsg_ifinfo+0x24/0x2c)
[<c04d7534>] (rtmsg_ifinfo) from [<c04b9d8c>] (netdev_state_change+0x5c/0x80)
[<c04b9d8c>] (netdev_state_change) from [<c04d8854>]
(linkwatch_do_dev+0x50/0x74)
[<c04d8854>] (linkwatch_do_dev) from [<c04d8b10>]
(__linkwatch_run_queue+0x138/0x19c)
[<c04d8b10>] (__linkwatch_run_queue) from [<c04d8b98>]
(linkwatch_event+0x24/0x34)
[<c04d8b98>] (linkwatch_event) from [<c013cc8c>] (process_one_work+0x250/0x41c)
[<c013cc8c>] (process_one_work) from [<c013d4b0>] (worker_thread+0x2cc/0x40c)
[<c013d4b0>] (worker_thread) from [<c014293c>] (kthread+0x120/0x140)
[<c014293c>] (kthread) from [<c01010b4>] (ret_from_fork+0x14/0x20)
Exception stack(0xdf51bfb0 to 0xdf51bff8)
bfa0: 00000000 00000000 00000000 00000000
bfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
bfe0: 00000000 00000000 00000000 00000000 00000013 00000000
Code: e5903000 e0831001 e5910000 f57ff04f (e12fff1e)
I've bisected this to "net: phy: use new function phy_stop_suspending in,
mdio_bus_phy_suspend".
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 00/16] remove eight obsolete architectures
From: Hannes Reinecke @ 2018-03-15 9:59 UTC (permalink / raw)
To: David Howells, Arnd Bergmann
Cc: linux-arch-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-doc-u79uwXL29TY76Z2rM5mHXA,
linux-block-u79uwXL29TY76Z2rM5mHXA,
linux-ide-u79uwXL29TY76Z2rM5mHXA,
linux-input-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
linux-pwm-u79uwXL29TY76Z2rM5mHXA,
linux-rtc-u79uwXL29TY76Z2rM5mHXA,
linux-spi-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
linux-watchdog-u79uwXL29TY76Z2rM5mHXA,
linux-fsdevel-u79uwXL29TY76Z2rM5mHXA,
linux-mm-Bw31MaZKKs3YtjvyW6yDsg
In-Reply-To: <2929.1521106970-S6HVgzuS8uM4Awkfq6JHfwNdhmdF6hFW@public.gmane.org>
On 03/15/2018 10:42 AM, David Howells wrote:
> Do we have anything left that still implements NOMMU?
>
RISC-V ?
(evil grin :-)
Cheers,
Hannes
--
Dr. Hannes Reinecke Teamlead Storage & Networking
hare-l3A5Bk7waGM@public.gmane.org +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
^ permalink raw reply
* Re: [PATCH 00/16] remove eight obsolete architectures
From: Arnd Bergmann @ 2018-03-15 9:56 UTC (permalink / raw)
To: David Howells
Cc: linux-arch, linux-pwm, linux-fbdev, linux-watchdog,
open list:DOCUMENTATION, Networking, linux-usb, linux-wireless,
Linux Kernel Mailing List, dri-devel, linux-spi, linux-block,
IDE-ML, open list:HID CORE LAYER, Linux FS-devel Mailing List,
Linux-MM, linux-rtc
In-Reply-To: <2929.1521106970@warthog.procyon.org.uk>
On Thu, Mar 15, 2018 at 10:42 AM, David Howells <dhowells@redhat.com> wrote:
> Do we have anything left that still implements NOMMU?
Yes, plenty. I was wondering the same thing, but it seems that the architectures
we remove are almost completely representative of what we support overall,
except that they are all not licensed to 3rd parties, unlike many of the ones we
keep.
I've made an overview of the remaining architectures for my own reference[1].
The remaining NOMMU architectures are:
- arch/arm has ARMv7-M (Cortex-M microcontroller), which is actually
gaining traction
- arch/sh has an open-source J2 core that was added not that long ago,
it seems to
be the only SH compatible core that anyone is working on.
- arch/microblaze supports both MMU/NOMMU modes (most use an MMU)
- arch/m68k supports several NOMMU targets, both the coldfire SoCs and the
classic processors
- c6x has no MMU
Arnd
[1] https://docs.google.com/spreadsheets/d/1QxMvW5jpVG2jb4RM9CQQl27-wVpNYOa-_3K2RVKifb0
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ 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