Re: pf NAT and VNET Jails
On 11/1/15 2:50 AM, Shawn Webb wrote: I'm at r290228 on amd64. I'm not sure which revision I was on last when it last worked, but it seems VNET jails aren't working anymore. I've got a bridge, bridge1, with an IP of 192.168.7.1. The VNET jails set their default route to 192.168.7.1. The host simply NATs outbound from 192.168.7.0/24 to the rest of the world. The various epairs get added to bridge1 and assigned to each jail. Pretty simple setup. That worked until today. When I do tcpdump on my public-facing NIC, I see that NAT isn't applied. When I run `ping 8.8.8.8` from the jail, the jail's 192.168.7.0/24 address gets sent on the wire. Let me know what I can do to help debug this further. send the list your setup script/settings? Thanks, Shawn Webb ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Compilation failure with WITH_DTRACE_TESTS on mips/mips and powerpc/powerpc; it's trying to compile a host object on mips/powerpc because MAKEOBJDIRPREFIX is incorrect
> On Oct 31, 2015, at 14:37, NGie Cooper wrote: > > >> On Oct 30, 2015, at 23:51, NGie Cooper wrote: >> >> >>> On Oct 30, 2015, at 16:43, Simon J. Gerraty wrote: >>> >>> NGie Cooper wrote: I tried doing buildworld on powerpc/powerpc with -DWITH_DTRACE_TESTS and I ran into this linker issue below. I have no idea (yet) why it’s trying to compile an x64 object when I specify powerpc/powerpc — and more importantly, why is the object not being put in obj.powerpc? I ran into the same issue on ref11-amd64.freebsd.org when I ran “make tinderbox". >>> >>> Is it possible that the file is left over from a previous build (of amd64?) >>> >>> Does your log show it being built? >>> >>> dtrace -C -x nolibs -G -o usdt.o -s /usr/src/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/usdt.d tst.usdt.o dtrace: failed to link script /usr/src/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/usdt.d: incorrect ELF machine type for object file: tst.usdt.o *** Error code 1 $ find /usr/obj/usr/src/svn/ -name tst.usdt.o /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o $ file /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o: ELF 64-bit LSB relocatable, x86-64, version 1 (FreeBSD), not stripped >> >> Still running into issues on ref11-amd64: >> >> cc1: error: unrecognized command line option "-m64" >> dtrace: failed to compile script >> /scratch/tmp/ngie/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/usdt.d: >> Preprocessor failed to process input program >> --- usdt.h --- >> *** [usdt.h] Error code 1 >> >> Let’s see what happens if I use make buildenv > > … > > Deleting the lines that pass -m32/-m64 gets me back to the same point I was > at before: > > dtrace: failed to link script > /scratch/tmp/ngie/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/usdt.d: > incorrect ELF machine type for object file: tst.usdt.o > --- usdt.o --- > *** [usdt.o] Error code 1 > > I’ll need to check .PATH, but I think it’s picking up the host copy by > accident: > > $ find ../obj/ -name tst.usdt.o | xargs file > ../obj/arm.armv6hf/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o: >ELF 32-bit LSB relocatable, ARM, EABI5 version 1 (FreeBSD), not > stripped > ../obj/arm.arm/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o: >ELF 32-bit LSB relocatable, ARM, EABI5 version 1 (FreeBSD), not > stripped > ../obj/arm.armeb/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o: > ELF 32-bit MSB relocatable, ARM, EABI5 version 1 (FreeBSD), not > stripped > ../obj/powerpc.powerpc/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o: >ELF 32-bit MSB relocatable, PowerPC or cisco 4500, version 1 (FreeBSD), > not stripped > ../obj/arm.armv6/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o: > ELF 32-bit LSB relocatable, ARM, EABI5 version 1 (FreeBSD), not > stripped > ../obj/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o: >ELF 64-bit LSB relocatable, x86-64, version 1 (FreeBSD), > not stripped > ../obj/i386.i386/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o: > ELF 32-bit LSB relocatable, Intel 80386, version 1 (FreeBSD), not > stripped > ../obj/pc98.i386/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o: > ELF 32-bit LSB relocatable, Intel 80386, version 1 (FreeBSD), not > stripped > ../obj/powerpc.powerpc64/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o: > ELF 64-bit MSB relocatable, 64-bit PowerPC or cisco 7500, version 1 > (FreeBSD), not stripped > ../obj/arm64.aarch64/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o: > ELF 64-bit LSB relocatable, ARM aarch64, version 1 (FreeBSD), not > stripped And here’s the real issue — .PATH is completely broken when TARGET/TARGET_ARCH are specified as explicit values: $ env MAKEOBJDIRPREFIX=/scratch/tmp/ngie/obj/ make buildenv TARGET=powerpc TARGET_ARCH=powerpc Entering world for powerpc:powerpc $ cd cddl/usr.sbin/dtrace/tests/common/json $ make -V.OBJDIR /scratch/tmp/ngie/obj//powerpc.powerpc/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json $ make -VMAKEOBJDIRPREFIX /scratch/tmp/ngie/obj//powerpc.powerpc $ make depend (cd /scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json && DEPENDFILE=.depend.tst.usdt.exe NO_SUBDIR=1 make -f /scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/Makefile _RECURSING_PROGS= PROG=tst.usdt.exe depend) $ make all (cd /scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json && DEPENDFILE=.depend.tst.usdt.exe NO_SUBDIR=1 make -f /scratch/tmp/ngie/svn/c
Re: Compilation failure with WITH_DTRACE_TESTS on mips/mips and powerpc/powerpc; it's trying to compile a host object on mips/powerpc because MAKEOBJDIRPREFIX is incorrect
> On Oct 30, 2015, at 23:51, NGie Cooper wrote: > > >> On Oct 30, 2015, at 16:43, Simon J. Gerraty wrote: >> >> NGie Cooper wrote: >>> I tried doing buildworld on powerpc/powerpc with -DWITH_DTRACE_TESTS >>> and I ran into this linker issue below. I have no idea (yet) why it’s >>> trying to compile an x64 object when I specify powerpc/powerpc — and more >>> importantly, why is the object not being put in obj.powerpc? >>> I ran into the same issue on ref11-amd64.freebsd.org when I ran “make >>> tinderbox". >> >> Is it possible that the file is left over from a previous build (of amd64?) >> >> Does your log show it being built? >> >> >>> dtrace -C -x nolibs -G -o usdt.o -s >>> /usr/src/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/usdt.d >>> tst.usdt.o >>> dtrace: failed to link script >>> /usr/src/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/usdt.d: >>> incorrect ELF machine type for object file: tst.usdt.o >>> *** Error code 1 >>> $ find /usr/obj/usr/src/svn/ -name tst.usdt.o >>> /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o >>> $ file >>> /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o >>> /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o: ELF >>> 64-bit LSB relocatable, x86-64, version 1 (FreeBSD), not stripped > > Still running into issues on ref11-amd64: > > cc1: error: unrecognized command line option "-m64" > dtrace: failed to compile script > /scratch/tmp/ngie/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/usdt.d: > Preprocessor failed to process input program > --- usdt.h --- > *** [usdt.h] Error code 1 > > Let’s see what happens if I use make buildenv … Deleting the lines that pass -m32/-m64 gets me back to the same point I was at before: dtrace: failed to link script /scratch/tmp/ngie/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/usdt.d: incorrect ELF machine type for object file: tst.usdt.o --- usdt.o --- *** [usdt.o] Error code 1 I’ll need to check .PATH, but I think it’s picking up the host copy by accident: $ find ../obj/ -name tst.usdt.o | xargs file ../obj/arm.armv6hf/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o: ELF 32-bit LSB relocatable, ARM, EABI5 version 1 (FreeBSD), not stripped ../obj/arm.arm/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o: ELF 32-bit LSB relocatable, ARM, EABI5 version 1 (FreeBSD), not stripped ../obj/arm.armeb/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o: ELF 32-bit MSB relocatable, ARM, EABI5 version 1 (FreeBSD), not stripped ../obj/powerpc.powerpc/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o: ELF 32-bit MSB relocatable, PowerPC or cisco 4500, version 1 (FreeBSD), not stripped ../obj/arm.armv6/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o: ELF 32-bit LSB relocatable, ARM, EABI5 version 1 (FreeBSD), not stripped ../obj/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o: ELF 64-bit LSB relocatable, x86-64, version 1 (FreeBSD), not stripped ../obj/i386.i386/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (FreeBSD), not stripped ../obj/pc98.i386/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (FreeBSD), not stripped ../obj/powerpc.powerpc64/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o: ELF 64-bit MSB relocatable, 64-bit PowerPC or cisco 7500, version 1 (FreeBSD), not stripped ../obj/arm64.aarch64/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o: ELF 64-bit LSB relocatable, ARM aarch64, version 1 (FreeBSD), not stripped ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
pf NAT and VNET Jails
I'm at r290228 on amd64. I'm not sure which revision I was on last when it last worked, but it seems VNET jails aren't working anymore. I've got a bridge, bridge1, with an IP of 192.168.7.1. The VNET jails set their default route to 192.168.7.1. The host simply NATs outbound from 192.168.7.0/24 to the rest of the world. The various epairs get added to bridge1 and assigned to each jail. Pretty simple setup. That worked until today. When I do tcpdump on my public-facing NIC, I see that NAT isn't applied. When I run `ping 8.8.8.8` from the jail, the jail's 192.168.7.0/24 address gets sent on the wire. Let me know what I can do to help debug this further. Thanks, Shawn Webb ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic in arptimer in r289937
31.10.2015, 16:46, "Adrian Chadd" :
> On 31 October 2015 at 09:34, Alexander V. Chernikov
> wrote:
>> 31.10.2015, 05:32, "Adrian Chadd" :
>>> Hiya,
>>>
>>> Here's a panic from arptimer:
>> Hi Adrian,
>>
>> As far as I see, line 205 in if_ether.c is IF_AFDATA_LOCK(ifp) which
>> happens after LLE_WUNLOCK().
>> So, it looks like (pre-cached) ifp had been freed before locking ifdata.
>> Do you have any more details on that? (e.g. was some interface detached at
>> that moment, is it reproducible, etc..)
>>
>> From a quick glance, potential use-after-free has been possible for quite a
>> long time, but I wonder why it hasn't been observed before.
>> Probably lltable_free() changes might have triggered that.
>>
>> I'll take a deeper look on that and reply.
>
> Hiya!
>
> Thanks for your quick response.
>
> I mean, I use wifi, and ARPs can get lost / transmit can get delayed /
> etc. I'm also testing through a MIPS CPU based bridge, so I'm also not
I remember that :)
> bridging at line rate. (The above is from one of the x86 laptops doing
> the traffic test.) These are both reasons why I may be poking at a
> path that you don't normally see. :)
Yup. So, once again, could you provide a bit more details? :)
Was it related with any interface being destroyed?
What was the test scenario (just bridging between interfaces?)
Is this reproducible?
>
> I appreciate you taking a very quick look at this!
>
> Thanks,
>
> -adrian
>
>>> (kgdb) bt
>>> #0 doadump (textdump=0) at pcpu.h:221
>>> #1 0x803666b6 in db_fncall (dummy1=,
>>> dummy2=, dummy3=,
>>> dummy4=) at
>>> /usr/home/adrian/work/freebsd/head/src/sys/ddb/db_command.c:568
>>> #2 0x8036614e in db_command (cmd_table=0x0) at
>>> /usr/home/adrian/work/freebsd/head/src/sys/ddb/db_command.c:440
>>> #3 0x80365ee4 in db_command_loop () at
>>> /usr/home/adrian/work/freebsd/head/src/sys/ddb/db_command.c:493
>>> #4 0x8036897b in db_trap (type=, code=0)
>>> at /usr/home/adrian/work/freebsd/head/src/sys/ddb/db_main.c:251
>>> #5 0x8096c0f3 in kdb_trap (type=9, code=0, tf=>> optimized out>) at
>>> /usr/home/adrian/work/freebsd/head/src/sys/kern/subr_kdb.c:654
>>> #6 0x80d34c81 in trap_fatal (frame=0xfe022815d7a0,
>>> eva=) at
>>> /usr/home/adrian/work/freebsd/head/src/sys/amd64/amd64/trap.c:829
>>> #7 0x80d34951 in trap (frame=) at
>>> /usr/home/adrian/work/freebsd/head/src/sys/amd64/amd64/trap.c:203
>>> #8 0x80d149f7 in calltrap () at
>>> /usr/home/adrian/work/freebsd/head/src/sys/amd64/amd64/exception.S:234
>>> #9 0x8092c3fb in _rw_wlock_cookie (c=0xdeadc0dedeadc2de,
>>> file=0x81211b1f
>>> "/usr/home/adrian/work/freebsd/head/src/sys/netinet/if_ether.c",
>>> line=205)
>>> at /usr/home/adrian/work/freebsd/head/src/sys/kern/kern_rwlock.c:261
>>> #10 0x80a2487f in arptimer (arg=0xf8005ecc4000) at
>>> /usr/home/adrian/work/freebsd/head/src/sys/netinet/if_ether.c:205
>>> #11 0x80944c24 in softclock_call_cc (c=0xf8005ecc40a8,
>>> cc=0x81b2d480, direct=0) at
>>> /usr/home/adrian/work/freebsd/head/src/sys/kern/kern_timeout.c:722
>>> #12 0x80944f87 in softclock (arg=) at
>>> /usr/home/adrian/work/freebsd/head/src/sys/kern/kern_timeout.c:851
>>> #13 0x808f7eb6 in intr_event_execute_handlers (p=>> optimized out>, ie=0xf800035a6600) at
>>> /usr/home/adrian/work/freebsd/head/src/sys/kern/kern_intr.c:1262
>>> #14 0x808f8546 in ithread_loop (arg=0xf800032c47c0) at
>>> /usr/home/adrian/work/freebsd/head/src/sys/kern/kern_intr.c:1275
>>> #15 0x808f57a4 in fork_exit (callout=0x808f84a0
>>> , arg=0xf800032c47c0, frame=0xfe022815dac0) at
>>> /usr/home/adrian/work/freebsd/head/src/sys/kern/kern_fork.c:1011
>>> #16 0x80d14f2e in fork_trampoline () at
>>> /usr/home/adrian/work/freebsd/head/src/sys/amd64/amd64/exception.S:609
>>> #17 0x in ?? ()
>>> Current language: auto; currently minimal
>>>
>>> (kgdb) print *(struct llentry *)c_arg
>>> $2 = {lle_next = {le_next = 0x0, le_prev = 0xf8005e867dc8},
>>> r_l3addr = {addr4 = {s_addr = 16782508}, addr6 = {__u6_addr =
>>> {__u6_addr8 = 0xf8005ecc4010 "�\024", __u6_addr16 =
>>> 0xf8005ecc4010,
>>> __u6_addr32 = 0xf8005ecc4010}}}, ll_addr = {mac_aligned =
>>> 110869256150596, mac16 = 0xf8005ecc4020, mac8 = 0xf8005ecc4020
>>> "D\036���d"}, spare0 = 0, spare1 = 0, lle_tbl = 0xf8005e867e00,
>>> lle_head = 0xf8005e867dc8, lle_free = 0x80a2c5d0
>>> , la_hold = 0x0, la_numheld = 0, la_expire =
>>> 2110, la_flags = 1, la_asked = 0, la_preempt = 5, ln_state = 0,
>>> ln_router = 0, ln_ntick = 0,
>>> lle_refcnt = 1, lle_chain = {le_next = 0x0, le_prev = 0x0},
>>> lle_timer = {c_links = {le = {le_next = 0x0, le_prev =
>>> 0x81b2d588}, sle = {sle_next = 0x0}, tqe = {tqe_next = 0x0,
>>> tqe_prev = 0x81b2d588}},
>>> c_time = 9066299
Re: [HEADSUP] OpenSSL updated to 1.0.2d
On 10/31/15 5:25 AM, O. Hartmann wrote: Am Fri, 30 Oct 2015 16:57:45 -0400 Jung-uk Kim schrieb: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 OpenSSL on head has been updated to 1.0.2d. Please make sure to recompile all binaries depending on libcrypto.so.7 or libssl.so.7. That is good news. Could you provide, please, some hints how one could check all installed ports for the usage of those specific libraries? Or could you provide a hint towards an existing port already providing those tools? It would be great for those "from the set of ordinary people" using FreeBSD. I ask for that because I recall that there were a couple of ports which explicitely asks for a selection of what SSL lib should be used and in my case, I use the base system's one. I expect there's a port, but I'm not aware of one. This should work: find /usr/local/*bin /usr/local/lib* -type f | \ while read F; do \ objdump -x $F 2>&1 | grep -Eq 'NEEDED *lib(crypto|ssl).so.7' && \ echo $F; \ done This is in /bin/sh (or bash). You could change "echo" to "pkg which" to show the package names. Cheers, Eric ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic in arptimer in r289937
On 31 October 2015 at 09:34, Alexander V. Chernikov
wrote:
>
>
> 31.10.2015, 05:32, "Adrian Chadd" :
>> Hiya,
>>
>> Here's a panic from arptimer:
> Hi Adrian,
>
> As far as I see, line 205 in if_ether.c is IF_AFDATA_LOCK(ifp) which happens
> after LLE_WUNLOCK().
> So, it looks like (pre-cached) ifp had been freed before locking ifdata.
> Do you have any more details on that? (e.g. was some interface detached at
> that moment, is it reproducible, etc..)
>
> From a quick glance, potential use-after-free has been possible for quite a
> long time, but I wonder why it hasn't been observed before.
> Probably lltable_free() changes might have triggered that.
>
> I'll take a deeper look on that and reply.
Hiya!
Thanks for your quick response.
I mean, I use wifi, and ARPs can get lost / transmit can get delayed /
etc. I'm also testing through a MIPS CPU based bridge, so I'm also not
bridging at line rate. (The above is from one of the x86 laptops doing
the traffic test.) These are both reasons why I may be poking at a
path that you don't normally see. :)
I appreciate you taking a very quick look at this!
Thanks,
-adrian
>
>>
>> (kgdb) bt
>> #0 doadump (textdump=0) at pcpu.h:221
>> #1 0x803666b6 in db_fncall (dummy1=,
>> dummy2=, dummy3=,
>> dummy4=) at
>> /usr/home/adrian/work/freebsd/head/src/sys/ddb/db_command.c:568
>> #2 0x8036614e in db_command (cmd_table=0x0) at
>> /usr/home/adrian/work/freebsd/head/src/sys/ddb/db_command.c:440
>> #3 0x80365ee4 in db_command_loop () at
>> /usr/home/adrian/work/freebsd/head/src/sys/ddb/db_command.c:493
>> #4 0x8036897b in db_trap (type=, code=0)
>> at /usr/home/adrian/work/freebsd/head/src/sys/ddb/db_main.c:251
>> #5 0x8096c0f3 in kdb_trap (type=9, code=0, tf=> optimized out>) at
>> /usr/home/adrian/work/freebsd/head/src/sys/kern/subr_kdb.c:654
>> #6 0x80d34c81 in trap_fatal (frame=0xfe022815d7a0,
>> eva=) at
>> /usr/home/adrian/work/freebsd/head/src/sys/amd64/amd64/trap.c:829
>> #7 0x80d34951 in trap (frame=) at
>> /usr/home/adrian/work/freebsd/head/src/sys/amd64/amd64/trap.c:203
>> #8 0x80d149f7 in calltrap () at
>> /usr/home/adrian/work/freebsd/head/src/sys/amd64/amd64/exception.S:234
>> #9 0x8092c3fb in _rw_wlock_cookie (c=0xdeadc0dedeadc2de,
>> file=0x81211b1f
>> "/usr/home/adrian/work/freebsd/head/src/sys/netinet/if_ether.c",
>> line=205)
>> at /usr/home/adrian/work/freebsd/head/src/sys/kern/kern_rwlock.c:261
>> #10 0x80a2487f in arptimer (arg=0xf8005ecc4000) at
>> /usr/home/adrian/work/freebsd/head/src/sys/netinet/if_ether.c:205
>> #11 0x80944c24 in softclock_call_cc (c=0xf8005ecc40a8,
>> cc=0x81b2d480, direct=0) at
>> /usr/home/adrian/work/freebsd/head/src/sys/kern/kern_timeout.c:722
>> #12 0x80944f87 in softclock (arg=) at
>> /usr/home/adrian/work/freebsd/head/src/sys/kern/kern_timeout.c:851
>> #13 0x808f7eb6 in intr_event_execute_handlers (p=> optimized out>, ie=0xf800035a6600) at
>> /usr/home/adrian/work/freebsd/head/src/sys/kern/kern_intr.c:1262
>> #14 0x808f8546 in ithread_loop (arg=0xf800032c47c0) at
>> /usr/home/adrian/work/freebsd/head/src/sys/kern/kern_intr.c:1275
>> #15 0x808f57a4 in fork_exit (callout=0x808f84a0
>> , arg=0xf800032c47c0, frame=0xfe022815dac0) at
>> /usr/home/adrian/work/freebsd/head/src/sys/kern/kern_fork.c:1011
>> #16 0x80d14f2e in fork_trampoline () at
>> /usr/home/adrian/work/freebsd/head/src/sys/amd64/amd64/exception.S:609
>> #17 0x in ?? ()
>> Current language: auto; currently minimal
>>
>> (kgdb) print *(struct llentry *)c_arg
>> $2 = {lle_next = {le_next = 0x0, le_prev = 0xf8005e867dc8},
>> r_l3addr = {addr4 = {s_addr = 16782508}, addr6 = {__u6_addr =
>> {__u6_addr8 = 0xf8005ecc4010 "�\024", __u6_addr16 =
>> 0xf8005ecc4010,
>> __u6_addr32 = 0xf8005ecc4010}}}, ll_addr = {mac_aligned =
>> 110869256150596, mac16 = 0xf8005ecc4020, mac8 = 0xf8005ecc4020
>> "D\036���d"}, spare0 = 0, spare1 = 0, lle_tbl = 0xf8005e867e00,
>> lle_head = 0xf8005e867dc8, lle_free = 0x80a2c5d0
>> , la_hold = 0x0, la_numheld = 0, la_expire =
>> 2110, la_flags = 1, la_asked = 0, la_preempt = 5, ln_state = 0,
>> ln_router = 0, ln_ntick = 0,
>> lle_refcnt = 1, lle_chain = {le_next = 0x0, le_prev = 0x0},
>> lle_timer = {c_links = {le = {le_next = 0x0, le_prev =
>> 0x81b2d588}, sle = {sle_next = 0x0}, tqe = {tqe_next = 0x0,
>> tqe_prev = 0x81b2d588}},
>> c_time = 9066299815445, c_precision = 322122525000, c_arg =
>> 0xf8005ecc4000, c_func = 0x80a246e0 , c_lock =
>> 0x0, c_flags = 0, c_iflags = 144, c_cpu = 0}, lle_lock = {lock_object
>> = {
>> lo_name = 0x8120fbce "lle", lo_flags = 90374144, lo_data
>> = 0, lo_witness = 0xfeb53c80}, rw_lock = 1}}
>>
>> ..
>>
>> (kgdb) print *((struct llentry *)c_arg)->lle_tbl
>> $4 = {llt_link = {sle_next = 0xdeadc0dedeadc0d
Re: panic in arptimer in r289937
31.10.2015, 05:32, "Adrian Chadd" :
> Hiya,
>
> Here's a panic from arptimer:
Hi Adrian,
As far as I see, line 205 in if_ether.c is IF_AFDATA_LOCK(ifp) which happens
after LLE_WUNLOCK().
So, it looks like (pre-cached) ifp had been freed before locking ifdata.
Do you have any more details on that? (e.g. was some interface detached at that
moment, is it reproducible, etc..)
From a quick glance, potential use-after-free has been possible for quite a
long time, but I wonder why it hasn't been observed before.
Probably lltable_free() changes might have triggered that.
I'll take a deeper look on that and reply.
>
> (kgdb) bt
> #0 doadump (textdump=0) at pcpu.h:221
> #1 0x803666b6 in db_fncall (dummy1=,
> dummy2=, dummy3=,
> dummy4=) at
> /usr/home/adrian/work/freebsd/head/src/sys/ddb/db_command.c:568
> #2 0x8036614e in db_command (cmd_table=0x0) at
> /usr/home/adrian/work/freebsd/head/src/sys/ddb/db_command.c:440
> #3 0x80365ee4 in db_command_loop () at
> /usr/home/adrian/work/freebsd/head/src/sys/ddb/db_command.c:493
> #4 0x8036897b in db_trap (type=, code=0)
> at /usr/home/adrian/work/freebsd/head/src/sys/ddb/db_main.c:251
> #5 0x8096c0f3 in kdb_trap (type=9, code=0, tf= optimized out>) at
> /usr/home/adrian/work/freebsd/head/src/sys/kern/subr_kdb.c:654
> #6 0x80d34c81 in trap_fatal (frame=0xfe022815d7a0,
> eva=) at
> /usr/home/adrian/work/freebsd/head/src/sys/amd64/amd64/trap.c:829
> #7 0x80d34951 in trap (frame=) at
> /usr/home/adrian/work/freebsd/head/src/sys/amd64/amd64/trap.c:203
> #8 0x80d149f7 in calltrap () at
> /usr/home/adrian/work/freebsd/head/src/sys/amd64/amd64/exception.S:234
> #9 0x8092c3fb in _rw_wlock_cookie (c=0xdeadc0dedeadc2de,
> file=0x81211b1f
> "/usr/home/adrian/work/freebsd/head/src/sys/netinet/if_ether.c",
> line=205)
> at /usr/home/adrian/work/freebsd/head/src/sys/kern/kern_rwlock.c:261
> #10 0x80a2487f in arptimer (arg=0xf8005ecc4000) at
> /usr/home/adrian/work/freebsd/head/src/sys/netinet/if_ether.c:205
> #11 0x80944c24 in softclock_call_cc (c=0xf8005ecc40a8,
> cc=0x81b2d480, direct=0) at
> /usr/home/adrian/work/freebsd/head/src/sys/kern/kern_timeout.c:722
> #12 0x80944f87 in softclock (arg=) at
> /usr/home/adrian/work/freebsd/head/src/sys/kern/kern_timeout.c:851
> #13 0x808f7eb6 in intr_event_execute_handlers (p= optimized out>, ie=0xf800035a6600) at
> /usr/home/adrian/work/freebsd/head/src/sys/kern/kern_intr.c:1262
> #14 0x808f8546 in ithread_loop (arg=0xf800032c47c0) at
> /usr/home/adrian/work/freebsd/head/src/sys/kern/kern_intr.c:1275
> #15 0x808f57a4 in fork_exit (callout=0x808f84a0
> , arg=0xf800032c47c0, frame=0xfe022815dac0) at
> /usr/home/adrian/work/freebsd/head/src/sys/kern/kern_fork.c:1011
> #16 0x80d14f2e in fork_trampoline () at
> /usr/home/adrian/work/freebsd/head/src/sys/amd64/amd64/exception.S:609
> #17 0x in ?? ()
> Current language: auto; currently minimal
>
> (kgdb) print *(struct llentry *)c_arg
> $2 = {lle_next = {le_next = 0x0, le_prev = 0xf8005e867dc8},
> r_l3addr = {addr4 = {s_addr = 16782508}, addr6 = {__u6_addr =
> {__u6_addr8 = 0xf8005ecc4010 "�\024", __u6_addr16 =
> 0xf8005ecc4010,
> __u6_addr32 = 0xf8005ecc4010}}}, ll_addr = {mac_aligned =
> 110869256150596, mac16 = 0xf8005ecc4020, mac8 = 0xf8005ecc4020
> "D\036���d"}, spare0 = 0, spare1 = 0, lle_tbl = 0xf8005e867e00,
> lle_head = 0xf8005e867dc8, lle_free = 0x80a2c5d0
> , la_hold = 0x0, la_numheld = 0, la_expire =
> 2110, la_flags = 1, la_asked = 0, la_preempt = 5, ln_state = 0,
> ln_router = 0, ln_ntick = 0,
> lle_refcnt = 1, lle_chain = {le_next = 0x0, le_prev = 0x0},
> lle_timer = {c_links = {le = {le_next = 0x0, le_prev =
> 0x81b2d588}, sle = {sle_next = 0x0}, tqe = {tqe_next = 0x0,
> tqe_prev = 0x81b2d588}},
> c_time = 9066299815445, c_precision = 322122525000, c_arg =
> 0xf8005ecc4000, c_func = 0x80a246e0 , c_lock =
> 0x0, c_flags = 0, c_iflags = 144, c_cpu = 0}, lle_lock = {lock_object
> = {
> lo_name = 0x8120fbce "lle", lo_flags = 90374144, lo_data
> = 0, lo_witness = 0xfeb53c80}, rw_lock = 1}}
>
> ..
>
> (kgdb) print *((struct llentry *)c_arg)->lle_tbl
> $4 = {llt_link = {sle_next = 0xdeadc0dedeadc0de}, llt_af = -559038242,
> llt_hsize = -559038242, lle_head = 0xdeadc0dedeadc0de, llt_ifp =
> 0xdeadc0dedeadc0de, llt_lookup = 0xdeadc0dedeadc0de,
> llt_alloc_entry = 0xdeadc0dedeadc0de, llt_delete_entry =
> 0xdeadc0dedeadc0de, llt_prefix_free = 0xdeadc0dedeadc0de,
> llt_dump_entry = 0xdeadc0dedeadc0de, llt_hash = 0xdeadc0dedeadc0de,
> llt_match_prefix = 0xdeadc0dedeadc0de,
> llt_free_entry = 0xdeadc0dedeadc0de, llt_foreach_entry =
> 0xdeadc0dedeadc0de, llt_link_entry = 0xdeadc0dedeadc0de,
> llt_unlink_entry = 0xdeadc0dedeadc0de, llt_fill_sa_entry =
> 0xdeadc0dedeadc0de,
> llt_free_tb
Re: [HEADSUP] OpenSSL updated to 1.0.2d
Am Fri, 30 Oct 2015 16:57:45 -0400 Jung-uk Kim schrieb: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > OpenSSL on head has been updated to 1.0.2d. Please make sure to > recompile all binaries depending on libcrypto.so.7 or libssl.so.7. That is good news. Could you provide, please, some hints how one could check all installed ports for the usage of those specific libraries? Or could you provide a hint towards an existing port already providing those tools? It would be great for those "from the set of ordinary people" using FreeBSD. I ask for that because I recall that there were a couple of ports which explicitely asks for a selection of what SSL lib should be used and in my case, I use the base system's one. Thank you very much in advance, oh > > Cheers! > > Jung-uk Kim > -BEGIN PGP SIGNATURE- > Version: GnuPG v2 > > iQEcBAEBCAAGBQJWM9nDAAoJEHyflib82/FGuV8H+gKZRDJ/FvPQ/D5wCTBddfgJ > 0i8ptgdzWtSABOSOUeKYBceHhiHUOjlnl2UdMv3JWq6virqCx1YXlJTIHACeZL7D > SSqyuMT3qfZFLwi8fw/dnzgIZx1N86wQlIZOU/3807SN0+h0uCcOq1/Dj/j/wsQx > XpM/tLgnQfqiRSl8pZPUleyOKqqhrFv+pJv7uybAQzTwdQ03pzhd694dy4futsg2 > wxFLUK8BbXWv1ZW37wDysyMyaem02nqCMYUXPoGfjMEwN6DFsx3WVUyKpZxMYQ8x > fNtV3l61tXRczQWzh/rnslSxjbbjMlS4/DKt2x+mzHELUFiOoPqc3/z0CgFUoNk= > =Wa/Z > -END PGP SIGNATURE- > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" pgpqTSzdztuZr.pgp Description: OpenPGP digital signature
