[Bug 265463] sh crashes during fuzz testing

2022-07-27 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265463

--- Comment #1 from Evgeniy  ---
Created attachment 235502
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=235502&action=edit
Forgot to put db

-- 
You are receiving this mail because:
You are the assignee for the bug.


[Bug 229745] ahcich: CAM status: Command timeout

2022-07-27 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229745

Daniel Menelkir  changed:

   What|Removed |Added

 CC||dmenel...@gmail.com

--- Comment #66 from Daniel Menelkir  ---
(In reply to Chris from comment #64)
Try smartctl with a USB (archlinux ISO have smartmontools afaik), or even
Hirens BootCD (it's a mini windows with some tools if you're not familiar).
(In reply to Andriy Gapon from comment #65)
I don't think it's TRIM since I have the issues with two HDDs with different
brands/speeds.

-- 
You are receiving this mail because:
You are the assignee for the bug.


[Bug 229745] ahcich: CAM status: Command timeout

2022-07-27 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229745

--- Comment #67 from Chris  ---
In reply to Daniel (comment #66)

Smartmontools are available on FreeBSD. The drives show no issue with the
smartmontools. I believe there is a compatibility issue between the drives and
the motherboard. I updated the BIOS and firmware on the server which didn't
help.

-- 
You are receiving this mail because:
You are the assignee for the bug.


[Bug 258056] sys/fs/fuse: commit 7b8622fa22 breaks net/rclone mount

2022-07-27 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=258056

Keith White  changed:

   What|Removed |Added

 Attachment #235480|0   |1
is obsolete||
 Attachment #235481|0   |1
is obsolete||

--- Comment #18 from Keith White  ---
Created attachment 235506
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=235506&action=edit
lang/go118 special case /dev/fuse on FreeBSD

As suspected by asomers last year, go itself makes assumptions about what it
can do with opened files.  The attached patch makes "/dev/fuse" unpollable, and
is probably much closer to "the right thing" to do.

This go patch returns "rclone mount" functionality.

-- 
You are receiving this mail because:
You are the assignee for the bug.


[Bug 258056] sys/fs/fuse: commit 7b8622fa22 breaks net/rclone mount

2022-07-27 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=258056

--- Comment #19 from Alan Somers  ---
The whole point of 7b8622fa220b9c08041102f638f848c48e022644 was to make
/dev/fuse pollable.  It is pollable now, in other languages.  So there's
probably still a bug somewhere in the Go code.  Does Go wrongly assume that the
file is ready to read if it polls ready to write?

-- 
You are receiving this mail because:
You are the assignee for the bug.


[Bug 229745] ahcich: CAM status: Command timeout

2022-07-27 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229745

--- Comment #68 from Daniel Menelkir  ---
(In reply to Chris from comment #67)
I know, I mean to try different platforms. 
And to mention, this is an specific issue with 13.1+ZFS, I don't think it's
something of the motherboard itself, since this issue is only happens (for now)
on FreeBSD 13.1 with ZFS, since I had it in two different machines. If I use
the disk for anything else, this doesn't happens.

-- 
You are receiving this mail because:
You are the assignee for the bug.


[Bug 258056] sys/fs/fuse: commit 7b8622fa22 breaks net/rclone mount

2022-07-27 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=258056

--- Comment #20 from Keith White  ---
Not an issue for you!

I think the issue is how go itself "thinks" kqueue works with a file or device.

The comments in src/os/file_unix.go would seem to indicate that files that are
always ready to write are a problem for go's poll code.  It already special
cases regular files:

// Don't try to use kqueue with regular files on *BSDs.
// On FreeBSD a regular file is always
// reported as ready for writing.

-- 
You are receiving this mail because:
You are the assignee for the bug.


[Bug 265466] Shutdown Causes System Reboot on FreeBSD 13

2022-07-27 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265466

Bug ID: 265466
   Summary: Shutdown Causes System Reboot on FreeBSD 13
   Product: Base System
   Version: 13.1-STABLE
  Hardware: amd64
OS: Any
Status: New
  Severity: Affects Some People
  Priority: ---
 Component: misc
  Assignee: b...@freebsd.org
  Reporter: njm...@gmail.com

On FreeBSD 13.0, when I try to shut down one of my servers using the Web UI
and/or console, the server reboots 5 - 10 seconds after it powers off.  This
behavior was/is not present in FreeBSD 12.  Furthermore, this same issue occurs
in TrueNAS Core 13, but not TrueNAS Core 12.  The server specs are as follows:

Intel R2000 Chasis
Intel S2600GZ Motherboard
2 x Intel Xeon E5-2630L v2
2 x 16GB (32GB Total) ECC DDR3
Intel RMS25JB080 (LSI 2008) Flashed to IT
Boot Pool: 2 x Intel DC S3610 SSDs (Mirrored)
Storage Pool: 12 x 4TB HGST HUS724040ALS640 (6 drives per vdev, RaidZ2)


I originally created a thread about this in the TrueNAS community forum, and
another user (also running an Ivy Bridge CPU) posted they had experienced the
same problem.

https://www.truenas.com/community/threads/shutdown-causes-reboot-on-truenas-core-13-0-u1.102752/#post-706976

I have also reported this issue to iXSystems/TrueNAS:
https://ixsystems.atlassian.net/browse/NAS-117384

-- 
You are receiving this mail because:
You are the assignee for the bug.


[Bug 229745] ahcich: CAM status: Command timeout

2022-07-27 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229745

--- Comment #69 from Chris  ---
(In reply to Daniel Menelkir from comment #68)
The issue happens with 12 as well and requires vfs.zfs.cache_flush_disable=1
and a power cycle to clear. 

I don't think it's a just a ZFS issue since a reboot just doesn't clear it. The
system runs great with different disks. Using another OS or a different file
system isn't an option for me and I don't have another system to replace it to
continue running tests.

-- 
You are receiving this mail because:
You are the assignee for the bug.


[Bug 258056] sys/fs/fuse: commit 7b8622fa22 breaks net/rclone mount

2022-07-27 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=258056

--- Comment #21 from Keith White  ---
(In reply to Keith White from comment #20)
For more background reading.

It looks like the go bug report 19093 (referenced in src/os/file_unix.go) gives
more detail as to what go "assumes" and why regular BSD files were removed from
polling.
  https://github.com/golang/go/issues/19093

Polling was added in change 36800 which explains, somewhat, what's expected and
why go's polling doesn't work on all filetypes on all OSes?
https://go-review.googlesource.com/c/go/+/36800/

-- 
You are receiving this mail because:
You are the assignee for the bug.


[Bug 258056] lang/go118: musn't poll /dev/fuse

2022-07-27 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=258056

Alan Somers  changed:

   What|Removed |Added

Summary|sys/fs/fuse: commit |lang/go118: musn't poll
   |7b8622fa22 breaks   |/dev/fuse
   |net/rclone mount|

--- Comment #22 from Alan Somers  ---
So it sounds like they assume that regular files will always poll readable (not
true for /dev/fuse) and anything that isn't a socket or a pipe will fail when
you try to register it with kqueue/epoll (true for /dev/fuse until commit
7b8622fa220b9c08041102f638f848c48e022644).  And since regular files are special
cased on *BSD and fail to register with epoll, the poller code never worked for
them.  In that case I'd say that your change is the correct one.

The change looks correct to me, though I haven't tested it.  Please submit it
upstream too.

-- 
You are receiving this mail because:
You are the assignee for the bug.


[Bug 262743] Memory leak in security/strongswan's charon daemon when communicating over vici socket.

2022-07-27 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262743

--- Comment #5 from Michał Skalski  ---
Thank you very much for the clues


(In reply to Mark Millard from comment #4)

Yes, using default value 12 (I used stock qemu VM image):

# sysctl vm.pageout_oom_seq
vm.pageout_oom_seq: 12




(In reply to Kubilay Kocak from comment #3)


Result of `uname -a` (vm image FreeBSD-13.1-RELEASE)|

FreeBSD freebsd 13.1-RELEASE FreeBSD 13.1-RELEASE
releng/13.1-n250148-fc952ac2212 GENERIC  amd64


and the same is for:

FreeBSD freebsd 13.1-RELEASE FreeBSD 13.1-RELEASE
releng/13.1-n250148-fc952ac2212 GENERIC  arm64


Indeed, the packaged version (strongswan-5.9.6_2, either installed from binary
package or built from ports) behaves different. Still memory usage increases,
but only RSS one (VMS does not change in observable period) and in much lower
scale, raise is rather logarithmic than linear.

I compared then configure options for strongswan port and among other
differences `--with-printf-hooks=builtin` option is specified by default for
the port version. 


So I tested again sources of strongswan 5.9.6 - the same as used for ports and
when the strongswan is configured with:

./configure --disable-kernel-netlink --enable-kernel-pfroute
--enable-kernel-pfkey --disable-gmp --enable-openssl \
--enable-mediation --disable-scripts --with-group=wheel
--enable-gcm --enable-ccm --enable-pkcs11 \
--with-printf-hooks=builtin


(only `--with-printf-hooks=builtin` is added) the memory usage is similar to
packaged version even for unpatched original sources. Without this option (or
when port version is compiled with `libc` printf-hook which I believe is
default one) memory usage raises quickly as in this bug report.


I must have missed that on previous tests, I didn't notice that VMS does not
rise, and RSS raises on much smaller scale.
Also checked for `printf-hooks=vstr` and it is memory usage increase is
slightly bigger than for `builtin`, but still VMS is constant.

I'm still not sure if for `printf-hooks=builtin` memory does not raise too
much, I will check it.

-- 
You are receiving this mail because:
You are the assignee for the bug.


[Bug 253445] bectl: does not function in two-level zfs datasets

2022-07-27 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253445

--- Comment #38 from Jonathan Vasquez  ---
I've converted my existing one layer set up to a two layer one so I now have
the option of either using bectl or doing the snapshotting/cloning myself, and
still be compatible with the boot environment feature in the loader. I've also
updated my guide recommendation accordingly:
https://xyinn.org/md/freebsd/zfs_manual_partition_encrypted

previous layout (all 'canmount' options were 'on'):

tank
tank/os <- this would have a mountpoint set to /
tank/home <- /home

new layout

tank
tank/os <- canmount=off, mountpoint=none
tank/os/main <- main / dataset, canmount=noauto, mountpoint=none
tank/home <- /home

I can now either manually do a:

zfs snapshot tank/os/main@test
zfs clone tank/os/main@test tank/os/test

and reboot and select "tank/os/test" in the bootloader's boot environment
selection, and if it's good I can do a promotion and a deletion and set
'bootfs' on my pool accordingly if needed

or I can do 'bectl create test' and 'bectl activate test'.

I still think this feature is useful but not as high priority for me anymore..
I do prefer my new slightly modified layout :).

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug 262743] Memory leak in security/strongswan's charon daemon when communicating over vici socket.

2022-07-27 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262743

--- Comment #6 from Mark Millard  ---
(In reply to Michał Skalski from comment #5)

Use of the likes of vm.pageout_oom_seq=120 should delay any kills for
failures to reclaim enough memory to reach FreeBSD's target figure
for free RAM.

This can get extra time to inspect/investigate evidence about the
on-going memory/RAM usage.


Note: Using an increased vm.pageout_oom_seq is useful for avoiding
failed-to-reclaim kills only for bounded-duration "stays running"
activities. This can allow buildworld buildkernel -j4 on Small
Board Computers with 4 cores and only 2 GiBytes of RAM, for
example, when using the default tends to suffer failed-to-reclaim
kills.)


Note: In sufficiently modern variants of FreeBSD the messages
about kills were improved and no longer always report being
out of available swap space as the reason for the kill. The
messaging about reclaim failures is an example of the
improved messaging. Reclaim failures can happen even with
a swap space being configured but little/none of the swap space
being put to use. All it takes is one process (or m ore) that
stays runnable while keeping nearly all the RAM pages in the
active state (so: unable to be reclaimed). Even now, if a
FreeBSD is modern enough to have the failed-to-reclaim
message, if the message reports "out of swap" as the reason
for a kill, the message is somewhat of a misnomer, in that
kernel data structures for managing the swap areas ran out of
space (internal fragmentation?), not the swap media.

Note: My references to "stays running" presume leaving the kernel
configured to allow process kernel stacks to be swapped out when
a process has not stayed runnable. FreeBSD does not do such
swap outs for processes that are runnable at the time.

-- 
You are receiving this mail because:
You are the assignee for the bug.


[Bug 258056] lang/go118: musn't poll /dev/fuse

2022-07-27 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=258056

--- Comment #23 from Keith White  ---
Added upstream as https://github.com/golang/go/issues/54100

Assuming it gets noticed and incorporated, this FreeBSD bug could be "closed"
or changed to "not an issue..."

Thanks asomers for all your hints, support, etc.!

-- 
You are receiving this mail because:
You are the assignee for the bug.


[Bug 265471] loader: /boot/lua/menu.lua boots kernel from original bootenv when bootenv is changed

2022-07-27 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265471

Bug ID: 265471
   Summary: loader: /boot/lua/menu.lua boots kernel from original
bootenv when bootenv is changed
   Product: Base System
   Version: 13.1-RELEASE
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Some People
  Priority: ---
 Component: kern
  Assignee: b...@freebsd.org
  Reporter: crah...@gmail.com

Created attachment 235516
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=235516&action=edit
Unload any previously loaded kernel when changing boot environment.

Related to a bug fixed by Kyle Evans  in commit
e414851f3eb7a9dd2af8209eac4ada307cb6ff8e, if a password is set for the loader,
when the boot environment is changed in the lua menu, the kernel originally
loaded before the menu was brought up is booted in the new boot environment.

Since the kernel directory isn't mounted, this prevents modules from being
loaded during boot.  In addition, if the reason for using the boot environment
is to provide a known good kernel and environment, well...

I've attached a patch.

-- 
You are receiving this mail because:
You are the assignee for the bug.


[Bug 265472] /boot/loader: lua autoboot timer restarts if menu password is set

2022-07-27 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265472

Bug ID: 265472
   Summary: /boot/loader: lua autoboot  timer restarts if menu
password is set
   Product: Base System
   Version: 13.1-RELEASE
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Some People
  Priority: ---
 Component: kern
  Assignee: b...@freebsd.org
  Reporter: crah...@gmail.com

Created attachment 235517
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=235517&action=edit
After interrupting the autoboot timeout, prevent it from restarting.

In the lua loader, if one sets a password in loader.conf, the autoboot_delay
timer will start before the menu is displayed.  One can interrupt the autoboot
and bring up the menu by entering a keyboard character before the timer
expires.

If this is done a prompt for the password is displayed.  Entering the password
will bring up the menu, but the timer will again start and another keyboard
character must be entered or autoboot will abort the menu and boot the system.

This is unexpected and not useful.

A patch to correct the problem is attached.

-- 
You are receiving this mail because:
You are the assignee for the bug.


[Bug 265471] loader: /boot/lua/menu.lua boots kernel from original bootenv when bootenv is changed

2022-07-27 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265471

crah...@gmail.com changed:

   What|Removed |Added

 Attachment #235516|0   |1
is obsolete||

--- Comment #1 from crah...@gmail.com ---
Created attachment 235518
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=235518&action=edit
Unload any previously loaded kernel when changing boot environment.

Too much C, not enough Lua.

-- 
You are receiving this mail because:
You are the assignee for the bug.


[Bug 229745] ahcich: CAM status: Command timeout

2022-07-27 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229745

--- Comment #70 from Daniel Menelkir  ---
(In reply to Chris from comment #69)
A zpool error isn't supposed to clear with a reboot. The test I've mentioned
can be done with a live USB.

-- 
You are receiving this mail because:
You are the assignee for the bug.


[Bug 229745] ahcich: CAM status: Command timeout

2022-07-27 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229745

--- Comment #71 from Chris  ---
(In reply to Daniel Menelkir from comment #70)
I didn't get any zpool errors. The system was hanging with cam status timeouts. 

Since I changed the disks the performance of the system improved considerably.

-- 
You are receiving this mail because:
You are the assignee for the bug.