* [PATCH v3 net-next 3/8] tcp: use one bit in TCP_SKB_CB to mark ACK timestamps
From: Soheil Hassas Yeganeh @ 2016-04-03 3:08 UTC (permalink / raw)
To: davem, netdev
Cc: willemb, edumazet, ycheng, ncardwell, kafai,
Soheil Hassas Yeganeh
In-Reply-To: <1459652893-14207-1-git-send-email-soheil.kdev@gmail.com>
From: Soheil Hassas Yeganeh <soheil@google.com>
Currently, to avoid a cache line miss for accessing skb_shinfo,
tcp_ack_tstamp skips socket that do not have
SOF_TIMESTAMPING_TX_ACK bit set in sk_tsflags. This is
implemented based on an implicit assumption that the
SOF_TIMESTAMPING_TX_ACK is set via socket options for the
duration that ACK timestamps are needed.
To implement per-write timestamps, this check should be
removed and replaced with a per-packet alternative that
quickly skips packets missing ACK timestamps marks without
a cache-line miss.
To enable per-packet marking without a cache line miss, use
one bit in TCP_SKB_CB to mark a whether a SKB might need a
ack tx timestamp or not. Further checks in tcp_ack_tstamp are not
modified and work as before.
Signed-off-by: Soheil Hassas Yeganeh <soheil@google.com>
Acked-by: Willem de Bruijn <willemb@google.com>
Acked-by: Eric Dumazet <edumazet@google.com>
---
include/net/tcp.h | 3 ++-
net/ipv4/tcp.c | 2 ++
net/ipv4/tcp_input.c | 2 +-
3 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/include/net/tcp.h b/include/net/tcp.h
index b91370f..f3a80ec 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -754,7 +754,8 @@ struct tcp_skb_cb {
TCPCB_REPAIRED)
__u8 ip_dsfield; /* IPv4 tos or IPv6 dsfield */
- /* 1 byte hole */
+ __u8 txstamp_ack:1, /* Record TX timestamp for ack? */
+ unused:7;
__u32 ack_seq; /* Sequence number ACK'd */
union {
struct inet_skb_parm h4;
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index 08b8b96..ce3c9eb 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -432,10 +432,12 @@ static void tcp_tx_timestamp(struct sock *sk, struct sk_buff *skb)
{
if (sk->sk_tsflags) {
struct skb_shared_info *shinfo = skb_shinfo(skb);
+ struct tcp_skb_cb *tcb = TCP_SKB_CB(skb);
sock_tx_timestamp(sk, &shinfo->tx_flags);
if (shinfo->tx_flags & SKBTX_ANY_TSTAMP)
shinfo->tskey = TCP_SKB_CB(skb)->seq + skb->len - 1;
+ tcb->txstamp_ack = !!(shinfo->tx_flags & SKBTX_ACK_TSTAMP);
}
}
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index e6e65f7..2d5fee4 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -3093,7 +3093,7 @@ static void tcp_ack_tstamp(struct sock *sk, struct sk_buff *skb,
const struct skb_shared_info *shinfo;
/* Avoid cache line misses to get skb_shinfo() and shinfo->tx_flags */
- if (likely(!(sk->sk_tsflags & SOF_TIMESTAMPING_TX_ACK)))
+ if (likely(!TCP_SKB_CB(skb)->txstamp_ack))
return;
shinfo = skb_shinfo(skb);
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply related
* [PATCH v3 net-next 4/8] sock: accept SO_TIMESTAMPING flags in socket cmsg
From: Soheil Hassas Yeganeh @ 2016-04-03 3:08 UTC (permalink / raw)
To: davem, netdev
Cc: willemb, edumazet, ycheng, ncardwell, kafai,
Soheil Hassas Yeganeh
In-Reply-To: <1459652893-14207-1-git-send-email-soheil.kdev@gmail.com>
From: Soheil Hassas Yeganeh <soheil@google.com>
Accept SO_TIMESTAMPING in control messages of the SOL_SOCKET level
as a basis to accept timestamping requests per write.
This implementation only accepts TX recording flags (i.e.,
SOF_TIMESTAMPING_TX_HARDWARE, SOF_TIMESTAMPING_TX_SOFTWARE,
SOF_TIMESTAMPING_TX_SCHED, and SOF_TIMESTAMPING_TX_ACK) in
control messages. Users need to set reporting flags (e.g.,
SOF_TIMESTAMPING_OPT_ID) per socket via socket options.
This commit adds a tsflags field in sockcm_cookie which is
set in __sock_cmsg_send. It only override the SOF_TIMESTAMPING_TX_*
bits in sockcm_cookie.tsflags allowing the control message
to override the recording behavior per write, yet maintaining
the value of other flags.
This patch implements validating the control message and setting
tsflags in struct sockcm_cookie. Next commits in this series will
actually implement timestamping per write for different protocols.
Signed-off-by: Soheil Hassas Yeganeh <soheil@google.com>
Acked-by: Willem de Bruijn <willemb@google.com>
---
include/net/sock.h | 1 +
include/uapi/linux/net_tstamp.h | 10 ++++++++++
net/core/sock.c | 13 +++++++++++++
3 files changed, 24 insertions(+)
diff --git a/include/net/sock.h b/include/net/sock.h
index 03772d4..af012da 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -1418,6 +1418,7 @@ void sk_send_sigurg(struct sock *sk);
struct sockcm_cookie {
u32 mark;
+ u16 tsflags;
};
int __sock_cmsg_send(struct sock *sk, struct msghdr *msg, struct cmsghdr *cmsg,
diff --git a/include/uapi/linux/net_tstamp.h b/include/uapi/linux/net_tstamp.h
index 6d1abea..264e515 100644
--- a/include/uapi/linux/net_tstamp.h
+++ b/include/uapi/linux/net_tstamp.h
@@ -31,6 +31,16 @@ enum {
SOF_TIMESTAMPING_LAST
};
+/*
+ * SO_TIMESTAMPING flags are either for recording a packet timestamp or for
+ * reporting the timestamp to user space.
+ * Recording flags can be set both via socket options and control messages.
+ */
+#define SOF_TIMESTAMPING_TX_RECORD_MASK (SOF_TIMESTAMPING_TX_HARDWARE | \
+ SOF_TIMESTAMPING_TX_SOFTWARE | \
+ SOF_TIMESTAMPING_TX_SCHED | \
+ SOF_TIMESTAMPING_TX_ACK)
+
/**
* struct hwtstamp_config - %SIOCGHWTSTAMP and %SIOCSHWTSTAMP parameter
*
diff --git a/net/core/sock.c b/net/core/sock.c
index 0a64fe2..315f5e5 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -1870,6 +1870,8 @@ EXPORT_SYMBOL(sock_alloc_send_skb);
int __sock_cmsg_send(struct sock *sk, struct msghdr *msg, struct cmsghdr *cmsg,
struct sockcm_cookie *sockc)
{
+ u32 tsflags;
+
switch (cmsg->cmsg_type) {
case SO_MARK:
if (!ns_capable(sock_net(sk)->user_ns, CAP_NET_ADMIN))
@@ -1878,6 +1880,17 @@ int __sock_cmsg_send(struct sock *sk, struct msghdr *msg, struct cmsghdr *cmsg,
return -EINVAL;
sockc->mark = *(u32 *)CMSG_DATA(cmsg);
break;
+ case SO_TIMESTAMPING:
+ if (cmsg->cmsg_len != CMSG_LEN(sizeof(u32)))
+ return -EINVAL;
+
+ tsflags = *(u32 *)CMSG_DATA(cmsg);
+ if (tsflags & ~SOF_TIMESTAMPING_TX_RECORD_MASK)
+ return -EINVAL;
+
+ sockc->tsflags &= ~SOF_TIMESTAMPING_TX_RECORD_MASK;
+ sockc->tsflags |= tsflags;
+ break;
default:
return -EINVAL;
}
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply related
* [PATCH v3 net-next 2/8] tcp: accept SOF_TIMESTAMPING_OPT_ID for passive TFO
From: Soheil Hassas Yeganeh @ 2016-04-03 3:08 UTC (permalink / raw)
To: davem, netdev
Cc: willemb, edumazet, ycheng, ncardwell, kafai,
Soheil Hassas Yeganeh
In-Reply-To: <1459652893-14207-1-git-send-email-soheil.kdev@gmail.com>
From: Soheil Hassas Yeganeh <soheil@google.com>
SOF_TIMESTAMPING_OPT_ID is set to get data-independent IDs
to associate timestamps with send calls. For TCP connections,
tp->snd_una is used as the starting point to calculate
relative IDs.
This socket option will fail if set before the handshake on a
passive TCP fast open connection with data in SYN or SYN/ACK,
since setsockopt requires the connection to be in the
ESTABLISHED state.
To address these, instead of limiting the option to the
ESTABLISHED state, accept the SOF_TIMESTAMPING_OPT_ID option as
long as the connection is not in LISTEN or CLOSE states.
Signed-off-by: Soheil Hassas Yeganeh <soheil@google.com>
Acked-by: Willem de Bruijn <willemb@google.com>
Acked-by: Yuchung Cheng <ycheng@google.com>
Acked-by: Eric Dumazet <edumazet@google.com>
---
net/core/sock.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/core/sock.c b/net/core/sock.c
index 66976f8..0a64fe2 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -832,7 +832,8 @@ set_rcvbuf:
!(sk->sk_tsflags & SOF_TIMESTAMPING_OPT_ID)) {
if (sk->sk_protocol == IPPROTO_TCP &&
sk->sk_type == SOCK_STREAM) {
- if (sk->sk_state != TCP_ESTABLISHED) {
+ if ((1 << sk->sk_state) &
+ (TCPF_CLOSE | TCPF_LISTEN)) {
ret = -EINVAL;
break;
}
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply related
* [PATCH v3 net-next 1/8] sock: break up sock_cmsg_snd into __sock_cmsg_snd and loop
From: Soheil Hassas Yeganeh @ 2016-04-03 3:08 UTC (permalink / raw)
To: davem, netdev
Cc: willemb, edumazet, ycheng, ncardwell, kafai,
Soheil Hassas Yeganeh
In-Reply-To: <1459652893-14207-1-git-send-email-soheil.kdev@gmail.com>
From: Willem de Bruijn <willemb@google.com>
To process cmsg's of the SOL_SOCKET level in addition to
cmsgs of another level, protocols can call sock_cmsg_send().
This causes a double walk on the cmsghdr list, one for SOL_SOCKET
and one for the other level.
Extract the inner demultiplex logic from the loop that walks the list,
to allow having this called directly from a walker in the protocol
specific code.
Signed-off-by: Willem de Bruijn <willemb@google.com>
Signed-off-by: Soheil Hassas Yeganeh <soheil@google.com>
---
include/net/sock.h | 2 ++
net/core/sock.c | 33 ++++++++++++++++++++++-----------
2 files changed, 24 insertions(+), 11 deletions(-)
diff --git a/include/net/sock.h b/include/net/sock.h
index 255d3e0..03772d4 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -1420,6 +1420,8 @@ struct sockcm_cookie {
u32 mark;
};
+int __sock_cmsg_send(struct sock *sk, struct msghdr *msg, struct cmsghdr *cmsg,
+ struct sockcm_cookie *sockc);
int sock_cmsg_send(struct sock *sk, struct msghdr *msg,
struct sockcm_cookie *sockc);
diff --git a/net/core/sock.c b/net/core/sock.c
index b67b9ae..66976f8 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -1866,27 +1866,38 @@ struct sk_buff *sock_alloc_send_skb(struct sock *sk, unsigned long size,
}
EXPORT_SYMBOL(sock_alloc_send_skb);
+int __sock_cmsg_send(struct sock *sk, struct msghdr *msg, struct cmsghdr *cmsg,
+ struct sockcm_cookie *sockc)
+{
+ switch (cmsg->cmsg_type) {
+ case SO_MARK:
+ if (!ns_capable(sock_net(sk)->user_ns, CAP_NET_ADMIN))
+ return -EPERM;
+ if (cmsg->cmsg_len != CMSG_LEN(sizeof(u32)))
+ return -EINVAL;
+ sockc->mark = *(u32 *)CMSG_DATA(cmsg);
+ break;
+ default:
+ return -EINVAL;
+ }
+ return 0;
+}
+EXPORT_SYMBOL(__sock_cmsg_send);
+
int sock_cmsg_send(struct sock *sk, struct msghdr *msg,
struct sockcm_cookie *sockc)
{
struct cmsghdr *cmsg;
+ int ret;
for_each_cmsghdr(cmsg, msg) {
if (!CMSG_OK(msg, cmsg))
return -EINVAL;
if (cmsg->cmsg_level != SOL_SOCKET)
continue;
- switch (cmsg->cmsg_type) {
- case SO_MARK:
- if (!ns_capable(sock_net(sk)->user_ns, CAP_NET_ADMIN))
- return -EPERM;
- if (cmsg->cmsg_len != CMSG_LEN(sizeof(u32)))
- return -EINVAL;
- sockc->mark = *(u32 *)CMSG_DATA(cmsg);
- break;
- default:
- return -EINVAL;
- }
+ ret = __sock_cmsg_send(sk, msg, cmsg, sockc);
+ if (ret)
+ return ret;
}
return 0;
}
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply related
* [PATCH v3 net-next 0/8] add TX timestamping via cmsg
From: Soheil Hassas Yeganeh @ 2016-04-03 3:08 UTC (permalink / raw)
To: davem, netdev
Cc: willemb, edumazet, ycheng, ncardwell, kafai,
Soheil Hassas Yeganeh
From: Soheil Hassas Yeganeh <soheil@google.com>
This patch series aim at enabling TX timestamping via cmsg.
Currently, to occasionally sample TX timestamping on a socket,
applications need to call setsockopt twice: first for enabling
timestamps and then for disabling them. This is an unnecessary
overhead. With cmsg, in contrast, applications can sample TX
timestamps per sendmsg().
This patch series adds the code for processing SO_TIMESTAMPING
for cmsg's of the SOL_SOCKET level, and adds the glue code for
TCP, UDP, and RAW for both IPv4 and IPv6. This implementation
supports overriding timestamp generation flags (i.e.,
SOF_TIMESTAMPING_TX_*) but not timestamp reporting flags.
Applications must still enable timestamp reporting via
setsockopt to receive timestamps.
This series does not change existing timestamping behavior for
applications that are using socket options.
I will follow up with another patch to enable timestamping for
active TFO (client-side TCP Fast Open) and also setting packet
mark via cmsgs.
Thanks!
Changes in v2:
- Replace u32 with __u32 in the documentation.
Changes in v3:
- Fix the broken build for L2TP (due to changes
in IPv6).
Soheil Hassas Yeganeh (7):
tcp: accept SOF_TIMESTAMPING_OPT_ID for passive TFO
tcp: use one bit in TCP_SKB_CB to mark ACK timestamps
sock: accept SO_TIMESTAMPING flags in socket cmsg
ipv4: process socket-level control messages in IPv4
ipv6: process socket-level control messages in IPv6
sock: enable timestamping using control messages
sock: document timestamping via cmsg in Documentation
Willem de Bruijn (1):
sock: break up sock_cmsg_snd into __sock_cmsg_snd and loop
Documentation/networking/timestamping.txt | 48 ++++++++++++++++++++++++++++--
drivers/net/tun.c | 3 +-
include/net/ip.h | 3 +-
include/net/ipv6.h | 6 ++--
include/net/sock.h | 13 +++++---
include/net/tcp.h | 3 +-
include/net/transp_v6.h | 3 +-
include/uapi/linux/net_tstamp.h | 10 +++++++
net/can/raw.c | 2 +-
net/core/sock.c | 49 +++++++++++++++++++++++--------
net/ipv4/ip_sockglue.c | 9 +++++-
net/ipv4/ping.c | 7 +++--
net/ipv4/raw.c | 13 ++++----
net/ipv4/tcp.c | 22 ++++++++++----
net/ipv4/tcp_input.c | 2 +-
net/ipv4/udp.c | 10 +++----
net/ipv6/datagram.c | 9 +++++-
net/ipv6/icmp.c | 6 ++--
net/ipv6/ip6_flowlabel.c | 3 +-
net/ipv6/ip6_output.c | 15 ++++++----
net/ipv6/ipv6_sockglue.c | 3 +-
net/ipv6/ping.c | 3 +-
net/ipv6/raw.c | 7 +++--
net/ipv6/udp.c | 10 +++++--
net/l2tp/l2tp_ip6.c | 10 ++++---
net/packet/af_packet.c | 30 +++++++++++++++----
net/socket.c | 10 +++----
27 files changed, 231 insertions(+), 78 deletions(-)
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply
* Re: [RFC PATCH net 3/4] ipv6: datagram: Update dst cache of a connected datagram sk during pmtu update
From: Martin KaFai Lau @ 2016-04-03 2:33 UTC (permalink / raw)
To: Cong Wang; +Cc: netdev, Eric Dumazet, Wei Wang, Kernel Team
In-Reply-To: <CAM_iQpVeOKtTJ=oc9z6=SEaHDBTfpaPLKa-43TH1b_A3+TdWwA@mail.gmail.com>
On Fri, Apr 01, 2016 at 04:13:41PM -0700, Cong Wang wrote:
> On Fri, Apr 1, 2016 at 3:56 PM, Martin KaFai Lau <kafai@fb.com> wrote:
> > + bh_lock_sock(sk);
> > + if (!sock_owned_by_user(sk))
> > + ip6_datagram_dst_update(sk, false);
> > + bh_unlock_sock(sk);
>
>
> My discussion with Eric shows that we probably don't need to hold
> this sock lock here, and you are Cc'ed in that thread, so
>
> 1) why do you still take the lock here?
> 2) why didn't you involve in our discussion if you disagree?
It is because I agree with the last thread discussion that updating
sk->sk_dst_cache does not need a sk lock. I also don't see
a lock is need for other operations in that thread.
I am thinking another case that needs a lock, so I start
another RFC thread. A quick recall for this commit message:
>> It is done under '!sock_owned_by_user(sk)' condition because
>> the user may make another ip6_datagram_connect() while
>> dst lookup and update are happening.
If that could not happen, then the lock is not needed.
One thing to note is that this patch uses the addresses from the sk
instead of iph when updating sk->sk_dst_cache. It is basically the
same logic that the __ip6_datagram_connect() is doing, so some
refactoring works in the first two patches.
AFAIK, a UDP socket can become connected after sending out some
datagrams in un-connected state. or It can be connected
multiple times to different destinations. I did some quick
tests but I could be wrong.
I am thinking if there could be a chance that the skb->data, which
has the original outgoing iph, is not related to the current
connected address. If it is possible, we have to specifically
use the addresses in the sk instead of skb->data (i.e. iph) when
updating the sk->sk_dst_cache.
If we need to use the sk addresses (and other info) to find out a
new dst for a connected udp socket, it is better not doing it while
the userland is connecting to somewhere else.
If the above case is impossible, we can keep using the info from iph to
do the dst update for a connected-udp sk without taking the lock.
>> diff --git a/net/ipv6/route.c b/net/ipv6/route.c
>> index ed44663..f7e6a6d 100644
>> --- a/net/ipv6/route.c
>> +++ b/net/ipv6/route.c
>> @@ -1417,8 +1417,19 @@ EXPORT_SYMBOL_GPL(ip6_update_pmtu);
>>
>> void ip6_sk_update_pmtu(struct sk_buff *skb, struct sock *sk, __be32 mtu)
>> {
>> + struct dst_entry *dst;
>> +
>> ip6_update_pmtu(skb, sock_net(sk), mtu,
>> sk->sk_bound_dev_if, sk->sk_mark);
iph's addresses are used to update the pmtu. It is fine
because it does not update the sk->sk_dst_cache.
>>> +
>> + dst = __sk_dst_get(sk);
>> + if (!dst || dst->ops->check(dst, inet6_sk(sk)->dst_cookie))
>> + return;
>> +
>> + bh_lock_sock(sk);
>> + if (!sock_owned_by_user(sk))
sk is not connecting to another address. Find a new dst
for the connected address.
>> + ip6_datagram_dst_update(sk, false);
>> + bh_unlock_sock(sk);
>> }
^ permalink raw reply
* Re: [RFC PATCH 0/5] Add driver bpf hook for early packet drop
From: Lorenzo Colitti @ 2016-04-03 2:28 UTC (permalink / raw)
To: Tom Herbert
Cc: Johannes Berg, Brenden Blanco, David S. Miller,
Linux Kernel Network Developers, Alexei Starovoitov, gerlitz,
Daniel Borkmann, john fastabend, Jesper Dangaard Brouer
In-Reply-To: <CALx6S35kK9eNk8r-fZmP-mOSB=Tb8udbaQeSUjmHWJagh+=i=A@mail.gmail.com>
On Sun, Apr 3, 2016 at 7:57 AM, Tom Herbert <tom@herbertland.com> wrote:
> I am curious though, how do you think this would specifically help
> Android with power? Seems like the receiver still needs to be powered
> to receive packets to filter them anyway...
The receiver is powered up, but its wake/sleep cycles are much shorter
than the main CPU's. On a phone, leaving the CPU asleep with wifi on
might consume ~5mA average, but getting the CPU out of suspend might
average ~200mA for ~300ms as the system comes out of sleep,
initializes other hardware, wakes up userspace processes whose
timeouts have fired, freezes, and suspends again. Receiving one such
superfluous packet every 3 seconds (e.g., on networks that send
identical IPv6 RAs once every 3 seconds) works out to ~25mA, which is
5x the cost of idle. Pushing down filters to the hardware so it can
drop the packet without waking up the CPU thus saves a lot of idle
power.
That said, getting BPF to the driver is part of the picture. On the
chipsets we're targeting for APF, we're only seeing 2k-4k of memory
(that's 256-512 BPF instructions) available for filtering code, which
means that BPF might be too large.
^ permalink raw reply
* Re: [PATCH v2 net-next 0/8] add TX timestamping via cmsg
From: Soheil Hassas Yeganeh @ 2016-04-03 1:36 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20160402.212729.2129485115379390591.davem@davemloft.net>
On Sat, Apr 2, 2016 at 9:27 PM, David Miller <davem@davemloft.net> wrote:
> From: David Miller <davem@davemloft.net>
> Date: Sat, 02 Apr 2016 21:19:42 -0400 (EDT)
>
>> Series applied, thanks.
>
> I had to revert, this breaks the build:
>
> net/l2tp/l2tp_ip6.c: In function ‘l2tp_ip6_sendmsg’:
> net/l2tp/l2tp_ip6.c:565:9: error: too few arguments to function ‘ip6_datagram_send_ctl’
> err = ip6_datagram_send_ctl(sock_net(sk), sk, msg, &fl6, opt,
> ^
> In file included from net/l2tp/l2tp_ip6.c:33:0:
> include/net/transp_v6.h:43:5: note: declared here
> int ip6_datagram_send_ctl(struct net *net, struct sock *sk, struct msghdr *msg,
> ^
> net/l2tp/l2tp_ip6.c:625:8: error: too few arguments to function ‘ip6_append_data’
> err = ip6_append_data(sk, ip_generic_getfrag, msg,
> ^
> In file included from include/net/inetpeer.h:15:0,
> from include/net/route.h:28,
> from include/net/ip.h:31,
> from net/l2tp/l2tp_ip6.c:23:
> include/net/ipv6.h:865:5: note: declared here
> int ip6_append_data(struct sock *sk,
> ^
I'm really sorry about this. CONFIG_L2TP was no enabled in my config.
I'll fix the patch, and will mail v3.
Thanks,
Soheil
^ permalink raw reply
* Re: [PATCH v2 net-next 0/8] add TX timestamping via cmsg
From: David Miller @ 2016-04-03 1:27 UTC (permalink / raw)
To: soheil.kdev; +Cc: netdev, willemb, edumazet, ycheng, ncardwell, kafai, soheil
In-Reply-To: <20160402.211942.598210499165268433.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Sat, 02 Apr 2016 21:19:42 -0400 (EDT)
> Series applied, thanks.
I had to revert, this breaks the build:
net/l2tp/l2tp_ip6.c: In function ‘l2tp_ip6_sendmsg’:
net/l2tp/l2tp_ip6.c:565:9: error: too few arguments to function ‘ip6_datagram_send_ctl’
err = ip6_datagram_send_ctl(sock_net(sk), sk, msg, &fl6, opt,
^
In file included from net/l2tp/l2tp_ip6.c:33:0:
include/net/transp_v6.h:43:5: note: declared here
int ip6_datagram_send_ctl(struct net *net, struct sock *sk, struct msghdr *msg,
^
net/l2tp/l2tp_ip6.c:625:8: error: too few arguments to function ‘ip6_append_data’
err = ip6_append_data(sk, ip_generic_getfrag, msg,
^
In file included from include/net/inetpeer.h:15:0,
from include/net/route.h:28,
from include/net/ip.h:31,
from net/l2tp/l2tp_ip6.c:23:
include/net/ipv6.h:865:5: note: declared here
int ip6_append_data(struct sock *sk,
^
^ permalink raw reply
* Re: [PATCH v2 net-next 0/8] add TX timestamping via cmsg
From: David Miller @ 2016-04-03 1:19 UTC (permalink / raw)
To: soheil.kdev; +Cc: netdev, willemb, edumazet, ycheng, ncardwell, kafai, soheil
In-Reply-To: <1459523080-29329-1-git-send-email-soheil.kdev@gmail.com>
From: Soheil Hassas Yeganeh <soheil.kdev@gmail.com>
Date: Fri, 1 Apr 2016 11:04:32 -0400
> From: Soheil Hassas Yeganeh <soheil@google.com>
>
> This patch series aim at enabling TX timestamping via cmsg.
>
> Currently, to occasionally sample TX timestamping on a socket,
> applications need to call setsockopt twice: first for enabling
> timestamps and then for disabling them. This is an unnecessary
> overhead. With cmsg, in contrast, applications can sample TX
> timestamps per sendmsg().
>
> This patch series adds the code for processing SO_TIMESTAMPING
> for cmsg's of the SOL_SOCKET level, and adds the glue code for
> TCP, UDP, and RAW for both IPv4 and IPv6. This implementation
> supports overriding timestamp generation flags (i.e.,
> SOF_TIMESTAMPING_TX_*) but not timestamp reporting flags.
> Applications must still enable timestamp reporting via
> setsockopt to receive timestamps.
>
> This series does not change existing timestamping behavior for
> applications that are using socket options.
>
> I will follow up with another patch to enable timestamping for
> active TFO (client-side TCP Fast Open) and also setting packet
> mark via cmsgs.
...
> Changes in v2:
> - Replace u32 with __u32 in the documentation.
Series applied, thanks.
^ permalink raw reply
* Homeland Security
From: Jeh Charles Johnsonr @ 2016-04-03 0:37 UTC (permalink / raw)
To: DHS
Tel:+14073924312 text messages only
I am Mr. Jeh Charles Johnson. The secretary of the US Department of Homeland Security Washington DC, an international summit was held in West Africa and i was opporturned to be one of the officials, after the meeting I found out that a huge sum of 4.5 million dollars which is in your name was abandoned here in West Africa probably due to malpractices.
I would like you to kindly reconfirm your full address, Full name, Phone number, and nearest Airport so that I shall bring your parcel to our Head Office in Washington DC and you will come and claim or we can send it to your designated address I wait for your urgent and positive respond. You can reach me on this email as well: mr.jehjohnson12@gmail.com. I will be looking forward to your positive response. Thank you and God bless you.`
Best regards
Jeh Charles Johnson
mr.jehjohnson12@gmail.com.
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
^ permalink raw reply
* Homeland Security
From: Jeh Charles Johnsonr @ 2016-04-03 0:30 UTC (permalink / raw)
To: DHS
Tel:+14073924312 text messages only
I am Mr. Jeh Charles Johnson. The secretary of the US Department of Homeland Security Washington DC, an international summit was held in West Africa and i was opporturned to be one of the officials, after the meeting I found out that a huge sum of 4.5 million dollars which is in your name was abandoned here in West Africa probably due to malpractices.
I would like you to kindly reconfirm your full address, Full name, Phone number, and nearest Airport so that I shall bring your parcel to our Head Office in Washington DC and you will come and claim or we can send it to your designated address I wait for your urgent and positive respond. You can reach me on this email as well: mr.jehjohnson12@gmail.com. I will be looking forward to your positive response. Thank you and God bless you.`
Best regards
Jeh Charles Johnson
mr.jehjohnson12@gmail.com.
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
^ permalink raw reply
* Re: [RESEND PATCH net-next 00/13] Enhance stmmac driver to support GMAC4.x IP
From: David Miller @ 2016-04-03 0:23 UTC (permalink / raw)
To: alexandre.torgue; +Cc: netdev, peppe.cavallaro, lars.persson
In-Reply-To: <1459503457-22569-1-git-send-email-alexandre.torgue@st.com>
From: Alexandre TORGUE <alexandre.torgue@st.com>
Date: Fri, 1 Apr 2016 11:37:24 +0200
> This is a subset of patch to enhance current stmmac driver to support
> new GMAC4.x chips. New set of callbacks is defined to support this new
> family: descriptors, dma, core.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH v2 net-next] net: hns: add support of pause frame ctrl for HNS V2
From: David Miller @ 2016-04-03 0:17 UTC (permalink / raw)
To: Yisen.Zhuang
Cc: salil.mehta, liguozhu, huangdaode, arnd, andriy.shevchenko,
andrew, geliangtang, ivecera, lisheng011, fengguang.wu,
charles.chenxin, haifeng.wei, netdev, linux-kernel,
linux-arm-kernel, linuxarm
In-Reply-To: <1459429209-230671-1-git-send-email-Yisen.Zhuang@huawei.com>
From: Yisen Zhuang <Yisen.Zhuang@huawei.com>
Date: Thu, 31 Mar 2016 21:00:09 +0800
> From: Lisheng <lisheng011@huawei.com>
>
> The patch adds support of pause ctrl for HNS V2, and this feature is lost
> by HNS V1:
> 1) service ports can disable rx pause frame,
> 2) debug ports can open tx/rx pause frame.
>
> And this patch updates the REGs about the pause ctrl when updated
> status function called by upper layer routine.
>
> Signed-off-by: Lisheng <lisheng011@huawei.com>
> Signed-off-by: Yisen Zhuang <Yisen.Zhuang@huawei.com>
> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Applied.
^ permalink raw reply
* Re: [PATCH] netlink: use nla_get_in_addr and nla_put_in_addr for ipv4 address
From: David Miller @ 2016-04-03 0:16 UTC (permalink / raw)
To: yanhaishuang; +Cc: kuznet, jmorris, yoshfuji, kaber, netdev, linux-kernel
In-Reply-To: <1459419698-4466-1-git-send-email-yanhaishuang@cmss.chinamobile.com>
From: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>
Date: Thu, 31 Mar 2016 18:21:38 +0800
> Since nla_get_in_addr and nla_put_in_addr were implemented,
> so use them appropriately.
>
> Signed-off-by: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH v2 net-next] tcp: remove cwnd moderation after recovery
From: David Miller @ 2016-04-03 0:14 UTC (permalink / raw)
To: ycheng; +Cc: netdev, mattmathis, ncardwell, soheil
In-Reply-To: <1459374860-32643-1-git-send-email-ycheng@google.com>
From: Yuchung Cheng <ycheng@google.com>
Date: Wed, 30 Mar 2016 14:54:20 -0700
> For non-SACK connections, cwnd is lowered to inflight plus 3 packets
> when the recovery ends. This is an optional feature in the NewReno
> RFC 2582 to reduce the potential burst when cwnd is "re-opened"
> after recovery and inflight is low.
>
> This feature is questionably effective because of PRR: when
> the recovery ends (i.e., snd_una == high_seq) NewReno holds the
> CA_Recovery state for another round trip to prevent false fast
> retransmits. But if the inflight is low, PRR will overwrite the
> moderated cwnd in tcp_cwnd_reduction() later regardlessly. So if a
> receiver responds bogus ACKs (i.e., acking future data) to speed up
> transfer after recovery, it can only induce a burst up to a window
> worth of data packets by acking up to SND.NXT. A restart from (short)
> idle or receiving streched ACKs can both cause such bursts as well.
>
> On the other hand, if the recovery ends because the sender
> detects the losses were spurious (e.g., reordering). This feature
> unconditionally lowers a reverted cwnd even though nothing
> was lost.
>
> By principle loss recovery module should not update cwnd. Further
> pacing is much more effective to reduce burst. Hence this patch
> removes the cwnd moderation feature.
>
> v2 changes: revised commit message on bogus ACKs and burst, and
> missing signature
>
> Signed-off-by: Matt Mathis <mattmathis@google.com>
> Signed-off-by: Neal Cardwell <ncardwell@google.com>
> Signed-off-by: Soheil Hassas Yeganeh <soheil@google.com>
> Signed-off-by: Yuchung Cheng <ycheng@google.com>
Applied, thanks.
^ permalink raw reply
* Re: [RFC PATCH 0/5] Add driver bpf hook for early packet drop
From: Tom Herbert @ 2016-04-02 22:57 UTC (permalink / raw)
To: Johannes Berg
Cc: Brenden Blanco, David S. Miller, Linux Kernel Network Developers,
Alexei Starovoitov, gerlitz, Daniel Borkmann, john fastabend,
Jesper Dangaard Brouer, Lorenzo Colitti
In-Reply-To: <1459622491.18188.6.camel@sipsolutions.net>
On Sat, Apr 2, 2016 at 2:41 PM, Johannes Berg <johannes@sipsolutions.net> wrote:
> On Fri, 2016-04-01 at 18:21 -0700, Brenden Blanco wrote:
>> This patch set introduces new infrastructure for programmatically
>> processing packets in the earliest stages of rx, as part of an effort
>> others are calling Express Data Path (XDP) [1]. Start this effort by
>> introducing a new bpf program type for early packet filtering, before
>> even
>> an skb has been allocated.
>>
>> With this, hope to enable line rate filtering, with this initial
>> implementation providing drop/allow action only.
>
> Since this is handed to the driver in some way, I assume the API would
> also allow offloading the program to the NIC itself, and as such be
> useful for what Android wants to do to save power in wireless?
>
Conceptually, yes. There is some ongoing work to offload BPF and one
goal is that BPF programs (like for XDP) could be portable between
userspace, kernel (maybe even other OSes), and devices.
I am curious though, how do you think this would specifically help
Android with power? Seems like the receiver still needs to be powered
to receive packets to filter them anyway...
Thanks,
Tom
> johannes
^ permalink raw reply
* Re: bridge/brctl/ip
From: Nikolay Aleksandrov @ 2016-04-02 22:50 UTC (permalink / raw)
To: Bert Vermeulen, netdev, Stephen Hemminger
In-Reply-To: <57001CFF.20508@biot.com>
On 04/02/2016 09:26 PM, Bert Vermeulen wrote:
> Hi all,
>
> I'm wondering about the current userspace toolset to control bridging in
> the Linux kernel. As far as I can determine, functionality is a bit
> scattered right now between the iproute2 (ip, bridge) and bridge-utils
> (brctl) tools:
>
> - creating/deleting bridges: ip or brctl
> - adding/deleting ports to/from bridge: brctl only
ip link set dev ethX master bridgeY
ip link set dev ethX nomaster
> - showing bridge fdb: brctl (in-kernel fdb), bridge (hardware offloaded
> fdb) (!)
bridge fdb show - shows all fdb entries, offloaded or not.
> ...and no doubt a few other things.
>
> Also the brctl tool seems not to be getting updates, whereas the
> iproute2 tools are of course updated regularly. Is brctl considered
> obsolete?
iproute2 supports (almost, user-space stp?) everything now, there have been many recent
additions to the options that can be manipulated.
$ ip link set dev bridge0 type bridge help
Usage: ... bridge [ forward_delay FORWARD_DELAY ]
[ hello_time HELLO_TIME ]
[ max_age MAX_AGE ]
[ ageing_time AGEING_TIME ]
[ stp_state STP_STATE ]
[ priority PRIORITY ]
[ group_fwd_mask MASK ]
[ group_address ADDRESS ]
[ vlan_filtering VLAN_FILTERING ]
[ vlan_protocol VLAN_PROTOCOL ]
[ vlan_default_pvid VLAN_DEFAULT_PVID ]
[ mcast_snooping MULTICAST_SNOOPING ]
[ mcast_router MULTICAST_ROUTER ]
[ mcast_query_use_ifaddr MCAST_QUERY_USE_IFADDR ]
[ mcast_querier MULTICAST_QUERIER ]
[ mcast_hash_elasticity HASH_ELASTICITY ]
[ mcast_hash_max HASH_MAX ]
[ mcast_last_member_count LAST_MEMBER_COUNT ]
[ mcast_startup_query_count STARTUP_QUERY_COUNT ]
[ mcast_last_member_interval LAST_MEMBER_INTERVAL ]
[ mcast_membership_interval MEMBERSHIP_INTERVAL ]
[ mcast_querier_interval QUERIER_INTERVAL ]
[ mcast_query_interval QUERY_INTERVAL ]
[ mcast_query_response_interval QUERY_RESPONSE_INTERVAL ]
[ mcast_startup_query_interval STARTUP_QUERY_INTERVAL ]
[ nf_call_iptables NF_CALL_IPTABLES ]
[ nf_call_ip6tables NF_CALL_IP6TABLES ]
[ nf_call_arptables NF_CALL_ARPTABLES ]
Where: VLAN_PROTOCOL := { 802.1Q | 802.1ad }
>
> If that is the case, would patches to add the missing functionality into
> the bridge tool be welcome? I'm thinking primarily of creating/deleting
> bridges, and adding/deleting ports in bridges.
>
>
^ permalink raw reply
* Re: bridge/brctl/ip
From: Andrew Lunn @ 2016-04-02 22:39 UTC (permalink / raw)
To: Bert Vermeulen; +Cc: netdev, Stephen Hemminger
In-Reply-To: <57001CFF.20508@biot.com>
On Sat, Apr 02, 2016 at 09:26:55PM +0200, Bert Vermeulen wrote:
> Hi all,
>
> I'm wondering about the current userspace toolset to control bridging in
> the Linux kernel. As far as I can determine, functionality is a bit
> scattered right now between the iproute2 (ip, bridge) and bridge-utils
> (brctl) tools:
>
> - adding/deleting ports to/from bridge: brctl only
ip link set lan0 master br0
I think most of the normal operations can be done with iproute2. What
might be missing is things like setting the forwarding delay, hello
time, etc.
Andrew
^ permalink raw reply
* Re: net: memory leak due to CLONE_NEWNET
From: Cong Wang @ 2016-04-02 22:31 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: David S. Miller, Nicolas Dichtel, Thomas Graf, netdev, LKML,
Eric Dumazet, syzkaller, Kostya Serebryany, Alexander Potapenko,
Sasha Levin
In-Reply-To: <CACT4Y+bNxEoM9iEydzsKqO50Pfe3JLJszS=Kyiom47vE=J7cvQ@mail.gmail.com>
On Sat, Apr 2, 2016 at 6:55 AM, Dmitry Vyukov <dvyukov@google.com> wrote:
> Hello,
>
> The following program leads to memory leaks in:
>
> unreferenced object 0xffff88005c10d208 (size 96):
> comm "a.out", pid 10753, jiffies 4296778619 (age 43.118s)
> hex dump (first 32 bytes):
> e8 31 85 2d 00 88 ff ff 0f 00 00 00 00 00 00 00 .1.-............
> 00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .....N..........
> backtrace:
> [<ffffffff8679bb23>] kmemleak_alloc+0x63/0xa0 mm/kmemleak.c:915
> [< inline >] kmemleak_alloc_recursive include/linux/kmemleak.h:47
> [< inline >] slab_post_alloc_hook mm/slab.h:406
> [< inline >] slab_alloc_node mm/slub.c:2602
> [< inline >] slab_alloc mm/slub.c:2610
> [<ffffffff8179b4c0>] kmem_cache_alloc_trace+0x160/0x3d0 mm/slub.c:2627
> [< inline >] kmalloc include/linux/slab.h:478
> [< inline >] tc_action_net_init include/net/act_api.h:122
> [<ffffffff8574e62e>] csum_init_net+0x15e/0x450 net/sched/act_csum.c:593
> [<ffffffff8564ffc9>] ops_init+0xa9/0x3a0 net/core/net_namespace.c:109
> [<ffffffff85650474>] setup_net+0x1b4/0x3e0 net/core/net_namespace.c:287
> [<ffffffff85651a56>] copy_net_ns+0xd6/0x1a0 net/core/net_namespace.c:367
> [<ffffffff813d01bf>] create_new_namespaces+0x37f/0x740 kernel/nsproxy.c:106
> [<ffffffff813d0b69>] unshare_nsproxy_namespaces+0xa9/0x1d0
The following patch should fix it.
diff --git a/include/net/act_api.h b/include/net/act_api.h
index 2a19fe1..03e322b 100644
--- a/include/net/act_api.h
+++ b/include/net/act_api.h
@@ -135,6 +135,7 @@ void tcf_hashinfo_destroy(const struct tc_action_ops *ops,
static inline void tc_action_net_exit(struct tc_action_net *tn)
{
tcf_hashinfo_destroy(tn->ops, tn->hinfo);
+ kfree(tn->hinfo);
}
int tcf_generic_walker(struct tc_action_net *tn, struct sk_buff *skb,
^ permalink raw reply related
* Re: [net PATCH 2/2] ipv4/GRO: Make GRO conform to RFC 6864
From: Rick Jones @ 2016-04-02 20:26 UTC (permalink / raw)
To: Eric Dumazet, David Miller
Cc: alexander.duyck, aduyck, herbert, tom, jesse, edumazet, netdev
In-Reply-To: <1459563709.6473.305.camel@edumazet-glaptop3.roam.corp.google.com>
On 04/01/2016 07:21 PM, Eric Dumazet wrote:
> On Fri, 2016-04-01 at 22:16 -0400, David Miller wrote:
>> From: Alexander Duyck <alexander.duyck@gmail.com>
>> Date: Fri, 1 Apr 2016 12:58:41 -0700
>>
>>> RFC 6864 is pretty explicit about this, IPv4 ID used only for
>>> fragmentation. https://tools.ietf.org/html/rfc6864#section-4.1
>>>
>>> The goal with this change is to try and keep most of the existing
>>> behavior in tact without violating this rule? I would think the
>>> sequence number should give you the ability to infer a drop in the
>>> case of TCP. In the case of UDP tunnels we are now getting a bit more
>>> data since we were ignoring the outer IP header ID before.
>>
>> When retransmits happen, the sequence numbers are the same. But you
>> can then use the IP ID to see exactly what happened. You can even
>> tell if multiple retransmits got reordered.
>>
>> Eric's use case is extremely useful, and flat out eliminates ambiguity
>> when analyzing TCP traces.
>
> Yes, our team (including Van Jacobson ;) ) would be sad to not have
> sequential IP ID (but then we don't have them for IPv6 ;) )
Your team would not be the only one sad to see that go away.
rick jones
> Since the cost of generating them is pretty small (inet->inet_id
> counter), we probably should keep them in linux. Their usage will phase
> out as IPv6 wins the Internet war...
>
>
^ permalink raw reply
* bridge/brctl/ip
From: Bert Vermeulen @ 2016-04-02 19:26 UTC (permalink / raw)
To: netdev, Stephen Hemminger
Hi all,
I'm wondering about the current userspace toolset to control bridging in
the Linux kernel. As far as I can determine, functionality is a bit
scattered right now between the iproute2 (ip, bridge) and bridge-utils
(brctl) tools:
- creating/deleting bridges: ip or brctl
- adding/deleting ports to/from bridge: brctl only
- showing bridge fdb: brctl (in-kernel fdb), bridge (hardware offloaded
fdb) (!)
...and no doubt a few other things.
Also the brctl tool seems not to be getting updates, whereas the
iproute2 tools are of course updated regularly. Is brctl considered
obsolete?
If that is the case, would patches to add the missing functionality into
the bridge tool be welcome? I'm thinking primarily of creating/deleting
bridges, and adding/deleting ports in bridges.
--
Bert Vermeulen
bert@biot.com
^ permalink raw reply
* [PATCH v3 -next] net/core/dev: Warn on a too-short GRO frame
From: Aaron Conole @ 2016-04-02 19:26 UTC (permalink / raw)
To: netdev, Joe Perches, Eric Dumazet
From: Aaron Conole <aconole@bytheb.org>
When signaling that a GRO frame is ready to be processed, the network stack
correctly checks length and aborts processing when a frame is less than 14
bytes. However, such a condition is really indicative of a broken driver,
and should be loudly signaled, rather than silently dropped as the case is
today.
Convert the condition to use net_warn_ratelimited() to ensure the stack
loudly complains about such broken drivers.
Signed-off-by: Aaron Conole <aconole@bytheb.org>
---
v2:
* Switched from WARN_ON to net_warn_ratelimited
v3:
* Amend the string to include device name as a hint
net/core/dev.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/core/dev.c b/net/core/dev.c
index b9bcbe7..273f10d 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -4663,6 +4663,8 @@ static struct sk_buff *napi_frags_skb(struct napi_struct *napi)
if (unlikely(skb_gro_header_hard(skb, hlen))) {
eth = skb_gro_header_slow(skb, hlen, 0);
if (unlikely(!eth)) {
+ net_warn_ratelimited("%s: dropping impossible skb from %s\n",
+ __func__, napi->dev->name);
napi_reuse_skb(napi, skb);
return NULL;
}
--
2.5.5
^ permalink raw reply related
* Re: [RFC PATCH 0/5] Add driver bpf hook for early packet drop
From: Johannes Berg @ 2016-04-02 18:41 UTC (permalink / raw)
To: Brenden Blanco, davem
Cc: netdev, tom, alexei.starovoitov, gerlitz, daniel, john.fastabend,
brouer, Lorenzo Colitti
In-Reply-To: <1459560118-5582-1-git-send-email-bblanco@plumgrid.com>
On Fri, 2016-04-01 at 18:21 -0700, Brenden Blanco wrote:
> This patch set introduces new infrastructure for programmatically
> processing packets in the earliest stages of rx, as part of an effort
> others are calling Express Data Path (XDP) [1]. Start this effort by
> introducing a new bpf program type for early packet filtering, before
> even
> an skb has been allocated.
>
> With this, hope to enable line rate filtering, with this initial
> implementation providing drop/allow action only.
Since this is handed to the driver in some way, I assume the API would
also allow offloading the program to the NIC itself, and as such be
useful for what Android wants to do to save power in wireless?
johannes
^ permalink raw reply
* Re: [RFC PATCH 4/5] mlx4: add support for fast rx drop bpf program
From: Johannes Berg @ 2016-04-02 18:40 UTC (permalink / raw)
To: Brenden Blanco, davem
Cc: netdev, tom, alexei.starovoitov, gerlitz, daniel, john.fastabend,
brouer
In-Reply-To: <1459560118-5582-5-git-send-email-bblanco@plumgrid.com>
On Fri, 2016-04-01 at 18:21 -0700, Brenden Blanco wrote:
> +static int mlx4_bpf_set(struct net_device *dev, int fd)
> +{
[...]
> + if (prog->type != BPF_PROG_TYPE_PHYS_DEV) {
> + bpf_prog_put(prog);
> + return -EINVAL;
> + }
> + }
Why wouldn't this check be done in the generic code that calls
ndo_bpf_set()?
johannes
^ 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