* Re: [net-2.6 PATCH] af_packet: move strict addr_len check right before dev_[mc/unicast]_[add/del]
From: Jiri Pirko @ 2010-03-03 9:05 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
tcpdump-workers-YE1jQ5a0g24KACXWX4p+q9i2O/JbrIOy,
proski-mXXj517/zsQ, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20100303064001.GB2648-YzwxZg+R7et1/kRsl7OVgNvLeJWuRmrY@public.gmane.org>
Wed, Mar 03, 2010 at 07:40:01AM CET, jpirko-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org wrote:
>Subject: [net-2.6 PATCH] af_packet: move strict addr_len check right before dev_[mc/unicast]_[add/del]
Dave please apply this against net-next-2.6. I see that 914c8ad2d18b is still not in
net-2.6.
Thanks a lot
Jirka
>
>My previous patch 914c8ad2d18b62ad1420f518c0cab0b0b90ab308 incorrectly changed
>the length check in packet_mc_add to be more strict. The problem is that
>userspace is not filling this field (and it stays zeroed) in case of setting
>PACKET_MR_PROMISC or PACKET_MR_ALLMULTI. So move the strict check to the point
>in path where the addr_len must be set correctly.
>
>Signed-off-by: Jiri Pirko <jpirko-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>
>diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
>index 031a5e6..1612d41 100644
>--- a/net/packet/af_packet.c
>+++ b/net/packet/af_packet.c
>@@ -1688,6 +1688,8 @@ static int packet_dev_mc(struct net_device *dev, struct packet_mclist *i,
> {
> switch (i->type) {
> case PACKET_MR_MULTICAST:
>+ if (i->alen != dev->addr_len)
>+ return -EINVAL;
> if (what > 0)
> return dev_mc_add(dev, i->addr, i->alen, 0);
> else
>@@ -1700,6 +1702,8 @@ static int packet_dev_mc(struct net_device *dev, struct packet_mclist *i,
> return dev_set_allmulti(dev, what);
> break;
> case PACKET_MR_UNICAST:
>+ if (i->alen != dev->addr_len)
>+ return -EINVAL;
> if (what > 0)
> return dev_unicast_add(dev, i->addr);
> else
>@@ -1734,7 +1738,7 @@ static int packet_mc_add(struct sock *sk, struct packet_mreq_max *mreq)
> goto done;
>
> err = -EINVAL;
>- if (mreq->mr_alen != dev->addr_len)
>+ if (mreq->mr_alen > dev->addr_len)
> goto done;
>
> err = -ENOBUFS;
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [net-2.6 PATCH] af_packet: move strict addr_len check right before dev_[mc/unicast]_[add/del]
From: David Miller @ 2010-03-03 9:06 UTC (permalink / raw)
To: jpirko-H+wXaHxf7aLQT0dZR+AlfA
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
tcpdump-workers-YE1jQ5a0g24KACXWX4p+q9i2O/JbrIOy,
proski-mXXj517/zsQ, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20100303090512.GB2961-YzwxZg+R7evMbnheQZGK0N5OCZ2W11yPFxja6HXR22MAvxtiuMwx3w@public.gmane.org>
From: Jiri Pirko <jpirko-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Date: Wed, 3 Mar 2010 10:05:13 +0100
> Wed, Mar 03, 2010 at 07:40:01AM CET, jpirko-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org wrote:
>>Subject: [net-2.6 PATCH] af_packet: move strict addr_len check right before dev_[mc/unicast]_[add/del]
>
> Dave please apply this against net-next-2.6. I see that 914c8ad2d18b is still not in
> net-2.6.
Would you relax?
I just rebased net-2.6 and net-next-2.6 after Linus took in my
changes and I just applied your regression fix to my tree and
was about to let you know I applied it.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [net-2.6 PATCH] af_packet: move strict addr_len check right before dev_[mc/unicast]_[add/del]
From: David Miller @ 2010-03-03 9:06 UTC (permalink / raw)
To: jpirko-H+wXaHxf7aLQT0dZR+AlfA
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
tcpdump-workers-YE1jQ5a0g24KACXWX4p+q9i2O/JbrIOy,
proski-mXXj517/zsQ
In-Reply-To: <20100303064001.GB2648-YzwxZg+R7et1/kRsl7OVgNvLeJWuRmrY@public.gmane.org>
From: Jiri Pirko <jpirko-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Date: Wed, 3 Mar 2010 07:40:01 +0100
> Subject: [net-2.6 PATCH] af_packet: move strict addr_len check right before dev_[mc/unicast]_[add/del]
>
> My previous patch 914c8ad2d18b62ad1420f518c0cab0b0b90ab308 incorrectly changed
> the length check in packet_mc_add to be more strict. The problem is that
> userspace is not filling this field (and it stays zeroed) in case of setting
> PACKET_MR_PROMISC or PACKET_MR_ALLMULTI. So move the strict check to the point
> in path where the addr_len must be set correctly.
>
> Signed-off-by: Jiri Pirko <jpirko-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Applied.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] Bluetooth: Use single_open() for inquiry cache within debugfs
From: David Miller @ 2010-03-03 9:07 UTC (permalink / raw)
To: marcel; +Cc: netdev
In-Reply-To: <1267580903-30946-1-git-send-email-marcel@holtmann.org>
From: Marcel Holtmann <marcel@holtmann.org>
Date: Tue, 2 Mar 2010 17:48:23 -0800
> The inquiry cache information in debugfs should be using seq_file support
> and not allocating memory on the stack for the string. Since the usage of
> these information is really seldom, using single_open() for it is good
> enough.
>
> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Applied, thanks Marcel.
I guess we'll never figure out why my patch didn't work ;-)
^ permalink raw reply
* Re: [RFC PATCH]xfrm: fix perpetual bundles
From: David Miller @ 2010-03-03 9:07 UTC (permalink / raw)
To: hadi
Cc: steffen.klassert, herbert, kaber, yoshfuji, nakam, eric.dumazet,
netdev
In-Reply-To: <1267577222.3540.1.camel@bigi>
From: jamal <hadi@cyberus.ca>
Date: Tue, 02 Mar 2010 19:47:02 -0500
>
>> Acked-by: Steffen Klassert <steffen.klassert@secunet.com>
>
> tested - Looks good.
> Acked-by: Jamal Hadi Salim <hadi@cyberus.ca>
Applied and queued up for -stable, thanks everyone.
^ permalink raw reply
* Re: [patch] cpmac: use after free
From: David Miller @ 2010-03-03 9:07 UTC (permalink / raw)
To: jpirko; +Cc: error27, netdev, florian, ralf, weil, kernel-janitors
In-Reply-To: <20100303085957.GA2961@psychotron.lab.eng.brq.redhat.com>
From: Jiri Pirko <jpirko@redhat.com>
Date: Wed, 3 Mar 2010 09:59:58 +0100
> Wed, Mar 03, 2010 at 09:46:10AM CET, error27@gmail.com wrote:
>>The original code dereferenced "cpmac_mii" after calling
>>"mdiobus_free(cpmac_mii);"
>>
>>Signed-off-by: Dan Carpenter <error27@gmail.com>
>>---
>>Found by a static checker and not tested. Sorry. :/
>>
>>diff --git a/drivers/net/cpmac.c b/drivers/net/cpmac.c
>>index b85c81f..9d48942 100644
>>--- a/drivers/net/cpmac.c
>>+++ b/drivers/net/cpmac.c
>>@@ -1290,8 +1290,8 @@ void __devexit cpmac_exit(void)
>> {
>> platform_driver_unregister(&cpmac_driver);
>> mdiobus_unregister(cpmac_mii);
>>- mdiobus_free(cpmac_mii);
>> iounmap(cpmac_mii->priv);
>>+ mdiobus_free(cpmac_mii);
>> }
>>
>> module_init(cpmac_init);
>
> Looks good. Thanks.
>
> Reviewed-by: Jiri Pirko <jpirko@redhat.com>
Applied.
^ permalink raw reply
* Re: [net-next PATCH] be2net: download NCSI section during firmware update
From: David Miller @ 2010-03-03 9:07 UTC (permalink / raw)
To: sarveshwarb; +Cc: netdev
In-Reply-To: <20100303083718.GA27402@serverengines.com>
From: Sarveshwar Bandi <sarveshwarb@serverengines.com>
Date: Wed, 3 Mar 2010 14:07:28 +0530
> Adding code to update NCSI section while updating firmware on the controller.
> Signed-off-by: Sarveshwar Bandi <sarveshwarb@serverengines.com>
Applied.
^ 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
* 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: 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 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: [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: [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 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: 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 -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: [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: 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
* 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: [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
* 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: [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: [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: [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
* [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
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