[IPSEC] : Use the correct ip_local_out function
diff mbox series

Message ID 20080520092511.GA9005@gondor.apana.org.au
State New, archived
Headers show
Series
  • [IPSEC] : Use the correct ip_local_out function
Related show

Commit Message

Herbert Xu May 20, 2008, 9:25 a.m. UTC
On Wed, May 14, 2008 at 10:19:57AM +0200, Marco Berizzi wrote:
> 
> I hope this helps.

OK found the problem, it was my fault after all :)

Dave, this patch needs to go into stable too.

[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>

Cheers,

Comments

Marco Berizzi May 20, 2008, 10:18 a.m. UTC | #1
Herbert Xu wrote:

> On Wed, May 14, 2008 at 10:19:57AM +0200, Marco Berizzi wrote:
> >
> > I hope this helps.
>
> OK found the problem, it was my fault after all :)
>
> Dave, this patch needs to go into stable too.
>
> [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.

Herbert,
many many thanks to you for fixing this bug.
I was going on with git bisect, but I was not
able anymore to reproduce the bug after four
git bisect step.
I'm going to apply immediately your patch to
2.6.25.4
Just for record, this is my last git bisect log:
root@Venus:/tmp/GIT/my2.6.25.y# git bisect log
git-bisect start
# good: [49914084e797530d9baaf51df9eda77babc98fa8] Linux 2.6.24
git-bisect good 49914084e797530d9baaf51df9eda77babc98fa8
# bad: [4b119e21d0c66c22e8ca03df05d9de623d0eb50f] Linux 2.6.25
git-bisect bad 4b119e21d0c66c22e8ca03df05d9de623d0eb50f
# bad: [dd5f5fed6c9458a7aa81eeef3732cc3a9891cfdf] Merge branch
'audit.b46' of
git://git.kernel.org/pub/scm/linux/kernel/git/viro/audit-current
git-bisect bad dd5f5fed6c9458a7aa81eeef3732cc3a9891cfdf
# bad: [fde3571fd8613483f1203d11394ae316c6b79a03] iwlwifi: avoid
firmware command sending if rfkill is enabled
git-bisect bad fde3571fd8613483f1203d11394ae316c6b79a03
# good: [1c7c2cdec3a6b2873439096983794a550d7ff65b] Merge
git://git.kernel.org/pub/scm/linux/kernel/git/bart/ide-2.6
git-bisect good 1c7c2cdec3a6b2873439096983794a550d7ff65b
# bad: [4c37799ccf6c722e0dad6a0677af22d1c23fb897] [NETFILTER]: Use
lowercase names for matches in Kconfig
git-bisect bad 4c37799ccf6c722e0dad6a0677af22d1c23fb897
# good: [f4798748dee00c807a63f5518f08b3df161e0f6d] Merge branch
'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid
git-bisect good f4798748dee00c807a63f5518f08b3df161e0f6d
# good: [9c55e01c0cc835818475a6ce8c4d684df9949ac8] [TCP]: Splice receive
support.
git-bisect good 9c55e01c0cc835818475a6ce8c4d684df9949ac8
# good: [8e8c71f1ab0ca1c4e74efad14533b991524dcb6c] [DCCP]: Honour and
make use of shutdown option set by user
git-bisect good 8e8c71f1ab0ca1c4e74efad14533b991524dcb6c
# good: [dd88590995de7c7ce108718a9ad52b3832e77814] [DECNET]: Remove
extra memset from dn_fib_check_nh
git-bisect good dd88590995de7c7ce108718a9ad52b3832e77814


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
David Miller May 20, 2008, 9:32 p.m. UTC | #2
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Tue, 20 May 2008 17:25:11 +0800

> On Wed, May 14, 2008 at 10:19:57AM +0200, Marco Berizzi wrote:
> > 
> > I hope this helps.
> 
> OK found the problem, it was my fault after all :)
> 
> Dave, this patch needs to go into stable too.
> 
> [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>

Applied and queued to -stable, thanks!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Marco Berizzi May 27, 2008, 9:04 a.m. UTC | #3
David Miller wrote:

> From: Herbert Xu <herbert@gondor.apana.org.au>
> Date: Tue, 20 May 2008 17:25:11 +0800
>
> > On Wed, May 14, 2008 at 10:19:57AM +0200, Marco Berizzi wrote:
> > >
> > > I hope this helps.
> >
> > OK found the problem, it was my fault after all :)
> >
> > Dave, this patch needs to go into stable too.
> >
> > [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>
>
> Applied and queued to -stable, thanks!

Just a confirmation message that this bug has been fixed
(one week uptime).


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Marco Berizzi June 7, 2008, 8:27 p.m. UTC | #4
David Miller wrote:

> From: Herbert Xu <herbert@gondor.apana.org.au>
> Date: Tue, 20 May 2008 17:25:11 +0800
> 
>> On Wed, May 14, 2008 at 10:19:57AM +0200, Marco Berizzi wrote:
>> > 
>> > I hope this helps.
>> 
>> OK found the problem, it was my fault after all :)
>> 
>> Dave, this patch needs to go into stable too.
>> 
>> [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>
> 
> Applied and queued to -stable, thanks!

Hi David,

I don't see this patch in Chris 2.6.25.6 -stable review message.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Willy Tarreau June 7, 2008, 8:43 p.m. UTC | #5
On Sat, Jun 07, 2008 at 10:27:58PM +0200, Marco Berizzi wrote:
> David Miller wrote:
> 
> > From: Herbert Xu <herbert@gondor.apana.org.au>
> > Date: Tue, 20 May 2008 17:25:11 +0800
> > 
> >> On Wed, May 14, 2008 at 10:19:57AM +0200, Marco Berizzi wrote:
> >> > 
> >> > I hope this helps.
> >> 
> >> OK found the problem, it was my fault after all :)
> >> 
> >> Dave, this patch needs to go into stable too.
> >> 
> >> [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>
> > 
> > Applied and queued to -stable, thanks!
> 
> Hi David,
> 
> I don't see this patch in Chris 2.6.25.6 -stable review message.

Is it already in mainline ? (stable should only contain already merged
patches). It generally helps the stable team if you indicate the commit
id, as it's easier to "git show" than to "git log|grep".

Regards,
Willy

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Marco Berizzi June 8, 2008, 11:56 a.m. UTC | #6
Willy Tarreau wrote:

> On Sat, Jun 07, 2008 at 10:27:58PM +0200, Marco Berizzi wrote:
>> David Miller wrote:
>> 
>> > From: Herbert Xu <herbert@gondor.apana.org.au>
>> > Date: Tue, 20 May 2008 17:25:11 +0800
>> > 
>> >> On Wed, May 14, 2008 at 10:19:57AM +0200, Marco Berizzi wrote:
>> >> > 
>> >> > I hope this helps.
>> >> 
>> >> OK found the problem, it was my fault after all :)
>> >> 
>> >> Dave, this patch needs to go into stable too.
>> >> 
>> >> [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>
>> > 
>> > Applied and queued to -stable, thanks!
>> 
>> Hi David,
>> 
>> I don't see this patch in Chris 2.6.25.6 -stable review message.
> 
> Is it already in mainline ?

yes, since 2008/05/20
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=1ac06e0306d0192a7a4d9ea1c9e06d355ce7e7d3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Willy Tarreau June 8, 2008, 12:36 p.m. UTC | #7
On Sun, Jun 08, 2008 at 01:56:01PM +0200, Marco Berizzi wrote:
> Willy Tarreau wrote:
> 
> > On Sat, Jun 07, 2008 at 10:27:58PM +0200, Marco Berizzi wrote:
> >> David Miller wrote:
> >> 
> >> > From: Herbert Xu <herbert@gondor.apana.org.au>
> >> > Date: Tue, 20 May 2008 17:25:11 +0800
> >> > 
> >> >> On Wed, May 14, 2008 at 10:19:57AM +0200, Marco Berizzi wrote:
> >> >> > 
> >> >> > I hope this helps.
> >> >> 
> >> >> OK found the problem, it was my fault after all :)
> >> >> 
> >> >> Dave, this patch needs to go into stable too.
> >> >> 
> >> >> [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>
> >> > 
> >> > Applied and queued to -stable, thanks!
> >> 
> >> Hi David,
> >> 
> >> I don't see this patch in Chris 2.6.25.6 -stable review message.
> > 
> > Is it already in mainline ?
> 
> yes, since 2008/05/20
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=1ac06e0306d0192a7a4d9ea1c9e06d355ce7e7d3

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		=	ip6_rt_update_pmtu,
-	.local_out		=	ip6_local_out,
+	.local_out		=	__ip6_local_out,
 	.entry_size		=	sizeof(struct rt6_info),
 	.entries		=	ATOMIC_INIT(0),
 };
David Miller June 8, 2008, 2:10 p.m. UTC | #8
From: Willy Tarreau <w@1wt.eu>
Date: Sun, 8 Jun 2008 14:36:01 +0200

> 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.

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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Willy Tarreau June 8, 2008, 2:19 p.m. UTC | #9
On Sun, Jun 08, 2008 at 07:10:51AM -0700, David Miller wrote:
> From: Willy Tarreau <w@1wt.eu>
> Date: Sun, 8 Jun 2008 14:36:01 +0200
> 
> > 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.
> 
> 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.

OK

> 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.

Perfect, thank you David.
Willy

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Jay Cliburn June 8, 2008, 3:38 p.m. UTC | #10
On Sun, 08 Jun 2008 07:10:51 -0700 (PDT)
David Miller <davem@davemloft.net> wrote:


> 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.


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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Willy Tarreau June 8, 2008, 4:06 p.m. UTC | #11
On Sun, Jun 08, 2008 at 10:38:35AM -0500, Jay Cliburn wrote:
> On Sun, 08 Jun 2008 07:10:51 -0700 (PDT)
> David Miller <davem@davemloft.net> wrote:
> 
> 
> > 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.
> 
> 
> 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?

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Jeff Garzik June 8, 2008, 8:07 p.m. UTC | #12
Jay Cliburn wrote:
> On Sun, 08 Jun 2008 07:10:51 -0700 (PDT)
> David Miller <davem@davemloft.net> wrote:
> 
> 
>> 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.
> 
> 
> 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?

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



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
David Miller June 9, 2008, 2:26 a.m. UTC | #13
From: Jeff Garzik <jeff@garzik.org>
Date: Sun, 08 Jun 2008 16:07:47 -0400

> Jay Cliburn wrote:
> > 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?
> 
> 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.

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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Patch
diff mbox series

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 12bba08..849b78a 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		=	ip6_rt_update_pmtu,
-	.local_out		=	ip6_local_out,
+	.local_out		=	__ip6_local_out,
 	.entry_size		=	sizeof(struct rt6_info),
 	.entries		=	ATOMIC_INIT(0),
 };