From: Arnaldo Carvalho de Melo <acme@conectiva.com.br>
To: Lennert Buytenhek <buytenh@wantstofly.org>
Cc: "David S. Miller" <davem@davemloft.net>,
hadi@cyberus.ca, yoshfuji@linux-ipv6.org, jgarzik@pobox.com,
netdev@oss.sgi.com
Subject: Re: BUG: dst underflow (again)
Date: Sat, 06 Nov 2004 06:17:19 -0200 [thread overview]
Message-ID: <418C888F.3060509@conectiva.com.br> (raw)
In-Reply-To: <20041106090211.GA8106@xi.wantstofly.org>
Lennert Buytenhek wrote:
> On Fri, Nov 05, 2004 at 04:23:19PM -0800, David S. Miller wrote:
>
>
>>>>>IPSEC.. not that I know of. So unless my distro does stuff behind
>>>>>my back, no. How do I make sure?
>>>>
>>>>setkey -DP
>>>
>>>Thanks. Both machines I'm seeing this problem on have:
>>>
>>># setkey -DP
>>>No SPD entries.
>>>#
>>
>>Well, xfrm_lookup() is returning an error somehow, that's the only
>>way to execute dst_release() in udpv6_sendmsg(). And xfrm_lookup()
>>only returns errors if IPSEC policies have been configured either
>>globally or locally for the socket.
>
>
> Please note that my traces were made on the Fedora Core 2 kernel
> ('2.6.8-1.521smp'), where these codepaths all look a bit different.
>
> I'm hoping to try a mainline kernel on one of these boxes soon.
>
Lennert, could you try to reproduce what I observed at Jeff Garzik's
ipv6 gateway, running first:
[acme@pretzel network-scripts]$ for a in $(seq 1 10) ; do dmesg | grep
'^BUG: dst underf' | md5sum ; ping6 -c 1 www.linux-ipv6.org | head -2 ;
sleep 2 ; done
edc1a887cbd8ec99257c5b00a2b95b1e -
PING www.linux-ipv6.org(pc14.fujisawa.wide.ad.jp) 56 data bytes
64 bytes from pc14.fujisawa.wide.ad.jp: icmp_seq=0 ttl=61 time=302 ms
4b422fb5ef1abd2a9d7c0d2eac16ed95 -
PING www.linux-ipv6.org(pc14.fujisawa.wide.ad.jp) 56 data bytes
64 bytes from pc14.fujisawa.wide.ad.jp: icmp_seq=0 ttl=61 time=308 ms
337774afcf7944ca6f8769b021890bfc -
PING www.linux-ipv6.org(pc14.fujisawa.wide.ad.jp) 56 data bytes
64 bytes from pc14.fujisawa.wide.ad.jp: icmp_seq=0 ttl=60 time=309 ms
bfb23793729c27093f51f478ce524a15 -
PING www.linux-ipv6.org(pc14.fujisawa.wide.ad.jp) 56 data bytes
64 bytes from pc14.fujisawa.wide.ad.jp: icmp_seq=0 ttl=61 time=308 ms
1fbef3369bdca718e6f59e9ec8ddb540 -
PING www.linux-ipv6.org(pc14.fujisawa.wide.ad.jp) 56 data bytes
64 bytes from pc14.fujisawa.wide.ad.jp: icmp_seq=0 ttl=61 time=308 ms
bd93a08ff06688789ab4e94b761571d6 -
PING www.linux-ipv6.org(pc14.fujisawa.wide.ad.jp) 56 data bytes
64 bytes from pc14.fujisawa.wide.ad.jp: icmp_seq=0 ttl=60 time=308 ms
cdc166d49c07b98a6668af21b7808107 -
PING www.linux-ipv6.org(pc14.fujisawa.wide.ad.jp) 56 data bytes
64 bytes from pc14.fujisawa.wide.ad.jp: icmp_seq=0 ttl=61 time=308 ms
b10df2f221b0a6b9cb80d511ddf0034f -
PING www.linux-ipv6.org(pc14.fujisawa.wide.ad.jp) 56 data bytes
64 bytes from pc14.fujisawa.wide.ad.jp: icmp_seq=0 ttl=61 time=307 ms
38748d154ea1cce6097221fa442daf57 -
PING www.linux-ipv6.org(pc14.fujisawa.wide.ad.jp) 56 data bytes
64 bytes from pc14.fujisawa.wide.ad.jp: icmp_seq=0 ttl=61 time=307 ms
0d9ee97a76410ed20b2cb0dc958cd146 -
PING www.linux-ipv6.org(pc14.fujisawa.wide.ad.jp) 56 data bytes
64 bytes from pc14.fujisawa.wide.ad.jp: icmp_seq=0 ttl=60 time=308 ms
[acme@pretzel network-scripts]$
then:
[acme@pretzel network-scripts]$ for a in $(seq 1 10) ; do dmesg | grep
'^BUG: dst underf' | md5sum ; sleep 2 ; done
3079d6c2a8c9be8b97fa31e91f8f37df -
3079d6c2a8c9be8b97fa31e91f8f37df -
3079d6c2a8c9be8b97fa31e91f8f37df -
3079d6c2a8c9be8b97fa31e91f8f37df -
3079d6c2a8c9be8b97fa31e91f8f37df -
3079d6c2a8c9be8b97fa31e91f8f37df -
3079d6c2a8c9be8b97fa31e91f8f37df -
3079d6c2a8c9be8b97fa31e91f8f37df -
3079d6c2a8c9be8b97fa31e91f8f37df -
3079d6c2a8c9be8b97fa31e91f8f37df -
[acme@pretzel network-scripts]$
The md5sum is just a trick, using wc-l gives a false impression because
the dmesg output wraps around and stays with just BUG underflow...
messages.
Another thing: can you try with IPv6 privacy extensions not built into
the kernel/ipv6 module? I couldn't reproduce it here at home, not sure
why, but I tried with 2.6.9-final (like Jeff's machine) and with latest
Linus BK tree, couldn't reproduce.
The problem (or part of it ;) ) lies in net/ipv6/datagram.c,
ip6_datagram_connect and the functions it calls that end up calling
dst_release, but I don't know that much this code and I'm almost falling
asleep here.
Thanks,
- Arnaldo
prev parent reply other threads:[~2004-11-06 8:17 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-22 6:39 BUG: dst underflow (again) Jeff Garzik
2004-10-22 6:51 ` YOSHIFUJI Hideaki / 吉藤英明
2004-10-22 7:59 ` Lennert Buytenhek
2004-11-04 14:15 ` jamal
2004-11-05 6:18 ` David S. Miller
2004-11-05 6:53 ` YOSHIFUJI Hideaki / 吉藤英明
2004-11-05 7:16 ` David S. Miller
2004-11-05 7:44 ` YOSHIFUJI Hideaki / 吉藤英明
2004-11-05 7:05 ` Jeff Garzik
2004-11-05 7:14 ` David S. Miller
2004-11-05 7:34 ` Jeff Garzik
2004-11-05 7:38 ` Jeff Garzik
2004-11-05 9:13 ` Lennert Buytenhek
2004-11-05 9:14 ` Lennert Buytenhek
2004-11-05 9:42 ` Arnaldo Carvalho de Melo
[not found] ` <20041105101513.GA28779@xi.wantstofly.org>
2004-11-06 0:23 ` David S. Miller
2004-11-06 1:53 ` Herbert Xu
2004-11-06 9:02 ` Lennert Buytenhek
2004-11-06 8:17 ` Arnaldo Carvalho de Melo [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=418C888F.3060509@conectiva.com.br \
--to=acme@conectiva.com.br \
--cc=buytenh@wantstofly.org \
--cc=davem@davemloft.net \
--cc=hadi@cyberus.ca \
--cc=jgarzik@pobox.com \
--cc=netdev@oss.sgi.com \
--cc=yoshfuji@linux-ipv6.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.