* sctp use-uninitialized warning in net-2.6.25
From: Andrew Morton @ 2008-01-16 21:59 UTC (permalink / raw)
To: netdev
net/sctp/sm_statefuns.c: In function 'sctp_sf_do_5_1C_ack':
net/sctp/sm_statefuns.c:484: warning: 'error' may be used uninitialized in this function
It is not obvious that this is a false positive.
^ permalink raw reply
* Re: questions on NAPI processing latency and dropped network packets
From: Jarek Poplawski @ 2008-01-16 22:42 UTC (permalink / raw)
To: Willy Tarreau; +Cc: Herbert Xu, cfriesen, davem, netdev, linux-kernel
In-Reply-To: <20080116200458.GC8953@1wt.eu>
On Wed, Jan 16, 2008 at 09:04:58PM +0100, Willy Tarreau wrote:
...
> you can work with latest release provided that you always have a fallback
> to an earlier one. That way, you don't bet too much on something you don't
> completely control. If it works, it tells you you'll be able to completely
> exploit its new possibilities in next product release, and if it breaks,
> it's easy to issue a fix to get back to earlier, well-tested version.
Of course, this way looks preferable, but sometimes maybe too costly,
especially with some complex systems. Actually, I don't even think
this have to be fully (production ready) implemented or workable.
Probably there would be even enough to maintain some simplified kind
of test checking how current kernel changes could affect such a system,
and how new versions of this system are better, BTW.
Regards,
Jarek P.
^ permalink raw reply
* Re: [RFC][PATCH] Fixing SA/SP dumps on netlink/af_key
From: Herbert Xu @ 2008-01-16 22:58 UTC (permalink / raw)
To: hadi; +Cc: timo.teras, netdev
In-Reply-To: <1200491531.4457.91.camel@localhost>
jamal <hadi@cyberus.ca> wrote:
>
> There are two issues that are inter-mingled in there. The most important
> is pf_key not being robust on dump. The other being the accurracy of
IMHO doing significant work on af_key is a waste of time. It has no
advantages at all over xfrm_user since neither is portable. So we
should discourage people from using af_key wherever possible.
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] ICMP: ICMP_MIB_OUTMSGS increment duplicated
From: Herbert Xu @ 2008-01-16 23:17 UTC (permalink / raw)
To: David Stevens; +Cc: herbert, davem, netdev, wangchen
In-Reply-To: <OF0A9FA609.40104566-ON882573D2.0057C6DA-882573D2.005A0894@us.ibm.com>
David Stevens <dlstevens@us.ibm.com> wrote:
>
> The patch was to support the ICMPMsgStats table. Since none of
> certain
> types of output ICMP messages are generated by the kernel, but are
> required
> by the RFC, counting raw sockets is intentional (and the only way those
> ICMP
> types can be counted at all).
> Raw UDP packets would not be counted either before or after the
> patch,
> but aren't part of the ICMPMsgStats table. Adding those might be
> worthwhile,
> but it isn't quite the hole that the ICMP out stats were, since there is a
> cooked interface for UDP output that counts the common use, at least.
Fair enough. How about moving this code back into icmp.c and just
add a new count call in raw.c? The push pending function is used on
the UDP fast path so the leaner it is the better.
Thanks,
--
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] ICMP: ICMP_MIB_OUTMSGS increment duplicated
From: David Stevens @ 2008-01-17 0:10 UTC (permalink / raw)
To: Herbert Xu; +Cc: davem, herbert, netdev, netdev-owner, wangchen
In-Reply-To: <E1JFHVh-00012A-00@gondolin.me.apana.org.au>
netdev-owner@vger.kernel.org wrote on 01/16/2008 03:17:29 PM:
> Fair enough. How about moving this code back into icmp.c and just
> add a new count call in raw.c? The push pending function is used on
> the UDP fast path so the leaner it is the better.
I started out with it there, but it certainly wasn't
cleaner. You have to peek on the queue, which I didn't
want to do for all the SMP issues that brings in, and
then replicate all the code push_pending_frames does to
get you a protocol header pointer in one buffer, and there
are multiple ways in the raw path to get you there (so the
counter code itself would appear in multiple places).
I don't think the 2 instructions measurably impact
anything in the fast path and that is the earliest common
point for the multiple paths to generate ICMP output where
the header and type are available without replicating code.
So, simplicity is exactly why I put it there, rather than
the "obvious" places at the higher layer. :-) It's probably
the better, single place to put the other protocol "out messages"
counters, too, since those probably also have multiple paths
that end up here, but ICMPMsgStats was all that patch was
after.
+-DLS
^ permalink raw reply
* Re: [PATCH] ICMP: ICMP_MIB_OUTMSGS increment duplicated
From: Wang Chen @ 2008-01-17 0:55 UTC (permalink / raw)
To: David Stevens; +Cc: Herbert Xu, davem, netdev
In-Reply-To: <OF0A9FA609.40104566-ON882573D2.0057C6DA-882573D2.005A0894@us.ibm.com>
David Stevens said the following on 2008-1-17 0:23:
> Wang,
> I think your patch is correct; did you test the same case for
> IPv6?
>
I've tested IPv4, but IPv6 not yet.
If Davem accept this one, I will see the IPv6, or you take care of it.
--
WCN
^ permalink raw reply
* Re: [RFC][PATCH] Fixing SA/SP dumps on netlink/af_key
From: jamal @ 2008-01-17 1:25 UTC (permalink / raw)
To: Timo Teräs; +Cc: netdev
In-Reply-To: <478E1479.3020204@iki.fi>
On Wed, 2008-16-01 at 16:28 +0200, Timo Teräs wrote:
[..]
> Creating a separate af_key patch would not be a big problem. I was
> just hoping avoiding it as the xfrm_state / xfrm_policy changes
> modify the API and requires changing af_key also.
The way dumping is done by xfrm_user is consistent across all netlink
not just ipsec. Thats why i said it had broader implications.
OTOH, theres a clear issue with pf_key.
> No. I'm not creating second copies of the SADB/SPD entries. The entries
> are just added to one more list.
Ah, sorry - yes, that sounds reasonable.
So what happens if i delete an entry; does it get removed from the list?
Also what happens on modification?
> If more entries are added, you can get notifications of them.
how would a user app (example racoon) appropriately deal with it?
Example an entry sits in the dump-list, it gets deleted - an event gets
generated user-space and later that entry shows up in user space dump.
cheers,
jamal
^ permalink raw reply
* Re: [RFC][PATCH] Fixing SA/SP dumps on netlink/af_key
From: jamal @ 2008-01-17 1:39 UTC (permalink / raw)
To: Herbert Xu; +Cc: timo.teras, netdev
In-Reply-To: <E1JFHDM-00010A-00@gondolin.me.apana.org.au>
On Thu, 2008-17-01 at 09:58 +1100, Herbert Xu wrote:
> IMHO doing significant work on af_key is a waste of time. It has no
> advantages at all over xfrm_user since neither is portable. So we
> should discourage people from using af_key wherever possible.
I wouldnt disagree except some apps like racoon which depend on pfkey
are unfortunately beyond repair. Timo has a pretty good handle on the
issue from what i have seen so far, so it pretty much seems to be there
without significant changes (if the two issues are separated).
cheers,
jamal
^ permalink raw reply
* Re: [RFC][PATCH] Fixing SA/SP dumps on netlink/af_key
From: Herbert Xu @ 2008-01-17 2:17 UTC (permalink / raw)
To: jamal; +Cc: timo.teras, netdev
In-Reply-To: <1200533980.4451.100.camel@localhost>
On Wed, Jan 16, 2008 at 08:39:40PM -0500, jamal wrote:
>
> I wouldnt disagree except some apps like racoon which depend on pfkey
> are unfortunately beyond repair. Timo has a pretty good handle on the
Racoon doesn't use pfkey dumping as far as I know.
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] add net_device_stats support to ethtool
From: Dan Nicolaescu @ 2008-01-17 5:13 UTC (permalink / raw)
To: Ben Greear; +Cc: netdev
In-Reply-To: <478E5122.1060009@candelatech.com>
Ben Greear <greearb@candelatech.com> writes:
> Dan Nicolaescu wrote:
> > Ben Greear <greearb@candelatech.com> writes:
> >
> > > Dan Nicolaescu wrote:
> > > > Hi,
> > > >
> > > > I have posted this patch in the past with absolutely no reply.
> > > > I would appreciate some sort of feedback of the form interested/not
> > > > interested. Should I just drop it?
> > > >
> > > > > I like it, but why not offer this for all devices since
> > they all have
> > > these stats.
> > >
> > > Could add new handlers called something like .get_strings_generic, or
> > > just add this to the higher-level ethtool handling before it looks for
> > > handlers.
> >
> > If I get your point, then the difference would be that drivers would add
> > to the initialization of the ethtool structure something like:
> >
> I meant something more like this (this will not apply..I hand-edited
> it to remove
> some extraneous crap from my patch...and I'm sure it's white-space damaged).
OK.
Hopefully someone can pick up these patches to be merged...
^ permalink raw reply
* Re: [PATCH 3/4] bonding: Fix work rearming
From: Makito SHIOKAWA @ 2008-01-17 5:30 UTC (permalink / raw)
To: Jarek Poplawski; +Cc: netdev, Makito SHIOKAWA
In-Reply-To: <20080116133646.GE2307@ff.dom.local>
> But, since during this change from sysfs cancel_delayed_work_sync()
> could be probably used, and it's rather efficient with killing
> rearming works, it seems this check could be unnecessary yet.
What going to be cancelled in bonding_store_miimon() when setting miimon to 0
is arp monitor, not mii monitor. So, this check will be needed to stop
rearming mii monitor when value 0 is set to miimon.
--
Makito SHIOKAWA
MIRACLE LINUX CORPORATION
^ permalink raw reply
* Re: [PATCH 4/4] bonding: Fix some RTNL taking
From: Makito SHIOKAWA @ 2008-01-17 5:30 UTC (permalink / raw)
To: Jarek Poplawski; +Cc: netdev, Makito SHIOKAWA
In-Reply-To: <20080116124450.GD2307@ff.dom.local>
> Maybe I'm wrong, but since this read_lock() is given and taken anyway,
> it seems this looks a bit better to me (why hold this rtnl longer
> than needed?):
> read_unlock(&bond->lock);
> rtnl_unlock();
> read_lock(&bond->lock);
Seems better.
> On the other hand, probably 'if (bond->kill_timers)' could be repeated
> after this read_lock() retaking.
Sorry, what do you mean? (A case that bond->kill_timers = 1 is done during
lock retaking, and work being queued only to do 'if (bond->kill_timers)'? If
so, I think that won't differ much.)
> If this if () is really necessary here, then this should be better
> before "delay = ..." with a block.
I agree.
--
Makito SHIOKAWA
MIRACLE LINUX CORPORATION
^ permalink raw reply
* Re: [RFC][PATCH] Fixing SA/SP dumps on netlink/af_key
From: Timo Teräs @ 2008-01-17 5:54 UTC (permalink / raw)
To: Herbert Xu; +Cc: jamal, netdev
In-Reply-To: <20080117021743.GA5182@gondor.apana.org.au>
jamal wrote:
> On Wed, 2008-16-01 at 16:28 +0200, Timo Teräs wrote:
>> > No. I'm not creating second copies of the SADB/SPD entries. The entries
>> > are just added to one more list.
>
> Ah, sorry - yes, that sounds reasonable.
> So what happens if i delete an entry; does it get removed from the list?
> Also what happens on modification?
If the entry is removed befored it is dumped, it wont be dumped at all.
The state during dump code execution is returned. Depending when the
modification occurs it might or might not be reflected in the dumped
entry.
>> > If more entries are added, you can get notifications of them.
>
> how would a user app (example racoon) appropriately deal with it?
> Example an entry sits in the dump-list, it gets deleted - an event gets
> generated user-space and later that entry shows up in user space dump.
You listen for the events. It is guaranteed that if the dumping code
does return the entry to be deleted, the deletion notification will
occur after that dump entry.
Herbert Xu wrote:
> On Wed, Jan 16, 2008 at 08:39:40PM -0500, jamal wrote:
>> I wouldnt disagree except some apps like racoon which depend on pfkey
>> are unfortunately beyond repair. Timo has a pretty good handle on the
>
> Racoon doesn't use pfkey dumping as far as I know.
ipsec-tools racoon uses pfkey and only pfkey. And it's non trivial to
make it use netlink; it relies heavily all around the code to pfkey
structs. It also runs on BSD so we cannot rip pfkey away; adding a
layer to work with both pfkey and netlink would be doable, but just a
lot of work.
Also ipsec-tools racoon seems to be the default IKE daemon in some
popular distros. So for the time being I think pfkey is an evil we have
to live with.
Cheers,
Timo
^ permalink raw reply
* Re: [RFC][PATCH] Fixing SA/SP dumps on netlink/af_key
From: Timo Teräs @ 2008-01-17 6:27 UTC (permalink / raw)
To: Herbert Xu; +Cc: hadi, netdev
In-Reply-To: <E1JFHDM-00010A-00@gondolin.me.apana.org.au>
Herbert Xu wrote:
> jamal <hadi@cyberus.ca> wrote:
>> There are two issues that are inter-mingled in there. The most important
>> is pf_key not being robust on dump. The other being the accurracy of
>
> IMHO doing significant work on af_key is a waste of time. It has no
> advantages at all over xfrm_user since neither is portable. So we
> should discourage people from using af_key wherever possible.
I don't know about netlink. But pfkey works in *BSD too and it is RFC'd.
So I'd say pfkey might be a bit more portable. Though netlink is definitely
more robust and extensive.
Cheers,
Timo
^ permalink raw reply
* [PATCH] request_irq() always returns -EINVAL with a NULL handler.
From: Rusty Russell @ 2008-01-17 6:57 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev, linux-kernel
I assume that these ancient network drivers were trying to find out if
an irq is available. eepro.c expecting +EBUSY was doubly wrong.
I'm not sure that can_request_irq() is the right thing, but these drivers
are definitely wrong.
request_irq should BUG() on bad input, and these would have been found
earlier.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
---
drivers/net/3c503.c | 2 +-
drivers/net/e2100.c | 2 +-
drivers/net/eepro.c | 2 +-
drivers/net/hp.c | 2 +-
kernel/irq/manage.c | 1 +
5 files changed, 5 insertions(+), 4 deletions(-)
diff -r 0b7e4fbb6238 drivers/net/3c503.c
--- a/drivers/net/3c503.c Thu Jan 17 15:49:34 2008 +1100
+++ b/drivers/net/3c503.c Thu Jan 17 16:40:28 2008 +1100
@@ -379,7 +379,7 @@ el2_open(struct net_device *dev)
outb(EGACFR_NORM, E33G_GACFR); /* Enable RAM and interrupts. */
do {
- if (request_irq (*irqp, NULL, 0, "bogus", dev) != -EBUSY) {
+ if (can_request_irq(*irqp, 0)) {
/* Twinkle the interrupt, and check if it's seen. */
unsigned long cookie = probe_irq_on();
outb_p(0x04 << ((*irqp == 9) ? 2 : *irqp), E33G_IDCFR);
diff -r 0b7e4fbb6238 drivers/net/e2100.c
--- a/drivers/net/e2100.c Thu Jan 17 15:49:34 2008 +1100
+++ b/drivers/net/e2100.c Thu Jan 17 16:40:28 2008 +1100
@@ -202,7 +202,7 @@ static int __init e21_probe1(struct net_
if (dev->irq < 2) {
int irqlist[] = {15,11,10,12,5,9,3,4}, i;
for (i = 0; i < 8; i++)
- if (request_irq (irqlist[i], NULL, 0, "bogus", NULL) != -EBUSY) {
+ if (can_request_irq(irqlist[i], 0)) {
dev->irq = irqlist[i];
break;
}
diff -r 0b7e4fbb6238 drivers/net/eepro.c
--- a/drivers/net/eepro.c Thu Jan 17 15:49:34 2008 +1100
+++ b/drivers/net/eepro.c Thu Jan 17 16:40:28 2008 +1100
@@ -914,7 +914,7 @@ static int eepro_grab_irq(struct net_dev
eepro_sw2bank0(ioaddr); /* Switch back to Bank 0 */
- if (request_irq (*irqp, NULL, IRQF_SHARED, "bogus", dev) != EBUSY) {
+ if (can_request_irq(*irqp, IRQF_SHARED)) {
unsigned long irq_mask;
/* Twinkle the interrupt, and check if it's seen */
irq_mask = probe_irq_on();
diff -r 0b7e4fbb6238 drivers/net/hp.c
--- a/drivers/net/hp.c Thu Jan 17 15:49:34 2008 +1100
+++ b/drivers/net/hp.c Thu Jan 17 16:40:28 2008 +1100
@@ -170,7 +170,7 @@ static int __init hp_probe1(struct net_d
int *irqp = wordmode ? irq_16list : irq_8list;
do {
int irq = *irqp;
- if (request_irq (irq, NULL, 0, "bogus", NULL) != -EBUSY) {
+ if (can_request_irq(irq, 0)) {
unsigned long cookie = probe_irq_on();
/* Twinkle the interrupt, and check if it's seen. */
outb_p(irqmap[irq] | HP_RUN, ioaddr + HP_CONFIGURE);
diff -r 0b7e4fbb6238 kernel/irq/manage.c
--- a/kernel/irq/manage.c Thu Jan 17 15:49:34 2008 +1100
+++ b/kernel/irq/manage.c Thu Jan 17 16:40:28 2008 +1100
@@ -252,6 +252,7 @@ int can_request_irq(unsigned int irq, un
return !action;
}
+EXPORT_SYMBOL(can_request_irq);
void compat_irq_chip_set_default_handler(struct irq_desc *desc)
{
^ permalink raw reply
* [PATCH] BUG_ON() bad input to request_irq
From: Rusty Russell @ 2008-01-17 6:59 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev, linux-kernel, Andrew Morton
In-Reply-To: <200801171757.59026.rusty@rustcorp.com.au>
Is there any reason why these bugs should be treated gently? The
caller might not want to check NR_IRQS and IRQ_NOREQUEST cases, but
a NULL handler or NULL dev_id w/ shared are coding bugs.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
---
kernel/irq/manage.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff -r c2eb8ef5a0be kernel/irq/manage.c
--- a/kernel/irq/manage.c Thu Jan 17 15:48:03 2008 +1100
+++ b/kernel/irq/manage.c Thu Jan 17 15:49:33 2008 +1100
@@ -532,13 +532,12 @@ int request_irq(unsigned int irq, irq_ha
* which interrupt is which (messes up the interrupt freeing
* logic etc).
*/
- if ((irqflags & IRQF_SHARED) && !dev_id)
- return -EINVAL;
+ BUG_ON((irqflags & IRQF_SHARED) && !dev_id);
+ BUG_ON(!handler);
+
if (irq >= NR_IRQS)
return -EINVAL;
if (irq_desc[irq].status & IRQ_NOREQUEST)
- return -EINVAL;
- if (!handler)
return -EINVAL;
action = kmalloc(sizeof(struct irqaction), GFP_ATOMIC);
^ permalink raw reply
* [PATCH] e1000e Kconfig: remove ref to nonexistant docs
From: Jason Uhlenkott @ 2008-01-17 7:03 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev, Auke Kok
There is no Documentation/networking/e1000e.txt.
Signed-off-by: Jason Uhlenkott <jasonuhl@jasonuhl.org>
Cc: Auke Kok <auke-jan.h.kok@intel.com>
---
Index: linux/drivers/net/Kconfig
===================================================================
--- linux.orig/drivers/net/Kconfig 2008-01-16 17:48:03.041103083 -0800
+++ linux/drivers/net/Kconfig 2008-01-16 23:00:23.647430487 -0800
@@ -1976,9 +1976,6 @@
<http://support.intel.com>
- More specific information on configuring the driver is in
- <file:Documentation/networking/e1000e.txt>.
-
To compile this driver as a module, choose M here. The module
will be called e1000e.
^ permalink raw reply
* RE: [REGRESSION] 2.6.24-rc7: e1000: Detected Tx Unit Hang
From: Brandeburg, Jesse @ 2008-01-17 7:09 UTC (permalink / raw)
To: David Miller; +Cc: slavon, elendil, netdev, linux-kernel
In-Reply-To: <20080115.210214.170759690.davem@davemloft.net>
David Miller wrote:
> From: "Brandeburg, Jesse" <jesse.brandeburg@intel.com>
> Date: Tue, 15 Jan 2008 13:53:43 -0800
>
>> The tx code has an "early exit" that tries to limit the amount of tx
>> packets handled in a single poll loop and requires napi or interrupt
>> rescheduling based on the return value from e1000_clean_tx_irq.
>
> That explains everything, thanks Jesse.
>
> Ok, here is the patch I'll propose to fix this. The goal is to make
> it as simple as possible without regressing the thing we were trying
> to fix.
We spent Wednesday trying to reproduce (without the patch) these issues
without much luck, and have applied the patch cleanly and will continue
testing it. Given the simplicity of the changes, and the community
testing, I'll give my ack and we will continue testing.
I think we should fix Robert's (unrelated, but in this thread) reported
issue before 2.6.24 final if we can, and I'll look at that tonight and
tomorrow.
Thanks for your work on this Dave,
Jesse
Acked-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
^ permalink raw reply
* Re: [RFC][PATCH] Fixing SA/SP dumps on netlink/af_key
From: David Miller @ 2008-01-17 7:16 UTC (permalink / raw)
To: timo.teras; +Cc: herbert, hadi, netdev
In-Reply-To: <478EF542.1010702@iki.fi>
From: Timo_Teräs <timo.teras@iki.fi>
Date: Thu, 17 Jan 2008 08:27:14 +0200
> I don't know about netlink. But pfkey works in *BSD too and it is RFC'd.
> So I'd say pfkey might be a bit more portable. Though netlink is definitely
> more robust and extensive.
The RFCs say absolutely nothing about policy interfaces for AF_KEY,
everybody rolls their own in slightly incompatible ways.
It is therefore anything but standardized.
^ permalink raw reply
* Re: [REGRESSION] 2.6.24-rc7: e1000: Detected Tx Unit Hang
From: David Miller @ 2008-01-17 7:20 UTC (permalink / raw)
To: jesse.brandeburg; +Cc: slavon, elendil, netdev, linux-kernel
In-Reply-To: <36D9DB17C6DE9E40B059440DB8D95F520432DA91@orsmsx418.amr.corp.intel.com>
From: "Brandeburg, Jesse" <jesse.brandeburg@intel.com>
Date: Wed, 16 Jan 2008 23:09:47 -0800
> We spent Wednesday trying to reproduce (without the patch) these issues
> without much luck, and have applied the patch cleanly and will continue
> testing it. Given the simplicity of the changes, and the community
> testing, I'll give my ack and we will continue testing.
You need a slow CPU, and you need to make sure you do actually
trigger the TX limiting code there.
I bet your cpus are fast enough that it simply never triggers.
:-)
> Acked-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Thanks for reviewing Jesse.
^ permalink raw reply
* Re: [RFC][PATCH] Fixing SA/SP dumps on netlink/af_key
From: Timo Teräs @ 2008-01-17 7:38 UTC (permalink / raw)
To: David Miller; +Cc: herbert, hadi, netdev
In-Reply-To: <20080116.231654.74131878.davem@davemloft.net>
David Miller wrote:
> From: Timo_Teräs <timo.teras@iki.fi>
> Date: Thu, 17 Jan 2008 08:27:14 +0200
>
>> I don't know about netlink. But pfkey works in *BSD too and it is RFC'd.
>> So I'd say pfkey might be a bit more portable. Though netlink is definitely
>> more robust and extensive.
>
> The RFCs say absolutely nothing about policy interfaces for AF_KEY,
> everybody rolls their own in slightly incompatible ways.
>
> It is therefore anything but standardized.
Yes, there's non-standardized extensions. But the point was that there are
other implementations of pfkey. And ipsec-tools racoon is an example of
a widely used application that runs in Linux and *BSD using this API. So
for the time being I'd consider having pfkey fixes as a good thing. This
pfkey dumping problem seems to be affecting many users.
- Timo
^ permalink raw reply
* Re: [REGRESSION] 2.6.24-rc7: e1000: Detected Tx Unit Hang
From: Frans Pop @ 2008-01-17 7:51 UTC (permalink / raw)
To: David Miller; +Cc: jesse.brandeburg, slavon, netdev, linux-kernel
In-Reply-To: <20080116.232037.261622584.davem@davemloft.net>
On Thursday 17 January 2008, David Miller wrote:
> From: "Brandeburg, Jesse" <jesse.brandeburg@intel.com>
>
> > We spent Wednesday trying to reproduce (without the patch) these issues
> > without much luck, and have applied the patch cleanly and will continue
> > testing it. Given the simplicity of the changes, and the community
> > testing, I'll give my ack and we will continue testing.
>
> You need a slow CPU, and you need to make sure you do actually
> trigger the TX limiting code there.
Hmmm. Is a dual core Pentium D 3.20GHz considered slow these days?
^ permalink raw reply
* Re: [RFC][PATCH] Fixing SA/SP dumps on netlink/af_key
From: David Miller @ 2008-01-17 7:59 UTC (permalink / raw)
To: timo.teras; +Cc: herbert, hadi, netdev
In-Reply-To: <478F05E7.6070503@iki.fi>
From: Timo_Teräs <timo.teras@iki.fi>
Date: Thu, 17 Jan 2008 09:38:15 +0200
> David Miller wrote:
> > From: Timo_Teräs <timo.teras@iki.fi>
> > Date: Thu, 17 Jan 2008 08:27:14 +0200
> >
> >> I don't know about netlink. But pfkey works in *BSD too and it is RFC'd.
> >> So I'd say pfkey might be a bit more portable. Though netlink is definitely
> >> more robust and extensive.
> >
> > The RFCs say absolutely nothing about policy interfaces for AF_KEY,
> > everybody rolls their own in slightly incompatible ways.
> >
> > It is therefore anything but standardized.
>
> Yes, there's non-standardized extensions.
You can't implement a keying daemon without policy support, and policy
support is where the "non-standardized extensions" live.
Doing anything other than "life support" bug fixes for AF_KEY is
inappropriate.
^ permalink raw reply
* Re: [REGRESSION] 2.6.24-rc7: e1000: Detected Tx Unit Hang
From: David Miller @ 2008-01-17 8:00 UTC (permalink / raw)
To: elendil; +Cc: jesse.brandeburg, slavon, netdev, linux-kernel
In-Reply-To: <200801170851.56029.elendil@planet.nl>
From: Frans Pop <elendil@planet.nl>
Date: Thu, 17 Jan 2008 08:51:55 +0100
> On Thursday 17 January 2008, David Miller wrote:
> > From: "Brandeburg, Jesse" <jesse.brandeburg@intel.com>
> >
> > > We spent Wednesday trying to reproduce (without the patch) these issues
> > > without much luck, and have applied the patch cleanly and will continue
> > > testing it. Given the simplicity of the changes, and the community
> > > testing, I'll give my ack and we will continue testing.
> >
> > You need a slow CPU, and you need to make sure you do actually
> > trigger the TX limiting code there.
>
> Hmmm. Is a dual core Pentium D 3.20GHz considered slow these days?
No of course :-) I guess it therefore depends upon the load
as well.
^ permalink raw reply
* Re: [RFC][PATCH] Fixing SA/SP dumps on netlink/af_key
From: Timo Teräs @ 2008-01-17 8:11 UTC (permalink / raw)
To: David Miller; +Cc: herbert, hadi, netdev
In-Reply-To: <20080116.235923.208347316.davem@davemloft.net>
David Miller wrote:
> Doing anything other than "life support" bug fixes for AF_KEY is
> inappropriate.
Yes. I thought my patch would qualify as "life support" bug fix.
Currently racoon fails to work if there are too many SPDs or SAs
because the kernel cannot handle the dump request properly. And
this is what my patch fixes for pfkey. It adds no new features or
functionality; just makes the dumping work with large databases.
Then there's also the xfrm dumping changes which change the
algorithm from O(n^2) to O(n) with some memory overhead, but
that is a different story. Any comments on that?
- Timo
^ 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