date:20151031

FreeBSD_HEAD_i386 - Build #1558 - Fixed

2015-10-31 Thread jenkins-admin

FreeBSD_HEAD_i386 - Build #1558 - Fixed:

Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/1558/
Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/1558/changes
Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/1558/console

Change summaries:

290224 by imp:
The error classification from lower layers is a poor indicator of
whether an error is recoverable. Always re-dirty the buffer on errors
from write requests. The invalidation we used to do for errors not EIO
doesn't need to be done for a device that's really gone, since that's
done in a different path.

Reviewed by: mckusick@, kib@

290223 by imp:
Rather than using the #define for path names, indirect through a char *
variable that could change for different executable types detected.

290222 by imp:
Move all the paths into a new path.h to centralize them.

290221 by jhibbits:
Print unsigned memory sizes, to handle >2GB RAM on 32-bit powerpc.

Sponsored by:   Alex Perez/Intertial Computing

290220 by bdrewery:
Don't hide stderr when checking ${CC} --version.

This can have important debugging information such as 'cc: not found' or
'ccache: error: Could not find compiler "cc" in PATH'.

MFC after:  2 weeks
Sponsored by:   EMC / Isilon Storage Division

___
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

2015-10-31 Thread NGie Cooper


> 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

$ env MAKEOBJDIRPREFIX=/scratch/tmp/$USER/obj make buildenv TARGET=mips 
TARGET_ARCH=mips
Entering world for mips:mips
$ make -VMAKEOBJDIRPREFIX
/scratch/tmp/ngie/obj/mips.mips
$ which dtrace
/usr/sbin/dtrace

Uh… yeah… running the copy from the build host is no bueno. So, that root 
causes that issue. I’ll file a bug for that (dtrace needs to be built as a 
bootstrap/cross tool). The -m64 issue is because it’s compiled for amd64 and is 
running arguments that are only supposed to “work” for x86 platforms (in 
reality, there’s also no reason why -m32/-m64 need to be passed to 
${CC}/${CPP}):

1256 #ifdef illumos
1257 #ifdef __x86
1258 /*
1259  * On x86 systems, __i386 is defined for  for 
32-bit
1260  * compiles and __amd64 is defined for 64-bit compiles.  Unlike 
SPARC,
1261  * they are defined exclusive of one another (see PSARC 2004/619).
1262  */
1263 if (dtp->dt_conf.dtc_ctfmodel == CTF_MODEL_LP64) {
1264 if (dt_cpp_add_arg(dtp, "-D__amd64") == NULL)
1265 return (set_open_errno(dtp, errp, EDT_NOMEM));
1266 } else {
1267 if (dt_cpp_add_arg(dtp, "-D__i386") == NULL)
1268 return (set_open_errno(dtp, errp, EDT_NOMEM));
1269 }
1270 #endif
1271 #else
1272 #if defined(__amd64__) || defined(__i386__)
1273 if (dtp->dt_conf.dtc_ctfmodel == CTF_MODEL_LP64) {
1274 if (dt_cpp_add_arg(dtp, "-m64") == NULL)
1275 return (set_open_errno(dtp, errp, EDT_NOMEM));
1276 } else {
1277 if (dt_cpp_add_arg(dtp, "-m32") == NULL)
1278 return (set_open_errno(dtp, errp, EDT_NOMEM));
1279 }
1280 #endif
1281 #endif

As for why the original issue occurred on my VM (which was the powerpc:powerpc 
case), I’m not sure yet. I’m working on figuring that out.

Thanks!
-NGie
___
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: [HEADSUP] OpenSSL updated to 1.0.2d

2015-10-31 Thread O. Hartmann

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

pf NAT and VNET Jails

2015-10-31 Thread Shawn Webb

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: 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

2015-10-31 Thread NGie Cooper


> 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"

Re: panic in arptimer in r289937

2015-10-31 Thread Alexander V . Chernikov



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 =
>

Re: panic in arptimer in r289937

2015-10-31 Thread 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
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

Re: [HEADSUP] OpenSSL updated to 1.0.2d

2015-10-31 Thread Eric van Gyzen


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

2015-10-31 Thread Alexander V . Chernikov



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,

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

2015-10-31 Thread NGie Cooper


> 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

Re: pf NAT and VNET Jails

2015-10-31 Thread Julian Elischer


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"

FreeBSD_HEAD_i386 - Build #1558 - Fixed

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

Re: [HEADSUP] OpenSSL updated to 1.0.2d

pf NAT and VNET Jails

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

Re: panic in arptimer in r289937

Re: panic in arptimer in r289937

Re: [HEADSUP] OpenSSL updated to 1.0.2d

Re: panic in arptimer in r289937

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

Re: pf NAT and VNET Jails

11 matches

Site Navigation

Mail list logo

Footer information