* 2.6.38-rc5 tcp_connect oops: EIP = 0x0
@ 2011-02-18 5:03 George Spelvin
2011-02-18 6:32 ` Eric Dumazet
0 siblings, 1 reply; 11+ messages in thread
From: George Spelvin @ 2011-02-18 5:03 UTC (permalink / raw)
To: linux-kernel, linux-netdev; +Cc: linux
But wonder of wonders, kernel mode switching worked so I got to see the
oops on the text-mode console. It happened just as I tried to ssh out.
It's a Core 2 duo laptop (Dell E1405), 2 GB RAM, running a 32-bit kernel.
It's worth noting that I was using wired internet (b44 driver) and
not wireless.
I've been having a lot of weird lockups with 2.6.38-rcX, quite a change
from the very stable 2.6.36, but this is the first time I booted -rc5.
Also, the symptoms are very different; before the lockup did not seen
correlated with any particular activity, but the "lockup" was more like
something getting wedged in the kernel that more and more tasks would
get stuck on until everything stopped responding.
I should mention that this is transcribed by hand from the screen.
Oh, and also, it is far from the first time I ran ssh this boot.
(I re-tested it ater rebooting, just to be sure. Not a consistent
crash.)
Anyway, jumping to address 0 looks "interesting", so it seems worth reporting.
BUG: unable to handle kernel NULL pointer dereference at (null)
IP: [< (null)>] (null)
*pde = 00000000
Oops: 0000 [#1] SMP
last sysfs file: /sys/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda/uevent
Modules linked in: rfcomm btusb sco l2cap crc16 bluetooth b43 mac80211 cfg80211 [last unloaded: sha256_generic]
Pid: 12178, comm: ssh Not tainted 2.6.38-rc5 #227 Dell Inc. MXC061 /0MG532
EIP: 0060:[<00000000>] EFLAGS: 0021246 CPU: 0
EIP is at 0x0
EAX: f5947e00 EBX: f5982f80 ECX: 00000024 EDX: c148fe00
ESI: f5947e00 EDI: ebf29e54 EBP: ebf29ee0 ESP: ebf29dd0
DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
Process ssh (pid: 12178, ti=ebf28000 task=ebefc6c0 task.ti = ebef28000)
Stack:
c12c83ea 07e2427d 02000000 7b018f79 c117b827 0b996609 7b018f79 5f5f6644
f5982f80 00000000 ebf29e58 ebf29ee0 c12cc0e0 00001600 00000000 00000001
03641600 00000000 00000000 00000000 00000000 036423c0 3e6423c0 00000000
Call Trace:
[<c12c83ea>] ? tcp_connect+0xdd/0x3fd
[<c117b827>] ? secure_tcp_sequence_number+0x4f/0x65
[<c12cc0e0>] ? tcp_v4_connect+0x3c1/0x417
[<c12d6726>] ? inet_stream_connect+0x88/0x1fc
[<c1110705>] ? _copy_from_user+0x2b/0x10e
[<c129307d>] ? sys_connect+0x70/0x98
[<c108df0f>] ? get_empty_filp+0x9f/0x121
[<c108dfa0>] ? alloc_file+0xf/0x85
[<c1293287>] ? sock_alloc_file+0x97/0xeb
[<c108b758>] ? fd_install+0x1b/0x38
[<c12932f6>] ? sock_map_fd+0x1b/0x20
[<c1293bdf>] ? sys_socketcall+0x9d/0x291
[<c1002750>] ? sysenter_do_call+0x12/0x26
Code: Bad EIP value
EIP: [<00000000>] 0x0 SS:ESP 0068:ebf29dd0
CR2: 0000000000000000
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: 2.6.38-rc5 tcp_connect oops: EIP = 0x0
2011-02-18 5:03 2.6.38-rc5 tcp_connect oops: EIP = 0x0 George Spelvin
@ 2011-02-18 6:32 ` Eric Dumazet
2011-02-18 9:57 ` [PATCH] net: Add default_advmss() methods to blackhole dst_ops Eric Dumazet
0 siblings, 1 reply; 11+ messages in thread
From: Eric Dumazet @ 2011-02-18 6:32 UTC (permalink / raw)
To: George Spelvin; +Cc: linux-kernel, netdev
Le vendredi 18 février 2011 à 00:03 -0500, George Spelvin a écrit :
> But wonder of wonders, kernel mode switching worked so I got to see the
> oops on the text-mode console. It happened just as I tried to ssh out.
>
CC netdev (removed linux-netdev)
I'll take a look this morning, thanks for the report.
> It's a Core 2 duo laptop (Dell E1405), 2 GB RAM, running a 32-bit kernel.
> It's worth noting that I was using wired internet (b44 driver) and
> not wireless.
>
> I've been having a lot of weird lockups with 2.6.38-rcX, quite a change
> from the very stable 2.6.36, but this is the first time I booted -rc5.
> Also, the symptoms are very different; before the lockup did not seen
> correlated with any particular activity, but the "lockup" was more like
> something getting wedged in the kernel that more and more tasks would
> get stuck on until everything stopped responding.
>
> I should mention that this is transcribed by hand from the screen.
> Oh, and also, it is far from the first time I ran ssh this boot.
> (I re-tested it ater rebooting, just to be sure. Not a consistent
> crash.)
>
> Anyway, jumping to address 0 looks "interesting", so it seems worth reporting.
>
> BUG: unable to handle kernel NULL pointer dereference at (null)
> IP: [< (null)>] (null)
> *pde = 00000000
> Oops: 0000 [#1] SMP
> last sysfs file: /sys/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda/uevent
> Modules linked in: rfcomm btusb sco l2cap crc16 bluetooth b43 mac80211 cfg80211 [last unloaded: sha256_generic]
>
> Pid: 12178, comm: ssh Not tainted 2.6.38-rc5 #227 Dell Inc. MXC061 /0MG532
> EIP: 0060:[<00000000>] EFLAGS: 0021246 CPU: 0
> EIP is at 0x0
> EAX: f5947e00 EBX: f5982f80 ECX: 00000024 EDX: c148fe00
> ESI: f5947e00 EDI: ebf29e54 EBP: ebf29ee0 ESP: ebf29dd0
> DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
> Process ssh (pid: 12178, ti=ebf28000 task=ebefc6c0 task.ti = ebef28000)
> Stack:
> c12c83ea 07e2427d 02000000 7b018f79 c117b827 0b996609 7b018f79 5f5f6644
> f5982f80 00000000 ebf29e58 ebf29ee0 c12cc0e0 00001600 00000000 00000001
> 03641600 00000000 00000000 00000000 00000000 036423c0 3e6423c0 00000000
> Call Trace:
> [<c12c83ea>] ? tcp_connect+0xdd/0x3fd
> [<c117b827>] ? secure_tcp_sequence_number+0x4f/0x65
> [<c12cc0e0>] ? tcp_v4_connect+0x3c1/0x417
> [<c12d6726>] ? inet_stream_connect+0x88/0x1fc
> [<c1110705>] ? _copy_from_user+0x2b/0x10e
> [<c129307d>] ? sys_connect+0x70/0x98
> [<c108df0f>] ? get_empty_filp+0x9f/0x121
> [<c108dfa0>] ? alloc_file+0xf/0x85
> [<c1293287>] ? sock_alloc_file+0x97/0xeb
> [<c108b758>] ? fd_install+0x1b/0x38
> [<c12932f6>] ? sock_map_fd+0x1b/0x20
> [<c1293bdf>] ? sys_socketcall+0x9d/0x291
> [<c1002750>] ? sysenter_do_call+0x12/0x26
> Code: Bad EIP value
> EIP: [<00000000>] 0x0 SS:ESP 0068:ebf29dd0
> CR2: 0000000000000000
^ permalink raw reply [flat|nested] 11+ messages in thread
* [PATCH] net: Add default_advmss() methods to blackhole dst_ops
2011-02-18 6:32 ` Eric Dumazet
@ 2011-02-18 9:57 ` Eric Dumazet
2011-02-18 13:16 ` Changli Gao
2011-02-18 19:58 ` [PATCH] net: Add " George Spelvin
0 siblings, 2 replies; 11+ messages in thread
From: Eric Dumazet @ 2011-02-18 9:57 UTC (permalink / raw)
To: George Spelvin, David Miller; +Cc: linux-kernel, netdev, Roland Dreier
Le vendredi 18 février 2011 à 07:32 +0100, Eric Dumazet a écrit :
> Le vendredi 18 février 2011 à 00:03 -0500, George Spelvin a écrit :
> > But wonder of wonders, kernel mode switching worked so I got to see the
> > oops on the text-mode console. It happened just as I tried to ssh out.
> >
>
> CC netdev (removed linux-netdev)
>
> I'll take a look this morning, thanks for the report.
>
> > It's a Core 2 duo laptop (Dell E1405), 2 GB RAM, running a 32-bit kernel.
> > It's worth noting that I was using wired internet (b44 driver) and
> > not wireless.
> >
> > I've been having a lot of weird lockups with 2.6.38-rcX, quite a change
> > from the very stable 2.6.36, but this is the first time I booted -rc5.
> > Also, the symptoms are very different; before the lockup did not seen
> > correlated with any particular activity, but the "lockup" was more like
> > something getting wedged in the kernel that more and more tasks would
> > get stuck on until everything stopped responding.
> >
> > I should mention that this is transcribed by hand from the screen.
> > Oh, and also, it is far from the first time I ran ssh this boot.
> > (I re-tested it ater rebooting, just to be sure. Not a consistent
> > crash.)
> >
> > Anyway, jumping to address 0 looks "interesting", so it seems worth reporting.
> >
> > BUG: unable to handle kernel NULL pointer dereference at (null)
> > IP: [< (null)>] (null)
> > *pde = 00000000
> > Oops: 0000 [#1] SMP
> > last sysfs file: /sys/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda/uevent
> > Modules linked in: rfcomm btusb sco l2cap crc16 bluetooth b43 mac80211 cfg80211 [last unloaded: sha256_generic]
> >
> > Pid: 12178, comm: ssh Not tainted 2.6.38-rc5 #227 Dell Inc. MXC061 /0MG532
> > EIP: 0060:[<00000000>] EFLAGS: 0021246 CPU: 0
> > EIP is at 0x0
> > EAX: f5947e00 EBX: f5982f80 ECX: 00000024 EDX: c148fe00
> > ESI: f5947e00 EDI: ebf29e54 EBP: ebf29ee0 ESP: ebf29dd0
> > DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
> > Process ssh (pid: 12178, ti=ebf28000 task=ebefc6c0 task.ti = ebef28000)
> > Stack:
> > c12c83ea 07e2427d 02000000 7b018f79 c117b827 0b996609 7b018f79 5f5f6644
> > f5982f80 00000000 ebf29e58 ebf29ee0 c12cc0e0 00001600 00000000 00000001
> > 03641600 00000000 00000000 00000000 00000000 036423c0 3e6423c0 00000000
> > Call Trace:
> > [<c12c83ea>] ? tcp_connect+0xdd/0x3fd
> > [<c117b827>] ? secure_tcp_sequence_number+0x4f/0x65
> > [<c12cc0e0>] ? tcp_v4_connect+0x3c1/0x417
> > [<c12d6726>] ? inet_stream_connect+0x88/0x1fc
> > [<c1110705>] ? _copy_from_user+0x2b/0x10e
> > [<c129307d>] ? sys_connect+0x70/0x98
> > [<c108df0f>] ? get_empty_filp+0x9f/0x121
> > [<c108dfa0>] ? alloc_file+0xf/0x85
> > [<c1293287>] ? sock_alloc_file+0x97/0xeb
> > [<c108b758>] ? fd_install+0x1b/0x38
> > [<c12932f6>] ? sock_map_fd+0x1b/0x20
> > [<c1293bdf>] ? sys_socketcall+0x9d/0x291
> > [<c1002750>] ? sysenter_do_call+0x12/0x26
> > Code: Bad EIP value
> > EIP: [<00000000>] 0x0 SS:ESP 0068:ebf29dd0
> > CR2: 0000000000000000
I suspect following patch is needed
CC Roland Dreier <roland@purestorage.com> because he fixed the
default_mtu problem in commit ec831ea72ee5d7d47
(net: Add default_mtu() methods to blackhole dst_ops)
Thanks !
[PATCH] net: Add default_advmss() methods to blackhole dst_ops
Commit 0dbaee3b37e118a (net: Abstract default ADVMSS behind an
accessor.) introduced a possible crash in tcp_connect_init(), when
dst->default_advmss() is called from dst_metric_advmss()
Reported-by: George Spelvin <linux@horizon.com>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
CC: Roland Dreier <roland@purestorage.com>
---
net/ipv4/route.c | 7 +++++++
net/ipv6/route.c | 6 ++++++
2 files changed, 13 insertions(+)
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index 788a3e7..5edb605 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -2712,6 +2712,12 @@ static unsigned int ipv4_blackhole_default_mtu(const struct dst_entry *dst)
return 0;
}
+static unsigned int ipv4_blackhole_default_advmss(const struct dst_entry *dst)
+{
+ return 256;
+}
+
+
static void ipv4_rt_blackhole_update_pmtu(struct dst_entry *dst, u32 mtu)
{
}
@@ -2722,6 +2728,7 @@ static struct dst_ops ipv4_dst_blackhole_ops = {
.destroy = ipv4_dst_destroy,
.check = ipv4_blackhole_dst_check,
.default_mtu = ipv4_blackhole_default_mtu,
+ .default_advmss = ipv4_blackhole_default_advmss,
.update_pmtu = ipv4_rt_blackhole_update_pmtu,
};
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index 1c29f95..2eeeabb 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -118,6 +118,11 @@ static unsigned int ip6_blackhole_default_mtu(const struct dst_entry *dst)
return 0;
}
+static unsigned int ip6_blackhole_default_advmss(const struct dst_entry *dst)
+{
+ return 256;
+}
+
static void ip6_rt_blackhole_update_pmtu(struct dst_entry *dst, u32 mtu)
{
}
@@ -128,6 +133,7 @@ static struct dst_ops ip6_dst_blackhole_ops = {
.destroy = ip6_dst_destroy,
.check = ip6_dst_check,
.default_mtu = ip6_blackhole_default_mtu,
+ .default_advmss = ip6_blackhole_default_advmss,
.update_pmtu = ip6_rt_blackhole_update_pmtu,
};
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] net: Add default_advmss() methods to blackhole dst_ops
2011-02-18 9:57 ` [PATCH] net: Add default_advmss() methods to blackhole dst_ops Eric Dumazet
@ 2011-02-18 13:16 ` Changli Gao
2011-02-18 13:24 ` Eric Dumazet
2011-02-18 19:58 ` [PATCH] net: Add " George Spelvin
1 sibling, 1 reply; 11+ messages in thread
From: Changli Gao @ 2011-02-18 13:16 UTC (permalink / raw)
To: Eric Dumazet
Cc: George Spelvin, David Miller, linux-kernel, netdev, Roland Dreier
On Fri, Feb 18, 2011 at 5:57 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
>
> I suspect following patch is needed
>
> CC Roland Dreier <roland@purestorage.com> because he fixed the
> default_mtu problem in commit ec831ea72ee5d7d47
> (net: Add default_mtu() methods to blackhole dst_ops)
>
> Thanks !
>
> [PATCH] net: Add default_advmss() methods to blackhole dst_ops
>
> Commit 0dbaee3b37e118a (net: Abstract default ADVMSS behind an
> accessor.) introduced a possible crash in tcp_connect_init(), when
> dst->default_advmss() is called from dst_metric_advmss()
>
> Reported-by: George Spelvin <linux@horizon.com>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> CC: Roland Dreier <roland@purestorage.com>
> ---
> net/ipv4/route.c | 7 +++++++
> net/ipv6/route.c | 6 ++++++
> 2 files changed, 13 insertions(+)
>
> diff --git a/net/ipv4/route.c b/net/ipv4/route.c
> index 788a3e7..5edb605 100644
> --- a/net/ipv4/route.c
> +++ b/net/ipv4/route.c
> @@ -2712,6 +2712,12 @@ static unsigned int ipv4_blackhole_default_mtu(const struct dst_entry *dst)
> return 0;
> }
>
> +static unsigned int ipv4_blackhole_default_advmss(const struct dst_entry *dst)
> +{
> + return 256;
> +}
> +
> +
I am wondering why magic number 256 is used here. Is there a special
reason? Thanks.
--
Regards,
Changli Gao(xiaosuo@gmail.com)
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] net: Add default_advmss() methods to blackhole dst_ops
2011-02-18 13:16 ` Changli Gao
@ 2011-02-18 13:24 ` Eric Dumazet
2011-02-18 13:29 ` Changli Gao
0 siblings, 1 reply; 11+ messages in thread
From: Eric Dumazet @ 2011-02-18 13:24 UTC (permalink / raw)
To: Changli Gao
Cc: George Spelvin, David Miller, linux-kernel, netdev, Roland Dreier
Le vendredi 18 février 2011 à 21:16 +0800, Changli Gao a écrit :
> I am wondering why magic number 256 is used here. Is there a special
> reason? Thanks.
>
It really doesnt matter. SYN message will be dropped anyway.
256 happens to be the default value
of /proc/sys/net/ipv4/route/min_adv_mss
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] net: Add default_advmss() methods to blackhole dst_ops
2011-02-18 13:24 ` Eric Dumazet
@ 2011-02-18 13:29 ` Changli Gao
2011-02-18 13:33 ` Eric Dumazet
0 siblings, 1 reply; 11+ messages in thread
From: Changli Gao @ 2011-02-18 13:29 UTC (permalink / raw)
To: Eric Dumazet
Cc: George Spelvin, David Miller, linux-kernel, netdev, Roland Dreier
On Fri, Feb 18, 2011 at 9:24 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le vendredi 18 février 2011 à 21:16 +0800, Changli Gao a écrit :
>
>> I am wondering why magic number 256 is used here. Is there a special
>> reason? Thanks.
>>
>
> It really doesnt matter. SYN message will be dropped anyway.
>
> 256 happens to be the default value
> of /proc/sys/net/ipv4/route/min_adv_mss
>
Thanks for your explaining. IMHO, ip_rt_min_advmss is better than a
magic number, here.
--
Regards,
Changli Gao(xiaosuo@gmail.com)
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] net: Add default_advmss() methods to blackhole dst_ops
2011-02-18 13:29 ` Changli Gao
@ 2011-02-18 13:33 ` Eric Dumazet
2011-02-18 13:43 ` Daniel Baluta
2011-02-18 13:44 ` [PATCH v2] net: provide " Eric Dumazet
0 siblings, 2 replies; 11+ messages in thread
From: Eric Dumazet @ 2011-02-18 13:33 UTC (permalink / raw)
To: Changli Gao
Cc: George Spelvin, David Miller, linux-kernel, netdev, Roland Dreier
Le vendredi 18 février 2011 à 21:29 +0800, Changli Gao a écrit :
> On Fri, Feb 18, 2011 at 9:24 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> > Le vendredi 18 février 2011 à 21:16 +0800, Changli Gao a écrit :
> >
> >> I am wondering why magic number 256 is used here. Is there a special
> >> reason? Thanks.
> >>
> >
> > It really doesnt matter. SYN message will be dropped anyway.
> >
> > 256 happens to be the default value
> > of /proc/sys/net/ipv4/route/min_adv_mss
> >
>
> Thanks for your explaining. IMHO, ip_rt_min_advmss is better than a
> magic number, here.
>
I had this exact idea but found we need struct net pointer to get this
value, not provided in parameters, so I falled back to the 256 value.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] net: Add default_advmss() methods to blackhole dst_ops
2011-02-18 13:33 ` Eric Dumazet
@ 2011-02-18 13:43 ` Daniel Baluta
2011-02-18 13:44 ` [PATCH v2] net: provide " Eric Dumazet
1 sibling, 0 replies; 11+ messages in thread
From: Daniel Baluta @ 2011-02-18 13:43 UTC (permalink / raw)
To: Eric Dumazet
Cc: Changli Gao, George Spelvin, David Miller, linux-kernel, netdev,
Roland Dreier
On Fri, Feb 18, 2011 at 3:33 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le vendredi 18 février 2011 à 21:29 +0800, Changli Gao a écrit :
>> On Fri, Feb 18, 2011 at 9:24 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>> > Le vendredi 18 février 2011 à 21:16 +0800, Changli Gao a écrit :
>> >
>> >> I am wondering why magic number 256 is used here. Is there a special
>> >> reason? Thanks.
>> >>
>> >
>> > It really doesnt matter. SYN message will be dropped anyway.
>> >
>> > 256 happens to be the default value
>> > of /proc/sys/net/ipv4/route/min_adv_mss
Perhaps a comment would make sense then.
thanks,
Daniel.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [PATCH v2] net: provide default_advmss() methods to blackhole dst_ops
2011-02-18 13:33 ` Eric Dumazet
2011-02-18 13:43 ` Daniel Baluta
@ 2011-02-18 13:44 ` Eric Dumazet
2011-02-18 19:39 ` David Miller
1 sibling, 1 reply; 11+ messages in thread
From: Eric Dumazet @ 2011-02-18 13:44 UTC (permalink / raw)
To: Changli Gao
Cc: George Spelvin, David Miller, linux-kernel, netdev,
Roland Dreier, Daniel Baluta
Le vendredi 18 février 2011 à 14:33 +0100, Eric Dumazet a écrit :
> I had this exact idea but found we need struct net pointer to get this
> value, not provided in parameters, so I falled back to the 256 value.
>
>
Hmm, reading again this stuff, maybe we can just use
ipv4_default_advmss() instead of a custom one.
dst->dev should be available
[PATCH] net: provide default_advmss() methods to blackhole dst_ops
Commit 0dbaee3b37e118a (net: Abstract default ADVMSS behind an
accessor.) introduced a possible crash in tcp_connect_init(), when
dst->default_advmss() is called from dst_metric_advmss()
Reported-by: George Spelvin <linux@horizon.com>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
CC: Roland Dreier <roland@purestorage.com>
CC: Changli Gao <xiaosuo@gmail.com>
CC: Daniel Baluta <dbaluta@ixiacom.com>
---
net/ipv4/route.c | 1 +
net/ipv6/route.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index 788a3e7..6ed6603 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -2722,6 +2722,7 @@ static struct dst_ops ipv4_dst_blackhole_ops = {
.destroy = ipv4_dst_destroy,
.check = ipv4_blackhole_dst_check,
.default_mtu = ipv4_blackhole_default_mtu,
+ .default_advmss = ipv4_default_advmss,
.update_pmtu = ipv4_rt_blackhole_update_pmtu,
};
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index 1c29f95..a998db6 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -128,6 +128,7 @@ static struct dst_ops ip6_dst_blackhole_ops = {
.destroy = ip6_dst_destroy,
.check = ip6_dst_check,
.default_mtu = ip6_blackhole_default_mtu,
+ .default_advmss = ip6_default_advmss,
.update_pmtu = ip6_rt_blackhole_update_pmtu,
};
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH v2] net: provide default_advmss() methods to blackhole dst_ops
2011-02-18 13:44 ` [PATCH v2] net: provide " Eric Dumazet
@ 2011-02-18 19:39 ` David Miller
0 siblings, 0 replies; 11+ messages in thread
From: David Miller @ 2011-02-18 19:39 UTC (permalink / raw)
To: eric.dumazet; +Cc: xiaosuo, linux, linux-kernel, netdev, roland, dbaluta
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 18 Feb 2011 14:44:32 +0100
> Le vendredi 18 février 2011 à 14:33 +0100, Eric Dumazet a écrit :
>
>> I had this exact idea but found we need struct net pointer to get this
>> value, not provided in parameters, so I falled back to the 256 value.
>>
>>
>
> Hmm, reading again this stuff, maybe we can just use
> ipv4_default_advmss() instead of a custom one.
>
> dst->dev should be available
>
> [PATCH] net: provide default_advmss() methods to blackhole dst_ops
>
> Commit 0dbaee3b37e118a (net: Abstract default ADVMSS behind an
> accessor.) introduced a possible crash in tcp_connect_init(), when
> dst->default_advmss() is called from dst_metric_advmss()
>
> Reported-by: George Spelvin <linux@horizon.com>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Yes, this is a lot better, applied.
Thanks!
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] net: Add default_advmss() methods to blackhole dst_ops
2011-02-18 9:57 ` [PATCH] net: Add default_advmss() methods to blackhole dst_ops Eric Dumazet
2011-02-18 13:16 ` Changli Gao
@ 2011-02-18 19:58 ` George Spelvin
1 sibling, 0 replies; 11+ messages in thread
From: George Spelvin @ 2011-02-18 19:58 UTC (permalink / raw)
To: davem, eric.dumazet, linux; +Cc: linux-kernel, netdev, roland
This makes sense to me; I was having trouble at the time with a loose
ethernet cable (broken RJ45 retention clip), so the cable could have
come unplugged at the time I tried to make the connection.
Thank you very much!
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2011-02-18 19:58 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-02-18 5:03 2.6.38-rc5 tcp_connect oops: EIP = 0x0 George Spelvin
2011-02-18 6:32 ` Eric Dumazet
2011-02-18 9:57 ` [PATCH] net: Add default_advmss() methods to blackhole dst_ops Eric Dumazet
2011-02-18 13:16 ` Changli Gao
2011-02-18 13:24 ` Eric Dumazet
2011-02-18 13:29 ` Changli Gao
2011-02-18 13:33 ` Eric Dumazet
2011-02-18 13:43 ` Daniel Baluta
2011-02-18 13:44 ` [PATCH v2] net: provide " Eric Dumazet
2011-02-18 19:39 ` David Miller
2011-02-18 19:58 ` [PATCH] net: Add " George Spelvin
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®