freebsd-net Digest, Vol 363, Issue 2
freebsd-n...@freebsd.org
freeb...@freebsd.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.freebsd.org/mailman/listinfo/freebsd-net
or, via email, send a message with subject or body 'help' to
freebsd-n...@freebsd.org
You can reach the person managing the list at
freebsd-...@freebsd.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of freebsd-net digest..."
Today's Topics:
1. Re: [ping6] freeaddrinfo() (Hajimu UMEMOTO)
2. Re: Bridge causes freezes (Giulio Ferro)
3. Re: [ping6] freeaddrinfo() (Earl Lapus)
4. Re: kern/144777: [arp] proxyarp broken in 8.0 [regression]
(lin...@FreeBSD.org)
5. Re: kmem leakage on tun/tap device removal (Mikolaj Golub)
----------------------------------------------------------------------
Message: 1
Date: Tue, 16 Mar 2010 01:06:18 +0900
From: Hajimu UMEMOTO <u...@freebsd.org>
Subject: Re: [ping6] freeaddrinfo()
To: Earl Lapus <earl....@gmail.com>
Cc: freeb...@freebsd.org
Message-ID: <ygeeijlzi11.wl%u...@mahoroba.org>
Content-Type: text/plain; charset=US-ASCII
Hi,
>>>>> On Sat, 13 Mar 2010 20:25:29 +0800
>>>>> Earl Lapus <earl....@gmail.com> said:
earl> I was browsing through the ping6 code and I noticed that one
earl> particular call to getaddrinfo() didn't have a freeaddrinfo() pair.
earl> All calls to getaddrinfo() should have an equivalent freeaddrinfo(), right?
Yup, it should be good practice. But, this is rather intentional.
The `hostname' variable points to res->ai_canonname, and is used
later. This is why the `res' variable is declared globally.
Sincerely,
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
u...@mahoroba.org ume@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/
------------------------------
Message: 2
Date: Mon, 15 Mar 2010 22:24:50 +0100
From: Giulio Ferro <au...@zirakzigil.org>
Subject: Re: Bridge causes freezes
To: freeb...@freebsd.org, freebsd...@freebsd.org
Message-ID: <4B9EA5A2...@zirakzigil.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
I confirm this problem for another server:
stable 8 amd64 + vlan + carp
Whenever I join a bridge with a vlan interface:
ifconfig bridge0 addm vlan35
The system soon or later freezes.
This time it has happened after 3 days of normal behavior.
No logs, no dump.
On 03.03.2010 12:30, Giulio Ferro wrote:
> I'm setting up an openvpn demon in bridge mode on a firewall.
>
> Scenario:
> freebsd 8 amd64 stable (last week), pf, vlans, openvpn in tun mode
> (different
> port, of course), many routes
>
> I've created the bridge interface in rc.conf like this:
> cloned_interfaces="vlan.. .. .. bridge0"
> ...
> ifconfig_bridge0="addm vlan35 up"
>
>
> Everything seems to work as expected as far as networking is concerned.
>
> The problem arises after an hour or so: the system simply freezes, and
> no relevant
> log can be found after restart.
>
> This _always_ happens, even when I don't start the openvpn bridge
> demon...
>
> Any idea, anybody?
>
> Thanks.
> _______________________________________________
> freeb...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net...@freebsd.org"
------------------------------
Message: 3
Date: Tue, 16 Mar 2010 11:03:27 +0800
From: Earl Lapus <earl....@gmail.com>
Subject: Re: [ping6] freeaddrinfo()
To: Hajimu UMEMOTO <u...@freebsd.org>
Cc: freeb...@freebsd.org
Message-ID:
<604f76121003152003i463...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Tue, Mar 16, 2010 at 12:06 AM, Hajimu UMEMOTO <u...@freebsd.org> wrote:
>
> Yup, it should be good practice. But, this is rather intentional.
> The `hostname' variable points to res->ai_canonname, and is used
> later. This is why the `res' variable is declared globally.
>
> Sincerely,
>
I see. I was unable to see that one.
Thanks.
--
There are seven words in this sentence.
------------------------------
Message: 4
Date: Tue, 16 Mar 2010 04:11:00 GMT
From: lin...@FreeBSD.org
Subject: Re: kern/144777: [arp] proxyarp broken in 8.0 [regression]
To: lin...@FreeBSD.org, freebs...@FreeBSD.org,
freeb...@FreeBSD.org
Message-ID: <201003160411....@freefall.freebsd.org>
Old Synopsis: [arp] proxyarp broken in 8.0
New Synopsis: [arp] proxyarp broken in 8.0 [regression]
Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Tue Mar 16 04:10:40 UTC 2010
Responsible-Changed-Why:
Over to maintainer(s).
http://www.freebsd.org/cgi/query-pr.cgi?pr=144777
------------------------------
Message: 5
Date: Tue, 16 Mar 2010 08:45:28 +0200
From: Mikolaj Golub <to.my....@gmail.com>
Subject: Re: kmem leakage on tun/tap device removal
To: freeb...@freebsd.org
Cc: Kostik Belousov <kost...@gmail.com>
Message-ID: <86634wd...@zhuzha.ua1>
Content-Type: text/plain; charset="gb2312"
On Feb 28, 1:30 pm, to.my....@gmail.com (Mikolaj Golub) wrote:
> But I have faced with another issue (not related to your patch, as it is
> observed with unpatched kernel too). When I try to run concurrently two
> create/destroy scripts with the same interface the system panics:
>
> Unread portion of the kernel message buffer:
> panic: Bad link elm 0xc5f1a800 next->prev != elm
> cpuid = 2
> KDB: enter: panic
> exclusive sleep mutex if_clone lock (if_clone lock) r = 0 (0xc0da1cf0) locked @ /usr/src/sys/net/if_clone.c:248
> exclusive sleep mutex if_clone lock (if_clone lock) r = 0 (0xc0da1cf0) locked @ /usr/src/sys/net/if_clone.c:248
> exclusive sx so_rcv_sx (so_rcv_sx) r = 0 (0xc6cd3560) locked @ /usr/src/sys/kern/uipc_sockbuf.c:148
> exclusive sx so_rcv_sx (so_rcv_sx) r = 0 (0xc6b4dbd0) locked @ /usr/src/sys/kern/uipc_sockbuf.c:148
> Physical memory: 2019 MB
> Dumping 160 MB: 145 129 113 97 81 65 49 33 17 1
>
> #0 doadump () at pcpu.h:246
> 246 __asm __volatile("movl %%fs:0,%0" : "=r" (td));
> (kgdb) bt
> #0 doadump () at pcpu.h:246
> #1 0xc04e8bb9 in db_fncall (dummy1=-1064515926, dummy2=0, dummy3=-1, dummy4=0xe83f4834 "HH?¨¨")
> at /usr/src/sys/ddb/db_command.c:548
> #2 0xc04e8fef in db_command (last_cmdp=0xc0de14dc, cmd_table=0x0, dopager=0)
> at /usr/src/sys/ddb/db_command.c:445
> #3 0xc04e90a4 in db_command_script (command=0xc0de2404 "call doadump")
> at /usr/src/sys/ddb/db_command.c:516
> #4 0xc04ed1d0 in db_script_exec (scriptname=0xe83f4940 "kdb.enter.panic", warnifnotfound=Variable "warnifnotfound" is not available.
> )
> at /usr/src/sys/ddb/db_script.c:302
> #5 0xc04ed2b7 in db_script_kdbenter (eventname=0xc0ca1948 "panic") at /usr/src/sys/ddb/db_script.c:324
> #6 0xc04eaf98 in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_main.c:228
> #7 0xc08cc526 in kdb_trap (type=3, code=0, tf=0xe83f4a7c) at /usr/src/sys/kern/subr_kdb.c:535
> #8 0xc0bdd38b in trap (frame=0xe83f4a7c) at /usr/src/sys/i386/i386/trap.c:690
> #9 0xc0bbef1b in calltrap () at /usr/src/sys/i386/i386/exception.s:165
> #10 0xc08cc6aa in kdb_enter (why=0xc0ca1948 "panic", msg=0xc0ca1948 "panic") at cpufunc.h:71
> #11 0xc089d716 in panic (fmt=0xc0c3c80c "Bad link elm %p next->prev != elm")
> at /usr/src/sys/kern/kern_shutdown.c:562
> #12 0xc094e7fb in if_clone_destroyif (ifc=0xc0da1cc0, ifp=0xc5f1a800) at /usr/src/sys/net/if_clone.c:249
> #13 0xc094eb52 in if_clone_destroy (name=0xc664ac20 "tun0") at /usr/src/sys/net/if_clone.c:227
> #14 0xc094c8a6 in ifioctl (so=0xc6e0a9a8, cmd=2149607801, data=0xc664ac20 "tun0", td=0xc66c0d80)
> at /usr/src/sys/net/if.c:2412
> #15 0xc08e8b25 in soo_ioctl (fp=0xc6d46af0, cmd=2149607801, data=0xc664ac20, active_cred=0xc5f62280,
> td=0xc66c0d80) at /usr/src/sys/kern/sys_socket.c:212
> #16 0xc08e31bd in kern_ioctl (td=0xc66c0d80, fd=3, com=2149607801, data=0xc664ac20 "tun0") at file.h:262
> #17 0xc08e3344 in ioctl (td=0xc66c0d80, uap=0xe83f4cf8) at /usr/src/sys/kern/sys_generic.c:678
> #18 0xc0bdca33 in syscall (frame=0xe83f4d38) at /usr/src/sys/i386/i386/trap.c:1078
> #19 0xc0bbefb0 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:261
> #20 0x00000033 in ?? ()
> Previous frame inner to this frame (corrupt stack?)
> (kgdb) fr 12
> #12 0xc094e7fb in if_clone_destroyif (ifc=0xc0da1cc0, ifp=0xc5f1a800) at /usr/src/sys/net/if_clone.c:249
> 249 IFC_IFLIST_REMOVE(ifc, ifp);
> (kgdb) list
> 244 * switch to the vnet context of the target vnet.
> 245 */
> 246 CURVNET_SET_QUIET(ifp->if_vnet);
> 247
> 248 IF_CLONE_LOCK(ifc);
> 249 IFC_IFLIST_REMOVE(ifc, ifp);
> 250 IF_CLONE_UNLOCK(ifc);
> 251
> 252 if_delgroup(ifp, ifc->ifc_name);
> 253
>
Actually, this issue has already been reported (kern/116837, see the bottom of
the discussion) and there was a patch provided by Takahiro Kurosawa [check
that ifp is on ifc->ifc_iflist before calling IFC_IFLIST_REMOVE(ifc, ifp)].
Although he mentioned that another race was still possible. I have tried the
patch and yes it makes the situation much better: the box did not crush when
running two "ifconfig tun0 create/destroy" scripts concurrently, but when I
tried 8 concurrent processes :-) it crashed after a couple minutes in another
place:
(kgdb) bt
#0 doadump () at pcpu.h:246
#1 0xc04ec379 in db_fncall (dummy1=1, dummy2=0, dummy3=-1056947200, dummy4=0xe86848e4 "")
at /usr/src/sys/ddb/db_command.c:548
#2 0xc04ec771 in db_command (last_cmdp=0xc0e04d1c, cmd_table=0x0, dopager=1)
at /usr/src/sys/ddb/db_command.c:445
#3 0xc04ec8ca in db_command_loop () at /usr/src/sys/ddb/db_command.c:498
#4 0xc04ee76d in db_trap (type=12, code=0) at /usr/src/sys/ddb/db_main.c:229
#5 0xc08d7d06 in kdb_trap (type=12, code=0, tf=0xe8684ad0) at /usr/src/sys/kern/subr_kdb.c:535
#6 0xc0bea66f in trap_fatal (frame=0xe8684ad0, eva=3735929054) at /usr/src/sys/i386/i386/trap.c:929
#7 0xc0beaf90 in trap (frame=0xe8684ad0) at /usr/src/sys/i386/i386/trap.c:328
#8 0xc0bccd7b in calltrap () at /usr/src/sys/i386/i386/exception.s:165
#9 0xc094bfa6 in strcmp (s1=0xc663686b "vmnet", s2=0xdeadc0de <Address 0xdeadc0de out of bounds>)
at /usr/src/sys/libkern/strcmp.c:45
#10 0xc095a9c2 in if_clone_destroy (name=0xc5f7d840 "tun0") at /usr/src/sys/net/if_clone.c:209
#11 0xc09584d6 in ifioctl (so=0xc721a80c, cmd=2149607801, data=0xc5f7d840 "tun0", td=0xc731fb90)
at /usr/src/sys/net/if.c:2486
#12 0xc08f4615 in soo_ioctl (fp=0xc5f1ca80, cmd=2149607801, data=0xc5f7d840, active_cred=0xc5ed4180,
td=0xc731fb90) at /usr/src/sys/kern/sys_socket.c:212
#13 0xc08eec8d in kern_ioctl (td=0xc731fb90, fd=3, com=2149607801, data=0xc5f7d840 "tun0") at file.h:262
#14 0xc08eee14 in ioctl (td=0xc731fb90, uap=0xe8684cf8) at /usr/src/sys/kern/sys_generic.c:678
#15 0xc0beab40 in syscall (frame=0xe8684d38) at /usr/src/sys/i386/i386/trap.c:1111
#16 0xc0bcce10 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:261
#17 0x00000033 in ?? ()
Previous frame inner to this frame (corrupt stack?)
(kgdb) fr 10
#10 0xc095a9c2 in if_clone_destroy (name=0xc5f7d840 "tun0") at /usr/src/sys/net/if_clone.c:209
209 if (strcmp(ifc->ifc_name, ifp->if_dname) == 0) {
(kgdb) list
204 return (ENXIO);
205
206 /* Find the cloner for this interface */
207 IF_CLONERS_LOCK();
208 LIST_FOREACH(ifc, &V_if_cloners, ifc_list) {
209 if (strcmp(ifc->ifc_name, ifp->if_dname) == 0) {
210 break;
211 }
212 }
213 #ifdef VIMAGE
(kgdb) p ifc->ifc_name
$1 = 0xc663686b "vmnet"
(kgdb) p ifp->if_dname
$2 = 0xdeadc0de <Address 0xdeadc0de out of bounds>
(kgdb)
May be we can use ifunit_ref() instead of ifunit() like in the patch below to
avoid this race (the patch also includes Takahiro Kurosawa's patch from
kern/116837)?
I was running 32 "ifconfig tun0 create/destroy" on the patched kernel through
all the night and did not manage to crash the system.
--
Mikolaj Golub
-------------- next part --------------
A non-text attachment was scrubbed...
Name: if_clone.c.if_clone_destroy.patch
Type: text/x-patch
Size: 1255 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20100316/55a5d231/if_clone.c.if_clone_destroy-0001.bin
------------------------------
End of freebsd-net Digest, Vol 363, Issue 2
*******************************************