* Re: [PATCH V2 5/7] sctp: use limited socket backlog
From: Vlad Yasevich @ 2010-03-03 14:10 UTC (permalink / raw)
To: Zhu Yi; +Cc: netdev, Sridhar Samudrala
In-Reply-To: <1267605389-7369-5-git-send-email-yi.zhu@intel.com>
Zhu Yi wrote:
> Make sctp adapt to the limited socket backlog change.
>
> Cc: Vlad Yasevich <vladislav.yasevich@hp.com>
> Cc: Sridhar Samudrala <sri@us.ibm.com>
> Signed-off-by: Zhu Yi <yi.zhu@intel.com>
> ---
> net/sctp/input.c | 12 ++++++++----
> 1 files changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/net/sctp/input.c b/net/sctp/input.c
> index c0c973e..20e69c3 100644
> --- a/net/sctp/input.c
> +++ b/net/sctp/input.c
> @@ -75,7 +75,7 @@ static struct sctp_association *__sctp_lookup_association(
> const union sctp_addr *peer,
> struct sctp_transport **pt);
>
> -static void sctp_add_backlog(struct sock *sk, struct sk_buff *skb);
> +static int sctp_add_backlog(struct sock *sk, struct sk_buff *skb);
>
>
> /* Calculate the SCTP checksum of an SCTP packet. */
> @@ -265,8 +265,12 @@ int sctp_rcv(struct sk_buff *skb)
> }
>
> if (sock_owned_by_user(sk)) {
> + if (sctp_add_backlog(sk, skb)) {
> + sctp_bh_unlock_sock(sk);
> + sctp_chunk_free(chunk);
> + goto discard_release;
> + }
I think this will result in a double-free of the skb, because sctp_chunk_free
attempts to free the skb that's been assigned to the chunk. You can set the skb
to NULL to get around that.
> SCTP_INC_STATS_BH(SCTP_MIB_IN_PKT_BACKLOG);
> - sctp_add_backlog(sk, skb);
> } else {
> SCTP_INC_STATS_BH(SCTP_MIB_IN_PKT_SOFTIRQ);
> sctp_inq_push(&chunk->rcvr->inqueue, chunk);
> @@ -362,7 +366,7 @@ done:
> return 0;
> }
>
> -static void sctp_add_backlog(struct sock *sk, struct sk_buff *skb)
> +static int sctp_add_backlog(struct sock *sk, struct sk_buff *skb)
> {
> struct sctp_chunk *chunk = SCTP_INPUT_CB(skb)->chunk;
> struct sctp_ep_common *rcvr = chunk->rcvr;
> @@ -377,7 +381,7 @@ static void sctp_add_backlog(struct sock *sk, struct sk_buff *skb)
> else
> BUG();
>
> - sk_add_backlog(sk, skb);
> + return sk_add_backlog_limited(sk, skb);
> }
You also leak the ref counts here since now it's possible to not add a packet to
the backlog queue. That means you'll take refs, but never drop them because
the receive routing will never run.
-vlad
>
> /* Handle icmp frag needed error. */
^ permalink raw reply
* Re: [PATCH net-next-2.6 v6 00/12] net-caif: introducing CAIF protocol stack
From: Marcel Holtmann @ 2010-03-03 14:10 UTC (permalink / raw)
To: David Miller
Cc: sjur.brandeland, netdev, daniel.martensson, kaber, stefano.babic,
randy.dunlap
In-Reply-To: <20100303.011711.218594734.davem@davemloft.net>
Hi Dave,
> I'll take this in during the next merge window, I'm taking
> bug fixes only at this time.
>
> But this does mean that there's now more time to make refinements
> and make it even more ready for inclusion.
too bad, I would have really liked to see this one going in.
Sjur, don't wait until the next merge window. Once Dave opens the
net-next tree for 2.6.35, lets get this in to finalize the constant
assignments.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH 2/2] ipv4: flush ARP entries on device change
From: Patrick McHardy @ 2010-03-03 14:06 UTC (permalink / raw)
To: Timo Teras; +Cc: netdev
In-Reply-To: <1267624874-22326-2-git-send-email-timo.teras@iki.fi>
Timo Teras wrote:
> If device flag IFF_NOARP is changed, we should flush the ARP cache as all
> entries need to get refreshed.
>
> Signed-off-by: Timo Teras <timo.teras@iki.fi>
> ---
> net/ipv4/arp.c | 3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/net/ipv4/arp.c b/net/ipv4/arp.c
> index c4dd135..036da92 100644
> --- a/net/ipv4/arp.c
> +++ b/net/ipv4/arp.c
> @@ -1245,6 +1245,9 @@ static int arp_netdev_event(struct notifier_block *this, unsigned long event, vo
> neigh_changeaddr(&arp_tbl, dev);
> rt_cache_flush(dev_net(dev), 0);
> break;
> + case NETDEV_CHANGE:
> + neigh_changeaddr(&arp_tbl, dev);
> + break;
It would be nice if we could restrict this to IFF_NOARP changes.
^ permalink raw reply
* Re: [rfc/rft][patch] should use scheduler sync hint in tcp_prequeue()?
From: David Miller @ 2010-03-03 14:05 UTC (permalink / raw)
To: eric.dumazet; +Cc: efault, netdev, linux-kernel, mingo
In-Reply-To: <1267529273.2964.111.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 02 Mar 2010 12:27:53 +0100
> Le mardi 02 mars 2010 à 10:41 +0100, Mike Galbraith a écrit :
>> diff --git a/include/net/tcp.h b/include/net/tcp.h
>> index 34f5cc2..ba3fc64 100644
>> --- a/include/net/tcp.h
>> +++ b/include/net/tcp.h
>> @@ -939,7 +939,7 @@ static inline int tcp_prequeue(struct sock *sk, struct sk_buff *skb)
>>
>> tp->ucopy.memory = 0;
>> } else if (skb_queue_len(&tp->ucopy.prequeue) == 1) {
>> - wake_up_interruptible_poll(sk->sk_sleep,
>> + wake_up_interruptible_sync_poll(sk->sk_sleep,
>> POLLIN | POLLRDNORM | POLLRDBAND);
>> if (!inet_csk_ack_scheduled(sk))
>> inet_csk_reset_xmit_timer(sk, ICSK_TIME_DACK,
>>
...
> Ingo probably can answer to this question, since he changed
> sock_def_readable() (and others) in commit 6f3d09291b498299
> I suspect he missed tcp_prequeue() case, maybe not...
It definitely looks like an oversight to me and we should add
be using wake_up_interruptible_sync_poll() in tcp_prequeue()
as above.
Ingo?
^ permalink raw reply
* [PATCH 2/2] ipv4: flush ARP entries on device change
From: Timo Teras @ 2010-03-03 14:01 UTC (permalink / raw)
To: netdev; +Cc: Timo Teras
In-Reply-To: <1267624874-22326-1-git-send-email-timo.teras@iki.fi>
If device flag IFF_NOARP is changed, we should flush the ARP cache as all
entries need to get refreshed.
Signed-off-by: Timo Teras <timo.teras@iki.fi>
---
net/ipv4/arp.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/net/ipv4/arp.c b/net/ipv4/arp.c
index c4dd135..036da92 100644
--- a/net/ipv4/arp.c
+++ b/net/ipv4/arp.c
@@ -1245,6 +1245,9 @@ static int arp_netdev_event(struct notifier_block *this, unsigned long event, vo
neigh_changeaddr(&arp_tbl, dev);
rt_cache_flush(dev_net(dev), 0);
break;
+ case NETDEV_CHANGE:
+ neigh_changeaddr(&arp_tbl, dev);
+ break;
default:
break;
}
--
1.6.3.3
^ permalink raw reply related
* [PATCH 1/2] gre: fix hard header destination address checking
From: Timo Teras @ 2010-03-03 14:01 UTC (permalink / raw)
To: netdev; +Cc: Timo Teras
ipgre_header() can be called with zero daddr when the gre device is
configured as multipoint tunnel and still has the NOARP flag set (which is
typically cleared by the userspace arp daemon). If the NOARP packets are
not dropped, ipgre_tunnel_xmit() will take rt->rt_gateway (= NBMA IP) and
use that for route look up (and may lead to bogus xfrm acquires).
The multicast address check is removed as sending to multicast group should
be ok. In fact, if gre device has a multicast address as destination
ipgre_header is always called with multicast address.
Signed-off-by: Timo Teras <timo.teras@iki.fi>
---
net/ipv4/ip_gre.c | 7 ++-----
1 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
index c0c5274..f47c9f7 100644
--- a/net/ipv4/ip_gre.c
+++ b/net/ipv4/ip_gre.c
@@ -1144,12 +1144,9 @@ static int ipgre_header(struct sk_buff *skb, struct net_device *dev,
if (saddr)
memcpy(&iph->saddr, saddr, 4);
-
- if (daddr) {
+ if (daddr)
memcpy(&iph->daddr, daddr, 4);
- return t->hlen;
- }
- if (iph->daddr && !ipv4_is_multicast(iph->daddr))
+ if (iph->daddr)
return t->hlen;
return -t->hlen;
--
1.6.3.3
^ permalink raw reply related
* RE: [PATCH 8/8] x25: use limited socket backlog
From: Zhu, Yi @ 2010-03-03 14:00 UTC (permalink / raw)
To: andrew hendry, Eric Dumazet; +Cc: netdev@vger.kernel.org
In-Reply-To: <d45a3acc1003030338m3102a95p1b06b7db1b24e58e@mail.gmail.com>
andrew hendry <andrew.hendry@gmail.com> wrote:
> Will wait for the next spin and in the meantime think if there is way
> to test it. x25 with no loopback and being so slow probably cant generate the same
> as your UDP case.
I didn't find a way to drop the packet correctly. So I didn't change any behavior in
this patch. Nor did I do in the second spin. It will be fine if you also think x25 doesn't
need to limit its backlog size.
Thanks,
-yi
^ permalink raw reply
* [PATCH] rstp: Fix compiler type-punning error in rstp daemon
From: Neil Horman @ 2010-03-03 13:53 UTC (permalink / raw)
To: shemminger; +Cc: netdev
Hey-
Was trying to build the rstp daemon today and got a type-punning error
in bridge_track.c. This patch fixes it up.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
bridge_track.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/bridge_track.c b/bridge_track.c
index be555de..fa59732 100644
--- a/bridge_track.c
+++ b/bridge_track.c
@@ -599,7 +599,7 @@ void bridge_bpdu_rcv(int if_index, const unsigned char *data, int len)
// TST(ntohs(*(uint16_t*)bpdu.body.message_age)
// < ntohs(*(uint16_t*)bpdu.body.max_age), );
TST(memcmp(bpdu->body.bridge_id, &ifc->master->bridge_id, 8) != 0
- || (ntohs(*(uint16_t *) bpdu->body.port_id) & 0xfff) !=
+ || (ntohs((uint16_t) *bpdu->body.port_id) & 0xfff) !=
ifc->port_index,);
break;
case BPDU_TOPO_CHANGE_TYPE:
^ permalink raw reply related
* Re: [net-next-2.6 PATCH] wireless: convert to use netdev_for_each_mc_addr
From: Jiri Pirko @ 2010-03-03 12:42 UTC (permalink / raw)
To: Jussi Kivilinna; +Cc: netdev, davem
In-Reply-To: <20100303114506.19575pbsu8yz2kjk@hayate.sektori.org>
Wed, Mar 03, 2010 at 10:45:06AM CET, jussi.kivilinna@mbnet.fi wrote:
>Hello!
>
>Added locking broke rndis_wlan, rndis_set_oid/rndis_command sleeps.
>Also there is kmalloc(..., GFP_KERNEL) within lock/unlock.
>
Patch correcting this follows.
Subject: [net-2.6 PATCH] rndis_wlan: correct multicast_list handling
My previous patch (655ffee284dfcf9a24ac0343f3e5ee6db85b85c5) added locking in
a bad way. Because rndis_set_oid can sleep, there is need to prepare multicast
addresses into local buffer under netif_addr_lock first, then call
rndis_set_oid outside. This caused reorganizing of the whole function.
Please review.
Thanks
Jirka
Signed-off-by: Jiri Pirko <jpirko@redhat.com>
Reported-by: Jussi Kivilinna <jussi.kivilinna@mbnet.fi>
diff --git a/drivers/net/wireless/rndis_wlan.c b/drivers/net/wireless/rndis_wlan.c
index 9f6d6bf..824064b 100644
--- a/drivers/net/wireless/rndis_wlan.c
+++ b/drivers/net/wireless/rndis_wlan.c
@@ -1496,23 +1496,38 @@ static void set_multicast_list(struct usbnet *usbdev)
{
struct rndis_wlan_private *priv = get_rndis_wlan_priv(usbdev);
struct dev_mc_list *mclist;
- __le32 filter;
- int ret, i, size;
- char *buf;
+ __le32 filter, basefilter;
+ int ret;
+ char *mc_addrs = NULL;
+ int mc_count;
- filter = RNDIS_PACKET_TYPE_DIRECTED | RNDIS_PACKET_TYPE_BROADCAST;
+ basefilter = filter = RNDIS_PACKET_TYPE_DIRECTED |
+ RNDIS_PACKET_TYPE_BROADCAST;
- netif_addr_lock_bh(usbdev->net);
if (usbdev->net->flags & IFF_PROMISC) {
filter |= RNDIS_PACKET_TYPE_PROMISCUOUS |
RNDIS_PACKET_TYPE_ALL_LOCAL;
- } else if (usbdev->net->flags & IFF_ALLMULTI ||
- netdev_mc_count(usbdev->net) > priv->multicast_size) {
+ } else if (usbdev->net->flags & IFF_ALLMULTI) {
+ filter |= RNDIS_PACKET_TYPE_ALL_MULTICAST;
+ }
+
+ if (filter != basefilter)
+ goto set_filter;
+
+ /*
+ * mc_list should be accessed holding the lock, so copy addresses to
+ * local buffer first.
+ */
+ netif_addr_lock_bh(usbdev->net);
+ mc_count = netdev_mc_count(usbdev->net);
+ if (mc_count > priv->multicast_size) {
filter |= RNDIS_PACKET_TYPE_ALL_MULTICAST;
- } else if (!netdev_mc_empty(usbdev->net)) {
- size = min(priv->multicast_size, netdev_mc_count(usbdev->net));
- buf = kmalloc(size * ETH_ALEN, GFP_KERNEL);
- if (!buf) {
+ } else if (mc_count) {
+ int size = min(priv->multicast_size, mc_count);
+ int i = 0;
+
+ mc_addrs = kmalloc(size * ETH_ALEN, GFP_ATOMIC);
+ if (!mc_addrs) {
netdev_warn(usbdev->net,
"couldn't alloc %d bytes of memory\n",
size * ETH_ALEN);
@@ -1520,27 +1535,29 @@ static void set_multicast_list(struct usbnet *usbdev)
return;
}
- i = 0;
- netdev_for_each_mc_addr(mclist, usbdev->net) {
- if (i == size)
- break;
- memcpy(buf + i++ * ETH_ALEN, mclist->dmi_addr, ETH_ALEN);
- }
+ netdev_for_each_mc_addr(mclist, usbdev->net)
+ memcpy(mc_addrs + i++ * ETH_ALEN,
+ mclist->dmi_addr, ETH_ALEN);
+ }
+ netif_addr_unlock_bh(usbdev->net);
- ret = rndis_set_oid(usbdev, OID_802_3_MULTICAST_LIST, buf,
- i * ETH_ALEN);
- if (ret == 0 && i > 0)
+ if (filter != basefilter)
+ goto set_filter;
+
+ if (mc_count) {
+ ret = rndis_set_oid(usbdev, OID_802_3_MULTICAST_LIST, mc_addrs,
+ mc_count * ETH_ALEN);
+ kfree(mc_addrs);
+ if (ret == 0)
filter |= RNDIS_PACKET_TYPE_MULTICAST;
else
filter |= RNDIS_PACKET_TYPE_ALL_MULTICAST;
netdev_dbg(usbdev->net, "OID_802_3_MULTICAST_LIST(%d, max: %d) -> %d\n",
- i, priv->multicast_size, ret);
-
- kfree(buf);
+ mc_count, priv->multicast_size, ret);
}
- netif_addr_unlock_bh(usbdev->net);
+set_filter:
ret = rndis_set_oid(usbdev, OID_GEN_CURRENT_PACKET_FILTER, &filter,
sizeof(filter));
if (ret < 0) {
^ permalink raw reply related
* Re: [PATCH 8/8] x25: use limited socket backlog
From: andrew hendry @ 2010-03-03 11:38 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Zhu Yi, netdev
In-Reply-To: <1267600109.2839.101.camel@edumazet-laptop>
Will wait for the next spin and in the meantime think if there is way
to test it.
x25 with no loopback and being so slow probably cant generate the same
as your UDP case.
Andrew.
On Wed, Mar 3, 2010 at 6:08 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le mercredi 03 mars 2010 à 14:35 +0800, Zhu Yi a écrit :
>> Make x25 adapt to the limited socket backlog change.
>>
>> Cc: Andrew Hendry <andrew.hendry@gmail.com>
>> Signed-off-by: Zhu Yi <yi.zhu@intel.com>
>> ---
>> net/x25/x25_dev.c | 2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/net/x25/x25_dev.c b/net/x25/x25_dev.c
>> index 3e1efe5..5688123 100644
>> --- a/net/x25/x25_dev.c
>> +++ b/net/x25/x25_dev.c
>> @@ -53,7 +53,7 @@ static int x25_receive_data(struct sk_buff *skb, struct x25_neigh *nb)
>> if (!sock_owned_by_user(sk)) {
>> queued = x25_process_rx_frame(sk, skb);
>> } else {
>> - sk_add_backlog(sk, skb);
>> + __sk_add_backlog(sk, skb);
>> }
>> bh_unlock_sock(sk);
>> sock_put(sk);
>
> Please respin your patch the other way
>
> Ie: let sk_add_backlog(sk, skb) do its previous job (not leaking skbs,
> and returning a void status)
>
> Add a new function able to no limit backlog, and returns an error code,
> so that caller can free skb and increment SNMP counters accordingly.
>
> Callers MUST test return value, or use another helper that can free the
> skb for them.
>
> Name it sk_move_backlog() for example
>
> This will permit you to split the work as you tried.
>
> sk_add_backlog() could be redefined as the helper :
>
> void sk_add_backlog(sk, skb)
> {
> if (sk_move_backlog(sk, skb)) {
> kfree_skb(skb);
> atomic_inc(&sk->sk_drops);
> }
>
> }
>
> Thanks
>
>
>
^ permalink raw reply
* Re: [PATCH V2 2/7] tcp: use limited socket backlog
From: Eric Dumazet @ 2010-03-03 10:07 UTC (permalink / raw)
To: Zhu Yi
Cc: netdev@vger.kernel.org, David S. Miller, Alexey Kuznetsov,
Pekka Savola (ipv6), Patrick McHardy
In-Reply-To: <1267607162.2370.169.camel@debian>
Le mercredi 03 mars 2010 à 17:06 +0800, Zhu Yi a écrit :
> I simply follow how the code is originally written. As you can see,
> tcp_v4_do_rcv() doesn't always do so. And in the backlog queuing place,
> we don't even bother to check.
You add a new point where a packet can be dropped, this should be
accounted for, so that admins can have a clue whats going on.
Previously, packet was always queued, and dropped later (and accounted)
Not everybody runs drop monitor :)
^ permalink raw reply
* Re: [net-next-2.6 PATCH] wireless: convert to use netdev_for_each_mc_addr
From: David Miller @ 2010-03-03 10:01 UTC (permalink / raw)
To: jussi.kivilinna; +Cc: jpirko, netdev
In-Reply-To: <20100303114506.19575pbsu8yz2kjk@hayate.sektori.org>
From: "Jussi Kivilinna" <jussi.kivilinna@mbnet.fi>
Date: Wed, 03 Mar 2010 11:45:06 +0200
> Hello!
>
> Added locking broke rndis_wlan, rndis_set_oid/rndis_command
> sleeps. Also there is kmalloc(..., GFP_KERNEL) within lock/unlock.
Jiri please fix this.
^ permalink raw reply
* Re: [net-next-2.6 PATCH] wireless: convert to use netdev_for_each_mc_addr
From: Jussi Kivilinna @ 2010-03-03 9:45 UTC (permalink / raw)
To: Jiri Pirko; +Cc: netdev, davem
Hello!
Added locking broke rndis_wlan, rndis_set_oid/rndis_command sleeps.
Also there is kmalloc(..., GFP_KERNEL) within lock/unlock.
-Jussi
Quoting "Jiri Pirko" <jpirko@redhat.com>:
>
> also added missed locking in rndis_wlan.c
>
> Signed-off-by: Jiri Pirko <jpirko@redhat.com>
> ---
> drivers/net/wireless/libertas/main.c | 8 ++++++--
> drivers/net/wireless/orinoco/hw.c | 22 +++++++---------------
> drivers/net/wireless/orinoco/hw.h | 2 +-
> drivers/net/wireless/orinoco/main.c | 3 +--
> drivers/net/wireless/ray_cs.c | 8 ++++----
> drivers/net/wireless/rndis_wlan.c | 15 ++++++++-------
> drivers/net/wireless/zd1201.c | 9 ++++-----
> 7 files changed, 31 insertions(+), 36 deletions(-)
>
> diff --git a/drivers/net/wireless/libertas/main.c
> b/drivers/net/wireless/libertas/main.c
> index cd8ed7f..28a1c9d 100644
> --- a/drivers/net/wireless/libertas/main.c
> +++ b/drivers/net/wireless/libertas/main.c
> @@ -319,15 +319,18 @@ static int lbs_add_mcast_addrs(struct
> cmd_ds_mac_multicast_adr *cmd,
> {
> int i = nr_addrs;
> struct dev_mc_list *mc_list;
> + int cnt;
>
> if ((dev->flags & (IFF_UP|IFF_MULTICAST)) != (IFF_UP|IFF_MULTICAST))
> return nr_addrs;
>
> netif_addr_lock_bh(dev);
> - for (mc_list = dev->mc_list; mc_list; mc_list = mc_list->next) {
> + cnt = netdev_mc_count(dev);
> + netdev_for_each_mc_addr(mc_list, dev) {
> if (mac_in_list(cmd->maclist, nr_addrs, mc_list->dmi_addr)) {
> lbs_deb_net("mcast address %s:%pM skipped\n", dev->name,
> mc_list->dmi_addr);
> + cnt--;
> continue;
> }
>
> @@ -337,9 +340,10 @@ static int lbs_add_mcast_addrs(struct
> cmd_ds_mac_multicast_adr *cmd,
> lbs_deb_net("mcast address %s:%pM added to filter\n", dev->name,
> mc_list->dmi_addr);
> i++;
> + cnt--;
> }
> netif_addr_unlock_bh(dev);
> - if (mc_list)
> + if (cnt)
> return -EOVERFLOW;
>
> return i;
> diff --git a/drivers/net/wireless/orinoco/hw.c
> b/drivers/net/wireless/orinoco/hw.c
> index 404830f..e636924 100644
> --- a/drivers/net/wireless/orinoco/hw.c
> +++ b/drivers/net/wireless/orinoco/hw.c
> @@ -1028,7 +1028,7 @@ int orinoco_clear_tkip_key(struct
> orinoco_private *priv, int key_idx)
> }
>
> int __orinoco_hw_set_multicast_list(struct orinoco_private *priv,
> - struct dev_addr_list *mc_list,
> + struct net_device *dev,
> int mc_count, int promisc)
> {
> hermes_t *hw = &priv->hw;
> @@ -1049,24 +1049,16 @@ int __orinoco_hw_set_multicast_list(struct
> orinoco_private *priv,
> * group address if either we want to multicast, or if we were
> * multicasting and want to stop */
> if (!promisc && (mc_count || priv->mc_count)) {
> - struct dev_mc_list *p = mc_list;
> + struct dev_mc_list *p;
> struct hermes_multicast mclist;
> - int i;
> + int i = 0;
>
> - for (i = 0; i < mc_count; i++) {
> - /* paranoia: is list shorter than mc_count? */
> - BUG_ON(!p);
> - /* paranoia: bad address size in list? */
> - BUG_ON(p->dmi_addrlen != ETH_ALEN);
> -
> - memcpy(mclist.addr[i], p->dmi_addr, ETH_ALEN);
> - p = p->next;
> + netdev_for_each_mc_addr(p, dev) {
> + if (i == mc_count)
> + break;
> + memcpy(mclist.addr[i++], p->dmi_addr, ETH_ALEN);
> }
>
> - if (p)
> - printk(KERN_WARNING "%s: Multicast list is "
> - "longer than mc_count\n", priv->ndev->name);
> -
> err = hermes_write_ltv(hw, USER_BAP,
> HERMES_RID_CNFGROUPADDRESSES,
> HERMES_BYTES_TO_RECLEN(mc_count * ETH_ALEN),
> diff --git a/drivers/net/wireless/orinoco/hw.h
> b/drivers/net/wireless/orinoco/hw.h
> index e2f7fdc..9799a1d 100644
> --- a/drivers/net/wireless/orinoco/hw.h
> +++ b/drivers/net/wireless/orinoco/hw.h
> @@ -43,7 +43,7 @@ int __orinoco_hw_set_tkip_key(struct
> orinoco_private *priv, int key_idx,
> u8 *tsc, size_t tsc_len);
> int orinoco_clear_tkip_key(struct orinoco_private *priv, int key_idx);
> int __orinoco_hw_set_multicast_list(struct orinoco_private *priv,
> - struct dev_addr_list *mc_list,
> + struct net_device *dev,
> int mc_count, int promisc);
> int orinoco_hw_get_essid(struct orinoco_private *priv, int *active,
> char buf[IW_ESSID_MAX_SIZE+1]);
> diff --git a/drivers/net/wireless/orinoco/main.c
> b/drivers/net/wireless/orinoco/main.c
> index a9e9cea..b42634c 100644
> --- a/drivers/net/wireless/orinoco/main.c
> +++ b/drivers/net/wireless/orinoco/main.c
> @@ -1676,8 +1676,7 @@ __orinoco_set_multicast_list(struct net_device *dev)
> mc_count = netdev_mc_count(dev);
> }
>
> - err = __orinoco_hw_set_multicast_list(priv, dev->mc_list, mc_count,
> - promisc);
> + err = __orinoco_hw_set_multicast_list(priv, dev, mc_count, promisc);
>
> return err;
> }
> diff --git a/drivers/net/wireless/ray_cs.c b/drivers/net/wireless/ray_cs.c
> index 85905ca..84c530a 100644
> --- a/drivers/net/wireless/ray_cs.c
> +++ b/drivers/net/wireless/ray_cs.c
> @@ -1871,10 +1871,8 @@ static void ray_update_parm(struct net_device
> *dev, UCHAR objid, UCHAR *value,
> /*===========================================================================*/
> static void ray_update_multi_list(struct net_device *dev, int all)
> {
> - struct dev_mc_list *dmi, **dmip;
> int ccsindex;
> struct ccs __iomem *pccs;
> - int i = 0;
> ray_dev_t *local = netdev_priv(dev);
> struct pcmcia_device *link = local->finder;
> void __iomem *p = local->sram + HOST_TO_ECF_BASE;
> @@ -1895,9 +1893,11 @@ static void ray_update_multi_list(struct
> net_device *dev, int all)
> writeb(0xff, &pccs->var);
> local->num_multi = 0xff;
> } else {
> + struct dev_mc_list *dmi;
> + int i = 0;
> +
> /* Copy the kernel's list of MC addresses to card */
> - for (dmip = &dev->mc_list; (dmi = *dmip) != NULL;
> - dmip = &dmi->next) {
> + netdev_for_each_mc_addr(dmi, dev) {
> memcpy_toio(p, dmi->dmi_addr, ETH_ALEN);
> dev_dbg(&link->dev,
> "ray_update_multi add addr %02x%02x%02x%02x%02x%02x\n",
> diff --git a/drivers/net/wireless/rndis_wlan.c
> b/drivers/net/wireless/rndis_wlan.c
> index 65cbd06..9f6d6bf 100644
> --- a/drivers/net/wireless/rndis_wlan.c
> +++ b/drivers/net/wireless/rndis_wlan.c
> @@ -1502,6 +1502,7 @@ static void set_multicast_list(struct usbnet *usbdev)
>
> filter = RNDIS_PACKET_TYPE_DIRECTED | RNDIS_PACKET_TYPE_BROADCAST;
>
> + netif_addr_lock_bh(usbdev->net);
> if (usbdev->net->flags & IFF_PROMISC) {
> filter |= RNDIS_PACKET_TYPE_PROMISCUOUS |
> RNDIS_PACKET_TYPE_ALL_LOCAL;
> @@ -1515,16 +1516,15 @@ static void set_multicast_list(struct usbnet *usbdev)
> netdev_warn(usbdev->net,
> "couldn't alloc %d bytes of memory\n",
> size * ETH_ALEN);
> + netif_addr_unlock_bh(usbdev->net);
> return;
> }
>
> - mclist = usbdev->net->mc_list;
> - for (i = 0; i < size && mclist; mclist = mclist->next) {
> - if (mclist->dmi_addrlen != ETH_ALEN)
> - continue;
> -
> - memcpy(buf + i * ETH_ALEN, mclist->dmi_addr, ETH_ALEN);
> - i++;
> + i = 0;
> + netdev_for_each_mc_addr(mclist, usbdev->net) {
> + if (i == size)
> + break;
> + memcpy(buf + i++ * ETH_ALEN, mclist->dmi_addr, ETH_ALEN);
> }
>
> ret = rndis_set_oid(usbdev, OID_802_3_MULTICAST_LIST, buf,
> @@ -1539,6 +1539,7 @@ static void set_multicast_list(struct usbnet *usbdev)
>
> kfree(buf);
> }
> + netif_addr_unlock_bh(usbdev->net);
>
> ret = rndis_set_oid(usbdev, OID_GEN_CURRENT_PACKET_FILTER, &filter,
> sizeof(filter));
> diff --git a/drivers/net/wireless/zd1201.c b/drivers/net/wireless/zd1201.c
> index 5d2b52f..6917286 100644
> --- a/drivers/net/wireless/zd1201.c
> +++ b/drivers/net/wireless/zd1201.c
> @@ -875,17 +875,16 @@ static struct iw_statistics
> *zd1201_get_wireless_stats(struct net_device *dev)
> static void zd1201_set_multicast(struct net_device *dev)
> {
> struct zd1201 *zd = netdev_priv(dev);
> - struct dev_mc_list *mc = dev->mc_list;
> + struct dev_mc_list *mc;
> unsigned char reqbuf[ETH_ALEN*ZD1201_MAXMULTI];
> int i;
>
> if (netdev_mc_count(dev) > ZD1201_MAXMULTI)
> return;
>
> - for (i=0; i<netdev_mc_count(dev); i++) {
> - memcpy(reqbuf+i*ETH_ALEN, mc->dmi_addr, ETH_ALEN);
> - mc = mc->next;
> - }
> + i = 0;
> + netdev_for_each_mc_addr(mc, dev)
> + memcpy(reqbuf + i++ * ETH_ALEN, mc->dmi_addr, ETH_ALEN);
> zd1201_setconfig(zd, ZD1201_RID_CNFGROUPADDRESS, reqbuf,
> netdev_mc_count(dev) * ETH_ALEN, 0);
> }
> --
> 1.6.6
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
^ permalink raw reply
* increase in size for struct request_sock tolerable ?
From: Sébastien Barré @ 2010-03-03 9:35 UTC (permalink / raw)
To: netdev; +Cc: alan.p.smith
Hi,
As part of the development of the MPTCP protocol
(http://inl.info.ucl.ac.be/mptcp), we are wondering whether it is
tolerable to extend the length of the struct request_sock. In the
current version of the protocol
(http://tools.ietf.org/id/draft-ford-mptcp-multiaddressed-02.txt), a
32bit token is exchanged as TCP options in the SYN and SYN/ACK segments.
AFAIU, that requires that we store 8 bytes in the request sock for the
server side, so that it remembers the local and remote tokens until the
real sock is created.Even worse, since the NULL token is not a reserved
value, we need to store an additional bit (flag) to know that we
received that TCP option. Since there are no flags currently stored in
the request_sock, we need to directly increase the size by 8 additional
bits.
So with the current protocol design, I arrive to a struct request_sock
extension of 4 (local token)+4(remote token)+1(1bit flag+7free flags)=9
bytes.
A minor protocol modification would allow reducing that constraint.
Basically, we would then differ the token exchange until the real sock
is created. The flag would still be needed, though, thus in that case
we would arrive to 1 byte of extension only for the struct request_sock.
So my question is : Do you think there is a sufficient incentive here to
adapt our protocol draft ? Or is it tolerable to extend the struct
request_sock by 9 bytes ?
Thanks in advance !
Sébastien.
--
Sébastien Barré
Researcher,
CSE department, UCLouvain, Belgium
http://inl.info.ucl.ac.be/sbarre
^ permalink raw reply
* Re: TCP Appropriate Byte Counting per default off
From: Alexander Zimmermann @ 2010-03-03 9:33 UTC (permalink / raw)
To: Ilpo Järvinen; +Cc: David Miller, Netdev
In-Reply-To: <alpine.DEB.2.00.1003031035370.10775@melkinpaasi.cs.helsinki.fi>
Am 03.03.2010 um 09:48 schrieb Ilpo Järvinen:
> On Wed, 3 Mar 2010, Alexander Zimmermann wrote:
>
>> Hi David, hi Ilpo,
>>
>> I wonder why ABC is off per default? What are the reasons?
>> Should we turn it on per default?
>>
>> From algorithmic point of view I see no flaws just
>> benefits.
>>
>> With RFC5681 ABC is recommended.
>> OSX uses ABC per default.
>
> As Alexey once put it, ABC is very BSD specific algorithm.
>
> Out of two goals of ABC, protection against split ACKs is achieved in
> Linux by other means (see tcp_clean_rtx_queue and flags it gives to
> elsewhere). Thus, you can kind of think that we do APC already :-). The
> other part, faster increase during slow start, isn't currently done though
> it would be relatively simple to implement (I think I even have some,
> possibly unfinished, patch to do that lying around somewhere I wrote
> someday).
Related to that is a scenario that I have in mind: reverse path reordering.
With ABC we are more robust, ie, open cwnd as normal during SS
>
> ABC is not that necessary when window is counted in packets. And besides
> that, it was found to somewhat hurt small segment flows. There are some
> messages in archives in the timeframe ABC was disabled (plus there might
> have been some even older than that).
>
> --
> i.
//
// Dipl.-Inform. Alexander Zimmermann
// Department of Computer Science, Informatik 4
// RWTH Aachen University
// Ahornstr. 55, 52056 Aachen, Germany
// phone: (49-241) 80-21422, fax: (49-241) 80-22220
// email: zimmermann@cs.rwth-aachen.de
// web: http://www.umic-mesh.net
//
^ permalink raw reply
* Re: [RFC][ PATCH 0/3] vhost-net: Add mergeable RX buffer support to vhost-net
From: Michael S. Tsirkin @ 2010-03-03 9:28 UTC (permalink / raw)
To: David Stevens; +Cc: kvm, netdev, rusty, virtualization
In-Reply-To: <OFF77F6422.A58B61AC-ON882576DB.002F6BA9-882576DB.0030ED4C@us.ibm.com>
On Wed, Mar 03, 2010 at 12:54:25AM -0800, David Stevens wrote:
> "Michael S. Tsirkin" <mst@redhat.com> wrote on 03/02/2010 11:54:32 PM:
>
> > On Tue, Mar 02, 2010 at 04:20:03PM -0800, David Stevens wrote:
> > > These patches add support for mergeable receive buffers to
> > > vhost-net, allowing it to use multiple virtio buffer heads for a
> single
> > > receive packet.
> > > +-DLS
> > >
> > >
> > > Signed-off-by: David L Stevens <dlstevens@us.ibm.com>
> >
> > Do you have performance numbers (both with and without mergeable buffers
> > in guest)?
>
> Michael,
> Nothing formal. I did some TCP single-stream throughput tests
> and was seeing 20-25% improvement on a laptop (ie, low-end hardware).
> That actually surprised me; I'd think it'd be about the same, except
> maybe in a test that has mixed packet sizes. Comparisons with the
> net-next kernel these patches are for showed only ~10% improvement.
> But I also see a lot of variability both among different
> configurations and with the same configuration on different runs.
> So, I don't feel like those numbers are very solid, and I haven't
> yet done any tests on bigger hardware.
Interesting. Since the feature in question is billed first of all a
performance optimization, I think we might need some performance numbers
as a motivation.
Since the patches affect code paths when mergeable RX buffers are
disabled as well, I guess the most important point would be to verify
whether there's increase in latency and/or CPU utilization, or bandwidth
cost when the feature bit is *disabled*.
> 2 notes: I have a modified version of qemu to get the VHOST_FEATURES
> flags, including the mergeable RX bufs flag, passed to the guest; I'll
> be working with your current qemu git trees next, if any changes are
> needed to support it there.
This feature also seems to conflict with zero-copy rx patches from Xin
Xiaohui (subject: Provide a zero-copy method on KVM virtio-net) these
are not in a mergeable shape yet, so this is not a blocker, but I wonder
what your thoughts on the subject are: how will we do feature
negotiation if some backends don't support some features?
> Second, I've found a missing initialization in the patches I
> sent on the list, so I'll send an updated patch 2 with the fix,
If you do, any chance you could use git send-email for this?
> and qemu patches when they are ready (plus any code-review comments
> incorporated).
>
Pls take a look here as well
http://www.openfabrics.org/~mst/boring.txt
^ permalink raw reply
* Re: [PATCH -next] bridge: depends on INET
From: David Miller @ 2010-03-03 9:23 UTC (permalink / raw)
To: rdunlap; +Cc: sfr, linux-next, linux-kernel, shemminger, bridge, netdev
In-Reply-To: <4B8D4607.8070603@xenotime.net>
From: Randy Dunlap <rdunlap@xenotime.net>
Date: Tue, 02 Mar 2010 09:08:23 -0800
> From: Randy Dunlap <randy.dunlap@oracle.com>
>
> br_multicast calls ip_send_check(), so it should depend on INET.
>
> built-in:
> br_multicast.c:(.text+0x88cf4): undefined reference to `ip_send_check'
>
> or modular:
> ERROR: "ip_send_check" [net/bridge/bridge.ko] undefined!
>
> Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Applied, but I almost lost this patch.
You need to CC: netdev on all networking patches so that it
gets properly tracked in patchwork and therefore does not get
lost.
Thanks.
^ permalink raw reply
* Re: 2.6.33 dies on modprobe
From: Américo Wang @ 2010-03-03 9:18 UTC (permalink / raw)
To: Américo Wang, linux-kernel, Linux Kernel Network Developers
Cc: Greg Kroah-Hartman
In-Reply-To: <2375c9f91003030108h43973d0cw713d1004dd912389@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2020 bytes --]
On Wed, Mar 3, 2010 at 5:08 PM, Américo Wang <xiyou.wangcong@gmail.com> wrote:
> On Wed, Mar 3, 2010 at 4:58 PM, Américo Wang <xiyou.wangcong@gmail.com> wrote:
>> On Mon, Mar 1, 2010 at 5:07 PM, M G Berberich
>> <berberic@fmi.uni-passau.de> wrote:
>>> Hello,
>>>
>>> Am Montag, den 01. März schrieb Américo Wang:
>>>> On Mon, Mar 1, 2010 at 6:12 AM, M G Berberich
>>>> <berberic@fmi.uni-passau.de> wrote:
>>>
>>>> > I tried to build a 2.6.33 kernel but on boot it dies on modprobe
>>>> > (kernel-Oops). This might be the result of faulty config, but I'm
>>>> > totaly clueless what's the fault.
>>>> >
>>>> > The kernel starts up fine and mounts the root-filesystem, but then
>>>> > dies on the first modprobe executed. I can boot it with init=/bin/bash
>>>> > and get a working bash (until I do modprobe on any module).
>>>> >
>>>> > System is a Gigabyte M55S-S3 rev 2.0 (nForce 550) with an AMD Athlon64
>>>> > X2 5000+ and amd64-kernel architecture. kernel-sources are from
>>>> > kernel.org.
>>>
>>>> It seems something is wrong with forcedeth code or PCI code.
>>>> Adding some Cc's.
>>>
>>> I don't think it's forcedeth. forcedeth just happens to be the first
>>> module that get's loaded in startup. It crashes with any other module
>>> too (I tried ohci_hcd).
>>>
>>
>> Ok, below is my patch, I am not sure it could fix the BUG for you,
>> but it could fix the WARNING. But perhaps they are related.
>>
>> Please give it a try.
>>
>
> Oops! Ignore the patch, it should not be correct, I will send a
> correct version soon.
> Sorry.
>
Here we go:
--------------------->
It looks really odd that we do class_put() in non-failure path of
__class_register(). This seems wrong.
To fix this, just remove class_get() in __class_register(), we don't need
to call class_get() to get ref of cls->p->class_subsys, because
kset_register() has already done this for us.
Signed-off-by: WANG Cong <xiyou.wangcong@gmail.com>
Cc: Greg Kroah-Hartman <gregkh@suse.de>
[-- Attachment #2: drivers-base-class_c-move-class_put.diff --]
[-- Type: text/plain, Size: 414 bytes --]
diff --git a/drivers/base/class.c b/drivers/base/class.c
index 6e2c3b0..695d624 100644
--- a/drivers/base/class.c
+++ b/drivers/base/class.c
@@ -191,8 +191,7 @@ int __class_register(struct class *cls, struct lock_class_key *key)
kfree(cp);
return error;
}
- error = add_class_attrs(class_get(cls));
- class_put(cls);
+ error = add_class_attrs(cls);
return error;
}
EXPORT_SYMBOL_GPL(__class_register);
^ permalink raw reply related
* Re: [PATCH net-next-2.6 v6 00/12] net-caif: introducing CAIF protocol stack
From: David Miller @ 2010-03-03 9:17 UTC (permalink / raw)
To: sjur.brandeland
Cc: netdev, marcel, daniel.martensson, kaber, stefano.babic,
randy.dunlap
In-Reply-To: <1267445559-1911-1-git-send-email-sjur.brandeland@stericsson.com>
I'll take this in during the next merge window, I'm taking
bug fixes only at this time.
But this does mean that there's now more time to make refinements
and make it even more ready for inclusion.
Thanks.
^ permalink raw reply
* Re: [Bridge] [PATCH] bridge: per-cpu packet statistics (v3)
From: David Miller @ 2010-03-03 9:16 UTC (permalink / raw)
To: eric.dumazet; +Cc: shemminger, netdev, bridge
In-Reply-To: <1267596544.2839.71.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 03 Mar 2010 07:09:04 +0100
> Le mardi 02 mars 2010 à 15:32 -0800, Stephen Hemminger a écrit :
>> The shared packet statistics are a potential source of slow down
>> on bridged traffic. Convert to per-cpu array, but only keep those
>> statistics which change per-packet.
>>
>> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
>>
>
> Thanks Stephen !
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
This is fine but needs to go into the next merge window, not
this one.
Bug fixes only now.
^ permalink raw reply
* Re: [PATCH 00/12] IPv6 addrconf changes
From: David Miller @ 2010-03-03 9:16 UTC (permalink / raw)
To: shemminger; +Cc: yoshfuji, netdev
In-Reply-To: <20100302233243.259794027@vyatta.com>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Tue, 02 Mar 2010 15:32:43 -0800
> This set includes a mixed bag of changes all related to
> IPv6 address configuration: bugfixes (1-3,8), changes to use
> list interface (4-5,8), RCU (6), cosmetic cleanups (9-10,12) and
> minor improvments (7,11).
Unless you split out the change that are not bug fixes, this
will have to wait until the next merge window.
As I very clearly stated the other day I'm really not taking
anything other than bug fixes after Linus takes in my pull
request, which he did today.
^ permalink raw reply
* Re: [PATCH 1/1] bnx2x: Removed FW 5.2.7
From: David Miller @ 2010-03-03 9:09 UTC (permalink / raw)
To: vladz; +Cc: netdev, eilong
In-Reply-To: <1267559910.17814.4.camel@lb-tlvb-vladz>
From: "Vladislav Zolotarov" <vladz@broadcom.com>
Date: Tue, 2 Mar 2010 21:58:30 +0200
> Removed FW 5.2.7.
>
> Signed-off-by: Vladislav Zolotarov <vladz@broadcom.com>
> Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
Applied, thanks.
^ permalink raw reply
* Re: 2.6.33 dies on modprobe
From: Américo Wang @ 2010-03-03 9:08 UTC (permalink / raw)
To: Américo Wang, linux-kernel, Linux Kernel Network Developers
Cc: Greg Kroah-Hartman
In-Reply-To: <2375c9f91003030058h7456b5e1odc8ca958f5af2c0d@mail.gmail.com>
On Wed, Mar 3, 2010 at 4:58 PM, Américo Wang <xiyou.wangcong@gmail.com> wrote:
> On Mon, Mar 1, 2010 at 5:07 PM, M G Berberich
> <berberic@fmi.uni-passau.de> wrote:
>> Hello,
>>
>> Am Montag, den 01. März schrieb Américo Wang:
>>> On Mon, Mar 1, 2010 at 6:12 AM, M G Berberich
>>> <berberic@fmi.uni-passau.de> wrote:
>>
>>> > I tried to build a 2.6.33 kernel but on boot it dies on modprobe
>>> > (kernel-Oops). This might be the result of faulty config, but I'm
>>> > totaly clueless what's the fault.
>>> >
>>> > The kernel starts up fine and mounts the root-filesystem, but then
>>> > dies on the first modprobe executed. I can boot it with init=/bin/bash
>>> > and get a working bash (until I do modprobe on any module).
>>> >
>>> > System is a Gigabyte M55S-S3 rev 2.0 (nForce 550) with an AMD Athlon64
>>> > X2 5000+ and amd64-kernel architecture. kernel-sources are from
>>> > kernel.org.
>>
>>> It seems something is wrong with forcedeth code or PCI code.
>>> Adding some Cc's.
>>
>> I don't think it's forcedeth. forcedeth just happens to be the first
>> module that get's loaded in startup. It crashes with any other module
>> too (I tried ohci_hcd).
>>
>
> Ok, below is my patch, I am not sure it could fix the BUG for you,
> but it could fix the WARNING. But perhaps they are related.
>
> Please give it a try.
>
Oops! Ignore the patch, it should not be correct, I will send a
correct version soon.
Sorry.
^ permalink raw reply
* Re: [patch] davinci_emac: off by one
From: David Miller @ 2010-03-03 9:08 UTC (permalink / raw)
To: error27; +Cc: netdev, chaithrika, srk, khilman, anantgole, kernel-janitors
In-Reply-To: <20100303070724.GC5086@bicker>
From: Dan Carpenter <error27@gmail.com>
Date: Wed, 3 Mar 2010 10:07:24 +0300
> This off by one error was found by smatch.
>
> drivers/net/davinci_emac.c +2390 emac_dev_open(13) error: buffer overflow 'priv->mac_addr' 6 <= 6
>
> Signed-off-by: Dan Carpenter <error27@gmail.com>
> ---
> I don't have the hardware to test this. If would be cool if someone
> would verify that the hardware still works after the patch is applied.
It looks obvious enough for me, taking in more than 6 address
bytes make no sense in an ethernet driver, so I'll apply this.
Thanks.
^ permalink raw reply
* Re: [patch] cassini: fix off by one
From: David Miller @ 2010-03-03 9:07 UTC (permalink / raw)
To: error27
Cc: netdev, adobriyan, akpm, yanghy, kaber, linux-kernel,
kernel-janitors
In-Reply-To: <20100303082241.GA32640@bicker>
From: Dan Carpenter <error27@gmail.com>
Date: Wed, 3 Mar 2010 11:22:41 +0300
> There are only 6 link_modes.
>
> Signed-off-by: Dan Carpenter <error27@gmail.com>
Applied.
^ 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