CURRENT [r312928] TCP_RFC7413 kernel panic

2017-01-28 Thread Alex Deiter 
Hello,

The most recent CURRENT [r312928] with enabled kernel option TCP_RFC7413 panics 
spontaneously:

Fatal trap 12: page fault while in kernel mode
cpuid = 1; apic id = 02
fault virtual address   = 0x28
fault code  = supervisor read data, page not present
instruction pointer = 0x20:0x808a4555
stack pointer   = 0x28:0xfe083bf738b0
frame pointer   = 0x28:0xfe083bf738d0
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 12 (swi4: clock (0))
[ thread pid 12 tid 18 ]
Stopped at  tcp_fastopen_autokey_locked+0x35:   movq0x28(%rax),%rax

db> bt
Tracing pid 12 tid 18 td 0xf80007383500
tcp_fastopen_autokey_locked() at tcp_fastopen_autokey_locked+0x35/frame 
0xfe083bf738d0
tcp_fastopen_autokey_callout() at tcp_fastopen_autokey_callout+0x2d/frame 
0xfe083bf73900
softclock_call_cc() at softclock_call_cc+0x156/frame 0xfe083bf739b0
softclock() at softclock+0x94/frame 0xfe083bf739e0
intr_event_execute_handlers() at intr_event_execute_handlers+0x20f/frame 
0xfe083bf73a20
ithread_loop() at ithread_loop+0xc6/frame 0xfe083bf73a70
fork_exit() at fork_exit+0x85/frame 0xfe083bf73ab0
fork_trampoline() at fork_trampoline+0xe/frame 0xfe083bf73ab0
--- trap 0, rip = 0, rsp = 0, rbp = 0 ---
db> 

Thank you!

Alex Deiter
alex.dei...@gmail.com



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

pkg, base packages and subdirectories

2017-01-28 Thread Boris Samorodov 

Hi All,

I've created my base repo and installed the OS from packages.
All in all it all went rather smooth!

As for pkg it seems to not pay attention to base library subdirs:
-
# pkg check -Ba

Checking all packages:   3%
(FreeBSD-kernel-sm-12.0.s20170128125723) /boot/kernel/kernel - required 
shared library hack.pico not found

Checking all packages:  35%
(FreeBSD-runtime-12.0.s20170128125723) /sbin/ping - required shared 
library libcap_dns.so.0 not found
(FreeBSD-runtime-12.0.s20170128125723) /usr/bin/kdump - required shared 
library libcap_grp.so.0 not found
(FreeBSD-runtime-12.0.s20170128125723) /usr/bin/kdump - required shared 
library libcap_pwd.so.0 not found
(FreeBSD-runtime-12.0.s20170128125723) /usr/sbin/tcpdump - required 
shared library libcap_dns.so.0 not found

Checking all packages:  36%
(FreeBSD-tests-12.0.s20170128125723) 
/usr/tests/lib/libcasper/services/cap_dns/dns_test - required shared 
library libcap_dns.so.0 not found
(FreeBSD-tests-12.0.s20170128125723) 
/usr/tests/lib/libcasper/services/cap_grp/grp_test - required shared 
library libcap_grp.so.0 not found
(FreeBSD-tests-12.0.s20170128125723) 
/usr/tests/lib/libcasper/services/cap_pwd/pwd_test - required shared 
library libcap_pwd.so.0 not found
(FreeBSD-tests-12.0.s20170128125723) 
/usr/tests/lib/libcasper/services/cap_sysctl/sysctl_test - required 
shared library libcap_sysctl.so.0 not found

Checking all packages: 100%

# ldd `which ping`
/sbin/ping:
libm.so.5 => /lib/libm.so.5 (0x800828000)
libcasper.so.0 => /lib/libcasper.so.0 (0x800a52000)
libcap_dns.so.0 => /lib/casper/libcap_dns.so.0 (0x800c57000)
libipsec.so.4 => /lib/libipsec.so.4 (0x800e5b000)

# ls -l /lib/casper
total 51
-r--r--r--  1 root  wheel  16584 28 янв.  15:58 libcap_dns.so.0
-r--r--r--  1 root  wheel  15968 28 янв.  15:58 libcap_grp.so.0
-r--r--r--  1 root  wheel  15872 28 янв.  15:58 libcap_pwd.so.0
-r--r--r--  1 root  wheel   6904 28 янв.  15:58 libcap_random.so.0
-r--r--r--  1 root  wheel   8912 28 янв.  15:58 libcap_sysctl.so.0
-

--
WBR, Boris Samorodov (bsam)
FreeBSD Committer, http://www.FreeBSD.org The Power To Serve
___
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: gptzfsboot grew a lot after skein support was added; need knob to control bloat

2017-01-28 Thread Ngie Cooper 
On Sat, Jan 28, 2017 at 1:03 PM, Ngie Cooper  wrote:
> On Sat, Jan 28, 2017 at 12:17 PM, Ngie Cooper  wrote:
> ...
>
>> After some creative hacking... tada!
>>
>> # find /usr/obj/usr/src/sys/boot/ -type f -name \*zfsboot -exec ls -l {} \;
>> -rw-r--r--  1 root  wheel  131584 Jan 28 12:07
>> /usr/obj/usr/src/sys/boot/i386/zfsboot/zfsboot
>> -rw-r--r--  1 root  wheel  47527 Jan 28 12:07
>> /usr/obj/usr/src/sys/boot/i386/gptzfsboot/gptzfsboot
>
> Bah. It's still 2kB too big. I'll see if I can free up some more space
> in the text area (there was a patch kicking around at $work that might
> alleviate this a few more kB).

Ok, found the patch.

After applying all the changes, it's finally under 44kB and I can
write the bootcode to my disk:

$ sudo gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 da0
partcode written to da0p1
bootcode written to da0

-Ngie
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: gptzfsboot grew a lot after skein support was added; need knob to control bloat

2017-01-28 Thread Ngie Cooper 
On Sat, Jan 28, 2017 at 12:17 PM, Ngie Cooper  wrote:
...

> After some creative hacking... tada!
>
> # find /usr/obj/usr/src/sys/boot/ -type f -name \*zfsboot -exec ls -l {} \;
> -rw-r--r--  1 root  wheel  131584 Jan 28 12:07
> /usr/obj/usr/src/sys/boot/i386/zfsboot/zfsboot
> -rw-r--r--  1 root  wheel  47527 Jan 28 12:07
> /usr/obj/usr/src/sys/boot/i386/gptzfsboot/gptzfsboot

Bah. It's still 2kB too big. I'll see if I can free up some more space
in the text area (there was a patch kicking around at $work that might
alleviate this a few more kB).
-Ngie
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: gptzfsboot grew a lot after skein support was added; need knob to control bloat

2017-01-28 Thread Ngie Cooper 
On Sat, Jan 28, 2017 at 12:21 PM, Allan Jude  wrote:

...

> The 'zfsboot' version, is dd's into the zfs boot code area. It is read
> by the assembly code there. It is important the file be the size that
> will be read, so it is padded out. That file is currently only used for
> MBR booting from ZFS.

Thank you for the info -- it would be really nice if this was noted in
the Makefile in more detail for the next soul who wonders why the
sizes are so different.
Thanks!
-Ngie
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: gptzfsboot grew a lot after skein support was added; need knob to control bloat

2017-01-28 Thread Allan Jude 
On 2017-01-28 15:17, Ngie Cooper wrote:
> On Sat, Jan 28, 2017 at 11:22 AM, Ngie Cooper  wrote:
>>> What created a partition that small?
>>
>> Me.
>>
>> gpart up until last summer said that users should create 44kB
>> freebsd-boot partitions -- des@ corrected that in r303289:
>>
>> -This example uses 88 blocks (44 kB) so the next partition will be
>> -aligned on a 64 kB boundary without the need to specify an explicit
>> -offset or alignment.
>> -The boot partition itself is aligned on a 4 kB boundary.
>> +We create a 472-block (236 kB) boot partition at offset 40, which is
>> +the size of the partition table (34 blocks or 17 kB) rounded up to the
>> +nearest 4 kB boundary.
>>  .Bd -literal -offset indent
>> -/sbin/gpart add -b 40 -s 88 -t freebsd-boot ada0
>> +/sbin/gpart add -b 40 -s 472 -t freebsd-boot ada0
> 
> After some creative hacking... tada!
> 
> # find /usr/obj/usr/src/sys/boot/ -type f -name \*zfsboot -exec ls -l {} \;
> -rw-r--r--  1 root  wheel  131584 Jan 28 12:07
> /usr/obj/usr/src/sys/boot/i386/zfsboot/zfsboot
> -rw-r--r--  1 root  wheel  47527 Jan 28 12:07
> /usr/obj/usr/src/sys/boot/i386/gptzfsboot/gptzfsboot
> 
> -- wait, why is the size of zfsboot vs gptzfsboot so different? Oh,
> r304321 added that as `BOOT2SIZE`. Still, it seems a bit silly to only
> increase the size of one bootloader and not the other 4 instances of
> the bootloader :/. I don't understand the point in the size
> restriction 100%, but I'll leave it be.
> 
> Patch will be available sometime next week if my testing goes well.
> 
> Cheers,
> -Ngie
> 

The 'zfsboot' version, is dd's into the zfs boot code area. It is read
by the assembly code there. It is important the file be the size that
will be read, so it is padded out. That file is currently only used for
MBR booting from ZFS.

-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature

Re: gptzfsboot grew a lot after skein support was added; need knob to control bloat

2017-01-28 Thread Ngie Cooper 
On Sat, Jan 28, 2017 at 11:22 AM, Ngie Cooper  wrote:
>> What created a partition that small?
>
> Me.
>
> gpart up until last summer said that users should create 44kB
> freebsd-boot partitions -- des@ corrected that in r303289:
>
> -This example uses 88 blocks (44 kB) so the next partition will be
> -aligned on a 64 kB boundary without the need to specify an explicit
> -offset or alignment.
> -The boot partition itself is aligned on a 4 kB boundary.
> +We create a 472-block (236 kB) boot partition at offset 40, which is
> +the size of the partition table (34 blocks or 17 kB) rounded up to the
> +nearest 4 kB boundary.
>  .Bd -literal -offset indent
> -/sbin/gpart add -b 40 -s 88 -t freebsd-boot ada0
> +/sbin/gpart add -b 40 -s 472 -t freebsd-boot ada0

After some creative hacking... tada!

# find /usr/obj/usr/src/sys/boot/ -type f -name \*zfsboot -exec ls -l {} \;
-rw-r--r--  1 root  wheel  131584 Jan 28 12:07
/usr/obj/usr/src/sys/boot/i386/zfsboot/zfsboot
-rw-r--r--  1 root  wheel  47527 Jan 28 12:07
/usr/obj/usr/src/sys/boot/i386/gptzfsboot/gptzfsboot

-- wait, why is the size of zfsboot vs gptzfsboot so different? Oh,
r304321 added that as `BOOT2SIZE`. Still, it seems a bit silly to only
increase the size of one bootloader and not the other 4 instances of
the bootloader :/. I don't understand the point in the size
restriction 100%, but I'll leave it be.

Patch will be available sometime next week if my testing goes well.

Cheers,
-Ngie
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: gptzfsboot grew a lot after skein support was added; need knob to control bloat

2017-01-28 Thread Warner Losh 
On Sat, Jan 28, 2017 at 12:04 PM, Ngie Cooper  wrote:
> On Sat, Jan 28, 2017 at 10:57 AM, Allan Jude  wrote:
>> On 2017-01-28 13:56, Ngie Cooper wrote:
>>> On Sat, Jan 28, 2017 at 8:56 AM, Warner Losh  wrote:
>>>
>>> ...
>>>
 So? It literally doesn't matter where the freebsd-boot partition
 lives, or what it's number is. You can put it at the start or end of
 the swap partition after adjusting its size. I've done this on several
 systems...  NanoBSD plays games with this stuff as well to be bootable
 on old / new systems.
>>>
>>> True. Hopefully my BIOS/disk controller isn't dumb enough to not
>>> support large disks properly.
>>>
>>> *sigh* Unfortunately, in my infinity cleverness I only put 2
>>> partitions on the drive -- freebsd-boot and freebsd-zfs. I guess I'll
>>> need to make backups of my workstation so I don't lose anything
>>> critical.
>>
>> Did gptzfsboot not fall below 64kb when you used the
>> LOADER_NO_GELI_SUPPORT knob?
>
> It did, but unfortunately that's still way too small for my
> freebsd-boot partition (which apparently is only 44kB large :/..):
>
> Before:
>
> $ ls -l `make -V.OBJDIR`/gptzfsboot
> -rw-r--r--  1 ngie  wheel  111662 Jan 28 11:00
> /usr/obj/usr/src/sys/boot/i386/gptzfsboot/gptzfsboot
>
> After:
>
> $ ls -l `make -V.OBJDIR`/gptzfsboot
> -rw-r--r--  1 ngie  wheel  65371 Jan 28 11:05
> /usr/obj/usr/src/sys/boot/i386/gptzfsboot/gptzfsboot
>
> Time to do some more tricks to pare down the bootloader size.

You can tweak the start of your boot loader partition to start at 2,
which would give you 63.5k of space, which is 65024 bytes. Sadly, this
is 300 bytes less space than you have.

The end of the disk usually is a good place to look for space, but it
looks like there's at most 17k there.

> Sidenote to the folks who drive the release notes and upgrade
> instructions for FreeBSD 12.x -- it needs to be clearly explained that
> gptzfsboot has grown considerably in size and mitigation instructions
> should be provided for updating gptzfsboot -- in particular with folks
> who might be using freebsd-update, so don't have the luxury of the
> choice of bootloader build options when upgrading.

Upgrade scripts (including installworld) don't update the bootblocks
ever. Just the files in /boot.

Warner

> Thanks,
> -Ngie
>
> $ gpart list da0
> Geom name: da0
> modified: false
> state: OK
> fwheads: 255
> fwsectors: 63
> last: 250069646
> first: 34
> entries: 128
> scheme: GPT
> Providers:
> 1. Name: da0p1
>Mediasize: 45056 (44K)
>Sectorsize: 512
>Stripesize: 0
>Stripeoffset: 20480
>Mode: r0w0e0
>rawuuid: 29a79300-48b1-11e4-97ff-fc4dd43f2de9
>rawtype: 83bd6b9d-7f41-11dc-be0b-001560b84f0f
>label: (null)
>length: 45056
>offset: 20480
>type: freebsd-boot
>index: 1
>end: 127
>start: 40
> 2. Name: da0p2
>Mediasize: 128035593728 (119G)
>Sectorsize: 512
>Stripesize: 0
>Stripeoffset: 65536
>Mode: r1w1e1
>rawuuid: 4416180d-48b1-11e4-97ff-fc4dd43f2de9
>rawtype: 516e7cba-6ecf-11d6-8ff8-00022d09712b
>label: (null)
>length: 128035593728
>offset: 65536
>type: freebsd-zfs
>index: 2
>end: 250069646
>start: 128
> Consumers:
> 1. Name: da0
>Mediasize: 128035676160 (119G)
>Sectorsize: 512
>Mode: r1w1e2
___
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: gptzfsboot grew a lot after skein support was added; need knob to control bloat

2017-01-28 Thread Ngie Cooper 
> What created a partition that small?

Me.

gpart up until last summer said that users should create 44kB
freebsd-boot partitions -- des@ corrected that in r303289:

-This example uses 88 blocks (44 kB) so the next partition will be
-aligned on a 64 kB boundary without the need to specify an explicit
-offset or alignment.
-The boot partition itself is aligned on a 4 kB boundary.
+We create a 472-block (236 kB) boot partition at offset 40, which is
+the size of the partition table (34 blocks or 17 kB) rounded up to the
+nearest 4 kB boundary.
 .Bd -literal -offset indent
-/sbin/gpart add -b 40 -s 88 -t freebsd-boot ada0
+/sbin/gpart add -b 40 -s 472 -t freebsd-boot ada0

Thanks,
-Ngie
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: gptzfsboot grew a lot after skein support was added; need knob to control bloat

2017-01-28 Thread Allan Jude 
On 2017-01-28 14:04, Ngie Cooper wrote:
> On Sat, Jan 28, 2017 at 10:57 AM, Allan Jude  wrote:
>> On 2017-01-28 13:56, Ngie Cooper wrote:
>>> On Sat, Jan 28, 2017 at 8:56 AM, Warner Losh  wrote:
>>>
>>> ...
>>>
 So? It literally doesn't matter where the freebsd-boot partition
 lives, or what it's number is. You can put it at the start or end of
 the swap partition after adjusting its size. I've done this on several
 systems...  NanoBSD plays games with this stuff as well to be bootable
 on old / new systems.
>>>
>>> True. Hopefully my BIOS/disk controller isn't dumb enough to not
>>> support large disks properly.
>>>
>>> *sigh* Unfortunately, in my infinity cleverness I only put 2
>>> partitions on the drive -- freebsd-boot and freebsd-zfs. I guess I'll
>>> need to make backups of my workstation so I don't lose anything
>>> critical.
>>
>> Did gptzfsboot not fall below 64kb when you used the
>> LOADER_NO_GELI_SUPPORT knob?
> 
> It did, but unfortunately that's still way too small for my
> freebsd-boot partition (which apparently is only 44kB large :/..):
> 
> Before:
> 
> $ ls -l `make -V.OBJDIR`/gptzfsboot
> -rw-r--r--  1 ngie  wheel  111662 Jan 28 11:00
> /usr/obj/usr/src/sys/boot/i386/gptzfsboot/gptzfsboot
> 
> After:
> 
> $ ls -l `make -V.OBJDIR`/gptzfsboot
> -rw-r--r--  1 ngie  wheel  65371 Jan 28 11:05
> /usr/obj/usr/src/sys/boot/i386/gptzfsboot/gptzfsboot
> 
> Time to do some more tricks to pare down the bootloader size.
> 
> Sidenote to the folks who drive the release notes and upgrade
> instructions for FreeBSD 12.x -- it needs to be clearly explained that
> gptzfsboot has grown considerably in size and mitigation instructions
> should be provided for updating gptzfsboot -- in particular with folks
> who might be using freebsd-update, so don't have the luxury of the
> choice of bootloader build options when upgrading.
> 
> Thanks,
> -Ngie
> 
> $ gpart list da0
> Geom name: da0
> modified: false
> state: OK
> fwheads: 255
> fwsectors: 63
> last: 250069646
> first: 34
> entries: 128
> scheme: GPT
> Providers:
> 1. Name: da0p1
>Mediasize: 45056 (44K)
>Sectorsize: 512
>Stripesize: 0
>Stripeoffset: 20480
>Mode: r0w0e0
>rawuuid: 29a79300-48b1-11e4-97ff-fc4dd43f2de9
>rawtype: 83bd6b9d-7f41-11dc-be0b-001560b84f0f
>label: (null)
>length: 45056
>offset: 20480
>type: freebsd-boot
>index: 1
>end: 127
>start: 40
> 2. Name: da0p2
>Mediasize: 128035593728 (119G)
>Sectorsize: 512
>Stripesize: 0
>Stripeoffset: 65536
>Mode: r1w1e1
>rawuuid: 4416180d-48b1-11e4-97ff-fc4dd43f2de9
>rawtype: 516e7cba-6ecf-11d6-8ff8-00022d09712b
>label: (null)
>length: 128035593728
>offset: 65536
>type: freebsd-zfs
>index: 2
>end: 250069646
>start: 128
> Consumers:
> 1. Name: da0
>Mediasize: 128035676160 (119G)
>Sectorsize: 512
>Mode: r1w1e2
> 

What created a partition that small?

Even the FreeBSD 9.3 or 10.3 ZFS boot loaders would struggle to fit in
that space:

9.3:
-r--r--r--  1 root  wheel  42083 Jul 30  2015 /boot/gptzfsboot

10.3:
-r--r--r--  1 root  wheel  42143 Mar 25  2016 /boot/gptzfsboot


-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature

Re: gptzfsboot grew a lot after skein support was added; need knob to control bloat

2017-01-28 Thread Ngie Cooper 
On Sat, Jan 28, 2017 at 10:57 AM, Allan Jude  wrote:
> On 2017-01-28 13:56, Ngie Cooper wrote:
>> On Sat, Jan 28, 2017 at 8:56 AM, Warner Losh  wrote:
>>
>> ...
>>
>>> So? It literally doesn't matter where the freebsd-boot partition
>>> lives, or what it's number is. You can put it at the start or end of
>>> the swap partition after adjusting its size. I've done this on several
>>> systems...  NanoBSD plays games with this stuff as well to be bootable
>>> on old / new systems.
>>
>> True. Hopefully my BIOS/disk controller isn't dumb enough to not
>> support large disks properly.
>>
>> *sigh* Unfortunately, in my infinity cleverness I only put 2
>> partitions on the drive -- freebsd-boot and freebsd-zfs. I guess I'll
>> need to make backups of my workstation so I don't lose anything
>> critical.
>
> Did gptzfsboot not fall below 64kb when you used the
> LOADER_NO_GELI_SUPPORT knob?

It did, but unfortunately that's still way too small for my
freebsd-boot partition (which apparently is only 44kB large :/..):

Before:

$ ls -l `make -V.OBJDIR`/gptzfsboot
-rw-r--r--  1 ngie  wheel  111662 Jan 28 11:00
/usr/obj/usr/src/sys/boot/i386/gptzfsboot/gptzfsboot

After:

$ ls -l `make -V.OBJDIR`/gptzfsboot
-rw-r--r--  1 ngie  wheel  65371 Jan 28 11:05
/usr/obj/usr/src/sys/boot/i386/gptzfsboot/gptzfsboot

Time to do some more tricks to pare down the bootloader size.

Sidenote to the folks who drive the release notes and upgrade
instructions for FreeBSD 12.x -- it needs to be clearly explained that
gptzfsboot has grown considerably in size and mitigation instructions
should be provided for updating gptzfsboot -- in particular with folks
who might be using freebsd-update, so don't have the luxury of the
choice of bootloader build options when upgrading.

Thanks,
-Ngie

$ gpart list da0
Geom name: da0
modified: false
state: OK
fwheads: 255
fwsectors: 63
last: 250069646
first: 34
entries: 128
scheme: GPT
Providers:
1. Name: da0p1
   Mediasize: 45056 (44K)
   Sectorsize: 512
   Stripesize: 0
   Stripeoffset: 20480
   Mode: r0w0e0
   rawuuid: 29a79300-48b1-11e4-97ff-fc4dd43f2de9
   rawtype: 83bd6b9d-7f41-11dc-be0b-001560b84f0f
   label: (null)
   length: 45056
   offset: 20480
   type: freebsd-boot
   index: 1
   end: 127
   start: 40
2. Name: da0p2
   Mediasize: 128035593728 (119G)
   Sectorsize: 512
   Stripesize: 0
   Stripeoffset: 65536
   Mode: r1w1e1
   rawuuid: 4416180d-48b1-11e4-97ff-fc4dd43f2de9
   rawtype: 516e7cba-6ecf-11d6-8ff8-00022d09712b
   label: (null)
   length: 128035593728
   offset: 65536
   type: freebsd-zfs
   index: 2
   end: 250069646
   start: 128
Consumers:
1. Name: da0
   Mediasize: 128035676160 (119G)
   Sectorsize: 512
   Mode: r1w1e2
___
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: gptzfsboot grew a lot after skein support was added; need knob to control bloat

2017-01-28 Thread Allan Jude 
On 2017-01-28 13:56, Ngie Cooper wrote:
> On Sat, Jan 28, 2017 at 8:56 AM, Warner Losh  wrote:
> 
> ...
> 
>> So? It literally doesn't matter where the freebsd-boot partition
>> lives, or what it's number is. You can put it at the start or end of
>> the swap partition after adjusting its size. I've done this on several
>> systems...  NanoBSD plays games with this stuff as well to be bootable
>> on old / new systems.
> 
> True. Hopefully my BIOS/disk controller isn't dumb enough to not
> support large disks properly.
> 
> *sigh* Unfortunately, in my infinity cleverness I only put 2
> partitions on the drive -- freebsd-boot and freebsd-zfs. I guess I'll
> need to make backups of my workstation so I don't lose anything
> critical.
> 
> -Ngie
> 

Did gptzfsboot not fall below 64kb when you used the
LOADER_NO_GELI_SUPPORT knob?

-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature

Re: gptzfsboot grew a lot after skein support was added; need knob to control bloat

2017-01-28 Thread Ngie Cooper 
On Sat, Jan 28, 2017 at 8:56 AM, Warner Losh  wrote:

...

> So? It literally doesn't matter where the freebsd-boot partition
> lives, or what it's number is. You can put it at the start or end of
> the swap partition after adjusting its size. I've done this on several
> systems...  NanoBSD plays games with this stuff as well to be bootable
> on old / new systems.

True. Hopefully my BIOS/disk controller isn't dumb enough to not
support large disks properly.

*sigh* Unfortunately, in my infinity cleverness I only put 2
partitions on the drive -- freebsd-boot and freebsd-zfs. I guess I'll
need to make backups of my workstation so I don't lose anything
critical.

-Ngie
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: gptzfsboot grew a lot after skein support was added; need knob to control bloat

2017-01-28 Thread Toomas Soome 

> On 28. jaan 2017, at 18:56, Warner Losh  wrote:
> 
>> 
>> 
>> at $JOB we are just testing a script that expands the root zfs partition on
>> in-field appliances by shaving a bit off swap and cannibalising a small data
>> partition we don't really use. I see we only left 64K for the boot part.
>> It's big enough for us for now, but possibly we should fix that as well.
>> We have a mirror setup for system disks so we have the ability to take each
>> system drive offline one at a time and rearrange it and then re-add the root
>> partition to the mirror.
>> What are the chances a regular gpt+ZFS (no encrypt) bootblock will grow over
>> 64K?
> 
> Hard to say. Given boot1/boot2 growth over time, I'd peg that close to 100%.
> 
> 


There are few things to consider. First of all, the job of the boot2 is 
actually really small - read out the loader binary by using file system 
specific reader code and start it; and, on bios system, provide quite simple 
prompt for few options. Nothing more, nothing less. So in that sense, it should 
not grow too much.

The problem is, from historical reasons, the boot2 programs are using their own 
personal support functions for IO, and that means that boot loader has some 
duplication of the internal API. Mostly it does not disturb us too much, but 
zfs is complex software and bundling some other features like GELI, does not 
make things more easier. So thats one aspect where the “bloat” is appearing - 
to be able to implement some things, the “thin” implementations are just not 
enough, or some “unexpected” additions are needed.

For the illumos port I actually did something different - I did build one 
single gptzfsboot binary, capable of handling zfs, ufs and pcfs (as those are 
ones needed), and using libstand. Still it does use thin version of keyboard 
input and screen output.

The size of such combined boot2 is (this one is including both skein and edonr):

-r--r--r--   1 root sys   153600 jaan 24 14:08 gptzfsboot

Note, it does not have GELI, so if the same would be done for fbsd, the size 
would be a bit larger because of the crypto functions. But this setup also has 
a bit different strategy;  in case of zfs, the boot2 is *always* installed to 
3.5MB zfs bootblock area and in case of ufs, either boot partition (same idea 
as freebsd-boot) or if the MBR+VTOC schema is used, free space between MBR 
partition and VTOC. Since in most cases the default boot is zfs, it means the 
boot size is not an issue (3.5MB is more than enough;)

rgds,
toomas
___
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: gptzfsboot grew a lot after skein support was added; need knob to control bloat

2017-01-28 Thread Warner Losh 
On Sat, Jan 28, 2017 at 6:43 AM, Julian Elischer  wrote:
> On 28/1/17 4:16 am, Ngie Cooper wrote:
>>>
>>> On Jan 27, 2017, at 09:05, Warner Losh  wrote:
>>
>> ...
>>
>>> I'm curious why you can't find the space for a bigger partition?
>>> Almost all drives these days are partitioned with a little wasted
>>> space, and that wasted space should be more than enough to cover us
>>> here. Also, most drives have a swap partition that can be shrunk a
>>> trivial amount to get space for this...
>>
>> Unfortunately, in my infinite wisdom (IIRC) I put the zfs partition before
>> the swap partition.

So? It literally doesn't matter where the freebsd-boot partition
lives, or what it's number is. You can put it at the start or end of
the swap partition after adjusting its size. I've done this on several
systems...  NanoBSD plays games with this stuff as well to be bootable
on old / new systems.

>> We have a similar problem at work with sys/boot unfortunately, but that's
>> a side discussion for another time/place.
>>
>> Thank you for the idea though -- I'll check when I get back to work.
>
>
> at $JOB we are just testing a script that expands the root zfs partition on
> in-field appliances by shaving a bit off swap and cannibalising a small data
> partition we don't really use. I see we only left 64K for the boot part.
> It's big enough for us for now, but possibly we should fix that as well.
> We have a mirror setup for system disks so we have the ability to take each
> system drive offline one at a time and rearrange it and then re-add the root
> partition to the mirror.
> What are the chances a regular gpt+ZFS (no encrypt) bootblock will grow over
> 64K?

Hard to say. Given boot1/boot2 growth over time, I'd peg that close to 100%.

Warner

>> -Ngie
>> ___
>> freebsd-current@freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>>
>
>
___
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: gptzfsboot grew a lot after skein support was added; need knob to control bloat

2017-01-28 Thread Julian Elischer 

On 28/1/17 1:35 am, Allan Jude wrote:

On 2017-01-27 12:33, Shawn Webb wrote:

On Fri, Jan 27, 2017 at 12:30:17PM -0500, Allan Jude wrote:

On 2017-01-27 12:05, Warner Losh wrote:

On Fri, Jan 27, 2017 at 12:34 AM, Toomas Soome  wrote:

On 27. jaan 2017, at 1:40, Ngie Cooper (yaneurabeya)  
wrote:

Hi,
   I tried upgrading one of my workstations and unfortunately the 
freebsd-boot partition is too small (I follow manpage directions, exactly, and 
those seem to be too small as of 10.3-RELEASE timeframe), and I don???t have 
enough space or ability to resize the partition and make it bigger. So, I???m 
in need of a build knob to control the bloat, and/or having an alternative boot 
loader without geli/skein/crypto support compiled in. Would you be opposed to 
the work?
Thanks,
-Ngie


I do agree that since the geli knob is already there, it may do. Of course we 
also can think of additional knobs, but there is an issue - it wont help just 
to exclude some files, the additional features also do sit in the code, so the 
replacement stubs will be needed, also testing them all over will take some 
time. And the preprocessor spaghetti really is nasty thing to deal with;)

And then there is another issue (partly why I did the feature support in first 
place) - as the kernel does not block user from enabling the features, the user 
can end up facing non-bootable setup which is also not good, as user is using 
perfectly legal options, and still the whole thing is just rendered unusable???

I'm curious why you can't find the space for a bigger partition?
Almost all drives these days are partitioned with a little wasted
space, and that wasted space should be more than enough to cover us
here. Also, most drives have a swap partition that can be shrunk a
trivial amount to get space for this...

Warner


I need to do some testing to make a recipe that works for it, but the
other option is to use the ZFS bootcode area.

ZFS it self, reserves something like 3.5 mb of space in the ZFS
partition, for boot code. This is how we boot ZFS on MBR.

It should be possible to use this on GPT as well, we just don't.

In the future, maybe it'd be a good idea for the installer to leave
more space (a few MB, perhaps?) between the freebsd-boot and
freebsd-swap partitions? At least, for ZFS installs.

Thanks,


The PMBR code has a limitation for 536kb, and it all has to fit under
the 640k barrier, so the current 512kb size is plenty. The issue is some
people are upgrading from systems that were isntalled long ago, when
64kb or less was the default.

with 512K we can append a copy of FreeBSD1.0 on the end of the 
bootblock and leave us the option of bringing up a networked NFS based 
system for debugging.


maybe we could fall back to that after a crash...



___
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: gptzfsboot grew a lot after skein support was added; need knob to control bloat

2017-01-28 Thread Julian Elischer 

On 28/1/17 4:16 am, Ngie Cooper wrote:

On Jan 27, 2017, at 09:05, Warner Losh  wrote:

...


I'm curious why you can't find the space for a bigger partition?
Almost all drives these days are partitioned with a little wasted
space, and that wasted space should be more than enough to cover us
here. Also, most drives have a swap partition that can be shrunk a
trivial amount to get space for this...

Unfortunately, in my infinite wisdom (IIRC) I put the zfs partition before the 
swap partition.

We have a similar problem at work with sys/boot unfortunately, but that's a 
side discussion for another time/place.

Thank you for the idea though -- I'll check when I get back to work.


at $JOB we are just testing a script that expands the root zfs 
partition on in-field appliances by shaving a bit off swap and 
cannibalising a small data partition we don't really use. I see we 
only left 64K for the boot part. It's big enough for us for now, but 
possibly we should fix that as well.
We have a mirror setup for system disks so we have the ability to take 
each system drive offline one at a time and rearrange it and then 
re-add the root partition to the mirror.
What are the chances a regular gpt+ZFS (no encrypt) bootblock will 
grow over 64K?





-Ngie
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"




___
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: CURRENT [r309933] broke syslogd on IPv4 only system

2017-01-28 Thread Hiroki Sato 
Hi,

Alex Deiter  wrote
  in :

al> Hello,
al>
al> Please take a look SVN r309933:

(snip)

al> Successfully tested on IPv4-only CURRENT r312856M.

 Thank you for your report.  r312921 should fix this problem.  Please
 let me know if you still find something wrong with the latest
 version.

-- Hiroki


pgp201AQK1OwO.pgp
Description: PGP signature

CURRENT [r309933] broke syslogd on IPv4 only system

2017-01-28 Thread Alex Deiter 
Hello,

Please take a look SVN r309933:

r309933 | hrs | 2016-12-12 22:33:40 +0300 (Mon, 12 Dec 2016) | 13 lines

- Refactor listening socket list.  All of the listening sockets are
  now maintained in a single linked-list in a transport-independent manner.
- Use queue.h for linked-list structure.
- Use linked-list for AllowedPeers.
- Use getaddrinfo(8) even for Unix Domain sockets.
- Use macros to type-casting from/to struct sockaddr{,_in,_in6}.
- Define fu_* macro for union f_un to shorten the member names.
- Remove an extra #include .
- Add "static" to non-exported symbols.
- !INET support is still incomplete but will be fixed later.

There is no functional change except for some minor debug messages.


After this change syslogd is not listen on local sockets:

# /usr/sbin/syslogd -d
Try (null)
new socket fd is 6
shutdown
sending on socket
Try /var/run/log
Try /var/run/logpriv
off & running
init
loading timezone data via tzset()
. . .

# sockstat | grep syslogd
root syslogd19151 6  udp4   *:514 *:*

# ls -l /var/run/ |grep log
-rw---  1 root   wheel5 Jan 28 14:30 syslog.pid

Root cause:

usr.sbin/syslogd/syslogd.c
. . .
309 #ifdef INET6
310 static int  family = PF_UNSPEC; /* protocol family (IPv4, IPv6 or 
both) */
311 #else
312 static int  family = PF_INET; /* protocol family (IPv4 only) */
313 #endif
. . .
   2856 static int
   2857 socksetup(struct peer *pe)
. . .
2911 if (family != AF_UNSPEC && res->ai_family != family)
   2912 continue;

in case of IPv4-only system (WITHOUT_INET6=YES in /etc/src.conf) we have family 
= PF_INET in 312 line and function socksetup will skip listen on local sockets.

Proposed patch:

Index: syslogd.c
===
--- syslogd.c   (revision 312909)
+++ syslogd.c   (working copy)
@@ -2908,7 +2908,7 @@
/* Only AF_LOCAL in secure mode. */
continue;
}
-   if (family != AF_UNSPEC && res->ai_family != family)
+   if (res->ai_family != AF_LOCAL && res->ai_family != family)
continue;

s = socket(res->ai_family, res->ai_socktype,

Successfully tested on IPv4-only CURRENT r312856M.

Thank you! 

Alex Deiter
alex.dei...@gmail.com



___
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: malloc() call somehow calling the rtld malloc() implementaion

2017-01-28 Thread Don Lewis 
On 27 Jan, Alexander Kabaev wrote:
> On Fri, 27 Jan 2017 10:47:20 -0800 (PST)
> Don Lewis  wrote:
> 
>> On 27 Jan, Alexander Kabaev wrote:
>> > On Fri, 27 Jan 2017 00:31:30 -0800 (PST)
>> > Don Lewis  wrote:  
>> 
>> >> If I create a simple test program that calls malloc() and set a
>> >> breakpoint in malloc(), the breakpoint gets set in the rtld
>> >> version, but the the libc version of malloc is what gets called.
>> >> 
>> >> What the heck is going on here, and how can I fix it?
>> >>   
>> > 
>> > rtld on my system does not have malloc exposed as dynamic symbol, it
>> > cannot possibly be used for symbol resolution by any outside
>> > module.  
>> 
>> Same here, but gdb at least seems to find it anyway.
>> 
>> 12.0-CURRENT r311765M
>> 
>> %nm /libexec/ld-elf.so.1
>> nm: /libexec/ld-elf.so.1: no symbols
>> 
>> %elfdump -s /libexec/ld-elf.so.1 | grep st_name | sort
>>  st_name: 
>>  st_name: 
>>  st_name: FBSD_1.0
>>  st_name: FBSD_1.1
>>  st_name: FBSD_1.2
>>  st_name: FBSD_1.3
>>  st_name: FBSD_1.4
>>  st_name: FBSD_1.5
>>  st_name: FBSDprivate_1.0
>>  st_name: __tls_get_addr
>>  st_name: _r_debug_postinit
>>  st_name: _rtld_addr_phdr
>>  st_name: _rtld_allocate_tls
>>  st_name: _rtld_atfork_post
>>  st_name: _rtld_atfork_pre
>>  st_name: _rtld_error
>>  st_name: _rtld_free_tls
>>  st_name: _rtld_get_stack_prot
>>  st_name: _rtld_is_dlopened
>>  st_name: _rtld_thread_init
>>  st_name: dl_iterate_phdr
>>  st_name: dladdr
>>  st_name: dlclose
>>  st_name: dlerror
>>  st_name: dlfunc
>>  st_name: dlinfo
>>  st_name: dllockinit
>>  st_name: dlopen
>>  st_name: dlsym
>>  st_name: dlvsym
>>  st_name: fdlopen
>>  st_name: r_debug_state
>> 
>> %cd /tmp
>> zipper:/tmp 508%cat malloctest.c 
>> #include 
>> volatile void *p;
>> int
>> main(void) {
>>  p = malloc(16);
>> }
>> %cc -g malloctest.c
>> %gdb a.out
>> GNU gdb 6.1.1 [FreeBSD]
>> Copyright 2004 Free Software Foundation, Inc.
>> GDB is free software, covered by the GNU General Public License, and
>> you are welcome to change it and/or distribute copies of it under
>> certain conditions. Type "show copying" to see the conditions.
>> There is absolutely no warranty for GDB.  Type "show warranty" for
>> details. This GDB was configured as "amd64-marcel-freebsd"...
>> (gdb) break main
>> Breakpoint 1 at 0x40076b: file malloctest.c, line 5.
>> (gdb) run
>> Starting program: /tmp/a.out 
>> 
>> Breakpoint 1, main () at malloctest.c:5
>> 5p = malloc(16);
>> Current language:  auto; currently minimal
>> (gdb) break malloc
>> Breakpoint 2 at 0x80060e9a4: file /usr/src/libexec/rtld-elf/malloc.c,
>> line 163. (gdb) cont
>> Continuing.
>> 
>> Program exited normally.
>> (gdb) quit
>> 
>> Ports gdb finds both the rtld malloc() and the libc malloc():
>> 
>> %/usr/local/bin/gdb a.out
>> GNU gdb (GDB) 7.12 [GDB v7.12 for FreeBSD]
>> Copyright (C) 2016 Free Software Foundation, Inc.
>> License GPLv3+: GNU GPL version 3 or later
>>  This is free software: you are
>> free to change and redistribute it. There is NO WARRANTY, to the
>> extent permitted by law.  Type "show copying" and "show warranty" for
>> details. This GDB was configured as "x86_64-portbld-freebsd12.0".
>> Type "show configuration" for configuration details.
>> For bug reporting instructions, please see:
>> .
>> Find the GDB manual and other documentation resources online at:
>> .
>> For help, type "help".
>> Type "apropos word" to search for commands related to "word"...
>> Reading symbols from a.out...done.
>> (gdb) break main
>> Breakpoint 1 at 0x40076b: file malloctest.c, line 5.
>> (gdb) run
>> Starting program: /tmp/a.out 
>> 
>> Breakpoint 1, main () at malloctest.c:5
>> 5p = malloc(16);
>> (gdb) break malloc
>> Breakpoint 2 at 0x80060e9a4: malloc. (2 locations)
>> (gdb) cont
>> Continuing.
>> 
>> Breakpoint 2, __malloc (size=16) at jemalloc_jemalloc.c:1636
>> 1636 size_t usize JEMALLOC_CC_SILENCE_INIT(0);
> 
> gdb looks into debugging info for symbols in debug information and so
> has greater visibility. Symbols gdb sees play no role in dynasmic
> building, so rtld malloc somehow replacing the malloc from the program
> as you suspected is really impossible.

What threw me off here was that ld-elf.so is stripped, so I didn't think
that it had debug symbols available.  I'd forgotten that we now install
.debug files for the base system executables and shared libraries.

> kib@ has a better idea that is worth investigating further: is the
> address on which idlc traps corresponds to TLS storage? tls alloc calls
> are supposed to respect the tls section alignment though.

Once I had ports gdb available in the jail so that I could set
breakpoints in both versions of malloc(), I was

Re: malloc() call somehow calling the rtld malloc() implementaion

2017-01-28 Thread Don Lewis 
On 27 Jan, Konstantin Belousov wrote:
> On Fri, Jan 27, 2017 at 12:19:16PM -0500, Alexander Kabaev wrote:
>> On Fri, 27 Jan 2017 00:31:30 -0800 (PST)
>> Don Lewis  wrote:

>> > If I create a simple test program that calls malloc() and set a
>> > breakpoint in malloc(), the breakpoint gets set in the rtld version,
>> > but the the libc version of malloc is what gets called.
>> > 
>> > What the heck is going on here, and how can I fix it?
>> > 
>> 
>> rtld on my system does not have malloc exposed as dynamic symbol, it
>> cannot possibly be used for symbol resolution by any outside module.
> 
> Sure.
> 
> Also, the fact that rtld internal malloc is called does not mean that it
> is called by the application. There is no backtrace which would describe
> the reason for rtld allocating memory in reported cases. Generally,
> rtld needs memory for TLS allocation (the program is definitely linked
> with libthr, and even libc uses TLS), and, of course, to create data
> structures to track dlopen-ed objects.

After adding ports gdb as a RUN_DEPENDS so that it gets installed in the
poudriere jail that I was using for debugging, I can confirm that this
is exactly what is happening.  All of the calls to the rtld version of
malloc() happened before main() was entered.  Starting slightly before
the start of main() and continuing until the eventual SIGBUS, all of the
malloc() calls were to the version in libc.


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