| Message ID | 20101006.003541.71128466.davem@davemloft.net |
|---|---|
| State | Not Applicable, archived |
| Delegated to: | David Miller |
| Headers | show |
In fact, that is what I intent to change originally. However, consider Timo's issue, I intent to submit this patch instead. On Wed, Oct 6, 2010 at 12:35 AM, David Miller <davem@davemloft.net> wrote: > > This should have been fixed by: > > -------------------- > commit ae2688d59b5f861dc70a091d003773975d2ae7fb > Author: Jianzhao Wang <jianzhao.wang@6wind.com> > Date: Wed Sep 8 14:35:43 2010 -0700 > > net: blackhole route should always be recalculated > > Blackhole routes are used when xfrm_lookup() returns -EREMOTE (error > triggered by IKE for example), hence this kind of route is always > temporary and so we should check if a better route exists for next > packets. > Bug has been introduced by commit d11a4dc18bf41719c9f0d7ed494d295dd2973b92. > > Signed-off-by: Jianzhao Wang <jianzhao.wang@6wind.com> > Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com> > Signed-off-by: David S. Miller <davem@davemloft.net> > > diff --git a/net/ipv4/route.c b/net/ipv4/route.c > index 3f56b6e..6298f75 100644 > --- a/net/ipv4/route.c > +++ b/net/ipv4/route.c > @@ -2738,6 +2738,11 @@ slow_output: > } > EXPORT_SYMBOL_GPL(__ip_route_output_key); > > +static struct dst_entry *ipv4_blackhole_dst_check(struct dst_entry *dst, u32 cookie) > +{ > + return NULL; > +} > + > static void ipv4_rt_blackhole_update_pmtu(struct dst_entry *dst, u32 mtu) > { > } > @@ -2746,7 +2751,7 @@ static struct dst_ops ipv4_dst_blackhole_ops = { > .family = AF_INET, > .protocol = cpu_to_be16(ETH_P_IP), > .destroy = ipv4_dst_destroy, > - .check = ipv4_dst_check, > + .check = ipv4_blackhole_dst_check, > .update_pmtu = ipv4_rt_blackhole_update_pmtu, > .entries = ATOMIC_INIT(0), > }; > -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
I did not pay attention to the CL, actually that did not fix the issue
I encountered. I have a connected UDP socket which will not escape
from the "blackhole" since it will never enter the ipv4_blackhole
function.
In udp_sendmsg(), if the socket is connected one and the dst entry is
obsolete, you will never have a chance to reset the socket's dst entry
since rt will not be NULL.
udp_sendmsg() {
....
if (connected)
rt = (struct rtable *)sk_dst_check(sk, 0);
if (rt == NULL) {
... blackhole_function_will_be_executed_here?
}
...
}
On Wed, Oct 6, 2010 at 12:47 AM, Chung-Yih Wang (王崇懿) <cywang@google.com> wrote:
> In fact, that is what I intent to change originally. However, consider
> Timo's issue, I intent to submit this patch instead.
>
> On Wed, Oct 6, 2010 at 12:35 AM, David Miller <davem@davemloft.net> wrote:
>>
>> This should have been fixed by:
>>
>> --------------------
>> commit ae2688d59b5f861dc70a091d003773975d2ae7fb
>> Author: Jianzhao Wang <jianzhao.wang@6wind.com>
>> Date: Wed Sep 8 14:35:43 2010 -0700
>>
>> net: blackhole route should always be recalculated
>>
>> Blackhole routes are used when xfrm_lookup() returns -EREMOTE (error
>> triggered by IKE for example), hence this kind of route is always
>> temporary and so we should check if a better route exists for next
>> packets.
>> Bug has been introduced by commit d11a4dc18bf41719c9f0d7ed494d295dd2973b92.
>>
>> Signed-off-by: Jianzhao Wang <jianzhao.wang@6wind.com>
>> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
>> Signed-off-by: David S. Miller <davem@davemloft.net>
>>
>> diff --git a/net/ipv4/route.c b/net/ipv4/route.c
>> index 3f56b6e..6298f75 100644
>> --- a/net/ipv4/route.c
>> +++ b/net/ipv4/route.c
>> @@ -2738,6 +2738,11 @@ slow_output:
>> }
>> EXPORT_SYMBOL_GPL(__ip_route_output_key);
>>
>> +static struct dst_entry *ipv4_blackhole_dst_check(struct dst_entry *dst, u32 cookie)
>> +{
>> + return NULL;
>> +}
>> +
>> static void ipv4_rt_blackhole_update_pmtu(struct dst_entry *dst, u32 mtu)
>> {
>> }
>> @@ -2746,7 +2751,7 @@ static struct dst_ops ipv4_dst_blackhole_ops = {
>> .family = AF_INET,
>> .protocol = cpu_to_be16(ETH_P_IP),
>> .destroy = ipv4_dst_destroy,
>> - .check = ipv4_dst_check,
>> + .check = ipv4_blackhole_dst_check,
>> .update_pmtu = ipv4_rt_blackhole_update_pmtu,
>> .entries = ATOMIC_INIT(0),
>> };
>>
>
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
As I am testing the l2tp/ipsec client(it is working fine on 2.6.32 but failed on 2.6.35 with the same client). Please see the following log dump for sk_dst_check(). <2>[ 201.390289] ==== sk_dst_check sk=C7485800 dst=C717AC60 obsolete=FFFFFFFF cookie=0 check=C0296510 <2>[ 211.247467] ==== sk_dst_check sk=C7485000 dst=C717AC60 obsolete=FFFFFFFF cookie=0 check=C0296510 [Basically, the ipsec tunnel is built and then free the dst_entry for this l2tp socket. Therefore, the obsolete entry should be reset in sk_dst_check(). However, the kernel 2.6.35 will do nothing here since the ipv4_dst_check still return the obsolete entry even if it is obsolete(dst->obsolete=2)] <2>[ 216.571350] ==== sk_dst_check sk=C7485400 dst=C6F670E0 obsolete=00000002 cookie=0 check=C0296510 <6>[ 218.069396] alg: No test for authenc(hmac(sha1),cbc(des3_ede)) (authenc(hmac(sha1-generic),cbc(des3_ede-generic))) <6>[ 218.164764] batt: 96%, 4114 mV, 0 mA (-6 avg), 27.2 C, 1305 mAh <2>[ 218.575561] ==== sk_dst_check sk=C7485400 dst=C6F670E0 obsolete=00000002 cookie=0 check=C0296510 <2>[ 220.580535] ==== sk_dst_check sk=C7485400 dst=C6F670E0 obsolete=00000002 cookie=0 check=C0296510 <2>[ 222.585754] ==== sk_dst_check sk=C7485400 dst=C6F670E0 obsolete=00000002 cookie=0 check=C0296510 <2>[ 224.591522] ==== sk_dst_check sk=C7485400 dst=C6F670E0 obsolete=00000002 cookie=0 check=C0296510 <2>[ 226.599212] ==== sk_dst_check sk=C7485400 dst=C6F670E0 obsolete=00000002 cookie=0 check=C0296510 <2>[ 228.602600] ==== sk_dst_check sk=C7485400 dst=C6F670E0 obsolete=00000002 cookie=0 check=C0296510 <2>[ 230.608062] ==== sk_dst_check sk=C7485400 dst=C6F670E0 obsolete=00000002 cookie=0 check=C0296510 <2>[ 232.613464] ==== sk_dst_check sk=C7485400 dst=C6F670E0 obsolete=00000002 cookie=0 check=C0296510 <2>[ 234.618896] ==== sk_dst_check sk=C7485400 dst=C6F670E0 obsolete=00000002 cookie=0 check=C0296510 <2>[ 236.623504] ==== sk_dst_check sk=C7485400 dst=C6F670E0 obsolete=00000002 cookie=0 check=C0296510 <2>[ 238.628936] ==== sk_dst_check sk=C7485400 dst=C6F670E0 obsolete=00000002 cookie=0 check=C0296510 <2>[ 240.634338] ==== sk_dst_check sk=C7485400 dst=C6F670E0 obsolete=00000002 cookie=0 check=C0296510 <2>[ 242.639709] ==== sk_dst_check sk=C7485400 dst=C6F670E0 obsolete=00000002 cookie=0 check=C0296510 <2>[ 244.645111] ==== sk_dst_check sk=C7485400 dst=C6F670E0 obsolete=00000002 cookie=0 check=C0296510 <2>[ 246.648864] ==== sk_dst_check sk=C7485400 dst=C6F670E0 obsolete=00000002 cookie=0 check=C0296510 <2>[ 248.654693] ==== sk_dst_check sk=C7485400 dst=C6F670E0 obsolete=00000002 cookie=0 check=C0296510 <2>[ 250.660125] ==== sk_dst_check sk=C7485400 dst=C6F670E0 obsolete=00000002 cookie=0 check=C0296510 <2>[ 252.665527] ==== sk_dst_check sk=C7485400 dst=C6F670E0 obsolete=00000002 cookie=0 check=C0296510 -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
After I gave it a try, that patch worked. Please ignore my patch then. Thanks! On Thu, Oct 7, 2010 at 12:37 PM, Chung-Yih Wang (王崇懿) <cywang@google.com> wrote: > As I am testing the l2tp/ipsec client(it is working fine on 2.6.32 but > failed on 2.6.35 with the same client). Please see the following log > dump for sk_dst_check(). > > <2>[ 201.390289] ==== sk_dst_check sk=C7485800 dst=C717AC60 > obsolete=FFFFFFFF cookie=0 check=C0296510 > <2>[ 211.247467] ==== sk_dst_check sk=C7485000 dst=C717AC60 > obsolete=FFFFFFFF cookie=0 check=C0296510 > > [Basically, the ipsec tunnel is built and then free the dst_entry for > this l2tp socket. Therefore, the obsolete entry should be reset in > sk_dst_check(). However, the kernel 2.6.35 will do nothing here since > the ipv4_dst_check still return the obsolete entry even if it is > obsolete(dst->obsolete=2)] > > <2>[ 216.571350] ==== sk_dst_check sk=C7485400 dst=C6F670E0 > obsolete=00000002 cookie=0 check=C0296510 > <6>[ 218.069396] alg: No test for authenc(hmac(sha1),cbc(des3_ede)) > (authenc(hmac(sha1-generic),cbc(des3_ede-generic))) > <6>[ 218.164764] batt: 96%, 4114 mV, 0 mA (-6 avg), 27.2 C, 1305 mAh > <2>[ 218.575561] ==== sk_dst_check sk=C7485400 dst=C6F670E0 > obsolete=00000002 cookie=0 check=C0296510 > <2>[ 220.580535] ==== sk_dst_check sk=C7485400 dst=C6F670E0 > obsolete=00000002 cookie=0 check=C0296510 > <2>[ 222.585754] ==== sk_dst_check sk=C7485400 dst=C6F670E0 > obsolete=00000002 cookie=0 check=C0296510 > <2>[ 224.591522] ==== sk_dst_check sk=C7485400 dst=C6F670E0 > obsolete=00000002 cookie=0 check=C0296510 > <2>[ 226.599212] ==== sk_dst_check sk=C7485400 dst=C6F670E0 > obsolete=00000002 cookie=0 check=C0296510 > <2>[ 228.602600] ==== sk_dst_check sk=C7485400 dst=C6F670E0 > obsolete=00000002 cookie=0 check=C0296510 > <2>[ 230.608062] ==== sk_dst_check sk=C7485400 dst=C6F670E0 > obsolete=00000002 cookie=0 check=C0296510 > <2>[ 232.613464] ==== sk_dst_check sk=C7485400 dst=C6F670E0 > obsolete=00000002 cookie=0 check=C0296510 > <2>[ 234.618896] ==== sk_dst_check sk=C7485400 dst=C6F670E0 > obsolete=00000002 cookie=0 check=C0296510 > <2>[ 236.623504] ==== sk_dst_check sk=C7485400 dst=C6F670E0 > obsolete=00000002 cookie=0 check=C0296510 > <2>[ 238.628936] ==== sk_dst_check sk=C7485400 dst=C6F670E0 > obsolete=00000002 cookie=0 check=C0296510 > <2>[ 240.634338] ==== sk_dst_check sk=C7485400 dst=C6F670E0 > obsolete=00000002 cookie=0 check=C0296510 > <2>[ 242.639709] ==== sk_dst_check sk=C7485400 dst=C6F670E0 > obsolete=00000002 cookie=0 check=C0296510 > <2>[ 244.645111] ==== sk_dst_check sk=C7485400 dst=C6F670E0 > obsolete=00000002 cookie=0 check=C0296510 > <2>[ 246.648864] ==== sk_dst_check sk=C7485400 dst=C6F670E0 > obsolete=00000002 cookie=0 check=C0296510 > <2>[ 248.654693] ==== sk_dst_check sk=C7485400 dst=C6F670E0 > obsolete=00000002 cookie=0 check=C0296510 > <2>[ 250.660125] ==== sk_dst_check sk=C7485400 dst=C6F670E0 > obsolete=00000002 cookie=0 check=C0296510 > <2>[ 252.665527] ==== sk_dst_check sk=C7485400 dst=C6F670E0 > obsolete=00000002 cookie=0 check=C0296510 > -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/net/ipv4/route.c b/net/ipv4/route.c index 3f56b6e..6298f75 100644 --- a/net/ipv4/route.c +++ b/net/ipv4/route.c @@ -2738,6 +2738,11 @@ slow_output: } EXPORT_SYMBOL_GPL(__ip_route_output_key); +static struct dst_entry *ipv4_blackhole_dst_check(struct dst_entry *dst, u32 cookie) +{ + return NULL; +} + static void ipv4_rt_blackhole_update_pmtu(struct dst_entry *dst, u32 mtu) { } @@ -2746,7 +2751,7 @@ static struct dst_ops ipv4_dst_blackhole_ops = { .family = AF_INET, .protocol = cpu_to_be16(ETH_P_IP), .destroy = ipv4_dst_destroy, - .check = ipv4_dst_check, + .check = ipv4_blackhole_dst_check, .update_pmtu = ipv4_rt_blackhole_update_pmtu, .entries = ATOMIC_INIT(0), };
This should have been fixed by: -------------------- commit ae2688d59b5f861dc70a091d003773975d2ae7fb Author: Jianzhao Wang <jianzhao.wang@6wind.com> Date: Wed Sep 8 14:35:43 2010 -0700 net: blackhole route should always be recalculated Blackhole routes are used when xfrm_lookup() returns -EREMOTE (error triggered by IKE for example), hence this kind of route is always temporary and so we should check if a better route exists for next packets. Bug has been introduced by commit d11a4dc18bf41719c9f0d7ed494d295dd2973b92. Signed-off-by: Jianzhao Wang <jianzhao.wang@6wind.com> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com> Signed-off-by: David S. Miller <davem@davemloft.net> -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html