buffer overflow warning in /bin/sh
I got the error when compiling GENERIC kernel with address sanitizer /bin/sh: --- vers.c --- MAKE=make sh /usr/home/howardsu/freebsd/sys/conf/newvers.sh GENERIC= ==4132==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fffc9c0 at pc 0x0045fdc7 bp 0x7fffc930 sp 0x7fffc0f0 WRITE of size 312 at 0x7fffc9c0 thread T0 #0 0x45fdc6 (/bin/sh+0x45fdc6) #1 0x801431767 (/lib/libc.so.7+0x7c767) #2 0x42ff5e (/bin/sh+0x42ff5e) #3 0x4b6b00 (/bin/sh+0x4b6b00) #4 0x49686e (/bin/sh+0x49686e) #5 0x495572 (/bin/sh+0x495572) #6 0x48c3f9 (/bin/sh+0x48c3f9) #7 0x489920 (/bin/sh+0x489920) #8 0x4acde8 (/bin/sh+0x4acde8) #9 0x4aca4d (/bin/sh+0x4aca4d) #10 0x40fb0e (/bin/sh+0x40fb0e) #11 0x80071afff () Address 0x7fffc9c0 is located in stack of thread T0==4132==AddressSanitizer CHECK failed: /usr/home/howardsu/freebsd/lib/libclang_rt/asan/../../../contrib/compiler-rt/lib/asan/asan_thread.cc:246 "((ptr[0] == kCurrentStackFrameMagic)) != (0)" (0x0, 0x0) #0 0x422b9d (/bin/sh+0x422b9d) #1 0x41de09 (/bin/sh+0x41de09) #2 0x41f301 (/bin/sh+0x41f301) #3 0x4728be (/bin/sh+0x4728be) #4 0x474589 (/bin/sh+0x474589) #5 0x47502a (/bin/sh+0x47502a) #6 0x45fdef (/bin/sh+0x45fdef) #7 0x801431767 (/lib/libc.so.7+0x7c767) #8 0x42ff5e (/bin/sh+0x42ff5e) #9 0x4b6b00 (/bin/sh+0x4b6b00) #10 0x49686e (/bin/sh+0x49686e) #11 0x495572 (/bin/sh+0x495572) #12 0x48c3f9 (/bin/sh+0x48c3f9) #13 0x489920 (/bin/sh+0x489920) #14 0x4acde8 (/bin/sh+0x4acde8) #15 0x4aca4d (/bin/sh+0x4aca4d) #16 0x40fb0e (/bin/sh+0x40fb0e) #17 0x80071afff () *** [vers.c] Error code 1 I am using latest -Current and add the following flags to /etc/make.conf. # CFLAGS+= -g -fsanitize=address -fno-omit-frame-pointer I rebuild /bin/sh as a first step. with the /bin/sh I got the above error. I would like to understand how to get symbols. The following command doesn't work at all. addr2line -e /bin/sh 0x422b9d Any idea? -- -Howard ___ 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: SVN r296272 breaks virtualbox
On Tue, Mar 1, 2016 at 10:28 PM Kurt Jaeger wrote: > Hi! > > > > > The removal of "taskqueue_enqueue_fast" breaks the virtualbox kmods: > [...] > > Then the port needs to be patched? It's been using an API deprecated > > for the last 15 years. A simple > s/taskqueue_enqueue_fast/taskqueue_enqueue/ > > will fix it. > > A patch is possible if a new __FreeBSD_version is created for that > API. Who can do that ? > There is no version pump and it is not needed. r296272 didn't have any behavior change. binary compatible is kept as well. And taskqueue_enqueue_fast should and is able to be replaced with taskqueue_enqueue long time ago.Blind replace taskqueue_enqueue_fast with taskqueue_enqueue is enough. -Howard > > -- > p...@opsec.eu+49 171 3101372 4 years to > go ! > ___ > 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: WITHOUT_CDDL prevents install of ctfconvert which breaks kernel build
You need comment out the following line in GENRIC kernel conf file: makeoptions WITH_CTF=1 # Run ctfconvert(1) for DTrace support On Tue, Mar 15, 2016 at 6:49 PM, Julian H. Stacey wrote: > Hi current@ people > src.conf WITHOUT_CDDL > prevents installation of ctfconvert > lack of ctfconvert broke my GENERIC kernel build > > I could submit a send-pr (or whatever we call them on web now) > so man src.conf warns of this, or do you have a better fix ? > > Cheers, > Julian > -- > Julian Stacey, BSD Linux Unix Sys Eng Consultant Munich > http://berklix.eu/jhs/ > Mail plain text, No quoted-printable, HTML, base64, MS.doc. > Prefix old lines '> ' Reply below old, like play script. Break lines by > 80. > ___ > 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" > -- -Howard ___ 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"
Mis-use of BUS_PASS_ORDER_MIDDLE
I noticed several places there are code like this, especially in some arm low level drivers. EARLY_DRIVER_MODULE(aw_ccu, simplebus, aw_ccu_driver, aw_ccu_devclass, 0, 0, BUS_PASS_BUS + BUS_PASS_ORDER_MIDDLE); I feel the usage of BUS_PASS_ORDER_MIDDLE is misused. There are another macro EARLY_DRIVER_MODULE_ORDERED, which take an additional parameter "order". I believe BUS_PASS_ORDER_xxx is used for that parameter. -- -Howard ___ 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: Mis-use of BUS_PASS_ORDER_MIDDLE
On Tue, Apr 19, 2016 at 2:53 AM John Baldwin wrote: > On Monday, April 18, 2016 11:10:12 PM Howard Su wrote: > > I noticed several places there are code like this, especially in some arm > > low level drivers. > > EARLY_DRIVER_MODULE(aw_ccu, simplebus, aw_ccu_driver, aw_ccu_devclass, > > 0, 0, BUS_PASS_BUS + BUS_PASS_ORDER_MIDDLE); > > > > I feel the usage of BUS_PASS_ORDER_MIDDLE is misused. There are another > > macro EARLY_DRIVER_MODULE_ORDERED, which take an additional parameter > > "order". I believe BUS_PASS_ORDER_xxx is used for that parameter. > > No, this is actually correct. The _ORDERED variants actually accept a > SI_ORDER_* value to determine how drivers contained in a single .ko file > are registered (in particular if you have several drivers in a .ko file > you typically want the "top-most" driver to attach last so that all the > other drivers are ready once the actual device is attached). > Why not use _ORDERED here to achieve same thing? _ORDERED(, SI_ORDER_LAST, BUS_PASS_BUS)? I am thinking to add some macro like BUS_DRIVER_MODULE, INT_DRIVER_MODULE, TIMER_DRIVER_MODULE, so that the driver can declare itself in such way. If we can avoid usage of BUS_PASS_ORDER_XXX, the macro is much cleaner. I am plan to do is: in autoconf phase, first load timer, int and some bus, etc low level drivers first, then set cold=0, then load other driver to work around the problem that driver needs special handling on cold which is not necessary. of course, this may depends on your change of ap_startup. thoughts? > -- > John Baldwin > -- -Howard ___ 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: Mis-use of BUS_PASS_ORDER_MIDDLE
Can we only load the bus driver that is required by timer or pic? Then you don't need worry about acpi_pci or pcib. John Baldwin 于2016年4月20日周三 上午3:26写道： > On Tuesday, April 19, 2016 03:42:40 PM Howard Su wrote: > > On Tue, Apr 19, 2016 at 2:53 AM John Baldwin wrote: > > > > > On Monday, April 18, 2016 11:10:12 PM Howard Su wrote: > > > > I noticed several places there are code like this, especially in > some arm > > > > low level drivers. > > > > EARLY_DRIVER_MODULE(aw_ccu, simplebus, aw_ccu_driver, > aw_ccu_devclass, > > > > 0, 0, BUS_PASS_BUS + BUS_PASS_ORDER_MIDDLE); > > > > > > > > I feel the usage of BUS_PASS_ORDER_MIDDLE is misused. There are > another > > > > macro EARLY_DRIVER_MODULE_ORDERED, which take an additional parameter > > > > "order". I believe BUS_PASS_ORDER_xxx is used for that parameter. > > > > > > No, this is actually correct. The _ORDERED variants actually accept a > > > SI_ORDER_* value to determine how drivers contained in a single .ko > file > > > are registered (in particular if you have several drivers in a .ko file > > > you typically want the "top-most" driver to attach last so that all the > > > other drivers are ready once the actual device is attached). > > > > > Why not use _ORDERED here to achieve same thing? _ORDERED(, > > SI_ORDER_LAST, BUS_PASS_BUS)? > > > > I am thinking to add some macro like BUS_DRIVER_MODULE, > INT_DRIVER_MODULE, > > TIMER_DRIVER_MODULE, so that the driver can declare itself in such way. > If > > we can avoid usage of BUS_PASS_ORDER_XXX, the macro is much cleaner. > > > > I am plan to do is: in autoconf phase, first load timer, int and some > bus, > > etc low level drivers first, then set cold=0, then load other driver to > > work around the problem that driver needs special handling on cold which > is > > not necessary. of course, this may depends on your change of ap_startup. > > thoughts? > > I would like to get to that, but the path on x86 is a bit messier. Ideally > the order looks something like this: > > - enumerate the tree (BUS_PASS_BUS) > - reserve fixed-resources (things like acpi_sysres) (BUS_PASS_RESOURCE) > - reserve existing resources that could be moved or disabled if > their is a conflict (think PCI BARs programmed by firmware and/or > doing an initial pass of BARs) > - interrupt controllers (may need resources) (BUS_PASS_INTR) > - timers (probably need resources, need interrupts) (BUS_PASS_TIMER) > > Then all the rest. > > However, it ends up a bit messier on x86 at least. I have a WIP to at > least start doing BUS_PASS_BUS for x86, but I found that I really need > some ACPI bits to probe before the ACPI 'pcib' driver, so I've ended > up with a kind of 'BUS_PASS_PREBUS' for acpi0, and even then it turns out > that in some cases we need more granularity than just 'BUS_PASS_xxx'. > > SI_ORDER_* with ORDERED will not help as all the drivers are registered > at SI_SUB_DRIVERS during boot (which is when the SI_ORDER_* applies), > but the device tree is enumerated and attached at SI_SUB_CONFIGURE. > > And yes, the AP startup stuff is a precursor for this. > > -- > John Baldwin > -- -Howard ___ 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"
Failed to boot -Current snapshot memstick img with EFI
The issue is partition table in img is wrong so that GEOM cannot discover the partitions. Detailed error: GEOM_PART: last LBA is below first LBA: 0 < 32 GEOM_PART: integrity check failed (da0, MBR) I tried this month and last month memstick img. both has same problem. Any idea on the issue? -Howard -- -Howard ___ 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"
Fwd: Failed to boot -Current snapshot memstick img with EFI
The same issue is still there in 11-BETA2. I tried the memstick image for amd64. I got the exact same error (with boot -v). GEOM_PART: last LBA is below first LBA: 0 < 32 GEOM_PART: integrity check failed (da0, MBR) This make mem stick image totally useless. Anyone take a look? I am happy to provide more information. Thanks, Howard -- Forwarded message -- From: Howard Su Date: Sat, Apr 23, 2016 at 10:40 PM Subject: Failed to boot -Current snapshot memstick img with EFI To: "freebsd-current@freebsd.org" The issue is partition table in img is wrong so that GEOM cannot discover the partitions. Detailed error: GEOM_PART: last LBA is below first LBA: 0 < 32 GEOM_PART: integrity check failed (da0, MBR) I tried this month and last month memstick img. both has same problem. Any idea on the issue? -Howard -- -Howard -- -Howard ___ 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: Fwd: Failed to boot -Current snapshot memstick img with EFI
8GB Allan Jude 于2016年7月27日周三 上午11:35写道： > On 2016-07-26 23:33, Howard Su wrote: > > The same issue is still there in 11-BETA2. I tried the memstick image for > > amd64. I got the exact same error (with boot -v). > > GEOM_PART: last LBA is below first LBA: 0 < 32 > > GEOM_PART: integrity check failed (da0, MBR) > > > > This make mem stick image totally useless. Anyone take a look? I am happy > > to provide more information. > > > > Thanks, > > > > Howard > > > > -- Forwarded message -- > > From: Howard Su > > Date: Sat, Apr 23, 2016 at 10:40 PM > > Subject: Failed to boot -Current snapshot memstick img with EFI > > To: "freebsd-current@freebsd.org" > > > > > > The issue is partition table in img is wrong so that GEOM cannot discover > > the partitions. > > > > Detailed error: > > > > GEOM_PART: last LBA is below first LBA: 0 < 32 > > GEOM_PART: integrity check failed (da0, MBR) > > > > I tried this month and last month memstick img. both has same problem. > Any > > idea on the issue? > > > > -Howard > > > > The last LBA is being reported as 0, which is obviously bogus. > > How big is the USB device you have written the memstick to? > > -- > Allan Jude > > -- -Howard ___ 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: Fwd: Failed to boot -Current snapshot memstick img with EFI
It turns out a USB driver problem. the usb disk size is not correctly detected. But the disk works fine in BIOS. Here is dmesg information: ugen7.2: at usbus7 umass0: on usbus7 umass0: SCSI over Bulk-Only; quirks = 0x8100 umass0:6:0: Attached to scbus6 da0 at umass-sim0 bus 0 scbus6 target 0 lun 0 da0: Removable Direct Access SPC-4 SCSI device da0: Serial Number 137161312223005B da0: 40.000MB/s transfers da0: 0MB (1 512 byte sectors) < da0: quirks=0x2 GEOM_PART: integrity check failed (da0, MBR) GEOM_PART: integrity check failed (diskid/DISK-137161312223005B, MBR) Anyone has idea how this happen? -Howard On Wed, Jul 27, 2016 at 12:21 PM Howard Su wrote: > 8GB > > Allan Jude 于2016年7月27日周三 上午11:35写道： > >> On 2016-07-26 23:33, Howard Su wrote: >> > The same issue is still there in 11-BETA2. I tried the memstick image >> for >> > amd64. I got the exact same error (with boot -v). >> > GEOM_PART: last LBA is below first LBA: 0 < 32 >> > GEOM_PART: integrity check failed (da0, MBR) >> > >> > This make mem stick image totally useless. Anyone take a look? I am >> happy >> > to provide more information. >> > >> > Thanks, >> > >> > Howard >> > >> > -- Forwarded message -- >> > From: Howard Su >> > Date: Sat, Apr 23, 2016 at 10:40 PM >> > Subject: Failed to boot -Current snapshot memstick img with EFI >> > To: "freebsd-current@freebsd.org" >> > >> > >> > The issue is partition table in img is wrong so that GEOM cannot >> discover >> > the partitions. >> > >> > Detailed error: >> > >> > GEOM_PART: last LBA is below first LBA: 0 < 32 >> > GEOM_PART: integrity check failed (da0, MBR) >> > >> > I tried this month and last month memstick img. both has same problem. >> Any >> > idea on the issue? >> > >> > -Howard >> > >> >> The last LBA is being reported as 0, which is obviously bogus. >> >> How big is the USB device you have written the memstick to? >> >> -- >> Allan Jude >> >> -- > -Howard > -- -Howard ___ 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: Fwd: Failed to boot -Current snapshot memstick img with EFI
This is fixed by r303944. On Fri, Jul 29, 2016 at 1:24 AM Howard Su wrote: > It turns out a USB driver problem. the usb disk size is not correctly > detected. But the disk works fine in BIOS. > > Here is dmesg information: > ugen7.2: at usbus7 > umass0: on > usbus7 > umass0: SCSI over Bulk-Only; quirks = 0x8100 > umass0:6:0: Attached to scbus6 > da0 at umass-sim0 bus 0 scbus6 target 0 lun 0 > da0: Removable Direct Access SPC-4 SCSI > device > da0: Serial Number 137161312223005B > da0: 40.000MB/s transfers > da0: 0MB (1 512 byte sectors) < > da0: quirks=0x2 > GEOM_PART: integrity check failed (da0, MBR) > GEOM_PART: integrity check failed (diskid/DISK-137161312223005B, MBR) > > Anyone has idea how this happen? > > -Howard > > On Wed, Jul 27, 2016 at 12:21 PM Howard Su wrote: > >> 8GB >> >> Allan Jude 于2016年7月27日周三 上午11:35写道： >> >>> On 2016-07-26 23:33, Howard Su wrote: >>> > The same issue is still there in 11-BETA2. I tried the memstick image >>> for >>> > amd64. I got the exact same error (with boot -v). >>> > GEOM_PART: last LBA is below first LBA: 0 < 32 >>> > GEOM_PART: integrity check failed (da0, MBR) >>> > >>> > This make mem stick image totally useless. Anyone take a look? I am >>> happy >>> > to provide more information. >>> > >>> > Thanks, >>> > >>> > Howard >>> > >>> > -- Forwarded message -- >>> > From: Howard Su >>> > Date: Sat, Apr 23, 2016 at 10:40 PM >>> > Subject: Failed to boot -Current snapshot memstick img with EFI >>> > To: "freebsd-current@freebsd.org" >>> > >>> > >>> > The issue is partition table in img is wrong so that GEOM cannot >>> discover >>> > the partitions. >>> > >>> > Detailed error: >>> > >>> > GEOM_PART: last LBA is below first LBA: 0 < 32 >>> > GEOM_PART: integrity check failed (da0, MBR) >>> > >>> > I tried this month and last month memstick img. both has same problem. >>> Any >>> > idea on the issue? >>> > >>> > -Howard >>> > >>> >>> The last LBA is being reported as 0, which is obviously bogus. >>> >>> How big is the USB device you have written the memstick to? >>> >>> -- >>> Allan Jude >>> >>> -- >> -Howard >> > -- > -Howard > -- -Howard ___ 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"
[VBox] Extreme slow UDP performance between host and guest
I used iperf to do a quick experiment on the UDP performance between VirtualBox and Guest through vboxnetadp. Guest is acting as server and Host machine is acting as client. the UDP throughput is only 1/350 of TCP throughput. Guest kernel is -Current and Host Kernel is 11.0-RC2. Anyone has idea? is there any known issue in vboxnetadp? Client connecting to 192.168.0.60, UDP port 5001 Sending 1470 byte datagrams UDP buffer size: 9.00 KByte (default) [ 3] local 192.168.0.1 port 48290 connected with 192.168.0.60 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 1.25 MBytes 1.05 Mbits/sec [ 3] Sent 893 datagrams [ 3] Server Report: [ 3] 0.0-10.0 sec 1.25 MBytes 1.05 Mbits/sec 0.039 ms0/ 893 (0%) Client connecting to 192.168.0.60, UDP port 5001 Sending 4096 byte datagrams UDP buffer size: 9.00 KByte (default) [ 3] local 192.168.0.1 port 58009 connected with 192.168.0.60 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 1.25 MBytes 1.05 Mbits/sec [ 3] Sent 321 datagrams [ 3] Server Report: [ 3] 0.0-10.0 sec 1.25 MBytes 1.05 Mbits/sec 0.100 ms0/ 321 (0%) Client connecting to 192.168.0.60, TCP port 5001 TCP window size: 32.8 KByte (default) [ 3] local 192.168.0.1 port 15490 connected with 192.168.0.60 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 447 MBytes 374 Mbits/sec -Howard -- -Howard ___ 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"
