On 8/7/26 10:30, Mark Johnston wrote:
On Thu, Aug 06, 2026 at 04:52:55PM -0600, Alan Somers wrote:
On Tue, Aug 4, 2026 at 4:06 PM Mark Johnston <[email protected]> wrote:
On Tue, Aug 04, 2026 at 01:33:40PM -0600, Alan Somers wrote:
On Tue, Aug 4, 2026 at 1:00 PM Alan Somers <[email protected]> wrote:
On Tue, Aug 4, 2026 at 12:58 PM Mark Johnston <[email protected]> wrote:
On Mon, Aug 03, 2026 at 07:13:08PM +0000, Alan Somers wrote:
The branch main has been updated by asomers:
URL:
https://cgit.FreeBSD.org/src/commit/?id=4bd01d6ae01632501b63438b8d9a401db9744a78
commit 4bd01d6ae01632501b63438b8d9a401db9744a78
Author: Jitendra Bhati <[email protected]>
AuthorDate: 2026-06-12 17:07:55 +0000
Commit: Alan Somers <[email protected]>
CommitDate: 2026-08-03 19:12:28 +0000
fts: refactor to use fd-relative operations internally
Replace all _open() calls with _openat() in __fts_open(), fts_read(),
and fts_children(). Replace statfs() with _fstatfs().
Add fts_dirfd to struct _ftsent, set to the file descriptor of the
parent directory. Callers can use openat(ent->fts_dirfd, ent->fts_name,
...) to access files safely without relying on fts_accpath, which
enables programs in capability mode to open the files described by
_ftsent.
This is a preparatory change for fts_openat() which will allow callers
to provide a pre-opened directory fd, enabling fts(3) traversal inside
Capsicum capability mode.
Mirror all fts_open() changes to fts_open_b().
As a result of expanding _ftsend, publish new ELF symbol versions for
fts_openat and related functions.
Sponsored by: Google LLC (GSoC 2026)
Reviewed by: asomers
Pull Request: https://github.com/freebsd/freebsd-src/pull/2303
Quite a few regression tests seem to be failing after this commit, e.g.,
some of the makefs tests:
https://ci.freebsd.org/job/FreeBSD-main-amd64-test/29201/
I'm testing a fix now. I should have something ready for you soon.
The fix is committed now, as 74bd6fb1eb02 . Sorry for the trouble.
Thanks, but I think there are still some problems. I'm still seeing
vnode exhaustion while running the test suite.
First, fts_build() appears to dup() the directory entry into every
single(!) child FTS entry. That's slow and means that we'll potentially
acquire a large number of fds when traversing a wide directory, enough
to hit per-process fd limits. Second, the return value from dup() is
not checked, and it's not clear to me whether that's handled elsewhere.
Finally, I'm fairly sure these dup()ed fds are leaked in various places;
for instance, isn't fts_lfree() potentially leaking the dirfd of each
entry it frees?
The first and last issues are probably straightforward to fix, but I'm
not sure about the second one. I don't think FTS can reasonably consume
an fd for every entry in a directory, that's going to cause a lot of
problems.
Hi,
Can we go ahead and back this out until the outstanding issues are
resolved, please?
Thanks,
Kyle Evans
