* Re: [PATCH] Merge __load_pointer() and load_pointer() in net/core/filter.c; kernel 2.6.14
From: Herbert Xu @ 2005-11-03 1:50 UTC (permalink / raw)
To: Kris Katterjohn; +Cc: jschlst, torvalds, linux-kernel, davem, acme, netdev
In-Reply-To: <e626300280b94e0abc26defcc6043b91.kjak@ispwest.com>
Kris Katterjohn <kjak@ispwest.com> wrote:
> Another patch for net/core/filter.c by me. I merged __load_pointer() into
> load_pointer(). I don't see a point in having two seperate functions when
> both functions are really small and load_pointer() calls __load_pointer().
> Renamed the variable "k" to "offset" since that's what it is, and in
> skb_header_pointer() it's "offset".
>
> This patch is a diff from kernel 2.6.14
This code path is performance-critical so you should benchmark your
changes.
In this particular case, __load_pointer is the unlikely case and
therefore it wasn't inlined.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] Merge __load_pointer() and load_pointer() in net/core/filter.c; kernel 2.6.14
From: Kris Katterjohn @ 2005-11-03 2:13 UTC (permalink / raw)
To: Herbert Xu; +Cc: jschlst, torvalds, linux-kernel, davem, acme, netdev
I wasn't actually changing it to add performance, but to make the code look
cleaner. The new load_pointer() is virtually the same as having the seperate
functions that are currently there, but the code, I think, is "better looking".
If you look at the current net/core/filter.c and then my patched version, the
steps are done in the exact same order and same way, but all in that one
function.
That may sound silly, but I just kept looking at it and asking myself, "Why?"
Of course, one way may still out-perform the other.
Thanks
----- Original Message -----
From: Herbert Xu [mailto:herbert@gondor.apana.org.au]
Sent: 11/2/2005 5:50:29 PM
To: kjak@users.sourceforge.net
Cc: jschlst@samba.org; torvalds@osdl.org; linux-kernel@vger.kernel.org; davem@davemloft.net; acme@ghostprotocols.net; netdev@vger.kernel.org
Subject: Re: [PATCH] Merge __load_pointer() and load_pointer() in net/core/filter.c; kernel 2.6.14
> Kris Katterjohn <kjak@ispwest.com> wrote:
> > Another patch for net/core/filter.c by me. I merged __load_pointer() into
> > load_pointer(). I don't see a point in having two seperate functions when
> > both functions are really small and load_pointer() calls __load_pointer().
> > Renamed the variable "k" to "offset" since that's what it is, and in
> > skb_header_pointer() it's "offset".
> >
> > This patch is a diff from kernel 2.6.14
>
> This code path is performance-critical so you should benchmark your
> changes.
>
> In this particular case, __load_pointer is the unlikely case and
> therefore it wasn't inlined.
>
> Cheers,
> --
> Visit Openswan at http://www.openswan.org/
> Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] Merge __load_pointer() and load_pointer() in net/core/filter.c; kernel 2.6.14
From: Herbert Xu @ 2005-11-03 2:30 UTC (permalink / raw)
To: Kris Katterjohn
Cc: herbert, jschlst, torvalds, linux-kernel, davem, acme, netdev
In-Reply-To: <310a17ad00f84c389e64ae26656ce1a1.kjak@ispwest.com>
Kris Katterjohn <kjak@ispwest.com> wrote:
> I wasn't actually changing it to add performance, but to make the code look
> cleaner. The new load_pointer() is virtually the same as having the seperate
> functions that are currently there, but the code, I think, is "better looking".
> If you look at the current net/core/filter.c and then my patched version, the
> steps are done in the exact same order and same way, but all in that one
> function.
You've just changed an out-of-line function (__load_pointer) into an
inlined function. There may be a cost to that.
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] Merge __load_pointer() and load_pointer() in net/core/filter.c; kernel 2.6.14
From: Kris Katterjohn @ 2005-11-03 2:48 UTC (permalink / raw)
To: Herbert Xu; +Cc: jschlst, torvalds, linux-kernel, davem, acme, netdev
Forgive me because this is one of my first attempts at anything related to the
kernel, but...
1) How would I go about benchmarking this?
2) If the out-of-line code is executed anyway (since load_pointer() calls __load_pointer()),
would it really effect it very much?
I've been programming as a hobby for a few years, but I never really worried
about inlining my code. Most likely because when I was learning C, I was using
books etc. that were written before C99 was out.
Thanks
----- Original Message -----
From: Herbert Xu [mailto:herbert@gondor.apana.org.au]
Subject: Re: [PATCH] Merge __load_pointer() and load_pointer() in net/core/filter.c; kernel 2.6.14
> Kris Katterjohn <kjak@ispwest.com> wrote:
> > I wasn't actually changing it to add performance, but to make the code look
> > cleaner. The new load_pointer() is virtually the same as having the seperate
> > functions that are currently there, but the code, I think, is "better looking".
> > If you look at the current net/core/filter.c and then my patched version, the
> > steps are done in the exact same order and same way, but all in that one
> > function.
>
> You've just changed an out-of-line function (__load_pointer) into an
> inlined function. There may be a cost to that.
> --
> Visit Openswan at http://www.openswan.org/
> Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PKT_SCHED]: Rework QoS and/or fair queueing configuration
From: Arnaldo Carvalho de Melo @ 2005-11-03 4:25 UTC (permalink / raw)
To: Thomas Graf; +Cc: bunk, jengelh, linux-kernel, netdev
In-Reply-To: <20051101141302.GM23537@postel.suug.ch>
On 11/1/05, Thomas Graf <tgraf@suug.ch> wrote:
>
> Make "QoS and/or fair queueing" have its own menu, it's too big to be
> inlined into "Network options". Remove the obsolete NET_QOS option.
> Automatically select NET_CLS if needed. Do the same for NET_ESTIMATOR
> but allow it to be selected manually for statistical purposes. Add
> comments to separate queueing from classification. Fix dependencies
> and ordering of classifiers. Improve descriptions/help texts and
> remove outdated pieces.
>
> Signed-off-by: Thomas Graf <tgraf@suug.ch>
Thanks, applied.
^ permalink raw reply
* Re: [PATCH][MCAST]IPv6: small fix for ip6_mc_msfilter(...)
From: Willy Tarreau @ 2005-11-03 5:02 UTC (permalink / raw)
To: Marcelo Tosatti
Cc: David Stevens, David S. Miller, linux-kernel, netdev, Yan Zheng
In-Reply-To: <20051102205926.GB5078@logos.cnet>
On Wed, Nov 02, 2005 at 06:59:26PM -0200, Marcelo Tosatti wrote:
> On Wed, Nov 02, 2005 at 09:42:37AM -0800, David Stevens wrote:
> > Willy Tarreau <willy@w.ods.org> wrote on 11/02/2005 01:29:59 AM:
> >
> > > Marcelo, David, does this backport seem appropriate for 2.4.32 ? I
> > verified
> > > that it compiles, nothing more.
> >
> > Yes.
> >
> > > If it's OK, I've noticed another patch that
> > > Yan posted today and which might be of interest before a very solid
> > release.
> >
> > I think they should be reviewed first. :-)
>
> Alright, then let it be tested in v2.6 first. Willy, can you queue for
> 2.4.33-pre ?
OK.
Willy
^ permalink raw reply
* Re: [PATCH]dgrs - Fixes Warnings when CONFIG_ISA and CONFIG_PCI are not enabled
From: Ashutosh Naik @ 2005-11-03 5:39 UTC (permalink / raw)
To: Richard Knutsson
Cc: netdev, davej, acme, linux-net, akpm, linux-kernel, stable
In-Reply-To: <436927CA.3090105@student.ltu.se>
On 11/3/05, Richard Knutsson <ricknu-0@student.ltu.se> wrote:
> >
> >
> >>>This patch fixes compiler warnings when CONFIG_ISA and CONFIG_PCI are
> >>>not enabled in the dgrc network driver.
> >>>
> >>>Signed-off-by: Ashutosh Naik <ashutosh.naik@gmail.com>
> >>>
> >>>--
> >>>diff -Naurp linux-2.6.14/drivers/net/dgrs.c
> >>>linux-2.6.14-git1/drivers/net/dgrs.c---
> >>>linux-2.6.14/drivers/net/dgrs.c 2005-10-28 05:32:08.000000000
> >>>+0530
> >>>+++ linux-2.6.14-git1/drivers/net/dgrs.c 2005-11-01
> >>>10:30:03.000000000 +0530
> >>>@@ -1549,8 +1549,12 @@ MODULE_PARM_DESC(nicmode, "Digi RightSwi
> >>>static int __init dgrs_init_module (void) {
> >>> int i;
> >>>- int eisacount = 0, pcicount = 0;
> >>>-
> >>>+#ifdef CONFIG_EISA
> >>>+ int eisacount = 0;
> >>>+#endif
> >>>+#ifdef CONFIG_PCI
> >>>+ int pcicount = 0;
> >>>+#endif
> >>> /*
> >>> * Command line variable overrides
> >>> * debug=NNN
> >>>-
> >>>
> >>>
>
> >>Signed-off-by: Richard Knutsson <ricknu-0@student.ltu.se>
> >>
> >>---
> >>
> >>diff -uNr a/drivers/net/dgrs.c b/drivers/net/dgrs.c
> >>--- a/drivers/net/dgrs.c 2005-08-29 01:41:01.000000000 +0200
> >>+++ b/drivers/net/dgrs.c 2005-10-26 15:53:43.000000000 +0200
> >>@@ -1549,7 +1549,7 @@
> >> static int __init dgrs_init_module (void)
> >> {
> >> int i;
> >>- int eisacount = 0, pcicount = 0;
> >>+ int count;
> >>
> >> /*
> >> * Command line variable overrides
> >>@@ -1591,14 +1591,14 @@
> >> * Find and configure all the cards
> >> */
> >> #ifdef CONFIG_EISA
> >>- eisacount = eisa_driver_register(&dgrs_eisa_driver);
> >>- if (eisacount < 0)
> >>- return eisacount;
> >>+ count = eisa_driver_register(&dgrs_eisa_driver);
> >>+ if (count < 0)
> >>+ return count;
> >> #endif
> >> #ifdef CONFIG_PCI
> >>- pcicount = pci_register_driver(&dgrs_pci_driver);
> >>- if (pcicount)
> >>- return pcicount;
> >>+ count = pci_register_driver(&dgrs_pci_driver);
> >>+ if (count)
> >>+ return count;
> >> #endif
> >> return 0;
> >> }
> >>
> >>
> >
> >Well, both of them do the same stuff, but one of these patches needs
> >to be committed.
> >
> >Cheers
> >Ashutosh
> >
> >
> Can both CONFIG_PCI and CONFIG_EISA be undefined at the same time? If
> so, I think you patch is better.
> But on line 1015 in the dgrs.c-file (function dgrs_download()) there is
> an if-statement:
> if (priv0->plxreg)
> { /* PCI bus */
> ...
> }
> else
> { /* EISA bus */
> ...
> from where I got the idea it needs either pci or eisa (or both). If this
> is true, I vote for my patch.
Both CONFIG_PCI and CONFIG_EISA cant be undefined at the same time,
because the device has to be on either of the 2 busses. I think your
patch is better in that case.
Cheers
Ashutosh
^ permalink raw reply
* Re: [PATCH] Merge __load_pointer() and load_pointer() in net/core/filter.c; kernel 2.6.14
From: Kris Katterjohn @ 2005-11-03 6:19 UTC (permalink / raw)
To: Mitchell Blank Jr; +Cc: Herbert Xu, jschlst, davem, acme, netdev, linux-kernel
> From: Mitchell Blank Jr
> Cc:
> herbert@gondor.apana.org.au;jschlst@samba.org;davem@davemloft.net;
> acme@ghostprotocols.net;netdev@vger.kernel.org
>
> > (I trimmed the cc: list a bit; no need for this to be on LKML in my opinion)
> >
> > Kris Katterjohn wrote:
> > > Forgive me because this is one of my first attempts at anything related to the
> > > kernel, but...
> > >
> > > 1) How would I go about benchmarking this?
> >
> > The first thing to do is run "size net/core/filter.o" before and after and
> > see if your change makes the "text" section larger.
> >
> > The risk of putting more stuff into the inlined function is just that
> > the rarely-executed path will end up duplicated in a bunch of places, bloating
> > the generated code. It's hard to directly benchmark the effects of this but
> > it will generally make the fast-path code less compact in the L1 I-cache
> > which (if you do it enough) slows everything down. Thats one reason why
> > kernel developers try to keep a close eye on bloat.
> >
> > -Mitch
>
> Before patch:
>
> text data bss dec hex filename
> 2399 0 0 2399 95f x/net/core/filter.o
>
> After patch:
>
> text data bss dec hex filename
> 2589 0 0 2589 a1d y/net/core/filter.o
>
> After patch without inlining the function:
>
> text data bss dec hex filename
> 2127 0 0 2127 84f y/net/core/filter.o
>
>
> So I guess use my patch and take "inline" off? What do you think?
>
>
> Thanks
>
Here's the new patch. It's the same as the first one, just with "inline" removed.
Maybe "static" should be removed, too? Oh well.
---
--- x/net/core/filter.c 2005-10-27 19:02:08.000000000 -0500
+++ y/net/core/filter.c 2005-11-03 00:05:42.000000000 -0600
@@ -13,6 +13,8 @@
* 2 of the License, or (at your option) any later version.
*
* Andi Kleen - Fix a few bad bugs and races.
+ * Kris Katterjohn - Merged __load_pointer() into load_pointer() and
+ * cleaned it up a little bit - 2005-11-01
*/
#include <linux/module.h>
@@ -35,31 +37,27 @@
#include <asm/uaccess.h>
#include <linux/filter.h>
-/* No hurry in this branch */
-static void *__load_pointer(struct sk_buff *skb, int k)
+static void *load_pointer(struct sk_buff *skb, int offset,
+ unsigned int size, void *buffer)
{
u8 *ptr = NULL;
- if (k >= SKF_NET_OFF)
- ptr = skb->nh.raw + k - SKF_NET_OFF;
- else if (k >= SKF_LL_OFF)
- ptr = skb->mac.raw + k - SKF_LL_OFF;
+ if (offset >= 0)
+ return skb_header_pointer(skb, offset, size, buffer);
+
+ if (offset >= SKF_AD_OFF)
+ return NULL;
+
+ if (offset >= SKF_NET_OFF)
+ ptr = skb->nh.raw + offset - SKF_NET_OFF;
+
+ else if (offset >= SKF_LL_OFF)
+ ptr = skb->mac.raw + offset - SKF_LL_OFF;
if (ptr >= skb->head && ptr < skb->tail)
return ptr;
- return NULL;
-}
-static inline void *load_pointer(struct sk_buff *skb, int k,
- unsigned int size, void *buffer)
-{
- if (k >= 0)
- return skb_header_pointer(skb, k, size, buffer);
- else {
- if (k >= SKF_AD_OFF)
- return NULL;
- return __load_pointer(skb, k);
- }
+ return NULL;
}
/**
^ permalink raw reply
* Re: Re: [PATCH] Merge __load_pointer() and load_pointer() in net/core/filter.c; kernel 2.6.14
From: Kris Katterjohn @ 2005-11-03 6:54 UTC (permalink / raw)
To: Mitchell Blank Jr; +Cc: Herbert Xu, jschlst, davem, acme, netdev, linux-kernel
> > > From: Mitchell Blank Jr
> > > > (I trimmed the cc: list a bit; no need for this to be on LKML in my opinion)
>
> I see you just added it back. Oh well.
When I emailed (CC:) Herbert Xu (who emailed about this earlier), I got an email
back that said it couldn't send to him. So, I just added linux-kernel back so
he'd see it if he's interested at all.
> > > So I guess use my patch and take "inline" off? What do you think?
>
> Well the original author presumably thought that the fast-path of
> load_pointer() was critical enough to keep inline (since it can be run many
> times per packet) So they made the deliberate choice of separating it
> into two functions - one inline, one non-inline.
>
> So my personal feeling is that the code is probably fine as it stands today.
It probably is. Doesn't really matter I guess.
> > Maybe "static" should be removed, too? Oh well.
>
> Uh, why? It's clearly a file-local function.
No real reason, just that none of the other functions in filter.c are static.
Thanks
^ permalink raw reply
* Re: [PATCH] Merge __load_pointer() and load_pointer() in net/core/filter.c; kernel 2.6.14
From: Mitchell Blank Jr @ 2005-11-03 6:58 UTC (permalink / raw)
To: Kris Katterjohn; +Cc: Herbert Xu, jschlst, davem, acme, netdev, linux-kernel
In-Reply-To: <5b1bc8f2a7f34523b323fc1b58ef4c26.kjak@ispwest.com>
Kris Katterjohn wrote:
> > From: Mitchell Blank Jr
> > > (I trimmed the cc: list a bit; no need for this to be on LKML in my opinion)
I see you just added it back. Oh well.
> > So I guess use my patch and take "inline" off? What do you think?
Well the original author presumably thought that the fast-path of
load_pointer() was critical enough to keep inline (since it can be run many
times per packet) So they made the deliberate choice of separating it
into two functions - one inline, one non-inline.
So my personal feeling is that the code is probably fine as it stands today.
> Maybe "static" should be removed, too? Oh well.
Uh, why? It's clearly a file-local function.
-Mitch
^ permalink raw reply
* [PATCH 1/2] [NETFILTER] PPTP helper: Fix compilation of conntrack helper without NAT
From: Harald Welte @ 2005-11-03 12:04 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo
Cc: Linux Netdev List, Netfilter Development Mailinglist
[-- Attachment #1: Type: text/plain, Size: 3054 bytes --]
Hi Acme!
Please merge this to both 2.6.15 mainline and 2.6.14.x stable series,
thanks.
[NETFILTER] PPTP helper: Fix compilation of conntrack helper without NAT
This patch fixes compilation of the PPTP conntrack helper when NAT is
configured off.
Signed-off-by: Yasuyuki Kozakai <yasuyuki.kozakai@toshiba.co.jp>
Signed-off-by: Harald Welte <laforge@netfilter.org>
---
commit f6447dcd8a4f13b144c9f49df76682c31562a003
tree e5f7c3a472ba896ee793727fbe4de02f42047d75
parent 928f936ad8e099bd2a84d6e875e1a8c59f55bf7d
author Harald Welte <laforge@hanuman.de.gnumonks.org> Thu, 03 Nov 2005 10:56:16 +0100
committer Harald Welte <laforge@hanuman.de.gnumonks.org> Thu, 03 Nov 2005 10:56:16 +0100
net/ipv4/netfilter/ip_conntrack_helper_pptp.c | 4 ----
net/ipv4/netfilter/ip_nat_helper_pptp.c | 2 ++
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/net/ipv4/netfilter/ip_conntrack_helper_pptp.c b/net/ipv4/netfilter/ip_conntrack_helper_pptp.c
--- a/net/ipv4/netfilter/ip_conntrack_helper_pptp.c
+++ b/net/ipv4/netfilter/ip_conntrack_helper_pptp.c
@@ -270,14 +270,10 @@ exp_gre(struct ip_conntrack *master,
exp_orig->expectfn = pptp_expectfn;
exp_orig->flags = 0;
- exp_orig->dir = IP_CT_DIR_ORIGINAL;
-
/* both expectations are identical apart from tuple */
memcpy(exp_reply, exp_orig, sizeof(*exp_reply));
memcpy(&exp_reply->tuple, &exp_tuples[1], sizeof(exp_reply->tuple));
- exp_reply->dir = !exp_orig->dir;
-
if (ip_nat_pptp_hook_exp_gre)
ret = ip_nat_pptp_hook_exp_gre(exp_orig, exp_reply);
else {
diff --git a/net/ipv4/netfilter/ip_nat_helper_pptp.c b/net/ipv4/netfilter/ip_nat_helper_pptp.c
--- a/net/ipv4/netfilter/ip_nat_helper_pptp.c
+++ b/net/ipv4/netfilter/ip_nat_helper_pptp.c
@@ -216,6 +216,7 @@ pptp_exp_gre(struct ip_conntrack_expect
expect_orig->saved_proto.gre.key = htons(nat_pptp_info->pac_call_id);
expect_orig->tuple.src.u.gre.key = htons(nat_pptp_info->pns_call_id);
expect_orig->tuple.dst.u.gre.key = htons(ct_pptp_info->pac_call_id);
+ expect_orig->dir = IP_CT_DIR_ORIGINAL;
inv_t.src.ip = reply_t->src.ip;
inv_t.dst.ip = reply_t->dst.ip;
inv_t.src.u.gre.key = htons(nat_pptp_info->pac_call_id);
@@ -233,6 +234,7 @@ pptp_exp_gre(struct ip_conntrack_expect
expect_reply->saved_proto.gre.key = htons(nat_pptp_info->pns_call_id);
expect_reply->tuple.src.u.gre.key = htons(nat_pptp_info->pac_call_id);
expect_reply->tuple.dst.u.gre.key = htons(ct_pptp_info->pns_call_id);
+ expect_reply->dir = !exp_orig->dir;
inv_t.src.ip = orig_t->src.ip;
inv_t.dst.ip = orig_t->dst.ip;
inv_t.src.u.gre.key = htons(nat_pptp_info->pns_call_id);
--
- Harald Welte <laforge@netfilter.org> http://netfilter.org/
============================================================================
"Fragmentation is like classful addressing -- an interesting early
architectural error that shows how much experimentation was going
on while IP was being designed." -- Paul Vixie
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH 2/2] [NETFILTER] PPTP helper: Fix endianness bug in GRE key / CallID NAT
From: Harald Welte @ 2005-11-03 12:05 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo
Cc: Linux Netdev List, Netfilter Development Mailinglist
[-- Attachment #1: Type: text/plain, Size: 1860 bytes --]
Hi Acme!
Please merge this to both 2.6.15 mainline and 2.6.14.x stable series,
thanks.
[NETFILTER] PPTP helper: Fix endianness bug in GRE key / CallID NAT
This endianness bug slipped through while changing the 'gre.key' field in the
conntrack tuple from 32bit to 16bit.
None of my tests caught the problem, since the linux pptp client always has
'0' as call id / gre key. Only windows clients actually trigger the bug.
Signed-off-by: Harald Welte <laforge@netfilter.org>
---
commit 66d73ebf14b8bb18647eabca9975d7ceb787cb29
tree b92bab972b99c11ead4ca05d152ab78f741fc41f
parent f6447dcd8a4f13b144c9f49df76682c31562a003
author Harald Welte <laforge@hanuman.de.gnumonks.org> Thu, 03 Nov 2005 12:55:06 +0100
committer Harald Welte <laforge@hanuman.de.gnumonks.org> Thu, 03 Nov 2005 12:55:06 +0100
net/ipv4/netfilter/ip_nat_proto_gre.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/netfilter/ip_nat_proto_gre.c b/net/ipv4/netfilter/ip_nat_proto_gre.c
--- a/net/ipv4/netfilter/ip_nat_proto_gre.c
+++ b/net/ipv4/netfilter/ip_nat_proto_gre.c
@@ -139,8 +139,8 @@ gre_manip_pkt(struct sk_buff **pskb,
break;
case GRE_VERSION_PPTP:
DEBUGP("call_id -> 0x%04x\n",
- ntohl(tuple->dst.u.gre.key));
- pgreh->call_id = htons(ntohl(tuple->dst.u.gre.key));
+ ntohs(tuple->dst.u.gre.key));
+ pgreh->call_id = tuple->dst.u.gre.key;
break;
default:
DEBUGP("can't nat unknown GRE version\n");
--
- Harald Welte <laforge@netfilter.org> http://netfilter.org/
============================================================================
"Fragmentation is like classful addressing -- an interesting early
architectural error that shows how much experimentation was going
on while IP was being designed." -- Paul Vixie
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] [NETFILTER] PPTP helper: Fix compilation of conntrack helper without NAT
From: Harald Welte @ 2005-11-03 13:19 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo, Linux Netdev List,
Netfilter Development Mailinglist
In-Reply-To: <20051103120404.GB4479@sunbeam.de.gnumonks.org>
[-- Attachment #1: Type: text/plain, Size: 707 bytes --]
On Thu, Nov 03, 2005 at 01:04:04PM +0100, Harald Welte wrote:
> Hi Acme!
>
> Please merge this to both 2.6.15 mainline and 2.6.14.x stable series,
> thanks.
*sigh*. this is not my day. Please do _not_ apply this patch number 1.
I'll re-send a replacement.
Patch number '2' is fine and should go in.
Sorry for the mess.
--
- Harald Welte <laforge@netfilter.org> http://netfilter.org/
============================================================================
"Fragmentation is like classful addressing -- an interesting early
architectural error that shows how much experimentation was going
on while IP was being designed." -- Paul Vixie
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH][MCAST]Two fix for implementation of MLDv2 .
From: Yan Zheng @ 2005-11-03 13:26 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel, David Stevens
In-Reply-To: <436878E7.3030303@21cn.com>
You can test change in add_grec(...) by follow codes. without the
change no change to exclude report will be sent.
please adjust IFINDEX and make sure initial state for FF02::2 is idle
===================================================
#include <stdio.h>
#include <unistd.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <sys/socket.h>
#include <sys/types.h>
#define IFINDEX 6
int main(int argc, char argv[])
{
int sockfds[2];
struct ipv6_mreq req;
struct group_filter filter;
struct sockaddr_in6 *psin6;
req.ipv6mr_interface = IFINDEX;
inet_pton(PF_INET6, "FF02::2", &req.ipv6mr_multiaddr);
sockfds[0] = socket(PF_INET6, SOCK_DGRAM, 0);
sockfds[1] = socket(PF_INET6, SOCK_DGRAM, 0);
filter.gf_interface = IFINDEX;
filter.gf_fmode = MCAST_INCLUDE;
filter.gf_numsrc = 1;
psin6 = (struct sockaddr_in6 *)&filter.gf_group;
psin6->sin6_family = AF_INET6;
inet_pton(PF_INET6, "FF02::2", &psin6->sin6_addr);
psin6 = (struct sockaddr_in6 *)&filter.gf_slist[0];
psin6->sin6_family = AF_INET6;
inet_pton(PF_INET6, "2002:de12:1780::1", &psin6->sin6_addr);
setsockopt(sockfds[0], SOL_IPV6, IPV6_ADD_MEMBERSHIP, &req, sizeof(req));
setsockopt(sockfds[0], SOL_IPV6, MCAST_MSFILTER, &filter, sizeof(filter));
sleep(5);
setsockopt(sockfds[1], SOL_IPV6, IPV6_ADD_MEMBERSHIP, &req, sizeof(req));
pause();
return 0;
}
^ permalink raw reply
* Re: [PATCH 1/2] [NETFILTER] PPTP helper: Fix compilation of conntrack helper without NAT
From: Harald Welte @ 2005-11-03 13:27 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo, Linux Netdev List,
Netfilter Development Mailinglist
In-Reply-To: <20051103131917.GJ4479@sunbeam.de.gnumonks.org>
[-- Attachment #1: Type: text/plain, Size: 3000 bytes --]
Ok, here goes the real fix for [1/2]:
[NETFILTER] PPTP helper: Fix compilation of conntrack helper without NAT
This patch fixes compilation of the PPTP conntrack helper when NAT is
configured off.
Signed-off-by: Yasuyuki Kozakai <yasuyuki.kozakai@toshiba.co.jp>
Signed-off-by: Harald Welte <laforge@netfilter.org>
---
commit f6447dcd8a4f13b144c9f49df76682c31562a003
tree e5f7c3a472ba896ee793727fbe4de02f42047d75
parent 928f936ad8e099bd2a84d6e875e1a8c59f55bf7d
author Harald Welte <laforge@hanuman.de.gnumonks.org> Thu, 03 Nov 2005 10:56:16 +0100
committer Harald Welte <laforge@hanuman.de.gnumonks.org> Thu, 03 Nov 2005 10:56:16 +0100
net/ipv4/netfilter/ip_conntrack_helper_pptp.c | 4 ----
net/ipv4/netfilter/ip_nat_helper_pptp.c | 2 ++
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/net/ipv4/netfilter/ip_conntrack_helper_pptp.c b/net/ipv4/netfilter/ip_conntrack_helper_pptp.c
--- a/net/ipv4/netfilter/ip_conntrack_helper_pptp.c
+++ b/net/ipv4/netfilter/ip_conntrack_helper_pptp.c
@@ -270,14 +270,10 @@ exp_gre(struct ip_conntrack *master,
exp_orig->expectfn = pptp_expectfn;
exp_orig->flags = 0;
- exp_orig->dir = IP_CT_DIR_ORIGINAL;
-
/* both expectations are identical apart from tuple */
memcpy(exp_reply, exp_orig, sizeof(*exp_reply));
memcpy(&exp_reply->tuple, &exp_tuples[1], sizeof(exp_reply->tuple));
- exp_reply->dir = !exp_orig->dir;
-
if (ip_nat_pptp_hook_exp_gre)
ret = ip_nat_pptp_hook_exp_gre(exp_orig, exp_reply);
else {
diff --git a/net/ipv4/netfilter/ip_nat_helper_pptp.c b/net/ipv4/netfilter/ip_nat_helper_pptp.c
--- a/net/ipv4/netfilter/ip_nat_helper_pptp.c
+++ b/net/ipv4/netfilter/ip_nat_helper_pptp.c
@@ -216,6 +216,7 @@ pptp_exp_gre(struct ip_conntrack_expect
expect_orig->saved_proto.gre.key = htons(nat_pptp_info->pac_call_id);
expect_orig->tuple.src.u.gre.key = htons(nat_pptp_info->pns_call_id);
expect_orig->tuple.dst.u.gre.key = htons(ct_pptp_info->pac_call_id);
+ expect_orig->dir = IP_CT_DIR_ORIGINAL;
inv_t.src.ip = reply_t->src.ip;
inv_t.dst.ip = reply_t->dst.ip;
inv_t.src.u.gre.key = htons(nat_pptp_info->pac_call_id);
@@ -233,6 +234,7 @@ pptp_exp_gre(struct ip_conntrack_expect
expect_reply->saved_proto.gre.key = htons(nat_pptp_info->pns_call_id);
expect_reply->tuple.src.u.gre.key = htons(nat_pptp_info->pac_call_id);
expect_reply->tuple.dst.u.gre.key = htons(ct_pptp_info->pns_call_id);
+ expect_reply->dir = IP_CT_DIR_REPLY;
inv_t.src.ip = orig_t->src.ip;
inv_t.dst.ip = orig_t->dst.ip;
inv_t.src.u.gre.key = htons(nat_pptp_info->pns_call_id);
--
- Harald Welte <laforge@netfilter.org> http://netfilter.org/
============================================================================
"Fragmentation is like classful addressing -- an interesting early
architectural error that shows how much experimentation was going
on while IP was being designed." -- Paul Vixie
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Merge __load_pointer() and load_pointer() in net/core/filter.c; kernel 2.6.14
From: Patrick McHardy @ 2005-11-03 16:19 UTC (permalink / raw)
To: Mitchell Blank Jr
Cc: Kris Katterjohn, Herbert Xu, jschlst, davem, acme, netdev,
linux-kernel
In-Reply-To: <20051103065809.GC27232@gaz.sfgoth.com>
Mitchell Blank Jr wrote:
> Kris Katterjohn wrote:
>
>>>So I guess use my patch and take "inline" off? What do you think?
>
> Well the original author presumably thought that the fast-path of
> load_pointer() was critical enough to keep inline (since it can be run many
> times per packet) So they made the deliberate choice of separating it
> into two functions - one inline, one non-inline.
Exactly. __load_pointer is only called rarely, while load_pointer is
called whenever data needs to be read from the packet. It shouldn't
be changed without any justification.
^ permalink raw reply
* Re: [PATCH] Merge __load_pointer() and load_pointer() in net/core/filter.c;kernel 2.6.14
From: Kris Katterjohn @ 2005-11-03 18:13 UTC (permalink / raw)
To: Mitchell Blank Jr, Patrick McHardy
Cc: Herbert Xu, jschlst, davem, acme, netdev, linux-kernel
From: Patrick McHardy
> Mitchell Blank Jr wrote:
> > Well the original author presumably thought that the fast-path of
> > load_pointer() was critical enough to keep inline (since it can be run many
> > times per packet) So they made the deliberate choice of separating it
> > into two functions - one inline, one non-inline.
>
> Exactly. __load_pointer is only called rarely, while load_pointer is
> called whenever data needs to be read from the packet. It shouldn't
> be changed without any justification.
That's a good enough answer for me!
Thanks
^ permalink raw reply
* [PATCH] /drivers/net/dgrs.c - Fixes Warnings when CONFIG_EISA or CONFIG_PCI are not enabled
From: Richard Knutsson @ 2005-11-03 23:13 UTC (permalink / raw)
To: Ashutosh Naik
Cc: netdev, davej, acme, linux-net, akpm, linux-kernel, stable,
trivial
In-Reply-To: <c216304e0511022139j70614ae3l3a96767c0a36358e@mail.gmail.com>
>>>>>This patch fixes compiler warnings when CONFIG_ISA and CONFIG_PCI are
>>>>>not enabled in the dgrc network driver.
>>>>>
>>>>>Signed-off-by: Ashutosh Naik <ashutosh.naik@gmail.com>
>>>>>
>>>>>--
>>>>>diff -Naurp linux-2.6.14/drivers/net/dgrs.c
>>>>>linux-2.6.14-git1/drivers/net/dgrs.c---
>>>>>linux-2.6.14/drivers/net/dgrs.c 2005-10-28 05:32:08.000000000
>>>>>+0530
>>>>>+++ linux-2.6.14-git1/drivers/net/dgrs.c 2005-11-01
>>>>>10:30:03.000000000 +0530
>>>>>@@ -1549,8 +1549,12 @@ MODULE_PARM_DESC(nicmode, "Digi RightSwi
>>>>>static int __init dgrs_init_module (void) {
>>>>> int i;
>>>>>- int eisacount = 0, pcicount = 0;
>>>>>-
>>>>>+#ifdef CONFIG_EISA
>>>>>+ int eisacount = 0;
>>>>>+#endif
>>>>>+#ifdef CONFIG_PCI
>>>>>+ int pcicount = 0;
>>>>>+#endif
>>>>> /*
>>>>> * Command line variable overrides
>>>>> * debug=NNN
>>>>>
>>>>>
>
>Both CONFIG_PCI and CONFIG_EISA cant be undefined at the same time,
>because the device has to be on either of the 2 busses. I think your
>patch is better in that case.
>
>Cheers
>Ashutosh
>
>
OK, then I send in the patch again. Thanks for your help/opinion.
Till the next time...
/Richard
<-- snip -->
This patch fixes compiler warnings when CONFIG_ISA or CONFIG_PCI are not enabled in the dgrc network driver.
Cleanly patched to 2.6.14-git6.
Signed-off-by: Richard Knutsson <ricknu-0@student.ltu.se>
---
diff -Nurp a/drivers/net/dgrs.c b/drivers/net/dgrs.c
--- a/drivers/net/dgrs.c 2005-10-28 02:02:08.000000000 +0200
+++ b/drivers/net/dgrs.c 2005-11-02 10:19:43.000000000 +0100
@@ -1549,7 +1549,7 @@ MODULE_PARM_DESC(nicmode, "Digi RightSwi
static int __init dgrs_init_module (void)
{
int i;
- int eisacount = 0, pcicount = 0;
+ int count;
/*
* Command line variable overrides
@@ -1591,14 +1591,14 @@ static int __init dgrs_init_module (void
* Find and configure all the cards
*/
#ifdef CONFIG_EISA
- eisacount = eisa_driver_register(&dgrs_eisa_driver);
- if (eisacount < 0)
- return eisacount;
+ count = eisa_driver_register(&dgrs_eisa_driver);
+ if (count < 0)
+ return count;
#endif
#ifdef CONFIG_PCI
- pcicount = pci_register_driver(&dgrs_pci_driver);
- if (pcicount)
- return pcicount;
+ count = pci_register_driver(&dgrs_pci_driver);
+ if (count)
+ return count;
#endif
return 0;
}
^ permalink raw reply
* Bug#337089: linux-image-2.6.14-1-powerpc: add CONFIG_TCP_CONG_BIC=y
From: Horms @ 2005-11-04 3:27 UTC (permalink / raw)
To: Benoît Dejean, 337089; +Cc: NetDev
In-Reply-To: <20051102162451.0002CF64E@ibook.free.fr>
On Wed, Nov 02, 2005 at 05:24:50PM +0100, Benoît Dejean wrote:
> Package: linux-image-2.6.14-1-powerpc
> Version: 2.6.14-1
> Severity: normal
>
> Hi,
> Linux < 2.6.14 used to have every TCP congestion algorithms as builtins but
> NewReno + BIC was default.
>
> Linux 2.6.14 has splitted these features into modules. But default remains
> NewReno + BIC accordint to CONFIG_TCP_CONG_ADVANCED help message :
>
> "Nearly all users can safely say no here, and a safe default selection will
> be made (BIC-TCP with new Reno as a fallback)."
>
> And indeed NewReno+BIC is a good and safe default. Much better than NewReno
>
> But Debian .config has CONFIG_TCP_CONG_BIC=m (CONFIG_TCP_CONG_*=m) which
> makes NewReno default. So this is like a "regression". I'd like debian kernel
> to have CONFIG_TCP_CONG_BIC=y provided that one can easily switch to another
> algorithm (using /proc/sys/net/ipv4/tcp_congestion_control).
Hi Netdev,
could someone please comment on what a good default congestion
algorithm setup for distribution kernels is?
Thanks
--
Horms
^ permalink raw reply
* Re: ancient ieee80211/ipw2200 drivers in recent kernel (2.6.14)
From: Horms @ 2005-11-04 3:29 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: Mikhail Gusarov, debian-kernel, NetDev
In-Reply-To: <20051102162620.GA32696@infradead.org>
On Wed, Nov 02, 2005 at 04:26:21PM +0000, Christoph Hellwig wrote:
> On Wed, Nov 02, 2005 at 12:54:09PM +0600, Mikhail Gusarov wrote:
> > So, having in mind the two levels of 'stablenesss': kernel
> > 'stableness' and modules 'stableness' :) we should find the way to
> > exclude discussed modules from the build, because in-kernel versions
> > will always be, erm..., slightly (1.0.0 is mentioned only as 'stone
> > age' in the mailing list of ipw2200 developers) outdated due to fact
> > integration and testing gets some time in upstream kernels. I propose
> > just to disable compilation of this drivers: everyone will be able to
> > compile the recent version using ipw2200-source we provide.
>
> The kernel drivers aren't stable but obsolete. Because of that ever
> distribution that supports it's users must patch in a more recent one,
> which is what we should do for debian aswell.
>
> It's a pity the braindead Intel policies don't allow us to have an uptodate
> driver in mainline.
Christoph,
do I take that comment to mean that upstream can't update the
drivers but Debian can? And if so, do you recommend updating
Debian's kernel packages, or putting the updates elsewhere?
--
Horms
^ permalink raw reply
* Re: [PATCH][MCAST]Two fix for implementation of MLDv2 .
From: David Stevens @ 2005-11-04 4:30 UTC (permalink / raw)
To: Yan Zheng; +Cc: linux-kernel, netdev
In-Reply-To: <7e77d27c0511030526g45d8f6e6l@mail.gmail.com>
Yan,
I'm looking at this one. My original interpretation was that a
group and source specific query should only be answered if the source
were explicitly listed (which is what the code does), but I see your
point.
A general or group-specific query should still be answered with the
existing code, and the unsolicited reports will also include the EXCLUDE
records for that group, so I'm not aware of any actual circumstances
where a multicast router wouldn't forward. But maybe you have such
a case. An administrator-initiated query, however, would certainly be
misleading to the administrator in the example you provided, and so
far I tend to agree that there should be a record in the report.
However, I'm not sure your solution is appropriate since it
appears to include EXCLUDE records in cases where they aren't
needed.
So, I'll look at this more carefully and see if I still agree
it needs a fix and whether or not your patch, or some alternative
method might be more appropriate. But it'll probably be sometime
next week before I'll be done reviewing/considering alternatives on
this one.
+-DLS
^ permalink raw reply
* Re: [PATCH][MCAST]Two fix for implementation of MLDv2 .
From: Yan Zheng @ 2005-11-04 6:19 UTC (permalink / raw)
To: David Stevens; +Cc: linux-kernel, netdev
In-Reply-To: <OF70243A3E.F658C3A4-ON882570AF.001699E7-882570AF.0018C8DB@us.ibm.com>
> So, I'll look at this more carefully and see if I still agree
> it needs a fix and whether or not your patch, or some alternative
> method might be more appropriate. But it'll probably be sometime
> next week before I'll be done reviewing/considering alternatives on
> this one.
>
> +-DLS
>
>
I am sorry, I can't understand your opinion completely.
Please forgive my poor english :-)
Here is my opinion:
I think Multicast Address and Source Specific Query is sent only when
router want to block traffic from some source. So when the filter
mode is exclude, node should send a report which includes a
MODE_IS_INCLUDE Record with sources in the query but NOT in the
filter's source list. This is the required behaviour in rfc3810, but
it need addiction item in struct ifmcaddr6 to record sources in the
query. So I think make process Multicast Address Specific Query and
Multicast Address and Source Specific Query no difference is a
temporary fix.
the secoend change in is_in(...) is because I think include/exclude
counts also should be checked when type is MLD2_MODE_IS_INCLUDE or
MLD2_MODE_IS_EXCLUDE.
Regards
Here is my modify version is_in(...)
-----------------------------------------------------------------------------------------------
static int is_in(struct ifmcaddr6 *pmc, struct ip6_sf_list *psf, int type,
int gdeleted, int sdeleted)
{
switch (type) {
case MLD2_MODE_IS_INCLUDE:
case MLD2_CHANGE_TO_INCLUDE:
if (gdeleted || sdeleted)
return 0;
if (psf->sf_count[MCAST_INCLUDE] == 0)
return 0; // maybe never happen
if (type == MLD2_CHANGE_TO_INCLUDE)
return 1;
return !((pmc->mca_flags & MAF_GSQUERY) && !psf->sf_gsresp);
case MLD2_MODE_IS_EXCLUDE:
case MLD2_CHANGE_TO_EXCLUDE:
if (gdeleted || sdeleted)
return 0;
if (pmc->mca_sfcount[MCAST_EXCLUDE] == 0 ||
psf->sf_count[MCAST_INCLUDE])
return 0;
return pmc->mca_sfcount[MCAST_EXCLUDE] ==
psf->sf_count[MCAST_EXCLUDE];
case MLD2_ALLOW_NEW_SOURCES:
if (gdeleted || !psf->sf_crcount)
return 0;
return (pmc->mca_sfmode == MCAST_INCLUDE) ^ sdeleted;
case MLD2_BLOCK_OLD_SOURCES:
if (pmc->mca_sfmode == MCAST_INCLUDE)
return gdeleted || (psf->sf_crcount && sdeleted);
return psf->sf_crcount && !gdeleted && !sdeleted;
}
return 0;
}
^ permalink raw reply
* Bug#337089: linux-image-2.6.14-1-powerpc: add CONFIG_TCP_CONG_BIC=y
From: Ian McDonald @ 2005-11-04 18:24 UTC (permalink / raw)
To: Horms; +Cc: Benoît Dejean, 337089, NetDev
In-Reply-To: <20051104032726.GD4708@verge.net.au>
> > But Debian .config has CONFIG_TCP_CONG_BIC=m (CONFIG_TCP_CONG_*=m) which
> > makes NewReno default. So this is like a "regression". I'd like debian kernel
> > to have CONFIG_TCP_CONG_BIC=y provided that one can easily switch to another
> > algorithm (using /proc/sys/net/ipv4/tcp_congestion_control).
>
> could someone please comment on what a good default congestion
> algorithm setup for distribution kernels is?
>
If you want BIC as default then do as suggested here. My personal
opinion is that is the correct thing to do for a standard
distribution.
If it is an experimental distribution then turn on tcp advanced
congestion control and build the rest (except for BIC) as modules.
Ian
--
Ian McDonald
http://wand.net.nz/~iam4
WAND Network Research Group
University of Waikato
New Zealand
^ permalink raw reply
* [PATCH] [IPV4] Fix secondary IP addresses after promotion
From: Brian Pomerantz @ 2005-11-04 18:46 UTC (permalink / raw)
To: netdev; +Cc: davem, kuznet, pekkas, jmorris, yoshfuji, kaber, linux-kernel
When 3 or more IP addresses in the same subnet exist on a device and the
first one is removed, only the promoted IP address can be reached. Just
after promotion of the next IP address, this fix spins through any more
IP addresses on the interface and sends a NETDEV_UP notification for
that address. This repopulates the FIB with the proper route
information.
Signed-off-by: Brian Pomerantz <bapper@piratehaven.org>
---
net/ipv4/devinet.c | 10 ++++++++--
1 files changed, 8 insertions(+), 2 deletions(-)
applies-to: 9bbb209cab841f700162a96e158dfa3ecd361f46
489d4e25469c8329451aca3e91c8e1929e6ecf63
diff --git a/net/ipv4/devinet.c b/net/ipv4/devinet.c
index 4ec4b2c..72d6c93 100644
--- a/net/ipv4/devinet.c
+++ b/net/ipv4/devinet.c
@@ -235,6 +235,7 @@ static void inet_del_ifa(struct in_devic
{
struct in_ifaddr *promote = NULL;
struct in_ifaddr *ifa1 = *ifap;
+ struct in_ifaddr *ifa;
ASSERT_RTNL();
@@ -243,7 +244,6 @@ static void inet_del_ifa(struct in_devic
**/
if (!(ifa1->ifa_flags & IFA_F_SECONDARY)) {
- struct in_ifaddr *ifa;
struct in_ifaddr **ifap1 = &ifa1->ifa_next;
while ((ifa = *ifap1) != NULL) {
@@ -294,7 +294,13 @@ static void inet_del_ifa(struct in_devic
/* not sure if we should send a delete notify first? */
promote->ifa_flags &= ~IFA_F_SECONDARY;
rtmsg_ifa(RTM_NEWADDR, promote);
- notifier_call_chain(&inetaddr_chain, NETDEV_UP, promote);
+
+ /* update fib in the rest of this address list */
+ ifa = promote;
+ while (ifa != NULL) {
+ notifier_call_chain(&inetaddr_chain, NETDEV_UP, ifa);
+ ifa = ifa->ifa_next;
+ }
}
}
---
0.99.9.GIT
^ permalink raw reply related
* Re: [PATCH] ibmveth fix panic in initial replenish cycle
From: John W. Linville @ 2005-11-04 22:23 UTC (permalink / raw)
To: Santiago Leon; +Cc: Linus Torvalds, netdev, lkml, Jeff Garzik
In-Reply-To: <20051101175617.25145.73324.sendpatchset@ltcml8p7.rchland.ibm.com>
On Tue, Nov 01, 2005 at 02:15:09PM -0500, Santiago Leon wrote:
> This patch fixes a panic in the current tree caused by a race condition between the initial replenish cycle and the rx processing of the first packets trying to replenish the buffers.
Please restrain your line widths to less than 80 characters. 72 is
a nice number IMHO.
Thanks,
John
--
John W. Linville
linville@tuxdriver.com
^ 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