* Re: [patch 4/4] ucc_geth-fix-build-break-introduced-by-commit-09f75cd7bf13720738e6a196cc0107ce9a5bd5a0-checkpatch-fixes
From: David Miller @ 2007-10-18 2:37 UTC (permalink / raw)
To: akpm; +Cc: jeff, netdev, Emilian.Medve, galak, leoli, paulus
In-Reply-To: <200710162124.l9GLOCTB017977@imap1.linux-foundation.org>
From: akpm@linux-foundation.org
Date: Tue, 16 Oct 2007 14:24:12 -0700
> From: Andrew Morton <akpm@linux-foundation.org>
>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: Emil Medve <Emilian.Medve@Freescale.com>
> Cc: Jeff Garzik <jeff@garzik.org>
> Cc: Kumar Gala <galak@gate.crashing.org>
> Cc: Li Yang <leoli@freescale.com>
> Cc: Paul Mackerras <paulus@samba.org>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Please help my eyes, I can't see the fix:
> @@ -3454,7 +3454,7 @@ static int ucc_geth_rx(struct ucc_geth_p
> u16 length, howmany = 0;
> u32 bd_status;
> u8 *bdBuffer;
> - struct net_device * dev;
> + struct net_device *dev;
>
> ugeth_vdbg("%s: IN", __FUNCTION__);
>
This might be a coding style fix, as far as I can see, but I can't
imagine how it can effect compilation at all. It just removes a space
between the "*" and "dev" but that space is harmless.
^ permalink raw reply
* Re: [PATCH] br2684: get rid of broken header code.
From: David Miller @ 2007-10-18 2:39 UTC (permalink / raw)
To: shemminger; +Cc: chas, linux-atm-general, netdev
In-Reply-To: <20071016143850.5fcd5345@freepuppy.rosehill>
From: Stephen Hemminger <shemminger@linux-foundation.org>
Date: Tue, 16 Oct 2007 14:38:50 -0700
> Recent header_ops change would break the following dead
> code in br2684. Maintaining conditonal code in mainline is wrong.
>
> "Do, or do not. There is no 'try.'"
>
> Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
Applied.
^ permalink raw reply
* Re: [PATCH 1/7] Omit double hash calculations in xxx_frag_intern
From: David Miller @ 2007-10-18 2:44 UTC (permalink / raw)
To: xemul; +Cc: netdev, devel
In-Reply-To: <4714C13E.3040808@openvz.org>
From: Pavel Emelyanov <xemul@openvz.org>
Date: Tue, 16 Oct 2007 17:48:46 +0400
> Since the hash value is already calculated in xxx_find, we can
> simply use it later. This is already done in netfilter code,
> so make the same in ipv4 and ipv6.
>
> Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
Applied, but if we ever implement dynamically sized frag
queue hash tables, this recomputation of the hash function
in the hash insert function would need to be re-added.
^ permalink raw reply
* Re: [PATCH 2/7] Consolidate xxx_frag_intern
From: David Miller @ 2007-10-18 2:44 UTC (permalink / raw)
To: xemul; +Cc: netdev, devel
In-Reply-To: <4714C23F.2070008@openvz.org>
From: Pavel Emelyanov <xemul@openvz.org>
Date: Tue, 16 Oct 2007 17:53:03 +0400
> This routine checks for the existence of a given entry
> in the hash table and inserts the new one if needed.
>
> The ->equal callback is used to compare two frag_queue-s
> together, but this one is temporary and will be removed
> later. The netfilter code and the ipv6 one use the same
> routine to compare frags.
>
> The inet_frag_intern() always returns non-NULL pointer,
> so convert the inet_frag_queue into protocol specific
> one (with the container_of) without any checks.
>
> Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
Applied.
^ permalink raw reply
* Re: [PATCH 3/7] Consolidate xxx_frag_alloc()
From: David Miller @ 2007-10-18 2:45 UTC (permalink / raw)
To: xemul; +Cc: netdev, devel
In-Reply-To: <4714C358.50502@openvz.org>
From: Pavel Emelyanov <xemul@openvz.org>
Date: Tue, 16 Oct 2007 17:57:44 +0400
> Just perform the kzalloc() allocation and setup common
> fields in the inet_frag_queue(). Then return the result
> to the caller to initialize the rest.
>
> The inet_frag_alloc() may return NULL, so check the
> return value before doing the container_of(). This looks
> ugly, but the xxx_frag_alloc() will be removed soon.
>
> The xxx_expire() timer callbacks are patches,
> because the argument is now the inet_frag_queue, not
> the protocol specific queue.
>
> Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
Applied, although I had to correct the following white-space
problems in your patch:
Adds trailing whitespace.
diff:33:
Adds trailing whitespace.
diff:72:
Adds trailing whitespace.
diff:126:
warning: 3 lines add whitespace errors.
^ permalink raw reply
* Re: [PATCH 4/7] Consolidate xxx_frag_create()
From: David Miller @ 2007-10-18 2:46 UTC (permalink / raw)
To: xemul; +Cc: netdev, devel
In-Reply-To: <4714C3EA.4080109@openvz.org>
From: Pavel Emelyanov <xemul@openvz.org>
Date: Tue, 16 Oct 2007 18:00:10 +0400
> This one uses the xxx_frag_intern() and xxx_frag_alloc()
> routines, which are already consolidated, so remove them
> from protocol code (as promised).
>
> The ->constructor callback is used to init the rest of
> the frag queue and it is the same for netfilter and ipv6.
>
> Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
Applied.
^ permalink raw reply
* Re: [PATCH 5/7] Consolidate xxx_find() in fragment management
From: David Miller @ 2007-10-18 2:47 UTC (permalink / raw)
To: xemul; +Cc: netdev, devel
In-Reply-To: <4714C4B9.5010606@openvz.org>
From: Pavel Emelyanov <xemul@openvz.org>
Date: Tue, 16 Oct 2007 18:03:37 +0400
> Here we need another callback ->match to check whether the
> entry found in hash matches the key passed. The key used
> is the same as the creation argument for inet_frag_create.
>
> Yet again, this ->match is the same for netfilter and ipv6.
> Running a frew steps forward - this callback will later
> replace the ->equal one.
>
> Since the inet_frag_find() uses the already consolidated
> inet_frag_create() remove the xxx_frag_create from protocol
> codes.
>
> Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
Applied.
^ permalink raw reply
* Re: [PATCH 6/7] Remove no longer needed ->equal callback
From: David Miller @ 2007-10-18 2:48 UTC (permalink / raw)
To: xemul; +Cc: netdev, devel
In-Reply-To: <4714C52B.3030100@openvz.org>
From: Pavel Emelyanov <xemul@openvz.org>
Date: Tue, 16 Oct 2007 18:05:31 +0400
> Since this callback is used to check for conflicts in
> hashtable when inserting a newly created frag queue, we can
> do the same by checking for matching the queue with the
> argument, used to create one.
>
> Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
Applied.
^ permalink raw reply
* Re: [patch 4/4] ucc_geth-fix-build-break-introduced-by-commit-09f75cd7bf13720738e6a196cc0107ce9a5bd5a0-checkpatch-fixes
From: Andrew Morton @ 2007-10-18 2:47 UTC (permalink / raw)
To: David Miller; +Cc: jeff, netdev, Emilian.Medve, galak, leoli, paulus
In-Reply-To: <20071017.193721.48531740.davem@davemloft.net>
On Wed, 17 Oct 2007 19:37:21 -0700 (PDT) David Miller <davem@davemloft.net> wrote:
> From: akpm@linux-foundation.org
> Date: Tue, 16 Oct 2007 14:24:12 -0700
>
> > From: Andrew Morton <akpm@linux-foundation.org>
> >
> > Cc: "David S. Miller" <davem@davemloft.net>
> > Cc: Emil Medve <Emilian.Medve@Freescale.com>
> > Cc: Jeff Garzik <jeff@garzik.org>
> > Cc: Kumar Gala <galak@gate.crashing.org>
> > Cc: Li Yang <leoli@freescale.com>
> > Cc: Paul Mackerras <paulus@samba.org>
> > Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>
> Please help my eyes, I can't see the fix:
>
> > @@ -3454,7 +3454,7 @@ static int ucc_geth_rx(struct ucc_geth_p
> > u16 length, howmany = 0;
> > u32 bd_status;
> > u8 *bdBuffer;
> > - struct net_device * dev;
> > + struct net_device *dev;
> >
> > ugeth_vdbg("%s: IN", __FUNCTION__);
> >
>
> This might be a coding style fix, as far as I can see, but I can't
> imagine how it can effect compilation at all. It just removes a space
> between the "*" and "dev" but that space is harmless.
uh, this is fallout from the akpmbot.
- Someone sent a patch which I named foo.patch
- When I applied it I saw valid checkpatch warnings, so I queed a patch to
fix them, called foo-checkpatch-fixes.patch with the intention that it later be
folded into foo.patch
- You merged foo.patch. But foo-checkpatch-fixes.patch still applied, so I
retained it.
- I sent you the runt foo-checkpatch-fixes.patch.
Normally when this happens I'll just curse the original patch author and
drop foo-checkpatch-fixes.patch. This time I didn't notice.
(Perhaps people should be adding a checkpatch run to their git-commit
scripts..)
^ permalink raw reply
* Re: [PATCH 7/7] Consolidate frag queues freeing
From: David Miller @ 2007-10-18 2:48 UTC (permalink / raw)
To: xemul; +Cc: netdev, devel
In-Reply-To: <4714C59E.50209@openvz.org>
From: Pavel Emelyanov <xemul@openvz.org>
Date: Tue, 16 Oct 2007 18:07:26 +0400
> Since we now allocate the queues in inet_fragment.c, we
> can safely free it in the same place. The ->destructor
> callback thus becomes optional for inet_frags.
>
> Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
Also applied, thanks a lot Pavel!
^ permalink raw reply
* Re: [patch 4/4] ucc_geth-fix-build-break-introduced-by-commit-09f75cd7bf13720738e6a196cc0107ce9a5bd5a0-checkpatch-fixes
From: Andrew Morton @ 2007-10-18 2:50 UTC (permalink / raw)
To: David Miller, jeff, netdev, Emilian.Medve, galak, leoli, paulus
In-Reply-To: <20071017194759.bc3571b3.akpm@linux-foundation.org>
On Wed, 17 Oct 2007 19:47:59 -0700 Andrew Morton <akpm@linux-foundation.org> wrote:
> - When I applied it I saw valid checkpatch warnings, so I queed a patch to
> fix them, called foo-checkpatch-fixes.patch with the intention that it later be
> folded into foo.patch
incidentally, the reason I do it this way is to attempt to educate
patch originators into running checkpatch, rather than out of sheer joy for
the task. Hopefully I'll have to do this less often as time passes.
box:/usr/src/25> ls -lR patches|grep checkpatch-fixes | wc -l
38
^ permalink raw reply
* Re: [PATCH 1/2] net: Let inet_diag and friends autoload
From: David Miller @ 2007-10-18 2:51 UTC (permalink / raw)
To: jdelvare; +Cc: netdev, kuznet
In-Reply-To: <200710161728.23733.jdelvare@suse.de>
From: Jean Delvare <jdelvare@suse.de>
Date: Tue, 16 Oct 2007 17:28:23 +0200
> By adding module aliases to inet_diag, tcp_diag and dccp_diag, we let
> them load automatically as needed. This makes tools like "ss" run
> faster.
>
> Signed-off-by: Jean Delvare <jdelvare@suse.de>
> Cc: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
> ---
> The alias naming scheme for tcp_diag and dccp_diag follows what was
> done for dccp_ipv4 and dccp_ipv6.
I'm concerned it might be dangerous to load the module in
this context, the RTNL semaphore is held and the module we
are requesting could easily try to take it and deadlock.
Currently we are lucky and this won't happen, but if the sub-proto
registration is every changed to do so, it will be a nightmare for
whoever is so unlucky to try and debug it.
^ permalink raw reply
* Re: [PATCH 7/7] [TCP]: Limit processing lost_retrans loop to work-to-do cases
From: TAKANO Ryousei @ 2007-10-18 3:50 UTC (permalink / raw)
To: davem; +Cc: ilpo.jarvinen, y-kodama, netdev
In-Reply-To: <20071011.173622.09942622.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Subject: Re: [PATCH 7/7] [TCP]: Limit processing lost_retrans loop to work-to-do cases
Date: Thu, 11 Oct 2007 17:36:22 -0700 (PDT)
> From: "Ilpo_Järvinen" <ilpo.jarvinen@helsinki.fi>
> Date: Thu, 11 Oct 2007 14:41:07 +0300
>
> > This addition of lost_retrans_low to tcp_sock might be
> > unnecessary, it's not clear how often lost_retrans worker is
> > executed when there wasn't work to do.
> >
> > Cc: TAKANO Ryousei <takano@axe-inc.co.jp>
> > Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
>
> Applied.
> + after(highest_sack_end_seq, tp->lost_retrans_low) &&
This limit degrades the performance of my test case described before,
since it misses opportunities of detecting loss of retransmitted packets.
The results are shown as follows:
linux-2.6.23
iteration :001 .... done. T = 19.758205 BW = 404.895077 Mbps
iteration :002 .... done. T = 19.241735 BW = 415.762924 Mbps
iteration :003 .... done. T = 18.998427 BW = 421.087495 Mbps
iteration :004 .... done. T = 18.971502 BW = 421.685113 Mbps
iteration :005 .... done. T = 19.298313 BW = 414.544009 Mbps
net-2.6 (current):
iteration :001 .... done. T = 43.672971 BW = 183.179660 Mbps
iteration :002 .... done. T = 16.668652 BW = 479.942828 Mbps
iteration :003 .... done. T = 25.569106 BW = 312.877581 Mbps
iteration :004 .... done. T = 55.314832 BW = 144.626671 Mbps
iteration :005 .... done. T = 35.377025 BW = 226.135464 Mbps
net-2.6 (no limit)
iteration :001 .... done. T = 16.907727 BW = 473.156445 Mbps
iteration :002 .... done. T = 16.662908 BW = 480.108272 Mbps
iteration :003 .... done. T = 16.536396 BW = 483.781350 Mbps
iteration :004 .... done. T = 16.565220 BW = 482.939560 Mbps
iteration :005 .... done. T = 16.528676 BW = 484.007309 Mbps
"no limit" does as follows:
if (tp->retrans_out && highest_sack_end_seq &&
icsk->icsk_ca_state == TCP_CA_Recovery)
flag |= tcp_mark_lost_retrans(sk, highest_sack_end_seq);
Ryousei Takano
^ permalink raw reply
* Re: [RFC] remove netpoll receive code
From: Jason Wessel @ 2007-10-18 3:52 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David S. Miller, Andrew Morton, netdev, linux-kernel
In-Reply-To: <20071017132131.1992bedd@freepuppy.rosehill>
Kgdb has been submitted for inclusion in the mainline kernel at this
point, along with an additional change to the netpoll rx path.
If it is the case that this needs to be implemented in another manner,
that is ok but please do let me know what the plans are for the API so
that the kgdboe code can be adapted.
Thanks,
Jason.
Stephen Hemminger wrote:
> The netpoll receive code is:
> 1. Not used by any in-tree features, it is used by kgdb-over-ether.
> 2. A nice hook for people doing nasty things like private binary network stacks or rootkits.
> 3. Unsecured by any of the normal firewalling code.
>
> Hopefully all distro's are smart enough to turn it off in their default config *nudge, nudge*.
> Doubly true for any distribution that claims to be secure or enterprise ready.
>
> I propose that we take out all the whole netpoll rx path. If/when kgdb gets submitted
> a better and alternative receive path can be added.
>
>
^ permalink raw reply
* [PATCH] gianfar: fix compile warning
From: Grant Likely @ 2007-10-18 3:54 UTC (permalink / raw)
To: Li Yang, Jeff Garzik, linuxppc-dev, netdev
From: Grant Likely <grant.likely@secretlab.ca>
Eliminate an uninitialized variable warning. The code is correct, but
a pointer to the automatic variable 'addr' is passed to dma_alloc_coherent.
Since addr has never been initialized, and the compiler doesn't know
what dma_alloc_coherent will do with it, it complains.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
drivers/net/gianfar.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
index cc288d8..c009ab6 100644
--- a/drivers/net/gianfar.c
+++ b/drivers/net/gianfar.c
@@ -696,7 +696,7 @@ int startup_gfar(struct net_device *dev)
{
struct txbd8 *txbdp;
struct rxbd8 *rxbdp;
- dma_addr_t addr;
+ dma_addr_t addr = 0;
unsigned long vaddr;
int i;
struct gfar_private *priv = netdev_priv(dev);
^ permalink raw reply related
* Re: [PATCH] mac80211: only honor IW_SCAN_THIS_ESSID in STA, IBSS, and AP modes
From: David Miller @ 2007-10-18 4:16 UTC (permalink / raw)
To: linville-2XuSBdqkA4R54TAoqtyWWQ
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
flamingice-R9e9/4HEdknk1uMJSBkQmQ, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <11926328942540-git-send-email-linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
From: "John W. Linville" <linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
Date: Wed, 17 Oct 2007 10:54:54 -0400
> The previous IW_SCAN_THIS_ESSID patch left a hole allowing scan
> requests on interfaces in inappropriate modes.
>
> Signed-off-by: John W. Linville <linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
John I've pulled from your tree and added this patch on top.
Thanks!
^ permalink raw reply
* Re: [PATCH 0/4] Fix race between sk_filter reassign and sk_clone()
From: David Miller @ 2007-10-18 4:23 UTC (permalink / raw)
To: xemul; +Cc: netdev, devel
In-Reply-To: <4715D9D2.8070102@openvz.org>
From: Pavel Emelyanov <xemul@openvz.org>
Date: Wed, 17 Oct 2007 13:45:54 +0400
> The race can result in that some sock will get an sk_filter
> pointer set to kfree-d memory. Look
>
> CPU1: CPU2:
> sk_clone(): sk_attach_filter():
> new_sk = sk_alloc(...);
> sock_copy(new_sk, sk);
> /* copies the filter ptr */
> ...
> filter = new_sk->sk_filter;
> if (filter)
> old_fp = sk->sk_filter;
> ...
> sk_filter_release(old_fp);
> if (atomic_dec_and_test(&old_fp->refcnt))
> atomic_inc(&filter->refcnt);
> /* true */
> call_rcu(&fp->rcu, kfree);
>
> that's it - after a quiescent state pass the new_sk will have
> a pointer on kfree-d filter.
>
> The same problem exists for detaching filter (SO_DETACH_FILTER).
>
> The proposed fix consists of 3 preparation patches and the fix itself.
>
> Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
Looks good, applied.
Thanks for fixing this bug Pavel!
^ permalink raw reply
* Re: [PATCH] Fix return type for snmp6_free_dev()
From: David Miller @ 2007-10-18 4:23 UTC (permalink / raw)
To: xemul; +Cc: netdev, devel
In-Reply-To: <4715E3F7.7050506@openvz.org>
From: Pavel Emelyanov <xemul@openvz.org>
Date: Wed, 17 Oct 2007 14:29:11 +0400
> This call is essentially void.
>
> Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
Applied.
^ permalink raw reply
* Re: [PATCH] Cleanup snmp6_alloc_dev()
From: David Miller @ 2007-10-18 4:25 UTC (permalink / raw)
To: xemul; +Cc: netdev, devel
In-Reply-To: <4715E79C.80306@openvz.org>
From: Pavel Emelyanov <xemul@openvz.org>
Date: Wed, 17 Oct 2007 14:44:44 +0400
> This functions is never called with NULL or not setup argument,
> so the checks inside are redundant.
>
> Also, the return value is always -ENOMEM, so no need in
> additional variable for this.
>
> Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
Applied.
^ permalink raw reply
* Re: [PATCH] Consolidate creation of kmem caches with "calculated" names
From: David Miller @ 2007-10-18 4:27 UTC (permalink / raw)
To: xemul; +Cc: netdev, devel
In-Reply-To: <4716098A.9000201@openvz.org>
From: Pavel Emelyanov <xemul@openvz.org>
Date: Wed, 17 Oct 2007 17:09:30 +0400
> Some places in network (like protocol registration and dccp)
> generate the kmem cache name with snprintf() to create caches
> for several protocols with similar names.
>
> Make the routine that makes this in one place. Possibly, this
> is better to be put in mm/sl[uoa]b.c, but I haven't found
> any other places in kernel that require such functionality,
> so put this code (temporary?) in net/core/util.c
>
> Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
I don't think we should be putting kmem_*() interfaces in
a place like net/core/utils.c, please submit that seperately
to the SLAB and/or SLUB maintainers, and once that it in
we can add the uses to the networking.
Tanks.
^ permalink raw reply
* Re: [PATCH 1/11] [IPSEC]: Fix pure tunnel modes involving IPv6
From: David Miller @ 2007-10-18 4:28 UTC (permalink / raw)
To: herbert; +Cc: yoshfuji, kaber, netdev
In-Reply-To: <E1Ii9yK-0006Ga-00@gondolin.me.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Wed, 17 Oct 2007 22:34:08 +0800
> [IPSEC]: Fix pure tunnel modes involving IPv6
>
> I noticed that my recent patch broke 6-on-4 pure IPsec tunnels (the ones
> that are only used for incompressible IPsec packets). Subsequent reviews
> show that I broke 6-on-6 pure tunnels more than three years ago and nobody
> ever noticed. I suppose every must be testing 6-on-6 IPComp with large
> pings which are very compressible :)
>
> This patch fixes both cases.
>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Applied.
^ permalink raw reply
* Re: [PATCH 2/11] [IPSEC]: Move tunnel parsing for IPv4 out of xfrm4_input
From: David Miller @ 2007-10-18 4:29 UTC (permalink / raw)
To: herbert; +Cc: yoshfuji, kaber, netdev
In-Reply-To: <E1Ii9yL-0006Gp-00@gondolin.me.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Wed, 17 Oct 2007 22:34:09 +0800
> [IPSEC]: Move tunnel parsing for IPv4 out of xfrm4_input
>
> This patch moves the tunnel parsing for IPv4 out of xfrm4_input and into
> xfrm4_tunnel. This change is in line with what IPv6 does and will allow
> us to merge the two input functions.
>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Applied.
^ permalink raw reply
* Re: [PATCH 3/11] [IPSEC]: Get nexthdr from caller in xfrm6_rcv_spi
From: David Miller @ 2007-10-18 4:29 UTC (permalink / raw)
To: herbert; +Cc: yoshfuji, kaber, netdev
In-Reply-To: <E1Ii9yM-0006Gx-00@gondolin.me.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Wed, 17 Oct 2007 22:34:10 +0800
> [IPSEC]: Get nexthdr from caller in xfrm6_rcv_spi
>
> Currently xfrm6_rcv_spi gets the nexthdr value itself from the packet.
> This means that we need to fix up the value in case we have a 4-on-6
> tunnel. Moving this logic into the caller simplifies things and allows
> us to merge the code with IPv4.
>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Applied.
^ permalink raw reply
* Re: [PATCH 4/11] [IPSEC]: Move ip_summed zapping out of xfrm6_rcv_spi
From: David Miller @ 2007-10-18 4:30 UTC (permalink / raw)
To: herbert; +Cc: yoshfuji, kaber, netdev
In-Reply-To: <E1Ii9yN-0006H5-00@gondolin.me.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Wed, 17 Oct 2007 22:34:11 +0800
> [IPSEC]: Move ip_summed zapping out of xfrm6_rcv_spi
>
> Not every transform needs to zap ip_summed. For example, a pure tunnel
> mode encapsulation does not affect the hardware checksum at all. In fact,
> every algorithm (that needs this) other than AH6 already does its own
> ip_summed zapping.
>
> This patch moves the zapping into AH6 which is in line with what IPv4 does.
>
> Possible future optimisation: Checksum the data as we copy them in IPComp.
>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Applied.
^ permalink raw reply
* Re: [PATCH 5/11] [IPSEC]: Fix length check in xfrm_parse_spi
From: David Miller @ 2007-10-18 4:30 UTC (permalink / raw)
To: herbert; +Cc: yoshfuji, kaber, netdev
In-Reply-To: <E1Ii9yP-0006HD-00@gondolin.me.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Wed, 17 Oct 2007 22:34:13 +0800
> [IPSEC]: Fix length check in xfrm_parse_spi
>
> Currently xfrm_parse_spi requires there to be 16 bytes for AH and ESP.
> In contrived cases there may not actually be 16 bytes there since the
> respective header sizes are less than that (8 and 12 currently).
>
> This patch changes the test to use the actual header length instead of 16.
>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Applied.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox