sys/net/if_lagg_test:status_stress can lead to use-after-free in main (both before and after stable/14 was created), at least on aarch64
See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273081#c5 and the backtrace in the prior comment. The test context is aarch64. Kyle Evans provided a kgdb patch for devel/gdb for aarch64 that that finally let me track this down to the level of detail on how to interpret the register values reported vs. what code involved using the value. I will say that I've not managed to produce the crash with 14.0-BETA1. But I have produced the crash in my personal non-debug kernel builds and with the main snapshots dd'd to media and booted and used. === Mark Millard marklmi at yahoo.com
Re: Continually count the number of open files
On 12 Sep 2023, at 17:19, Bakul Shah wrote: > > FreeBSD > should add inotify. inotify is also probably not the right thing. If someone is interested in adding this, Apple’s fsevents API is a better inspiration. It is carefully designed to ensure that the things monitoring for events can’t ever block filesystem operations from making progress. I think there’s a nice design possible with a bloom filter in the kernel of events that ensures that monitors may get spurious events but don’t miss out on anything. On macOS because files have a stronger idea of which directory they live in and so it’s easier to have an API that notifies for changes to files in a directory. inotify monitors individual files but loses notifications if you write through the wrong hard link to a file (hard link foo from a/foo to b/foo, use inotify to watch a, write though b/foo, observe no notification). I think the right kernel API would walk the directory and add the vnodes to a bloom filter and trigger a notification on a match in the filter. You’d then have occasional spurious notifications but you’d have something that could be monitored via kqueue and could be made to not block anything else in the kernel. If anyone is interested in improving the current kqueue code here: there’s currently no mechanism for tracking when the last writable file descriptor for a file has been closed, which is useful for consuming files that are dropped via sftp or similar. NOTE_CLOSED_WRITE is hard to use without race conditions and tells you only that *a* file descriptor with write permission has closed, not that the last one has closed. I’m currently resorting to a process that runs as root that uses libprocstat to walk the entire list of open file descriptors and report that they’re closed, which is incredibly suboptimal. David
Re: Continually count the number of open files
On Sep 12, 2023, at 11:59 PM, Graham Perrin wrote: > > (I'm a tcsh user, I can easily 'sh' before running the command.) You can switch to zsh. Most of csh/tcsh + sh + many more features. > baloo is not used in 273669. It certainly feels like an inotify like use or a file-descr leak. The bug reporter can try "procstat fd " on running processes to see which one has all those open files. Another thing worth trying is to run under ktrace -di to see which syscalls were made.
Re: Continually count the number of open files
On Wed, 13 Sep 2023 11:52:19 -0700 Bakul Shah wrote: > On Sep 12, 2023, at 11:59 PM, Graham Perrin wrote: > > > > (I'm a tcsh user, I can easily 'sh' before running the command.) > > You can switch to zsh. Most of csh/tcsh + sh + many more features. > > > baloo is not used in 273669. > > It certainly feels like an inotify like use or a file-descr leak. > The bug reporter can try "procstat fd " on running processes > to see which one has all those open files. Another thing worth > trying is to run under ktrace -di to see which syscalls were made. Additional note. For emergency I heve a line below in ~/.tcshrc.mine and a flag file ~/.Use_zsh. This way, you can switch back to tcsh by deleting the flag file whenever you want. No need to update master.passwd entry, as the login shell itself is still tcsh and zsh is `exec`'ed from tcsh. if ( -X zsh && -f ~/.Use_zsh ) exec zsh -- Tomoaki AOKI
Re: git: 8d49fd7331bc - main - pf: remove DIOCGETRULE and DIOCGETSTATUS : net/py-libdnet and net/scapy now broken, kyua test suite damaged
This change leads the port net/py-libdnet to be broken:
--- fw-pf.lo ---
fw-pf.c:212:22: error: use of undeclared identifier 'DIOCGETRULE'
if (ioctl(fw->fd, DIOCGETRULE, &pcr) == 0 &&
^
fw-pf.c:252:22: error: use of undeclared identifier 'DIOCGETRULE'
if (ioctl(fw->fd, DIOCGETRULE, &pcr) == 0 &&
^
--- intf.lo ---
for (cnt = 0; !matched && cnt < (int) entry->intf_alias_num; cnt++) {
^
intf.c:571:2: note: previous statement is here
if (entry->intf_addr.addr_type == ADDR_TYPE_IP &&
^
--- fw-pf.lo ---
fw-pf.c:296:28: error: use of undeclared identifier 'DIOCGETRULE'
if ((ret = ioctl(fw->fd, DIOCGETRULE, &pr)) < 0)
^
3 errors generated.
That leads to:
[00:00:41] [29] [00:00:26] Finished net/py-libdnet@py39 | py39-libdnet-1.13_4:
Failed: build
[00:00:42] [29] [00:00:27] Skipping net/scapy@py39 | py39-scapy-2.5.0_1:
Dependent port net/py-libdnet@py39 | py39-libdnet-1.13_4 failed
net/scapy is used by parts of the kyua testsuite (when installed,
anyway). So the kyua testsuite is now has damaged functionality
on main [so: 15].
===
Mark Millard
marklmi at yahoo.com
