Re: Is NextBSD safe for bhyve?
Okay, thanks. Thats great news. I just wanted to run NEXTBSD as a client to test it out. I see that there is an ISO installer for simplicity. VBox may be just as easy if that's true. Russ On Thu, Aug 27, 2015 at 6:16 AM, Outback Dingo wrote: > > > On Thu, Aug 27, 2015 at 5:15 PM, Russell Haley > wrote: > >> Is NextBSD safe for bhyve? >> >> Thanks >> > > Consider that everything CURRENT, can be somewhat volatile at times, I > wouldnt recommend it for a production business case. > However that being said I do have XEN/NextBSD running as a dom0 quite > well, iocage, behyve and others are being reveiwed > for use cases, at this state of flux your mileage may vary depending on > exactly what your using it for, localized testing and > running a few vms, Ive accomplished that much with XEN so far. But again, > it is based on CURRENT with alot of additions > being merged in and worked on daily. > > >> >> Russ >> ___ >> 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"
r287246: buildworld fails: ld: i386:x86-64 architecture of input file `/usr/obj/usr/src/sys/boot/i386/gptboot/../../libstand32/libstand.a(qdivrem.o)' is incompatible with i386 output
Recent CURRENT sources fail to buildworld: [...] --- util.o --- cc -DBOOTPROG=\"gptboot\" -O1 -DGPT -DUFS1_AND_UFS2 -DSIOPRT=0x3f8 -DSIOFMT=0x3 -DSIOSPD=9600 -I/usr/src/sys/boot/i386/gptboot/../../common -I/usr/src/sys/boot/i386/gptboot/../common -I/usr/src/sys/boot/i386/gptboot/../btx/lib -I. -I/usr/src/sys/boot/i386/gptboot/../boot2 -I/usr/src/sys/boot/i386/gptboot/../../.. -Wall -Waggregate-return -Wbad-function-cast -Wcast-align -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wshadow -Wstrict-prototypes -Wwrite-strings -Winline -march=i386 -ffreestanding -mno-mmx -mno-sse -mno-avx -msoft-float -m32 -DNDEBUG -std=gnu99-Qunused-arguments -c /usr/src/sys/boot/i386/gptboot/../../common/util.c -o util.o --- gptldr.out --- ld -static -N --gc-sections -m elf_i386_fbsd -e start -Ttext 0x7c00 -o gptldr.out gptldr.o --- gptboot.out --- ld -static -N --gc-sections -m elf_i386_fbsd -Ttext 0x0 -o gptboot.out /usr/obj/usr/src/sys/boot/i386/gptboot/../btx/lib/crt0.o gptboot.o sio.o gpt.o crc32.o drv.o cons.o util.o /usr/obj/usr/src/sys/boot/i386/gptboot/../../libstand32/libstand.a ld: i386:x86-64 architecture of input file `/usr/obj/usr/src/sys/boot/i386/gptboot/../../libstand32/libstand.a(qdivrem.o)' is incompatible with i386 output *** [gptboot.out] Error code 1 make[6]: stopped in /usr/src/sys/boot/i386/gptboot 1 error make[6]: stopped in /usr/src/sys/boot/i386/gptboot *** [_sub.all] Error code 2 ___ 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: Why does netstat not work in jails?
On Fri, 28 Aug 2015 08:12:53 +0300 "Alexander V. Chernikov" wrote > 28.08.2015, 04:56, "Chris H" : > > I've been attempting to run jails on an 11-CURRENT > > for the purpose of building world/kernel && ports > > for all of our 9-STABLE production servers. I'm using > > standard/classic jail setup(s) -- not using any > > of the "convenience" ports/applications that abstract > > the process in any way. > > While everything seemed to go as intended/anticipated, > > I'm seeing things I *didn't* expect. > > The host network get's it's "public" IP from the router > > in front of it. From the router, I insure that it is > > allocated the same non-public IP everytime. So DHCP > > assigns it 192.168.0.100. I assigned the jail 192.168.0.103. > > SSHD is started within the jail, root IS allowed login. > > But any attempt to ssh to 192.168.0.103 from the host, > > returns: > > ssh_exchange_identification: Connection closed by remote host. > > > > SSHD id NOT running on the host. > > > > inetd_flags="-wW -a 192.168.0.100" and syslogd_flags="-ss" > > is set on the host via rc.conf > > > > second issue; loging into the jail, via jexex. If I perform: > > netstat -nr > > The following is returned: > > netstat: kvm not available: /dev/mem: No such file or directory > > Routing tables > > rt_tables: symbol not in namelist > > > > Any thought's jump out at anyone? > Direct kvm interface was removed from head a year ago. > What you can do is recompiling netstat binary from 9 with NewTree variable > defined to 1 and see if this helps. Output will look a bit different, but > you'll be able to see routing tables from jail. > https://svnweb.freebsd.org/base/stable/9/usr.bin/netstat/route.c?revision=242 > 025&view=markup#l122 > > Another option is merging r261207 and r263335. Perfect! That explains it. Thank you, Alexander! --Chris -- ___ 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: Why does netstat not work in jails?
28.08.2015, 04:56, "Chris H" : > I've been attempting to run jails on an 11-CURRENT > for the purpose of building world/kernel && ports > for all of our 9-STABLE production servers. I'm using > standard/classic jail setup(s) -- not using any > of the "convenience" ports/applications that abstract > the process in any way. > While everything seemed to go as intended/anticipated, > I'm seeing things I *didn't* expect. > The host network get's it's "public" IP from the router > in front of it. From the router, I insure that it is > allocated the same non-public IP everytime. So DHCP > assigns it 192.168.0.100. I assigned the jail 192.168.0.103. > SSHD is started within the jail, root IS allowed login. > But any attempt to ssh to 192.168.0.103 from the host, > returns: > ssh_exchange_identification: Connection closed by remote host. > > SSHD id NOT running on the host. > > inetd_flags="-wW -a 192.168.0.100" and syslogd_flags="-ss" > is set on the host via rc.conf > > second issue; loging into the jail, via jexex. If I perform: > netstat -nr > The following is returned: > netstat: kvm not available: /dev/mem: No such file or directory > Routing tables > rt_tables: symbol not in namelist > > Any thought's jump out at anyone? Direct kvm interface was removed from head a year ago. What you can do is recompiling netstat binary from 9 with NewTree variable defined to 1 and see if this helps. Output will look a bit different, but you'll be able to see routing tables from jail. https://svnweb.freebsd.org/base/stable/9/usr.bin/netstat/route.c?revision=242025&view=markup#l122 Another option is merging r261207 and r263335. > > Thanks! > > --Chris > > -- > > ___ > 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: Instant panic while trying run ports-mgmt/poudriere
On 08/23/15 22:54, Konstantin Belousov wrote:
> On Sun, Aug 23, 2015 at 12:08:16PM +0300, Konstantin Belousov wrote:
>> On Sun, Aug 23, 2015 at 09:54:28AM +0300, Andriy Gapon wrote:
>>> On 12/08/2015 17:11, Lawrence Stewart wrote:
On 08/07/15 07:33, Pawel Pekala wrote:
> Hi K.,
>
> On 2015-08-06 12:33 -0700, "K. Macy" wrote:
>> Is this still happening?
>
> Still crashes:
+1 for me running r286617
>>>
>>> Here is another +1 with r286922.
>>> I can add a couple of bits of debugging data:
>>>
>>> (kgdb) fr 8
>>> #8 0x80639d60 in knote (list=0xf8019a733ea0,
>>> hint=2147483648, lockflags=) at
>>> /usr/src/sys/kern/kern_event.c:1964
>>> 1964} else if ((lockflags & KNF_NOKQLOCK) != 0) {
>>> (kgdb) p *list
>>> $2 = {kl_list = {slh_first = 0x0}, kl_lock = 0x8063a1e0
>>> , kl_unlock = 0x8063a200 ,
>>> kl_assert_locked = 0x8063a220 ,
>>> kl_assert_unlocked = 0x8063a240 ,
>>> kl_lockarg = 0xf8019a733bb0}
>>> (kgdb) disassemble
>>> Dump of assembler code for function knote:
>>> 0x80639d00 : push %rbp
>>> 0x80639d01 : mov%rsp,%rbp
>>> 0x80639d04 : push %r15
>>> 0x80639d06 : push %r14
>>> 0x80639d08 : push %r13
>>> 0x80639d0a : push %r12
>>> 0x80639d0c : push %rbx
>>> 0x80639d0d : sub$0x18,%rsp
>>> 0x80639d11 : mov%edx,%r12d
>>> 0x80639d14 : mov%rsi,-0x30(%rbp)
>>> 0x80639d18 : mov%rdi,%rbx
>>> 0x80639d1b : test %rbx,%rbx
>>> 0x80639d1e : je 0x80639ef6
>>> 0x80639d24 : mov%r12d,%eax
>>> 0x80639d27 : and$0x1,%eax
>>> 0x80639d2a : mov%eax,-0x3c(%rbp)
>>> 0x80639d2d : mov0x28(%rbx),%rdi
>>> 0x80639d31 : je 0x80639d38
>>> 0x80639d33 : callq *0x18(%rbx)
>>> 0x80639d36 : jmp0x80639d42
>>> 0x80639d38 : callq *0x20(%rbx)
>>> 0x80639d3b : mov0x28(%rbx),%rdi
>>> 0x80639d3f : callq *0x8(%rbx)
>>> 0x80639d42 : mov%rbx,-0x38(%rbp)
>>> 0x80639d46 : mov(%rbx),%rbx
>>> 0x80639d49 : test %rbx,%rbx
>>> 0x80639d4c : je 0x80639ee5
>>> 0x80639d52 : and$0x2,%r12d
>>> 0x80639d56 : nopw %cs:0x0(%rax,%rax,1)
>>> 0x80639d60 : mov0x28(%rbx),%r14
>>>
>>> Panic is in the last quoted instruction.
>>> And:
>>> (kgdb) i reg
>>> rax0x246582
>>> rbx0xdeadc0dedeadc0de -2401050962867404578
>>> rcx0x0 0
>>> rdx0x12e302
>>> rsi0x80a26a5a -2136839590
>>> rdi0x80e81b80 -2132272256
>>> rbp0xfe02b7efea20 0xfe02b7efea20
>>> rsp0xfe02b7efe9e0 0xfe02b7efe9e0
>>> r8 0x80a269ce -2136839730
>>> r9 0x80e82838 -2132269000
>>> r100x1 65536
>>> r110x80fabd10 -2131051248
>>> r120x0 0
>>> r130xf801ff84a818 -8787511171048
>>> r140xf801ff84a800 -8787511171072
>>> r150xf8019a6974f0 -8789207452432
>>> rip0x80639d60 0x80639d60
>>> eflags 0x10286 66182
>>>
>>> I think that $rbx stands out here (this is a kernel with INVARIANTS).
>>>
>>> Looking at the code, is it possible that one of the calls from within
>>> the loop's body modifies the list? If that is so and provided that is a
>>> valid behavior, then maybe using SLIST_FOREACH_SAFE would help.
>>
>> This is first time a useful debugging data was posted.
>>
>> The 0x28 offset may indicate either kn_kq member access of the struct
>> knote, or kq_list of the struct kqueue.
>>
>> kl_list.slh_first of the list parameter is NULL, how would a list
>> iteration loop even start ? Can you look up the list argument value
>> from the previous frame (%rdi is overwritten, so debugger might be
>> confused) ?
>
> After looking at your data closely, I think you are right. The panic
> occurs when the exit1(9) does KNOTE_LOCKED(NOTE_EXIT). This is the
> only case in the tree where filter uses knlist_remove_inevent() to detach
> processed note, so indeed the slist is modified under the iterator.
>
> Below is the patch with the suggested change and unrelated cleanup of
> the uma(9) KPI use. Please test, everybody who has a panic with the
> backtrace pointing to the sys_exit().
Fixes the panic for me too, thanks Kostik.
Cheers,
Lawrence
___
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 - Build #3138 - Failure
FreeBSD_HEAD - Build #3138 - Failure: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD/3138/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD/3138/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD/3138/console Change summaries: 287240 by jhibbits: Extend pmap to support e500mc and e5500. As part of this, clean up tlb1_init(), since bootinfo is always NULL here just eliminate the loop altogether. Also, fix a bug in mmu_booke_mapdev_attr() where it's possible to map a larger immediately following a smaller page, causing the mappings to overlap. Instead, break up the new mapping into smaller chunks. The downside to this is that it uses more precious TLB1 entries, which, on smaller chips (e500v2) it could cause problems with TLB1 being out of space (e500v2 only has 16 TLB1 entries). Obtained from: Semihalf (partial) Sponsored by: Alex Perez/Inertial Computing 287239 by imp: Simply to appease gcc's warnings. 287238 by yongari: Set DMA alignment constraint of status, TX and RX LEs(List Elements in Marvell terms) to 32768. 32768 looks overkill but it will ensure correct DMAed update. This change addresses occasional watchdog timeouts reported on 10.2-RELEASE. Tested by: Johann Hugo MFC after: 2 weeks 287237 by delphij: Respect locale settings. MFC after: 2 weeks 287236 by delphij: Use exit() instead of return in main(). MFC after: 2 weeks 287235 by markj: Remove weighted page handling from vm_page_advise(). This was added in r51337 as part of the implementation of madvise(MADV_DONTNEED). Its objective was to ensure that the page daemon would eventually reclaim other unreferenced pages (i.e., unreferenced pages not touched by madvise()) from the active queue. Now that the pagedaemon performs steady scanning of the active page queue, this weighted handling is unnecessary. Instead, always "cache" clean pages by moving them to the head of the inactive page queue. This simplifies the implementation of vm_page_advise() and eliminates the fragmentation that resulted from the distribution of pages among multiple queues. Suggested by: alc Reviewed by:alc Sponsored by: EMC / Isilon Storage Division Differential Revision: https://reviews.freebsd.org/D3401 287234 by markj: Re-apply r274569. It was reverted in r276848 since that appeared to fix some ctfmerge crashes that started to occur on i386 weeks after r274569 was committed. Some later investigation indicated that the crashes were caused by malformed CTF info that led to a stack overflow. The issue with CTF info in i386 kernels seems to have been resolved by r261246, which updated libdwarf and libelf. r274569 fixes a bug which caused duplicate types to appear in the kernel's CTF info. This duplication generally does not cause problems when using DTrace, but makes it easier to hit the limit of 2^15 - 1 distinct type definitions in a CTF container. MFC after: 2 weeks 287233 by markj: Remove an unneeded instruction. MFC after: 1 week 287232 by markj: nv.h lives in sys/ as of r279439. 287227 by imp: Use CFLAGS_NO_SIMD in preference to varying lists of -mno- flags. Go ahead and defined -D_STANDALONE for all targets (only strictly needed for some architecture, but harmless on those it isn't required for). Also add -msoft-float to all architectures uniformly rather that higgley piggley like it is today. Differential Revision: https://reviews.freebsd.org/D3496 287225 by imp: New 1-Wire bus implementation. 1-Wire controller is abstracted, though only gpiobus configured via FDT is supported. Bus enumeration is supported. Devices are created for each device found. 1-Wire temperature controllers are supported, but other drivers could be written. Temperatures are polled and reported via a sysctl. Errors are reported via sysctl counters. Mis-wired bus detection is included for more trouble shooting. See ow(4), owc(4) and ow_temp(4) for details of what's supported and known issues. This has been tested on Raspberry Pi-B, Pi2 and Beagle Bone Black with up to 7 devices. Differential Revision: https://reviews.freebsd.org/D2956 Relnotes: yes MFC after: 2 weeks Reviewed by: loos@ (with many insightful comments) The end of the build log: [...truncated 55574 lines...] --- DiagnosticFrontendKinds.inc.h --- clang-tblgen -gen-clang-diags-defs -clang-component=Frontend -I /builds/FreeBSD_HEAD/usr.bin/clang/clang/../../../contrib/llvm/tools/clang/include/clang/Basic -d DiagnosticFrontendKinds.inc.d -o DiagnosticFrontendKinds.inc.h /builds/FreeBSD_HEAD/usr.bin/clang/clang/../../../contrib/llvm/tools/clang/include/clang/Basic/Diagnostic.td --- DiagnosticLexKinds.inc.h --- clang-tblgen -gen-clang-diags-defs -clang-component=Lex -I /builds/FreeBSD_HEAD/usr.bin/clang/clang/../../../contrib/llvm/tools/clang/include/clang/Basic -d DiagnosticLexKinds.inc.d -o DiagnosticLexKinds.inc.h /builds/FreeBSD_HEAD/usr.bin/clang/clang/../../../contrib/llvm/tools/clang/includ
Re: Why does netstat not work in jails?
On Thu, 27 Aug 2015 22:33:04 -0400 Allan Jude wrote > On 2015-08-27 22:12, Julian Elischer wrote: > > On 8/28/15 9:54 AM, Chris H wrote: > >> I've been attempting to run jails on an 11-CURRENT > >> for the purpose of building world/kernel && ports > >> for all of our 9-STABLE production servers. I'm using > >> standard/classic jail setup(s) -- not using any > >> of the "convenience" ports/applications that abstract > >> the process in any way. > >> While everything seemed to go as intended/anticipated, > >> I'm seeing things I *didn't* expect. > >> The host network get's it's "public" IP from the router > >> in front of it. From the router, I insure that it is > >> allocated the same non-public IP everytime. So DHCP > >> assigns it 192.168.0.100. I assigned the jail 192.168.0.103. > >> SSHD is started within the jail, root IS allowed login. > >> But any attempt to ssh to 192.168.0.103 from the host, > >> returns: > >> ssh_exchange_identification: Connection closed by remote host. > >> > >> SSHD id NOT running on the host. > >> > >> inetd_flags="-wW -a 192.168.0.100" and syslogd_flags="-ss" > >> is set on the host via rc.conf > > what does netstat -aAn show (on the main host). > > > >> second issue; loging into the jail, via jexex. If I perform: > >> netstat -nr > >> The following is returned: > >> netstat: kvm not available: /dev/mem: No such file or directory > > is there a /dev in the jail? if you have set it up, have you allowed > > mem to be one of the exported devices? > > I forget the exact details on how to set this but hopefully it's a hint. > > I have to look it up every time. Thanks for the hint, Julian! > > > >> Routing tables > >> rt_tables: symbol not in namelist > >> > >> Any thought's jump out at anyone? > >> > >> Thanks! > >> > >> --Chris > >> > >> -- > > Normally I wouldn't think you would want /dev/mem to be accessible > inside a jail, but you can probably do it by editing some of the devfs > rules. > > What info are you trying to get from netstat? Get some idea of what the jail thinks it's [network] topology is. So I might better debug my being unable to ssh into it from the host. > some of the info is available from sockstat etc. Indeed, sockstat(1) surprisingly *does* work. I thought of using it, too. But assumed /dev/mem would have been involved there, also. > > -- > Allan Jude Thanks, Allen, Julian! --Chris ___ 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: Why does netstat not work in jails?
On 2015-08-27 22:12, Julian Elischer wrote: > On 8/28/15 9:54 AM, Chris H wrote: >> I've been attempting to run jails on an 11-CURRENT >> for the purpose of building world/kernel && ports >> for all of our 9-STABLE production servers. I'm using >> standard/classic jail setup(s) -- not using any >> of the "convenience" ports/applications that abstract >> the process in any way. >> While everything seemed to go as intended/anticipated, >> I'm seeing things I *didn't* expect. >> The host network get's it's "public" IP from the router >> in front of it. From the router, I insure that it is >> allocated the same non-public IP everytime. So DHCP >> assigns it 192.168.0.100. I assigned the jail 192.168.0.103. >> SSHD is started within the jail, root IS allowed login. >> But any attempt to ssh to 192.168.0.103 from the host, >> returns: >> ssh_exchange_identification: Connection closed by remote host. >> >> SSHD id NOT running on the host. >> >> inetd_flags="-wW -a 192.168.0.100" and syslogd_flags="-ss" >> is set on the host via rc.conf > what does netstat -aAn show (on the main host). > >> second issue; loging into the jail, via jexex. If I perform: >> netstat -nr >> The following is returned: >> netstat: kvm not available: /dev/mem: No such file or directory > is there a /dev in the jail? if you have set it up, have you allowed > mem to be one of the exported devices? > I forget the exact details on how to set this but hopefully it's a hint. > I have to look it up every time. > >> Routing tables >> rt_tables: symbol not in namelist >> >> Any thought's jump out at anyone? >> >> Thanks! >> >> --Chris >> >> -- Normally I wouldn't think you would want /dev/mem to be accessible inside a jail, but you can probably do it by editing some of the devfs rules. What info are you trying to get from netstat? some of the info is available from sockstat etc. -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: Why does netstat not work in jails?
On 8/28/15 9:54 AM, Chris H wrote: I've been attempting to run jails on an 11-CURRENT for the purpose of building world/kernel && ports for all of our 9-STABLE production servers. I'm using standard/classic jail setup(s) -- not using any of the "convenience" ports/applications that abstract the process in any way. While everything seemed to go as intended/anticipated, I'm seeing things I *didn't* expect. The host network get's it's "public" IP from the router in front of it. From the router, I insure that it is allocated the same non-public IP everytime. So DHCP assigns it 192.168.0.100. I assigned the jail 192.168.0.103. SSHD is started within the jail, root IS allowed login. But any attempt to ssh to 192.168.0.103 from the host, returns: ssh_exchange_identification: Connection closed by remote host. SSHD id NOT running on the host. inetd_flags="-wW -a 192.168.0.100" and syslogd_flags="-ss" is set on the host via rc.conf what does netstat -aAn show (on the main host). second issue; loging into the jail, via jexex. If I perform: netstat -nr The following is returned: netstat: kvm not available: /dev/mem: No such file or directory is there a /dev in the jail? if you have set it up, have you allowed mem to be one of the exported devices? I forget the exact details on how to set this but hopefully it's a hint. I have to look it up every time. Routing tables rt_tables: symbol not in namelist Any thought's jump out at anyone? Thanks! --Chris -- ___ 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: Instant panic while trying run ports-mgmt/poudriere
On 08/27/15 17:15, Don Lewis wrote:
> On 27 Aug, Don Lewis wrote:
>> On 27 Aug, Lawrence Stewart wrote:
>>> On 08/27/15 09:36, John-Mark Gurney wrote:
Andriy Gapon wrote this message on Sun, Aug 23, 2015 at 09:54 +0300:
> On 12/08/2015 17:11, Lawrence Stewart wrote:
>> On 08/07/15 07:33, Pawel Pekala wrote:
>>> Hi K.,
>>>
>>> On 2015-08-06 12:33 -0700, "K. Macy" wrote:
Is this still happening?
>>>
>>> Still crashes:
>>
>> +1 for me running r286617
>
> Here is another +1 with r286922.
> I can add a couple of bits of debugging data:
>
> (kgdb) fr 8
> #8 0x80639d60 in knote (list=0xf8019a733ea0,
> hint=2147483648, lockflags=) at
> /usr/src/sys/kern/kern_event.c:1964
> 1964} else if ((lockflags & KNF_NOKQLOCK) != 0) {
> (kgdb) p *list
> $2 = {kl_list = {slh_first = 0x0}, kl_lock = 0x8063a1e0
We should/cannot get here w/ an empty list. If we do, then there is
something seriously wrong... The current kn (which we must have as we
are here) MUST be on the list, but as you just showed, there are no
knotes on the list.
Can you get me a print of the knote? That way I can see what flags
are on it?
>>>
>>> I quickly tried to get this info for you by building my kernel with -O0
>>> and reproducing, but I get an insta-panic on boot with the new kernel:
>>>
>>> Fatal double fault
>>> rip = 0x8218c794
>>> rsp = 0xfe044cdc9fe0
>>> rbp = 0xfe044cdca110
>>> cpuid = 2; apic id = 02
>>> panic: double fault
>>> cpuid = 2
>>> KDB: stack backtrace:
>>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
>>> 0xfe03dcfffe30
>>> vpanic() at vpanic+0x189/frame 0xfe03dcfffeb0
>>> panic() at panic+0x43/frame 0xfe03dc10
>>> dblfault_handler() at dblfault_handler+0xa2/frame 0xfe03dc30
>>> Xdblfault() at Xdblfault+0xac/frame 0xfe03dc30
>>> --- trap 0x17, rip = 0x8218c794, rsp = 0xfe044cdc9fe0, rbp =
>>> 0xfe044cdca110 ---
>>> vdev_queue_aggregate() at vdev_queue_aggregate+0x34/frame 0xfe044cdca110
>>> vdev_queue_io_to_issue() at vdev_queue_io_to_issue+0x1f5/frame
>>> 0xfe044cdca560
>>> vdev_queue_io() at vdev_queue_io+0x19a/frame 0xfe044cdca5b0
>>> zio_vdev_io_start() at zio_vdev_io_start+0x81f/frame 0xfe044cdca6e0
>>> zio_execute() at zio_execute+0x23b/frame 0xfe044cdca730
>>> zio_nowait() at zio_nowait+0xbe/frame 0xfe044cdca760
>>> vdev_mirror_io_start() at vdev_mirror_io_start+0x140/frame
>>> 0xfe044cdca800
>>> zio_vdev_io_start() at zio_vdev_io_start+0x12f/frame 0xfe044cdca930
>>> zio_execute() at zio_execute+0x23b/frame 0xfe044cdca980
>>> zio_nowait() at zio_nowait+0xbe/frame 0xfe044cdca9b0
>>> spa_load_verify_cb() at spa_load_verify_cb+0x37d/frame 0xfe044cdcaa50
>>> traverse_visitbp() at traverse_visitbp+0x5a5/frame 0xfe044cdcac60
>>> traverse_dnode() at traverse_dnode+0x98/frame 0xfe044cdcacd0
>>> traverse_visitbp() at traverse_visitbp+0xc66/frame 0xfe044cdcaee0
>>> traverse_visitbp() at traverse_visitbp+0x930/frame 0xfe044cdcb0f0
>>> traverse_visitbp() at traverse_visitbp+0x930/frame 0xfe044cdcb300
>>> traverse_visitbp() at traverse_visitbp+0x930/frame 0xfe044cdcb510
>>> traverse_visitbp() at traverse_visitbp+0x930/frame 0xfe044cdcb720
>>> traverse_visitbp() at traverse_visitbp+0x930/frame 0xfe044cdcb930
>>> traverse_visitbp() at traverse_visitbp+0x930/frame 0xfe044cdcbb40
>>> traverse_dnode() at traverse_dnode+0x98/frame 0xfe044cdcbbb0
>>> traverse_visitbp() at traverse_visitbp+0xe59/frame 0xfe044cdcbdc0
>>> traverse_impl() at traverse_impl+0x79d/frame 0xfe044cdcbfd0
>>> traverse_dataset() at traverse_dataset+0x93/frame 0xfe044cdcc040
>>> traverse_pool() at traverse_pool+0x1f2/frame 0xfe044cdcc140
>>> spa_load_verify() at spa_load_verify+0xf3/frame 0xfe044cdcc1f0
>>> spa_load_impl() at spa_load_impl+0x2069/frame 0xfe044cdcc610
>>> spa_load() at spa_load+0x320/frame 0xfe044cdcc6d0
>>> spa_load_impl() at spa_load_impl+0x150b/frame 0xfe044cdccaf0
>>> spa_load() at spa_load+0x320/frame 0xfe044cdccbb0
>>> spa_load_best() at spa_load_best+0xc6/frame 0xfe044cdccc50
>>> spa_open_common() at spa_open_common+0x246/frame 0xfe044cdccd40
>>> spa_open() at spa_open+0x35/frame 0xfe044cdccd70
>>> dsl_pool_hold() at dsl_pool_hold+0x2d/frame 0xfe044cdccdb0
>>> dmu_objset_own() at dmu_objset_own+0x2e/frame 0xfe044cdcce30
>>> zfsvfs_create() at zfsvfs_create+0x100/frame 0xfe044cdcd050
>>> zfs_domount() at zfs_domount+0xa7/frame 0xfe044cdcd0e0
>>> zfs_mount() at zfs_mount+0x6c3/frame 0xfe044cdcd390
>>> vfs_donmount() at vfs_donmount+0x1330/frame 0xfe044cdcd660
>>> kernel_mount() at kernel_mount+0x62/frame 0xfe044cdcd6c0
>>> parse_mount() at parse_mount+0x668/frame 0xfe044cdcd810
>>> vfs_mountroot() at vfs_mountroot+0x85c/frame 0xfe044cdcd9d
Why does netstat not work in jails?
I've been attempting to run jails on an 11-CURRENT for the purpose of building world/kernel && ports for all of our 9-STABLE production servers. I'm using standard/classic jail setup(s) -- not using any of the "convenience" ports/applications that abstract the process in any way. While everything seemed to go as intended/anticipated, I'm seeing things I *didn't* expect. The host network get's it's "public" IP from the router in front of it. From the router, I insure that it is allocated the same non-public IP everytime. So DHCP assigns it 192.168.0.100. I assigned the jail 192.168.0.103. SSHD is started within the jail, root IS allowed login. But any attempt to ssh to 192.168.0.103 from the host, returns: ssh_exchange_identification: Connection closed by remote host. SSHD id NOT running on the host. inetd_flags="-wW -a 192.168.0.100" and syslogd_flags="-ss" is set on the host via rc.conf second issue; loging into the jail, via jexex. If I perform: netstat -nr The following is returned: netstat: kvm not available: /dev/mem: No such file or directory Routing tables rt_tables: symbol not in namelist Any thought's jump out at anyone? Thanks! --Chris -- ___ 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_amd64_gcc4.9 - Build #387 - Failure
FreeBSD_HEAD_amd64_gcc4.9 - Build #387 - Failure: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc4.9/387/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc4.9/387/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc4.9/387/console Change summaries: 287237 by delphij: Respect locale settings. MFC after: 2 weeks 287236 by delphij: Use exit() instead of return in main(). MFC after: 2 weeks 287235 by markj: Remove weighted page handling from vm_page_advise(). This was added in r51337 as part of the implementation of madvise(MADV_DONTNEED). Its objective was to ensure that the page daemon would eventually reclaim other unreferenced pages (i.e., unreferenced pages not touched by madvise()) from the active queue. Now that the pagedaemon performs steady scanning of the active page queue, this weighted handling is unnecessary. Instead, always "cache" clean pages by moving them to the head of the inactive page queue. This simplifies the implementation of vm_page_advise() and eliminates the fragmentation that resulted from the distribution of pages among multiple queues. Suggested by: alc Reviewed by:alc Sponsored by: EMC / Isilon Storage Division Differential Revision: https://reviews.freebsd.org/D3401 287234 by markj: Re-apply r274569. It was reverted in r276848 since that appeared to fix some ctfmerge crashes that started to occur on i386 weeks after r274569 was committed. Some later investigation indicated that the crashes were caused by malformed CTF info that led to a stack overflow. The issue with CTF info in i386 kernels seems to have been resolved by r261246, which updated libdwarf and libelf. r274569 fixes a bug which caused duplicate types to appear in the kernel's CTF info. This duplication generally does not cause problems when using DTrace, but makes it easier to hit the limit of 2^15 - 1 distinct type definitions in a CTF container. MFC after: 2 weeks 287233 by markj: Remove an unneeded instruction. MFC after: 1 week 287232 by markj: nv.h lives in sys/ as of r279439. 287227 by imp: Use CFLAGS_NO_SIMD in preference to varying lists of -mno- flags. Go ahead and defined -D_STANDALONE for all targets (only strictly needed for some architecture, but harmless on those it isn't required for). Also add -msoft-float to all architectures uniformly rather that higgley piggley like it is today. Differential Revision: https://reviews.freebsd.org/D3496 287225 by imp: New 1-Wire bus implementation. 1-Wire controller is abstracted, though only gpiobus configured via FDT is supported. Bus enumeration is supported. Devices are created for each device found. 1-Wire temperature controllers are supported, but other drivers could be written. Temperatures are polled and reported via a sysctl. Errors are reported via sysctl counters. Mis-wired bus detection is included for more trouble shooting. See ow(4), owc(4) and ow_temp(4) for details of what's supported and known issues. This has been tested on Raspberry Pi-B, Pi2 and Beagle Bone Black with up to 7 devices. Differential Revision: https://reviews.freebsd.org/D2956 Relnotes: yes MFC after: 2 weeks Reviewed by: loos@ (with many insightful comments) 287224 by imp: Document bsd.endian.mk. 287222 by kp: pf: Remove support for 'scrub fragment crop|drop-ovl' The crop/drop-ovl fragment scrub modes are not very useful and likely to confuse users into making poor choices. It's also a fairly large amount of complex code, so just remove the support altogether. Users who have 'scrub fragment crop|drop-ovl' in their pf configuration will be implicitly converted to 'scrub fragment reassemble'. Reviewed by:gnn, eri Relnotes: yes Differential Revision: https://reviews.freebsd.org/D3466 The end of the build log: [...truncated 165633 lines...] /usr/local/x86_64-freebsd/bin/ranlib -D libficl.a ===> sys/boot/i386 (all) make[5]: "/builds/FreeBSD_HEAD_amd64_gcc4.9/sys/boot/i386/Makefile" line 16: warning: "Skipping boot2 with gcc 40902" make[5]: "/builds/FreeBSD_HEAD_amd64_gcc4.9/sys/boot/i386/Makefile" line 20: warning: "SUBDIR is mbr pmbr boot0 boot0sio btx cdboot gptboot kgzldr libi386 libfirewire loader pxeldr zfsboot gptzfsboot zfsloader" --- _sub.all --- ===> sys/boot/i386/mbr (all) --- mbr.o --- /usr/local/x86_64-freebsd/bin/as --defsym FLAGS=0x80 --32 -o mbr.o /builds/FreeBSD_HEAD_amd64_gcc4.9/sys/boot/i386/mbr/mbr.s --- lib.all__D --- --- ulog_login_pseudo.po --- /usr/local/bin/x86_64-portbld-freebsd10.1-gcc -isystem /builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/include -L/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/lib --sysroot=/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp -B/usr/local/x86_64-freebsd/bin/ -pg -O2 -pipe -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-p
Re: ramblings.. or not
On Wed, Aug 26, 2015 at 8:44 PM, Julian Elischer wrote: > I just enjoyed the following video. > > http://nextbsd.org/jordan-hubbard-visits-bafug/ > > That is a very good video. It is good to see the NextBSD folks pushing the boundaries and innovating with BSD. A lot of the Apple technologies have been battle tested by millions of users, so if FreeBSD can benefit from themwhy not? > Do we have a standard path for ideas from these projects and DragonFly? > >From what I can tell, there is no "official" standard path for getting anything into FreeBSD. Ideally, people should bring up ideas and discuss things on the mailing lists beforehand. That usually happens, but not always. At the end of the day, getting things into FreeBSD involves someone with a commit bit, who is motivated to slam the code into the tree. Occasionally there are problems, but for the most part, things seem to work out, and we've gotten cool things like ZFS, Dtrace, Netmap, etc. At the end of Jordan's video, he mentioned that while it took him a while to get accustomed to git, he realizes that git and git ecosystems like GitHub greatly facilitate interacting with an open source project. Forking, submitting patches, etc. are greatly > > We should also do a better job of productising and incorporating GSOC > work.. > > Definitely! It's sad to see people put a lot of working into something via GSOC, and then have the work die on the vine once the summer is over. > Maybe we should make the "ideas" page more mainline. Where people can put > in a more standard way links to their pet projects and "offically" submit > work for inclusion. > and then make it better known.. > > I've been working with a software developer in Egypt, Ahmed Kamal, who has helped me a lot with devops issues in the Jenkins cluster. Ahmed attended BSDCan this year and is eager to help out. Many thanks to FreeBSD Foundation for giving him a travel grant! One comment that Ahmed made to me, and also to the FreeBSD Foundation, is that for a complete newcomer to FreeBSD, it is very difficult for a newcomer to navigate all our web pages and wikis, and figure out where they can jump in and contribute to the project. The FreeBSD project could definitely work to improve this area, in order to attract new blood and new ideas to the project. Streamlining the ideas page would be a good start. -- Craig ___ 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 - Build #3136 - Fixed
FreeBSD_HEAD - Build #3136 - Fixed: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD/3136/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD/3136/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD/3136/console Change summaries: 287218 by jmg: add documentation for timers that silby added in r197244, almost 6 years ago... 287217 by delphij: die() would never return, mark it as so. MFC after: 2 weeks 287216 by ume: Move setting of LDFLAGS to the modules which require it actually, as other kerberos5 modules do so. ___ 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: Instant panic while trying run ports-mgmt/poudriere
On 27/08/2015 23:21, Andriy Gapon wrote: >> > First off, that can't be r286922, per: >> > https://svnweb.freebsd.org/base/stable/10/sys/kern/kern_event.c?annotate=286922 >> > >> > line 1964 is blank... The line of code above should be at line 1884, >> > so not sure what is wrong here... > No, it can not be indeed, because I am running head. > r286922 was the latest version of the repository, not the head branch, > at the moment when I pulled the repository via git. Hrm, a small - irrelevant for me, but probably not for you - nit: r286922 is actually a head commit: https://svnweb.freebsd.org/base?view=revision&revision=286922 And: https://svnweb.freebsd.org/base/head/sys/kern/kern_event.c?annotate=286922#l1964 Not sure why you chose to look at stable/10 (given the mailing list). -- Andriy Gapon ___ 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: Instant panic while trying run ports-mgmt/poudriere
On Thu, Aug 27, 2015 at 11:09:45AM -0700, John-Mark Gurney wrote:
> Andriy Gapon wrote this message on Thu, Aug 27, 2015 at 10:21 +0300:
> > On 27/08/2015 02:36, John-Mark Gurney wrote:
> > > We should/cannot get here w/ an empty list. If we do, then there is
> > > something seriously wrong... The current kn (which we must have as we
> > > are here) MUST be on the list, but as you just showed, there are no
> > > knotes on the list.
> > >
> > > Can you get me a print of the knote? That way I can see what flags
> > > are on it?
> >
> > Apologies if the following might sound a little bit patronizing, but it
> > seems that you have got all the facts correctly, but somehow the
> > connection between them did not become clear.
> >
> > So:
> > 1. The list originally is NOT empty. I guess that it has one entry, but
> > that's an unimportant detail.
> > 2. This is why the loop is entered. It's a fact that it is entered.
> > 3. The list becomes empty precisely because the entry is removed during
> > the iteration in the loop (as kib has explained). It's a fact that the
> > list became empty at least in the panic that I reported.
>
> On you're latest dump, you said:
> Here is another +1 with r286922.
>
> I can add a couple of bits of debugging data:
>
>
>
> (kgdb) fr 8
>
> #8 0x80639d60 in knote (list=0xf8019a733ea0,
>
> hint=2147483648, lockflags=) at
>
> /usr/src/sys/kern/kern_event.c:1964
>
> 1964} else if ((lockflags & KNF_NOKQLOCK) != 0) {
>
>
> First off, that can't be r286922, per:
> https://svnweb.freebsd.org/base/stable/10/sys/kern/kern_event.c?annotate=286922
>
> line 1964 is blank... The line of code above should be at line 1884,
> so not sure what is wrong here...
>
> Assuming that the pc really is at the line, f_event has not yet been
> called, which is why I said that the list cannot be empty yet, as
> f_event hasn't been called yet to remove the knote... It could be that
> optimization moved stuff around, but if that is the case, then the
> above wasn't useful..
>
> > 4. The element is not only unlinked from the list, but its memory is
> > also freed.
>
> Where is the memory freed? A knote MUST NOT be freed in an f_event
> handler. The only location that a list element is allowed to be
> freed is in knote_drop, which must happen after f_detach is called,
> but that can't/won't happen from knote (I believe the timer handles
> this specially, but we are talking about normal knlist type filters)..
>
> The rest of your explination is invalid due to the invalid assumption
> of this point...
>
> If you can provide to me where the knote is free'd in knote, w/
> function/line number stack trace (does not have to be dump, but a
> sample call path), then I'll reconsider, and fix that bug...
Sigh. Did you ever read the mails I sent ?
Look at the filt_proc()->knlist_remove_inevent().
> > 5. That's why we have the use after free: SLIST_FOREACH is trying to get
> > a pointer to a next element from the freed memory.
> > 6. This is why the commit for trashing the freed memory made all the
> > difference: previously the freed memory was unlikely to be re-used /
> > modified, so the use-after-free had a high chance of succeeding. It's a
> > fact that in my panic there was an attempt to dereference a trashed pointer.
> > 7. Finally, this is why SLIST_FOREACH_SAFE helps here: we stash the
> > pointer to the next element beforehand and, thus, we do not access the
> > freed memory.
> >
> > Please let me know if you see any fault in above reasoning or if
> > something is still no clear.
>
> --
> John-Mark GurneyVoice: +1 415 225 5579
>
> "All that I will do, has been done, All that I have, has not."
> ___
> 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: Instant panic while trying run ports-mgmt/poudriere
On 27/08/2015 21:09, John-Mark Gurney wrote:
> Andriy Gapon wrote this message on Thu, Aug 27, 2015 at 10:21 +0300:
>> On 27/08/2015 02:36, John-Mark Gurney wrote:
>>> We should/cannot get here w/ an empty list. If we do, then there is
>>> something seriously wrong... The current kn (which we must have as we
>>> are here) MUST be on the list, but as you just showed, there are no
>>> knotes on the list.
>>>
>>> Can you get me a print of the knote? That way I can see what flags
>>> are on it?
>>
>> Apologies if the following might sound a little bit patronizing, but it
>> seems that you have got all the facts correctly, but somehow the
>> connection between them did not become clear.
>>
>> So:
>> 1. The list originally is NOT empty. I guess that it has one entry, but
>> that's an unimportant detail.
>> 2. This is why the loop is entered. It's a fact that it is entered.
>> 3. The list becomes empty precisely because the entry is removed during
>> the iteration in the loop (as kib has explained). It's a fact that the
>> list became empty at least in the panic that I reported.
>
> On you're latest dump, you said:
> Here is another +1 with r286922.
>
> I can add a couple of bits of debugging data:
>
>
>
> (kgdb) fr 8
>
> #8 0x80639d60 in knote (list=0xf8019a733ea0,
>
> hint=2147483648, lockflags=) at
>
> /usr/src/sys/kern/kern_event.c:1964
>
> 1964} else if ((lockflags & KNF_NOKQLOCK) != 0) {
>
>
> First off, that can't be r286922, per:
> https://svnweb.freebsd.org/base/stable/10/sys/kern/kern_event.c?annotate=286922
>
> line 1964 is blank... The line of code above should be at line 1884,
> so not sure what is wrong here...
No, it can not be indeed, because I am running head.
r286922 was the latest version of the repository, not the head branch,
at the moment when I pulled the repository via git.
> Assuming that the pc really is at the line, f_event has not yet been
> called,
Even on the second loop iteration?
>which is why I said that the list cannot be empty yet, as
> f_event hasn't been called yet to remove the knote... It could be that
> optimization moved stuff around, but if that is the case, then the
> above wasn't useful..
I provided the disassembly of the code as well, it's very obvious how
the code was translated.
>> 4. The element is not only unlinked from the list, but its memory is
>> also freed.
>
> Where is the memory freed? A knote MUST NOT be freed in an f_event
> handler. The only location that a list element is allowed to be
> freed is in knote_drop, which must happen after f_detach is called,
> but that can't/won't happen from knote (I believe the timer handles
> this specially, but we are talking about normal knlist type filters)..
Well, right. knote()->filt_proc()->knlist_remove_inevent() just removes
the knote from the list. But then there is KNOTE_ACTIVATE() that passes
the knote to a different owner (so to say). And given that the knote has
EV_ONESHOT set on it (in filt_proc) and that poudriere can put quite a
stress load on a system, I am not surprised that another thread gets a
chance to call knote_drop() on the knote before the original thread
proceeds to the next iteration.
> The rest of your explination is invalid due to the invalid assumption
> of this point...
Eagerly waiting for your explanation...
> If you can provide to me where the knote is free'd in knote, w/
> function/line number stack trace (does not have to be dump, but a
> sample call path), then I'll reconsider, and fix that bug...
>> 5. That's why we have the use after free: SLIST_FOREACH is trying to get
>> a pointer to a next element from the freed memory.
>> 6. This is why the commit for trashing the freed memory made all the
>> difference: previously the freed memory was unlikely to be re-used /
>> modified, so the use-after-free had a high chance of succeeding. It's a
>> fact that in my panic there was an attempt to dereference a trashed pointer.
>> 7. Finally, this is why SLIST_FOREACH_SAFE helps here: we stash the
>> pointer to the next element beforehand and, thus, we do not access the
>> freed memory.
>>
>> Please let me know if you see any fault in above reasoning or if
>> something is still no clear.
>
--
Andriy Gapon
___
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: Instant panic while trying run ports-mgmt/poudriere
Andriy Gapon wrote this message on Thu, Aug 27, 2015 at 10:21 +0300:
> On 27/08/2015 02:36, John-Mark Gurney wrote:
> > We should/cannot get here w/ an empty list. If we do, then there is
> > something seriously wrong... The current kn (which we must have as we
> > are here) MUST be on the list, but as you just showed, there are no
> > knotes on the list.
> >
> > Can you get me a print of the knote? That way I can see what flags
> > are on it?
>
> Apologies if the following might sound a little bit patronizing, but it
> seems that you have got all the facts correctly, but somehow the
> connection between them did not become clear.
>
> So:
> 1. The list originally is NOT empty. I guess that it has one entry, but
> that's an unimportant detail.
> 2. This is why the loop is entered. It's a fact that it is entered.
> 3. The list becomes empty precisely because the entry is removed during
> the iteration in the loop (as kib has explained). It's a fact that the
> list became empty at least in the panic that I reported.
On you're latest dump, you said:
Here is another +1 with r286922.
I can add a couple of bits of debugging data:
(kgdb) fr 8
#8 0x80639d60 in knote (list=0xf8019a733ea0,
hint=2147483648, lockflags=) at
/usr/src/sys/kern/kern_event.c:1964
1964} else if ((lockflags & KNF_NOKQLOCK) != 0) {
First off, that can't be r286922, per:
https://svnweb.freebsd.org/base/stable/10/sys/kern/kern_event.c?annotate=286922
line 1964 is blank... The line of code above should be at line 1884,
so not sure what is wrong here...
Assuming that the pc really is at the line, f_event has not yet been
called, which is why I said that the list cannot be empty yet, as
f_event hasn't been called yet to remove the knote... It could be that
optimization moved stuff around, but if that is the case, then the
above wasn't useful..
> 4. The element is not only unlinked from the list, but its memory is
> also freed.
Where is the memory freed? A knote MUST NOT be freed in an f_event
handler. The only location that a list element is allowed to be
freed is in knote_drop, which must happen after f_detach is called,
but that can't/won't happen from knote (I believe the timer handles
this specially, but we are talking about normal knlist type filters)..
The rest of your explination is invalid due to the invalid assumption
of this point...
If you can provide to me where the knote is free'd in knote, w/
function/line number stack trace (does not have to be dump, but a
sample call path), then I'll reconsider, and fix that bug...
> 5. That's why we have the use after free: SLIST_FOREACH is trying to get
> a pointer to a next element from the freed memory.
> 6. This is why the commit for trashing the freed memory made all the
> difference: previously the freed memory was unlikely to be re-used /
> modified, so the use-after-free had a high chance of succeeding. It's a
> fact that in my panic there was an attempt to dereference a trashed pointer.
> 7. Finally, this is why SLIST_FOREACH_SAFE helps here: we stash the
> pointer to the next element beforehand and, thus, we do not access the
> freed memory.
>
> Please let me know if you see any fault in above reasoning or if
> something is still no clear.
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
___
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 - Build #3135 - Failure
FreeBSD_HEAD - Build #3135 - Failure:
Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD/3135/
Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD/3135/changes
Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD/3135/console
Change summaries:
287214 by andrew:
There is no need to get the bus tag or handle.
Sponsored by: ABT Systems Ltd
287213 by andrew:
Limit the speed to the bus frequency.
Sponsored by: ABT Systems Ltd
287212 by andrew:
Allow the fifo-depth and num-slots to be missing. For the former we read
the value from the hardware, for the latter assume a single slot.
Sponsored by: ABT Systems Ltd
287211 by bz:
get_inpcbinfo() and get_pcblist() are UDP local functions and
do not do what one would expect by name. Prefix them with "udp_"
to at least obviously limit the scope.
This is a non-functional change.
Reviewed by:gnn, rwatson
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D3505
287209 by ed:
Decompose linkat()/renameat() rights to source and target.
To make it easier to understand how Capsicum interacts with linkat() and
renameat(), rename the rights to CAP_{LINK,RENAME}AT_{SOURCE,TARGET}.
This also addresses a shortcoming in Capsicum, where it isn't possible
to disable linking to files stored in a directory. Creating hardlinks
essentially makes it possible to access files with additional rights.
Reviewed by:rwatson, wblock
Differential Revision: https://reviews.freebsd.org/D3411
287208 by ume:
Make it buildable with WITH_OPENLDAP, again.
MFC after: 1 week
287206 by kan:
Repair sys/cdefs.h enough to be usable with GCC 5.x
The __alloc_size and __alloc_align need to be defined to
nothingness for lint, but the existing check is deficient
and allows attributes with working __has_attrubute() to
slip through.
287205 by kan:
Make ncurses build with GCC 5.0 and up
Merge the end result of two upstream changes:
Original fix from 20141206:
+ modify MKlib_gen.sh to work around change in development version of
gcc introduced here:
https://gcc.gnu.org/ml/gcc-patches/2014-06/msg02185.html
https://gcc.gnu.org/ml/gcc-patches/2014-07/msg00236.html
(reports by Marcus Shawcroft, Maohui Lei).
Later fixed in different manner in 20150725:
+ use alternate workaround for gcc 5.x feature (adapted from patch by
Mikhail Peselnik).
287204 by kan:
Unbreak nvi message catalog generation for 8 bit locales.
Feeding any file encoded in 8 bit locales such as KOI8-RU
to sort utility running under UTF-8 locale produces astonishing
result of recoding the output to UTF-8. To counter that, just
run sort under 'C' locale for now.
287202 by andrew:
Allow us to select the transfer count. This allows us to work with hardware
that seems to only work with a single block at a time.
Sponsored by: ABT Systems Ltd
The end of the build log:
[...truncated 59031 lines...]
echo clang: /usr/lib/libc++.a >> .depend
--- all_subdir_clang ---
--- all_subdir_clang-tblgen ---
--- all_subdir_tblgen ---
--- all_subdir_clang ---
===> usr.bin/clang/clang (all)
--- all_subdir_clang-tblgen ---
===> usr.bin/clang/clang-tblgen (all)
--- all_subdir_tblgen ---
===> usr.bin/clang/tblgen (all)
--- all_subdir_clang ---
--- cc1_main.o ---
--- cc1as_main.o ---
--- driver.o ---
--- cc1_main.o ---
c++ -O2 -pipe
-I/builds/FreeBSD_HEAD/usr.bin/clang/clang/../../../contrib/llvm/include
-I/builds/FreeBSD_HEAD/usr.bin/clang/clang/../../../contrib/llvm/tools/clang/include
-I/builds/FreeBSD_HEAD/usr.bin/clang/clang/../../../contrib/llvm/tools/clang/tools/driver
-I.
-I/builds/FreeBSD_HEAD/usr.bin/clang/clang/../../../contrib/llvm/../../lib/clang/include
-DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS
-D__STDC_CONSTANT_MACROS -fno-strict-aliasing
-DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd11.0\"
-DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd11.0\"
-DDEFAULT_SYSROOT=\"/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp\"
-Qunused-arguments
-I/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/usr/include
-std=c++11 -fno-exceptions -fno-rtti -stdlib=libc++ -Wno-c++11-extensions -c
/builds/FreeBSD_HEAD/usr.bin/clang/clang/../../../contrib/llvm/tools/clang/tools/driver/cc1_main.cpp
-o cc1_main.o
--- cc1as_main.o ---
c++ -O2 -pipe
-I/builds/FreeBSD_HEAD/usr.bin/clang/clang/../../../contrib/llvm/include
-I/builds/FreeBSD_HEAD/usr.bin/clang/clang/../../../contrib/llvm/tools/clang/include
-I/builds/FreeBSD_HEAD/usr.bin/clang/clang/../../../contrib/llvm/tools/clang/tools/driver
-I.
-I/builds/FreeBSD_HEAD/usr.bin/clang/clang/../../../contrib/llvm/../../lib/clang/include
-DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS
-D__STDC_CONSTANT_MACROS -fno-strict-aliasing
-DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd11.0\"
-DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd11.0\"
-DDEFAULT_SYSROOT=\"/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp\"
-Qunused-arguments
-I/builds/Free
Re: [head up!] WiFi drivers changes
Good news, thanks! On Thu, Aug 27, 2015 at 06:45:14PM +0200, O. Hartmann wrote: O> sory, sorry - I forgot on that specific machine (1 of 5) to mergemaster :-( So, after O> mergemaster, the new rc scripts also got installed on the AP server and the interface is O> again up and running! O> O> Regards, O> O> oh -- Totus tuus, Glebius. ___ 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: [head up!] WiFi drivers changes
Am Thu, 27 Aug 2015 18:32:53 +0200 "O. Hartmann" schrieb: > Am Fri, 7 Aug 2015 16:50:23 -0700 > Adrian Chadd schrieb: > > > Hi, > > > > Gleb/others doing this: you have 4 days to figure out what's wrong > > with things, or I'm backing all of this work out. > > > > Thanks, > > > > > > -adrian > > > > > > On 7 August 2015 at 08:52, O. Hartmann wrote: > > > Am Thu, 6 Aug 2015 18:13:55 +0300 > > > Gleb Smirnoff schrieb: > > > > > >> Hi! > > >> > > >> As part of the "opaque ifnet project" [1], all 802.11 (WiFi) drivers > > >> undergo change of not being an interface anymore. Historically in FreeBSD > > >> 802.11 stack, 802.11 devices called if_attach() and created an interface. > > >> Later this was generalized and real functioning interface is created by > > >> net80211 stack. However, remnant of parent interface remained. If you > > >> are running Intel Centrino wireless, then you got iwn0 interface and > > >> wlan0 interface. However, the former doesn't do anything. You can't > > >> assign addresses to it or modify any of it parameters. Or you can > > >> modify them, but that affects nothing. > > >> > > >> This superfluous ifnet on the list entangles the net80211 stack and > > >> also is on the way of [1]. So, decision was made to remove it. I > > >> already did preparatory commits back in May, and now it is time to > > >> finish that. > > >> > > >> The patch is: > > >> > > >> https://reviews.freebsd.org/D2655 > > >> > > >> And the Wiki page for it is: > > >> > > >> https://wiki.freebsd.org/projects/ifnet/net80211 > > >> > > >> The patch modifies every driver, and diff is bulky. However, changes > > >> are mechanical and simple, most drivers appeared to work after first > > >> run. Most converted drivers are tested to work. > > >> > > >> This is list of drivers that are not tested, due to lack of testers: > > >> > > >> mwl, ipw, bwn, wi, upgt, uath. > > >> > > >> But, as said, changes are mechanical and probability is 95% that > > >> they will work. > > >> > > >> The only complex one is ndis(4). It could be broken by conversion. > > >> Since I already got a tester volunteer, I will fix it quickly if > > >> anything happens. > > >> > > >> Another untrivial one is wtap(4), which is not connected to the > > >> build and appeared to be broken even before conversion. Anyway, > > >> I made it compilable. > > >> > > >> Now, for the configuration. The sequence of commands you need > > >> to run to configure a WiFi interface doesn't change. As before > > >> it is: > > >> > > >> ifconfig wlan0 create wlandev iwn0 > > >> ifconfig wlan0 $foo > > >> > > >> Your rc.conf doesn't need any changes. As before: > > >> > > >> wlans_iwn0="wlan0" > > >> ifconfig_wlan0="DHCP WPA" > > >> > > >> However, iwn0 disappeared from the 'ifconfig -l'. It is still > > >> in devinfo, or in dmesg. For the sake of installers or other > > >> configuration software, a sysctl is provided: > > >> > > >> net.wlan.devices: iwn0 > > >> > > >> The /etc subsystem needs to be tweaked. Previously the wlan(4) > > >> interfaces were created in childif_create(), and the script > > >> did check for presence of parent interface. In my patch I > > >> provided wlans_up(), that doesn't check. The code in D2655 > > >> now works correctly both on patched and on unpatched kernel. > > >> > > >> Alternatively, I could tweak childif_create() to use net.wlan.devices > > >> instead of 'ifconfig -l'. Or, to use them both, to work on older > > >> and on newer kernels? > > >> > > >> I am not sure which path with /etc is better, so seeking for > > >> help with that. > > >> > > > > > > After updating to FreeBSD 11.0-CURRENT #0 r286415: Fri Aug 7 17:22:43 > > > CEST 2015 > > > amd64, several APs won't startup anymore: > > > > > > [...] > > > Starting hostapd. > > > Configuration file: /etc/hostapd.conf > > > bsd_set_if_media: SIOCSIFMEDIA Device not configured > > > bsd_init: failed to set operation mode > > > bsd driver initialization failed. > > > wlan0: interface state UNINITIALIZED->DISABLED > > > wlan0: AP-DISABLED > > > hostapd_free_hapd_data: Interface wlan0 wasn't started > > > ELOOP: remaining socket: sock=5 eloop_data=0x801c47100 user_data=0x0 > > > handler=0x41a0e0 /etc/rc.d/hostapd: WARNING: failed to start hostapd > > ___ > > freebsd-current@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > > Again, > with the most recent changes as of r287211, hostapd doens't start my WiFi AP > anymore > (FreeBSD 11.0-CURRENT #7 r287169: Wed Aug 26 20:26:49 CEST 2015 amd64 does!). Ups, sory, sorry - I forgot on that specific machine (1 of 5) to mergemaster :-( So, after mergemaster, the new rc scripts also got installed on the AP server and the interface is again up and running! Regards, oh pgpxHmF8Um9ku.pgp Description: OpenPGP digital signature
Re: [head up!] WiFi drivers changes
Oliver, O> Again, O> with the most recent changes as of r287211, hostapd doens't start my WiFi AP anymore O> (FreeBSD 11.0-CURRENT #7 r287169: Wed Aug 26 20:26:49 CEST 2015 amd64 does!). Let's start investigating from scratch, since the /etc part of the patch have changed significantly. Can you please send me privately your configs and debug log of hostapd? [Adding pluknet@ to Cc, who helped a lot with testing the hostap support during patch development] -- Totus tuus, Glebius. ___ 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: [head up!] WiFi drivers changes
Am Fri, 7 Aug 2015 16:50:23 -0700 Adrian Chadd schrieb: > Hi, > > Gleb/others doing this: you have 4 days to figure out what's wrong > with things, or I'm backing all of this work out. > > Thanks, > > > -adrian > > > On 7 August 2015 at 08:52, O. Hartmann wrote: > > Am Thu, 6 Aug 2015 18:13:55 +0300 > > Gleb Smirnoff schrieb: > > > >> Hi! > >> > >> As part of the "opaque ifnet project" [1], all 802.11 (WiFi) drivers > >> undergo change of not being an interface anymore. Historically in FreeBSD > >> 802.11 stack, 802.11 devices called if_attach() and created an interface. > >> Later this was generalized and real functioning interface is created by > >> net80211 stack. However, remnant of parent interface remained. If you > >> are running Intel Centrino wireless, then you got iwn0 interface and > >> wlan0 interface. However, the former doesn't do anything. You can't > >> assign addresses to it or modify any of it parameters. Or you can > >> modify them, but that affects nothing. > >> > >> This superfluous ifnet on the list entangles the net80211 stack and > >> also is on the way of [1]. So, decision was made to remove it. I > >> already did preparatory commits back in May, and now it is time to > >> finish that. > >> > >> The patch is: > >> > >> https://reviews.freebsd.org/D2655 > >> > >> And the Wiki page for it is: > >> > >> https://wiki.freebsd.org/projects/ifnet/net80211 > >> > >> The patch modifies every driver, and diff is bulky. However, changes > >> are mechanical and simple, most drivers appeared to work after first > >> run. Most converted drivers are tested to work. > >> > >> This is list of drivers that are not tested, due to lack of testers: > >> > >> mwl, ipw, bwn, wi, upgt, uath. > >> > >> But, as said, changes are mechanical and probability is 95% that > >> they will work. > >> > >> The only complex one is ndis(4). It could be broken by conversion. > >> Since I already got a tester volunteer, I will fix it quickly if > >> anything happens. > >> > >> Another untrivial one is wtap(4), which is not connected to the > >> build and appeared to be broken even before conversion. Anyway, > >> I made it compilable. > >> > >> Now, for the configuration. The sequence of commands you need > >> to run to configure a WiFi interface doesn't change. As before > >> it is: > >> > >> ifconfig wlan0 create wlandev iwn0 > >> ifconfig wlan0 $foo > >> > >> Your rc.conf doesn't need any changes. As before: > >> > >> wlans_iwn0="wlan0" > >> ifconfig_wlan0="DHCP WPA" > >> > >> However, iwn0 disappeared from the 'ifconfig -l'. It is still > >> in devinfo, or in dmesg. For the sake of installers or other > >> configuration software, a sysctl is provided: > >> > >> net.wlan.devices: iwn0 > >> > >> The /etc subsystem needs to be tweaked. Previously the wlan(4) > >> interfaces were created in childif_create(), and the script > >> did check for presence of parent interface. In my patch I > >> provided wlans_up(), that doesn't check. The code in D2655 > >> now works correctly both on patched and on unpatched kernel. > >> > >> Alternatively, I could tweak childif_create() to use net.wlan.devices > >> instead of 'ifconfig -l'. Or, to use them both, to work on older > >> and on newer kernels? > >> > >> I am not sure which path with /etc is better, so seeking for > >> help with that. > >> > > > > After updating to FreeBSD 11.0-CURRENT #0 r286415: Fri Aug 7 17:22:43 CEST > > 2015 > > amd64, several APs won't startup anymore: > > > > [...] > > Starting hostapd. > > Configuration file: /etc/hostapd.conf > > bsd_set_if_media: SIOCSIFMEDIA Device not configured > > bsd_init: failed to set operation mode > > bsd driver initialization failed. > > wlan0: interface state UNINITIALIZED->DISABLED > > wlan0: AP-DISABLED > > hostapd_free_hapd_data: Interface wlan0 wasn't started > > ELOOP: remaining socket: sock=5 eloop_data=0x801c47100 user_data=0x0 > > handler=0x41a0e0 > > /etc/rc.d/hostapd: WARNING: failed to start hostapd > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" Again, with the most recent changes as of r287211, hostapd doens't start my WiFi AP anymore (FreeBSD 11.0-CURRENT #7 r287169: Wed Aug 26 20:26:49 CEST 2015 amd64 does!). pgpbG0rBYoX3z.pgp Description: OpenPGP digital signature
FreeBSD_HEAD - Build #3134 - Fixed
FreeBSD_HEAD - Build #3134 - Fixed: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD/3134/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD/3134/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD/3134/console Change summaries: 287200 by jch: Silent a compilation warning on callout_stop() 287198 by jch: In callout_stop(), do not forget to initialize not_running variable. Thanks to hselasky for noticing that. Differential Revision: https://reviews.freebsd.org/D3078 (Updated) Submitted by: hselasky Pointy hat to: jch 287197 by glebius: Replay r286410. Change KPI of how device drivers that provide wireless connectivity interact with the net80211 stack. Historical background: originally wireless devices created an interface, just like Ethernet devices do. Name of an interface matched the name of the driver that created. Later, wlan(4) layer was introduced, and the wlanX interfaces become the actual interface, leaving original ones as "a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer and a driver became a mix of methods that pass a pointer to struct ifnet as identifier and methods that pass pointer to struct ieee80211com. From user point of view, the parent interface just hangs on in the ifconfig list, and user can't do anything useful with it. Now, the struct ifnet goes away. The struct ieee80211com is the only KPI between a device driver and net80211. Details: - The struct ieee80211com is embedded into drivers softc. - Packets are sent via new ic_transmit method, which is very much like the previous if_transmit. - Bringing parent up/down is done via new ic_parent method, which notifies driver about any changes: number of wlan(4) interfaces, number of them in promisc or allmulti state. - Device specific ioctls (if any) are received on new ic_ioctl method. - Packets/errors accounting are done by the stack. In certain cases, when driver experiences errors and can not attribute them to any specific interface, driver updates ic_oerrors or ic_ierrors counters. Details on interface configuration with new world order: - A sequence of commands needed to bring up wireless DOESN"T change. - /etc/rc.conf parameters DON'T change. - List of devices that can be used to create wlan(4) interfaces is now provided by net.wlan.devices sysctl. Most drivers in this change were converted by me, except of wpi(4), that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing changes to at least 8 drivers. Thanks to pluknet@, Oliver Hartmann, Olivier Cochard, gjb@, mmoll@, op@ and lev@, who also participated in testing. Reviewed by:adrian Sponsored by: Netflix Sponsored by: Nginx, Inc. ___ 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: Is NextBSD safe for bhyve?
On Thu, Aug 27, 2015 at 5:15 PM, Russell Haley wrote: > Is NextBSD safe for bhyve? > > Thanks > Consider that everything CURRENT, can be somewhat volatile at times, I wouldnt recommend it for a production business case. However that being said I do have XEN/NextBSD running as a dom0 quite well, iocage, behyve and others are being reveiwed for use cases, at this state of flux your mileage may vary depending on exactly what your using it for, localized testing and running a few vms, Ive accomplished that much with XEN so far. But again, it is based on CURRENT with alot of additions being merged in and worked on daily. > > Russ > ___ > 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 - Build #3133 - Failure
FreeBSD_HEAD - Build #3133 - Failure: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD/3133/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD/3133/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD/3133/console Change summaries: 287196 by jch: In callout_stop(), if a callout is both pending and currently being serviced return 0 (fail) but it is applicable only mpsafe callouts. Thanks to hselasky for finding this. Differential Revision: https://reviews.freebsd.org/D3078 (Updated) Submitted by: hselasky Reviewed by:jch 287195 by melifaro: Fix packets/bytes accounting on i386. Spotted by: julian 287193 by delphij: Plug a possible memory leak. MFC after: 2 weeks 287192 by bapt: More fixes to the new macros 287191 by bapt: Fix typo in new macros The end of the build log: [...truncated 283978 lines...] --- rt2860.o --- cc -c -O2 -pipe -fno-strict-aliasing -g -nostdinc -I. -I/builds/FreeBSD_HEAD/sys -I/builds/FreeBSD_HEAD/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -mno-aes -mno-avx -std=iso9899:1999 -Werror /builds/FreeBSD_HEAD/sys/dev/ral/rt2860.c --- rt2560.o --- ctfconvert -L VERSION -g rt2560.o --- randomdev.o --- cc -c -O2 -pipe -fno-strict-aliasing -g -nostdinc -I. -I/builds/FreeBSD_HEAD/sys -I/builds/FreeBSD_HEAD/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -mno-aes -mno-avx -std=iso9899:1999 -Werror /builds/FreeBSD_HEAD/sys/dev/random/randomdev.c --- if_mwl.o --- ctfconvert -L VERSION -g if_mwl.o --- syscons.o --- cc -c -O2 -pipe -fno-strict-aliasing -g -nostdinc -I. -I/builds/FreeBSD_HEAD/sys -I/builds/FreeBSD_HEAD/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -mno-aes -mno-avx -std=iso9899:1999 -Werror /builds/FreeBSD_HEAD/sys/dev/syscons/syscons.c --- rt2661.o --- ctfconvert -L VERSION -g rt2661.o --- uart_dbg.o --- cc -c -O2 -pipe -fno-strict-aliasing -g -nostdinc -I. -I/builds/FreeBSD_HEAD/sys -I/builds/FreeBSD_HEAD/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -mno-aes -mno-avx -std=iso9899:1999 -Werror /builds/FreeBSD_HEAD/sys/dev/uart/uart_dbg.c --- randomdev.o --- ctfconvert -L VERSION -g randomdev.o --- uart_subr.o --- cc -c -O2 -pipe -fno-strict-aliasing -g -nostdinc -I. -I/builds/FreeBSD_HEAD/sys -I/builds/FreeBSD_HEAD/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno
Re: Read-only /usr/obj/ no longer kosher?
> On Aug 26, 2015, at 19:03, O'Connor, Daniel wrote: > > >> On 27 Aug 2015, at 08:25, Pawel Jakub Dawidek wrote: >>> On Tue, Aug 25, 2015 at 03:32:35PM -0700, NGie Cooper wrote: On Tue, Aug 25, 2015 at 3:21 PM, Xin Li wrote: On 08/25/15 14:55, Pawel Jakub Dawidek wrote: >> Now that I think of it, it might have been that I did >> buildworld/buildkernel before -p1. Then freebsd-update updated >> newvers.sh and then I was trying to do installworld. > > Yes, I can now reproduce it with source updated to -p2. Yes, that's because freebsd-version.sh is generated from the files (but it's not clear to me whether if it's a bug or a feature that 'make install' checks if it's up-to-date and decides to regenerate it...). >>> >>> It's a quirk for sure. If you change the behavior, people will >>> definitely complain as they will now need to go back and rebuild >>> everything. >> >> What we have now is misleading. People should recompile. It is rather >> rare to see security advisory which bumps only patch level and something >> that doesn't require recompilation (eg. a shell script). Current >> behaviour would make people think they are running latest patch level >> because freebsd-version says so, eventhough they only did 'make >> installworld' without rebuilding affected binaries. > > So.. > How hard would it be to force CC/CXX to /usr/bin/false during installworld? Trivial in FreeBSD. Just make it so in Makefile for the installworld target, add false to itools, and add appropriate special casing in bsd.compiler.mk. Doing this just prevents recompiling though, so not pjd's case. Also, this might break someone's random usecase where they need CC/CXX to do something meaningful at install time, however, the likelihood of it being correct is slim IMHO.. ___ 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: Instant panic while trying run ports-mgmt/poudriere
On Thu, Aug 27, 2015 at 10:21:47AM +0300, Andriy Gapon wrote: > On 27/08/2015 02:36, John-Mark Gurney wrote: > > We should/cannot get here w/ an empty list. If we do, then there is > > something seriously wrong... The current kn (which we must have as we > > are here) MUST be on the list, but as you just showed, there are no > > knotes on the list. > > > > Can you get me a print of the knote? That way I can see what flags > > are on it? > > Apologies if the following might sound a little bit patronizing, but it > seems that you have got all the facts correctly, but somehow the > connection between them did not become clear. > > So: > 1. The list originally is NOT empty. I guess that it has one entry, but > that's an unimportant detail. > 2. This is why the loop is entered. It's a fact that it is entered. > 3. The list becomes empty precisely because the entry is removed during > the iteration in the loop (as kib has explained). It's a fact that the > list became empty at least in the panic that I reported. The only detail I can add to this explanation, which is probably third (?) time, is that the removal is done in the filt_proc() event method, by the call to knlist_remove_inevent(). > 4. The element is not only unlinked from the list, but its memory is > also freed. > 5. That's why we have the use after free: SLIST_FOREACH is trying to get > a pointer to a next element from the freed memory. > 6. This is why the commit for trashing the freed memory made all the > difference: previously the freed memory was unlikely to be re-used / > modified, so the use-after-free had a high chance of succeeding. It's a > fact that in my panic there was an attempt to dereference a trashed pointer. > 7. Finally, this is why SLIST_FOREACH_SAFE helps here: we stash the > pointer to the next element beforehand and, thus, we do not access the > freed memory. The additional, eighth item, should explain why the change to _SAFE() is the correct fix, and not just a papering over the problem. Nobody except the current thread can modify the knlist, because knlist is locked. As a consequence, only the current element can be unlinked and removed. So the _SAFE() iterator actually work. > > Please let me know if you see any fault in above reasoning or if > something is still no clear. ___ 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: Instant panic while trying run ports-mgmt/poudriere
On 27 Aug, Lawrence Stewart wrote:
> On 08/27/15 09:36, John-Mark Gurney wrote:
>> Andriy Gapon wrote this message on Sun, Aug 23, 2015 at 09:54 +0300:
>>> On 12/08/2015 17:11, Lawrence Stewart wrote:
On 08/07/15 07:33, Pawel Pekala wrote:
> Hi K.,
>
> On 2015-08-06 12:33 -0700, "K. Macy" wrote:
>> Is this still happening?
>
> Still crashes:
+1 for me running r286617
>>>
>>> Here is another +1 with r286922.
>>> I can add a couple of bits of debugging data:
>>>
>>> (kgdb) fr 8
>>> #8 0x80639d60 in knote (list=0xf8019a733ea0,
>>> hint=2147483648, lockflags=) at
>>> /usr/src/sys/kern/kern_event.c:1964
>>> 1964} else if ((lockflags & KNF_NOKQLOCK) != 0) {
>>> (kgdb) p *list
>>> $2 = {kl_list = {slh_first = 0x0}, kl_lock = 0x8063a1e0
>>
>> We should/cannot get here w/ an empty list. If we do, then there is
>> something seriously wrong... The current kn (which we must have as we
>> are here) MUST be on the list, but as you just showed, there are no
>> knotes on the list.
>>
>> Can you get me a print of the knote? That way I can see what flags
>> are on it?
>
> I quickly tried to get this info for you by building my kernel with -O0
> and reproducing, but I get an insta-panic on boot with the new kernel:
>
> Fatal double fault
> rip = 0x8218c794
> rsp = 0xfe044cdc9fe0
> rbp = 0xfe044cdca110
> cpuid = 2; apic id = 02
> panic: double fault
> cpuid = 2
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
> 0xfe03dcfffe30
> vpanic() at vpanic+0x189/frame 0xfe03dcfffeb0
> panic() at panic+0x43/frame 0xfe03dc10
> dblfault_handler() at dblfault_handler+0xa2/frame 0xfe03dc30
> Xdblfault() at Xdblfault+0xac/frame 0xfe03dc30
> --- trap 0x17, rip = 0x8218c794, rsp = 0xfe044cdc9fe0, rbp =
> 0xfe044cdca110 ---
> vdev_queue_aggregate() at vdev_queue_aggregate+0x34/frame 0xfe044cdca110
> vdev_queue_io_to_issue() at vdev_queue_io_to_issue+0x1f5/frame
> 0xfe044cdca560
> vdev_queue_io() at vdev_queue_io+0x19a/frame 0xfe044cdca5b0
> zio_vdev_io_start() at zio_vdev_io_start+0x81f/frame 0xfe044cdca6e0
> zio_execute() at zio_execute+0x23b/frame 0xfe044cdca730
> zio_nowait() at zio_nowait+0xbe/frame 0xfe044cdca760
> vdev_mirror_io_start() at vdev_mirror_io_start+0x140/frame
> 0xfe044cdca800
> zio_vdev_io_start() at zio_vdev_io_start+0x12f/frame 0xfe044cdca930
> zio_execute() at zio_execute+0x23b/frame 0xfe044cdca980
> zio_nowait() at zio_nowait+0xbe/frame 0xfe044cdca9b0
> spa_load_verify_cb() at spa_load_verify_cb+0x37d/frame 0xfe044cdcaa50
> traverse_visitbp() at traverse_visitbp+0x5a5/frame 0xfe044cdcac60
> traverse_dnode() at traverse_dnode+0x98/frame 0xfe044cdcacd0
> traverse_visitbp() at traverse_visitbp+0xc66/frame 0xfe044cdcaee0
> traverse_visitbp() at traverse_visitbp+0x930/frame 0xfe044cdcb0f0
> traverse_visitbp() at traverse_visitbp+0x930/frame 0xfe044cdcb300
> traverse_visitbp() at traverse_visitbp+0x930/frame 0xfe044cdcb510
> traverse_visitbp() at traverse_visitbp+0x930/frame 0xfe044cdcb720
> traverse_visitbp() at traverse_visitbp+0x930/frame 0xfe044cdcb930
> traverse_visitbp() at traverse_visitbp+0x930/frame 0xfe044cdcbb40
> traverse_dnode() at traverse_dnode+0x98/frame 0xfe044cdcbbb0
> traverse_visitbp() at traverse_visitbp+0xe59/frame 0xfe044cdcbdc0
> traverse_impl() at traverse_impl+0x79d/frame 0xfe044cdcbfd0
> traverse_dataset() at traverse_dataset+0x93/frame 0xfe044cdcc040
> traverse_pool() at traverse_pool+0x1f2/frame 0xfe044cdcc140
> spa_load_verify() at spa_load_verify+0xf3/frame 0xfe044cdcc1f0
> spa_load_impl() at spa_load_impl+0x2069/frame 0xfe044cdcc610
> spa_load() at spa_load+0x320/frame 0xfe044cdcc6d0
> spa_load_impl() at spa_load_impl+0x150b/frame 0xfe044cdccaf0
> spa_load() at spa_load+0x320/frame 0xfe044cdccbb0
> spa_load_best() at spa_load_best+0xc6/frame 0xfe044cdccc50
> spa_open_common() at spa_open_common+0x246/frame 0xfe044cdccd40
> spa_open() at spa_open+0x35/frame 0xfe044cdccd70
> dsl_pool_hold() at dsl_pool_hold+0x2d/frame 0xfe044cdccdb0
> dmu_objset_own() at dmu_objset_own+0x2e/frame 0xfe044cdcce30
> zfsvfs_create() at zfsvfs_create+0x100/frame 0xfe044cdcd050
> zfs_domount() at zfs_domount+0xa7/frame 0xfe044cdcd0e0
> zfs_mount() at zfs_mount+0x6c3/frame 0xfe044cdcd390
> vfs_donmount() at vfs_donmount+0x1330/frame 0xfe044cdcd660
> kernel_mount() at kernel_mount+0x62/frame 0xfe044cdcd6c0
> parse_mount() at parse_mount+0x668/frame 0xfe044cdcd810
> vfs_mountroot() at vfs_mountroot+0x85c/frame 0xfe044cdcd9d0
> start_init() at start_init+0x62/frame 0xfe044cdcda70
> fork_exit() at fork_exit+0x84/frame 0xfe044cdcdab0
> fork_trampoline() at fork_trampoline+0xe/frame 0xfe044cdcdab0
> --- trap 0, rip = 0, rsp = 0, rbp = 0 ---
> KDB: enter: panic
>
>
Re: Instant panic while trying run ports-mgmt/poudriere
On 27/08/2015 02:36, John-Mark Gurney wrote: > We should/cannot get here w/ an empty list. If we do, then there is > something seriously wrong... The current kn (which we must have as we > are here) MUST be on the list, but as you just showed, there are no > knotes on the list. > > Can you get me a print of the knote? That way I can see what flags > are on it? Apologies if the following might sound a little bit patronizing, but it seems that you have got all the facts correctly, but somehow the connection between them did not become clear. So: 1. The list originally is NOT empty. I guess that it has one entry, but that's an unimportant detail. 2. This is why the loop is entered. It's a fact that it is entered. 3. The list becomes empty precisely because the entry is removed during the iteration in the loop (as kib has explained). It's a fact that the list became empty at least in the panic that I reported. 4. The element is not only unlinked from the list, but its memory is also freed. 5. That's why we have the use after free: SLIST_FOREACH is trying to get a pointer to a next element from the freed memory. 6. This is why the commit for trashing the freed memory made all the difference: previously the freed memory was unlikely to be re-used / modified, so the use-after-free had a high chance of succeeding. It's a fact that in my panic there was an attempt to dereference a trashed pointer. 7. Finally, this is why SLIST_FOREACH_SAFE helps here: we stash the pointer to the next element beforehand and, thus, we do not access the freed memory. Please let me know if you see any fault in above reasoning or if something is still no clear. -- Andriy Gapon ___ 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"
Is NextBSD safe for bhyve?
Is NextBSD safe for bhyve? Thanks Russ ___ 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: Instant panic while trying run ports-mgmt/poudriere
On 27 Aug, Don Lewis wrote:
> On 27 Aug, Lawrence Stewart wrote:
>> On 08/27/15 09:36, John-Mark Gurney wrote:
>>> Andriy Gapon wrote this message on Sun, Aug 23, 2015 at 09:54 +0300:
On 12/08/2015 17:11, Lawrence Stewart wrote:
> On 08/07/15 07:33, Pawel Pekala wrote:
>> Hi K.,
>>
>> On 2015-08-06 12:33 -0700, "K. Macy" wrote:
>>> Is this still happening?
>>
>> Still crashes:
>
> +1 for me running r286617
Here is another +1 with r286922.
I can add a couple of bits of debugging data:
(kgdb) fr 8
#8 0x80639d60 in knote (list=0xf8019a733ea0,
hint=2147483648, lockflags=) at
/usr/src/sys/kern/kern_event.c:1964
1964} else if ((lockflags & KNF_NOKQLOCK) != 0) {
(kgdb) p *list
$2 = {kl_list = {slh_first = 0x0}, kl_lock = 0x8063a1e0
>>>
>>> We should/cannot get here w/ an empty list. If we do, then there is
>>> something seriously wrong... The current kn (which we must have as we
>>> are here) MUST be on the list, but as you just showed, there are no
>>> knotes on the list.
>>>
>>> Can you get me a print of the knote? That way I can see what flags
>>> are on it?
>>
>> I quickly tried to get this info for you by building my kernel with -O0
>> and reproducing, but I get an insta-panic on boot with the new kernel:
>>
>> Fatal double fault
>> rip = 0x8218c794
>> rsp = 0xfe044cdc9fe0
>> rbp = 0xfe044cdca110
>> cpuid = 2; apic id = 02
>> panic: double fault
>> cpuid = 2
>> KDB: stack backtrace:
>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
>> 0xfe03dcfffe30
>> vpanic() at vpanic+0x189/frame 0xfe03dcfffeb0
>> panic() at panic+0x43/frame 0xfe03dc10
>> dblfault_handler() at dblfault_handler+0xa2/frame 0xfe03dc30
>> Xdblfault() at Xdblfault+0xac/frame 0xfe03dc30
>> --- trap 0x17, rip = 0x8218c794, rsp = 0xfe044cdc9fe0, rbp =
>> 0xfe044cdca110 ---
>> vdev_queue_aggregate() at vdev_queue_aggregate+0x34/frame 0xfe044cdca110
>> vdev_queue_io_to_issue() at vdev_queue_io_to_issue+0x1f5/frame
>> 0xfe044cdca560
>> vdev_queue_io() at vdev_queue_io+0x19a/frame 0xfe044cdca5b0
>> zio_vdev_io_start() at zio_vdev_io_start+0x81f/frame 0xfe044cdca6e0
>> zio_execute() at zio_execute+0x23b/frame 0xfe044cdca730
>> zio_nowait() at zio_nowait+0xbe/frame 0xfe044cdca760
>> vdev_mirror_io_start() at vdev_mirror_io_start+0x140/frame
>> 0xfe044cdca800
>> zio_vdev_io_start() at zio_vdev_io_start+0x12f/frame 0xfe044cdca930
>> zio_execute() at zio_execute+0x23b/frame 0xfe044cdca980
>> zio_nowait() at zio_nowait+0xbe/frame 0xfe044cdca9b0
>> spa_load_verify_cb() at spa_load_verify_cb+0x37d/frame 0xfe044cdcaa50
>> traverse_visitbp() at traverse_visitbp+0x5a5/frame 0xfe044cdcac60
>> traverse_dnode() at traverse_dnode+0x98/frame 0xfe044cdcacd0
>> traverse_visitbp() at traverse_visitbp+0xc66/frame 0xfe044cdcaee0
>> traverse_visitbp() at traverse_visitbp+0x930/frame 0xfe044cdcb0f0
>> traverse_visitbp() at traverse_visitbp+0x930/frame 0xfe044cdcb300
>> traverse_visitbp() at traverse_visitbp+0x930/frame 0xfe044cdcb510
>> traverse_visitbp() at traverse_visitbp+0x930/frame 0xfe044cdcb720
>> traverse_visitbp() at traverse_visitbp+0x930/frame 0xfe044cdcb930
>> traverse_visitbp() at traverse_visitbp+0x930/frame 0xfe044cdcbb40
>> traverse_dnode() at traverse_dnode+0x98/frame 0xfe044cdcbbb0
>> traverse_visitbp() at traverse_visitbp+0xe59/frame 0xfe044cdcbdc0
>> traverse_impl() at traverse_impl+0x79d/frame 0xfe044cdcbfd0
>> traverse_dataset() at traverse_dataset+0x93/frame 0xfe044cdcc040
>> traverse_pool() at traverse_pool+0x1f2/frame 0xfe044cdcc140
>> spa_load_verify() at spa_load_verify+0xf3/frame 0xfe044cdcc1f0
>> spa_load_impl() at spa_load_impl+0x2069/frame 0xfe044cdcc610
>> spa_load() at spa_load+0x320/frame 0xfe044cdcc6d0
>> spa_load_impl() at spa_load_impl+0x150b/frame 0xfe044cdccaf0
>> spa_load() at spa_load+0x320/frame 0xfe044cdccbb0
>> spa_load_best() at spa_load_best+0xc6/frame 0xfe044cdccc50
>> spa_open_common() at spa_open_common+0x246/frame 0xfe044cdccd40
>> spa_open() at spa_open+0x35/frame 0xfe044cdccd70
>> dsl_pool_hold() at dsl_pool_hold+0x2d/frame 0xfe044cdccdb0
>> dmu_objset_own() at dmu_objset_own+0x2e/frame 0xfe044cdcce30
>> zfsvfs_create() at zfsvfs_create+0x100/frame 0xfe044cdcd050
>> zfs_domount() at zfs_domount+0xa7/frame 0xfe044cdcd0e0
>> zfs_mount() at zfs_mount+0x6c3/frame 0xfe044cdcd390
>> vfs_donmount() at vfs_donmount+0x1330/frame 0xfe044cdcd660
>> kernel_mount() at kernel_mount+0x62/frame 0xfe044cdcd6c0
>> parse_mount() at parse_mount+0x668/frame 0xfe044cdcd810
>> vfs_mountroot() at vfs_mountroot+0x85c/frame 0xfe044cdcd9d0
>> start_init() at start_init+0x62/frame 0xfe044cdcda70
>> fork_exit() at fork_exit+0x84/frame 0xfe044cdcdab0
>> fork_tr
