yes, since 2008/05/20

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commi...
--

Indeed. Most likely it was simply lost somewhere in the e-mail chain.

Then best thing to do is to retransmit it for next batch of patches.

Chris, here's the fix in question.
Thanks,

Willy

--
From 1ac06e0306d0192a7a4d9ea1c9e06d355ce7e7d3 Mon Sep 17 00:00:00 2001

From: Herbert Xu <herbert@gondor.apana.org.au>

Date: Tue, 20 May 2008 14:32:14 -0700

Subject: ipsec: Use the correct ip_local_out function
Because the IPsec output function xfrm_output_resume does its

own dst_output call it should always call __ip_local_output

instead of ip_local_output as the latter may invoke dst_output

directly.  Otherwise the return values from nf_hook and dst_output

may clash as they both use the value 1 but for different purposes.
When that clash occurs this can cause a packet to be used after

it has been freed which usually leads to a crash.  Because the

offending value is only returned from dst_output with qdiscs

such as HTB, this bug is normally not visible.
Thanks to Marco Berizzi for his perseverance in tracking this

down.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

Signed-off-by: David S. Miller <davem@davemloft.net>

---

 net/ipv4/route.c |    2 +-

 net/ipv6/route.c |    2 +-

 2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/route.c b/net/ipv4/route.c

index 92f90ae..df41026 100644

--- a/net/ipv4/route.c

+++ b/net/ipv4/route.c

@@ -160,7 +160,7 @@ static struct dst_ops ipv4_dst_ops = {

 	.negative_advice =	ipv4_negative_advice,

 	.link_failure =		ipv4_link_failure,

 	.update_pmtu =		ip_rt_update_pmtu,

-	.local_out =		ip_local_out,

+	.local_out =		__ip_local_out,

 	.entry_size =		sizeof(struct rtable),

 	.entries =		ATOMIC_INIT(0),

 };

diff --git a/net/ipv6/route.c b/net/ipv6/route.c

index b7a4a87..48534c6 100644

--- a/net/ipv6/route.c

+++ b/net/ipv6/route.c

@@ -109,7 +109,7 @@ static struct dst_ops ip6_dst_ops_template = {

 	.negative_advice	=	ip6_negative_advice,

 	.link_failure		=	ip6_link_failure,

 	.update_pmtu		...
[ message continues ]

From: Willy Tarreau <w@1wt.eu>
It did not get lost at all, it's perfectly sitting in my

networking -stable queue waiting for me to have an

opportunity to submit it to the -stable folks after I do

some testing.
If you ask me in the future about the status of a -stable

patch from the networking, I'll let you know exactly what

is happening to that patch wrt. stable.  I rarely forget

to submit an appropriate patch, and when I do forget you

merely have to let me know (rather than submitting it

to -stable directly, please don't do that) so that I can

fit it in with what I plan to submit to -stable already.
Right now is an unusual situation where I am in a 3 week

period of near constant travel, otherwise all of this

stuff would have been submitted already.  As I stated in

another reply to you, that period is ending tomorrow so I

should be able to crank out all of these patches to -stable

some time this week.
Thanks.

--

On Sun, 08 Jun 2008 07:10:51 -0700 (PDT)
As a netdev driver maintainer, I've been following this workflow for

patches that need to go to -stable:
1.  I submit a mainline patch to Jeff Garzik.

2.  Jeff submits to David.

3.  David submits to Linus.

4.  Linus merges patch into mainline.

5.  I extract mainline commit ID.

6.  I apply and test patch against appropriate 2.6.x.y git tree.

7.  I submit patch directly to -stable.
David's admonition tells me I'm doing it wrong, and that I should

submit the stable patch to Jeff as well.  Am I right?
Jay

--

I usually encourage a more-parallel process where you simply email

stable@kernel.org with the upstream commit id of the change(s) in question.
	Jeff
--

From: Jeff Garzik <jeff@garzik.org>
Right, and if Jeff wants to work things that way for the

networking drivers that's fine.
Personally, I like to make sure some time passes between when

a fix goes into Linus's tree and when I push it into -stable

because time is often what shakes out the last remaining problems

introduced by some change no matter how seeming obvious the

patch is.

--

The normal recommended method to get patches automatically sent to

stable is to add a "Cc: stable@kernel.org" line above your signed-off-by

line. That way it is automatically sent to stable when Linus merges it,

and David gets notified. This should *theorically* save him some of the

work consisting in checking his stable queue for unmerged patches, but

his workflow may be different. Also, this method is particularly suited

to ensure that patches don't get lost when the maintainer does not have

a specific stable queue, which is not the case here, according to David.
Regards,

Willy
--

Perfect, thank you David.

Willy
--