* Re: [PATCH 4/8] SCTP: Implete SCTP-AUTH parameter processing
From: David Miller @ 2007-09-17 2:32 UTC (permalink / raw)
To: vladislav.yasevich; +Cc: lksctp-developers, netdev
In-Reply-To: <11897954992330-git-send-email-vladislav.yasevich@hp.com>
From: Vlad Yasevich <vladislav.yasevich@hp.com>
Date: Fri, 14 Sep 2007 14:44:55 -0400
> Implement processing for the CHUNKS, RANDOM, and HMAC parameters and
> deal with how this parameters are effected by association restarts.
> In particular, during unexpeted INIT processing, we need to reply with
> parameters from the original INIT chunk. Also, after restart, we need
> to update the old association with new peer parameters and change the
> association shared keys.
>
> Signed-off-by: Vlad Yasevich <vladislav.yasevich@hp.com>
Applied to net-2.6.24, thanks.
^ permalink raw reply
* Re: [PATCH 3/8] SCTP: Implement SCTP-AUTH initializations.
From: David Miller @ 2007-09-17 2:31 UTC (permalink / raw)
To: vladislav.yasevich; +Cc: lksctp-developers, netdev
In-Reply-To: <11897954992191-git-send-email-vladislav.yasevich@hp.com>
From: Vlad Yasevich <vladislav.yasevich@hp.com>
Date: Fri, 14 Sep 2007 14:44:54 -0400
> The patch initializes AUTH related members of the generic SCTP
> structures and provides a way to enable/disable auth extension.
>
> Signed-off-by: Vlad Yasevich <vladislav.yasevich@hp.com>
Applied to net-2.6.24
^ permalink raw reply
* Re: [PATCH 2/8] SCTP: Implement SCTP-AUTH internals
From: David Miller @ 2007-09-17 2:29 UTC (permalink / raw)
To: vladislav.yasevich; +Cc: lksctp-developers, netdev
In-Reply-To: <11897954993782-git-send-email-vladislav.yasevich@hp.com>
From: Vlad Yasevich <vladislav.yasevich@hp.com>
Date: Fri, 14 Sep 2007 14:44:53 -0400
> This patch implements the internals operations of the AUTH, such as
> key computation and storage. It also adds necessary variables to
> the SCTP data structures.
>
> Signed-off-by: Vlad Yasevich <vladislav.yasevich@hp.com>
Applied to net-2.6.24, with lots of trailing whitspace fixed.
Please check your patches with GIT by using something such
as "git apply --check --whitespace=error-all foo.diff"
in the future, and you'll see stuff like this:
Adds trailing whitespace.
diff:696:
Adds trailing whitespace.
diff:732: return secret;
Adds trailing whitespace.
diff:805:
Adds trailing whitespace.
diff:815:/*
Adds trailing whitespace.
diff:1034: break;
Adds trailing whitespace.
diff:1098:
Adds trailing whitespace.
diff:1109:
fatal: 7 lines add trailing whitespaces.
Thanks.
^ permalink raw reply
* Re: [PATCH 1/8] SCTP: protocol definitions for SCTP-AUTH implementation
From: David Miller @ 2007-09-17 2:26 UTC (permalink / raw)
To: vladislav.yasevich; +Cc: lksctp-developers, netdev
In-Reply-To: <11897954991955-git-send-email-vladislav.yasevich@hp.com>
From: Vlad Yasevich <vladislav.yasevich@hp.com>
Date: Fri, 14 Sep 2007 14:44:52 -0400
> Signed-off-by: Vlad Yasevich <vladislav.yasevich@hp.com>
Applied to net-2.6.24
^ permalink raw reply
* [ofa-general] Re: [PATCH 0/10 REV5] Implement skb batching and support in IPoIB/E1000
From: David Miller @ 2007-09-17 2:25 UTC (permalink / raw)
To: hadi
Cc: johnpol, peter.p.waskiewicz.jr, kumarkr, herbert, gaagaan,
Robert.Olsson, netdev, rdreier, mcarlson, randy.dunlap, jagana,
general, mchan, tgraf, jeff, sri, shemminger, kaber
In-Reply-To: <1189995261.4230.61.camel@localhost>
From: jamal <hadi@cyberus.ca>
Date: Sun, 16 Sep 2007 22:14:21 -0400
> I still think this work - despite my vested interest - needs more
> scrutiny from a performance perspective.
Absolutely.
There are tertiary issues I'm personally interested in, for example
how well this stuff works when we enable software GSO on a non-TSO
capable card.
In such a case the GSO segment should be split right before we hit the
driver and then all the sub-segments of the original GSO frame batched
in one shot down to the device driver.
In this way you'll get a large chunk of the benefit of TSO without
explicit hardware support for the feature.
There are several cards (some even 10GB) that will benefit immensely
from this.
^ permalink raw reply
* [ofa-general] Re: [PATCH 0/10 REV5] Implement skb batching and support in IPoIB/E1000
From: jamal @ 2007-09-17 2:14 UTC (permalink / raw)
To: David Miller
Cc: johnpol, peter.p.waskiewicz.jr, kumarkr, herbert, gaagaan,
Robert.Olsson, netdev, rdreier, mcarlson, randy.dunlap, jagana,
general, mchan, tgraf, jeff, sri, shemminger, kaber
In-Reply-To: <20070916.180232.101592975.davem@davemloft.net>
On Sun, 2007-16-09 at 18:02 -0700, David Miller wrote:
> I do.
>
> And I'm reviewing and applying several hundred patches a day.
>
> What's the point? :-)
Reading the commentary made me think you were about to swallow that with
one more change by the time i wake up;->
I still think this work - despite my vested interest - needs more
scrutiny from a performance perspective.
I tend to send a url to my work, but it may be time to start posting
patches.
cheers,
jamal
^ permalink raw reply
* Re: [PATCH 0/10 REV5] Implement skb batching and support in IPoIB/E1000
From: David Miller @ 2007-09-17 1:02 UTC (permalink / raw)
To: hadi
Cc: krkumar2, johnpol, herbert, kaber, shemminger, jagana,
Robert.Olsson, rick.jones2, xma, gaagaan, netdev, rdreier,
peter.p.waskiewicz.jr, mcarlson, jeff, mchan, general, kumarkr,
tgraf, randy.dunlap, sri
In-Reply-To: <1189988958.4230.55.camel@localhost>
From: jamal <hadi@cyberus.ca>
Date: Sun, 16 Sep 2007 20:29:18 -0400
> On Sun, 2007-16-09 at 16:17 -0700, David Miller wrote:
>
> > The only major complaint I have about this patch series is that
> > the IPoIB part should just be one big changeset.
>
> Dave, you do realize that i have been investing my time working on
> batching as well, right?
I do.
And I'm reviewing and applying several hundred patches a day.
What's the point? :-)
^ permalink raw reply
* Re: [PATCH 0/10 REV5] Implement skb batching and support in IPoIB/E1000
From: jamal @ 2007-09-17 0:29 UTC (permalink / raw)
To: David Miller
Cc: krkumar2, johnpol, herbert, kaber, shemminger, jagana,
Robert.Olsson, rick.jones2, xma, gaagaan, netdev, rdreier,
peter.p.waskiewicz.jr, mcarlson, jeff, mchan, general, kumarkr,
tgraf, randy.dunlap, sri
In-Reply-To: <20070916.161748.48388692.davem@davemloft.net>
On Sun, 2007-16-09 at 16:17 -0700, David Miller wrote:
> The only major complaint I have about this patch series is that
> the IPoIB part should just be one big changeset.
Dave, you do realize that i have been investing my time working on
batching as well, right?
cheers,
jamal
^ permalink raw reply
* Re: [PATCH][NETNS] Use list_for_each_entry_continue_reverse in setup_net
From: David Miller @ 2007-09-17 0:07 UTC (permalink / raw)
To: ebiederm; +Cc: shemminger, xemul, netdev, containers, devel, dlezcano
In-Reply-To: <m1odg2w3yv.fsf@ebiederm.dsl.xmission.com>
From: ebiederm@xmission.com (Eric W. Biederman)
Date: Sun, 16 Sep 2007 18:06:00 -0600
> I did that audit when I replied to Stephen the first time and I just
> redid it to verify myself. We are calling functions that can fail
> from the init function (kmalloc in the most common). So the
> init function can fail.
>
> So short of adding a bunch of BUG_ON's to the kernel to trap those
> failure cases we can't remove the backwards list walk. Especially
> since I can initiate this code path as root by calling
> "clone(CLONE_NEWNET...)".
I just noticed that posting and thanks for reiterating.
^ permalink raw reply
* Re: [PATCH][NETNS] Use list_for_each_entry_continue_reverse in setup_net
From: Eric W. Biederman @ 2007-09-17 0:06 UTC (permalink / raw)
To: David Miller; +Cc: shemminger, xemul, netdev, containers, devel, dlezcano
In-Reply-To: <20070916.164914.15264075.davem@davemloft.net>
David Miller <davem@davemloft.net> writes:
> From: Stephen Hemminger <shemminger@linux-foundation.org>
> Date: Fri, 14 Sep 2007 22:07:14 +0200
>
>> Could we just make it so dev->init is not allowed to fail? Then it
>> can be a void function and the nasty unwind code can go?
>
> Someone (not me :-) need to do an audit to find all current
> users of this function and determine if they all can live
> without returning errors.
>
> If so, sure let's make the change and simplify things.
I did that audit when I replied to Stephen the first time and I just
redid it to verify myself. We are calling functions that can fail
from the init function (kmalloc in the most common). So the
init function can fail.
So short of adding a bunch of BUG_ON's to the kernel to trap those
failure cases we can't remove the backwards list walk. Especially
since I can initiate this code path as root by calling
"clone(CLONE_NEWNET...)".
Eric
^ permalink raw reply
* Re: [PATCH] Add ICMPMsgStats MIB (RFC 4293) [rev 2]
From: David Miller @ 2007-09-17 0:04 UTC (permalink / raw)
To: dlstevens; +Cc: yoshfuji, netdev
In-Reply-To: <OF04820EEE.89F4D267-ON88257356.0074B537-88257356.00759E10@us.ibm.com>
From: David Stevens <dlstevens@us.ibm.com>
Date: Fri, 14 Sep 2007 15:25:32 -0600
> Background: RFC 4293 deprecates existing individual, named ICMP
> type counters to be replaced with the ICMPMsgStatsTable. This table
> includes entries for both IPv4 and IPv6, and requires counting of all
> ICMP types, whether or not the machine implements the type.
>
> These patches "remove" (but not really) the existing counters, and
> replace them with the ICMPMsgStats tables for v4 and v6.
> It includes the named counters in the /proc places they were, but gets the
> values for them from the new tables. It also counts packets generated
> from raw socket output (e.g., OutEchoes, MLD queries, RA's from
> radvd, etc).
>
> Changes:
> 1) create icmpmsg_statistics mib
> 2) create icmpv6msg_statistics mib
> 3) modify existing counters to use these
> 4) modify /proc/net/snmp to add "IcmpMsg" with all ICMP types
> listed by number for easy SNMP parsing
> 5) modify /proc/net/snmp printing for "Icmp" to get the named data
> from new counters.
> [new to 2nd revision]
> 6) support per-interface ICMP stats
> 7) use common macro for per-device stat macros
>
> IPv6 patch attached.
>
> +-DLS
>
> Signed-off-by: David L Stevens <dlstevens@us.ibm.com>
No objections, so patch applied to net-2.6.24
The following is not directed at this patch specifically, but rather
in general.
All of these crappy "idev == NULL" checks for nearly EVERY SINGLE ipv6
counter bump has gotten _WAY_ out of control. By definition this
whole situation is broken if we need to test the thing basically
everywhere.
And it's the worst kind of disease because it's hidden inside all
kinds of macros so when you're reading the code you don't see this
nearly constant overhead spread all over the ipv6 stack in the most
critical paths we have.
How many remote OOPS'er DoS bugs have we had in ipv6 because of how
this stuff works? I can remember at least 3, and that's 3 too many.
We need to fix this, and I don't care how, such that idev is never
NULL and at least points to some dummy ipv6 idev object. And it
must be done in such a way that the cure is not worse than the
disease :-)
^ permalink raw reply
* Re: [PATCH][NETNS] Use list_for_each_entry_continue_reverse in setup_net
From: David Miller @ 2007-09-16 23:49 UTC (permalink / raw)
To: shemminger; +Cc: ebiederm, xemul, netdev, containers, devel, dlezcano
In-Reply-To: <20070914220714.3a1e87f8@oldman>
From: Stephen Hemminger <shemminger@linux-foundation.org>
Date: Fri, 14 Sep 2007 22:07:14 +0200
> Could we just make it so dev->init is not allowed to fail? Then it
> can be a void function and the nasty unwind code can go?
Someone (not me :-) need to do an audit to find all current
users of this function and determine if they all can live
without returning errors.
If so, sure let's make the change and simplify things.
^ permalink raw reply
* Re: Network Namespace status
From: Eric W. Biederman @ 2007-09-16 23:47 UTC (permalink / raw)
To: David Miller; +Cc: containers, netdev, htejun, gregkh, akpm
In-Reply-To: <20070916.153643.13760549.davem@davemloft.net>
David Miller <davem@davemloft.net> writes:
> From: ebiederm@xmission.com (Eric W. Biederman)
> Date: Thu, 13 Esp 2007 13:12:08 -0600
>
>> The final blocker to having multiple useful instances of network
>> namespaces is the loopback device. We recognize the network namespace
>> of incoming packets by looking at dev->nd_net. Which means for
>> packets to properly loopback within a network namespace we need a
>> loopback device per network namespace. There were some concerns
>> expressed when we posted the cleanup part of the patches that allowed
>> for multiple loopback devices a few weeks ago so resolving this one
>> may be tricky.
>
> There was a change posted recently to dynamically allocate the
> loopback device. I like that (sorry I don't have a reference
> to the patch handy), and you can build on top of that to get
> the namespace local loopback objects you want.
>
> static struct net_device *loopback_dev(struct net_namespace *net)
> {
> ...
> }
>
> You get the idea.
Sure. Thanks.
Since the change got dropped I figured it for a rejection, and that
I would have to rework that patch.
On a similar note. It recently occurred to me that I can make creating
multiple network namespaces depend on !CONFIG_SYSFS. Which will allow
most of the rest of the patches I am sure of to be merged now. And
give me just a little more time to work with Tejun and finish up the
sysfs support.
Eric
^ permalink raw reply
* Re: [PATCH] fix net_device leak in vlan
From: David Miller @ 2007-09-16 23:43 UTC (permalink / raw)
To: viro; +Cc: kaber, netdev
In-Reply-To: <20070903133520.GV21089@ftp.linux.org.uk>
From: Al Viro <viro@ftp.linux.org.uk>
Date: Mon, 3 Sep 2007 14:35:20 +0100
> In "[VLAN]: Move device registation to seperate function" (commit
> e89fe42cd03c8fd3686df82d8390a235717a66de), a pile of code got moved
> to register_vlan_dev(), including grabbing a reference to underlying
> device. However, original dev_hold() had been left behind, so we
> leak a reference to net_device now...
>
> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Patch applied, thanks Al.
^ permalink raw reply
* Re: [PATCH 1/2] net/: all net/ cleanup with ARRAY_SIZE
From: David Miller @ 2007-09-16 23:42 UTC (permalink / raw)
To: crquan; +Cc: rpjday, netdev, linux-kernel, cr_quan
In-Reply-To: <11887290181154-git-send-email-crquan@gmail.com>
From: Denis Cheng <crquan@gmail.com>
Date: Sun, 2 Sep 2007 18:30:17 +0800
> Signed-off-by: Denis Cheng <crquan@gmail.com>
You already submitted the net/ipv4/af_inet.c case
seperately, so I had to remove it from this patch for
it to apply properly.
Please keep your patches straight to avoid problems
like this.
Thans.
^ permalink raw reply
* Re: [PATCH] net/ipv4/af_inet.c: use ARRAY_SIZE macro from kernel.h instead
From: David Miller @ 2007-09-16 23:39 UTC (permalink / raw)
To: crquan; +Cc: netdev, linux-kernel, cr_quan
In-Reply-To: <11887091471748-git-send-email-crquan@gmail.com>
From: Denis Cheng <crquan@gmail.com>
Date: Sun, 2 Sep 2007 12:59:07 +0800
> Signed-off-by: Denis Cheng <crquan@gmail.com>
Applied to net-2.6.24, thanks!
^ permalink raw reply
* Re: [PATCH 3/3] netlink: use a statically allocated nl_table instead
From: David Miller @ 2007-09-16 23:38 UTC (permalink / raw)
To: crquan; +Cc: netdev, linux-kernel, cr_quan
In-Reply-To: <11886759772663-git-send-email-crquan@gmail.com>
From: Denis Cheng <crquan@gmail.com>
Date: Sun, 2 Sep 2007 03:45:59 +0800
> if the table is always fixed size with MAX_LINKS entries, why not use a statically
> allocated table straightforwardly?
>
> Signed-off-by: Denis Cheng <crquan@gmail.com>
I made the explicit decision to dynamically allocate because
many systems have limits on how large the kernel image can
be and therefore the less we statically allocate huge tables
(constant size or not) the better.
Lockdep is the worst offender, for example, it's completely awful. It
consumes 4MB of kernel BSS space when enabled on a 64-bit platform.
Patch not applied.
^ permalink raw reply
* Re: [PATCH 2/3] netlink: the temp variable name max is ambiguous
From: David Miller @ 2007-09-16 23:36 UTC (permalink / raw)
To: crquan; +Cc: netdev, linux-kernel, cr_quan
In-Reply-To: <11886759682348-git-send-email-crquan@gmail.com>
From: Denis Cheng <crquan@gmail.com>
Date: Sun, 2 Sep 2007 03:45:58 +0800
> with the macro max provided by <linux/kernel.h>, so changed its name to a more proper one: limit
>
> Signed-off-by: Denis Cheng <crquan@gmail.com>
Not strictly necessary because CPP knows to differentiate between
'max(' and plain 'max' when evaluating if a CPP macro should be
expanded or not.
Nonetheless, applied to net-2.6.24, thanks.
^ permalink raw reply
* Re: [PATCH 1/3] netlink: use the macro min(x,y) provided by <linux/kernel.h> instead
From: David Miller @ 2007-09-16 23:35 UTC (permalink / raw)
To: crquan; +Cc: netdev, linux-kernel, cr_quan
In-Reply-To: <1188675959178-git-send-email-crquan@gmail.com>
From: Denis Cheng <crquan@gmail.com>
Date: Sun, 2 Sep 2007 03:45:57 +0800
> Signed-off-by: Denis Cheng <crquan@gmail.com>
Applied to net-2.6.24, thanks.
^ permalink raw reply
* Re: [SKBUFF]: Fix up csum_start when head room changes
From: David Miller @ 2007-09-16 23:33 UTC (permalink / raw)
To: herbert; +Cc: netdev
In-Reply-To: <20070901011333.GA5223@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Sat, 1 Sep 2007 09:13:33 +0800
> Hi Dave:
>
> [SKBUFF]: Fix up csum_start when head room changes
>
> Thanks for noticing the bug where csum_start is not updated
> when the head room changes.
>
> This patch fixes that. It also moves the csum/ip_summed
> copying into copy_skb_header so that skb_copy_expand gets
> it too. I've checked its callers and no one should be upset
> by this.
>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Herbert, thanks for following up on this.
Although this is technically a "bug fix" we don't have anyone
explicitly triggering this and I don't feel comfortable pushing this
into net-2.6 without a reported failure case right now.
So I applied it to net-2.6.24 for now.
If you disagree, plead your case :-)
^ permalink raw reply
* Re: [NETLINK]: Avoid pointer in netlink_run_queue
From: David Miller @ 2007-09-16 23:31 UTC (permalink / raw)
To: herbert; +Cc: tgraf, netdev
In-Reply-To: <20070831120930.GA29914@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Fri, 31 Aug 2007 20:09:30 +0800
> Hi Dave:
>
> [NETLINK]: Avoid pointer in netlink_run_queue
>
> I was looking at Patrick's fix to inet_diag and it occured
> to me that we're using a pointer argument to return values
> unnecessarily in netlink_run_queue. Changing it to return
> the value will allow the compiler to generate better code
> since the value won't have to be memory-backed.
>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Applied to net-2.6.24, thanks Herbert.
^ permalink raw reply
* Re: [PATCH 7/7] [PPP] generic: Fix receive path data clobbering & non-linear handling
From: David Miller @ 2007-09-16 23:22 UTC (permalink / raw)
To: herbert; +Cc: jchapman, mostrows, paulus, toralf.foerster, netdev
In-Reply-To: <E1IR2VB-0007Nc-00@gondolin.me.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Fri, 31 Aug 2007 17:09:17 +0800
> [PPP] generic: Fix receive path data clobbering & non-linear handling
>
> This patch adds missing pskb_may_pull calls to deal with non-linear
> packets that may arrive from pppoe or pppol2tp.
>
> It also copies cloned packets before writing over them.
>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Applied, thanks Herbert.
^ permalink raw reply
* Re: [PATCH 6/7] [PPP] generic: Call skb_cow_head before scribbling over skb
From: David Miller @ 2007-09-16 23:21 UTC (permalink / raw)
To: herbert; +Cc: jchapman, mostrows, paulus, toralf.foerster, netdev
In-Reply-To: <E1IR2VA-0007NU-00@gondolin.me.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Fri, 31 Aug 2007 17:09:16 +0800
> [PPP] generic: Call skb_cow_head before scribbling over skb
>
> It's rude to write over data that other people are still using. So call
> skb_cow_head before PPP proceeds to modify the skb data.
>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Applied, thanks Herbert.
^ permalink raw reply
* Re: [PATCH 5/7] [NET] skbuff: Add skb_cow_head
From: David Miller @ 2007-09-16 23:21 UTC (permalink / raw)
To: herbert; +Cc: jchapman, mostrows, paulus, toralf.foerster, netdev
In-Reply-To: <E1IR2V9-0007NM-00@gondolin.me.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Fri, 31 Aug 2007 17:09:15 +0800
> [NET] skbuff: Add skb_cow_head
>
> This patch adds an optimised version of skb_cow that avoids the copy if
> the header can be modified even if the rest of the payload is cloned.
>
> This can be used in encapsulating paths where we only need to modify the
> header. As it is, this can be used in PPPOE and bridging.
>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Applied, thanks Herbert.
^ permalink raw reply
* Re: [PATCH 4/7] [BRIDGE]: Kill clone argument to br_flood_*
From: David Miller @ 2007-09-16 23:21 UTC (permalink / raw)
To: herbert; +Cc: jchapman, mostrows, paulus, toralf.foerster, netdev
In-Reply-To: <E1IR2V8-0007NE-00@gondolin.me.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Fri, 31 Aug 2007 17:09:14 +0800
> [BRIDGE]: Kill clone argument to br_flood_*
>
> The clone argument is only used by one caller and that caller can clone
> the packet itself. This patch moves the clone call into the caller and
> kills the clone argument.
>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Applied, thanks Herbert.
^ 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