Re: git: 4bd01d6ae016 - main - fts: refactor to use fd-relative operations internally

On Mon, Aug 10, 2026 at 8:58 AM Alan Somers <asomers@freebsd.org> wrote:
>
> On Mon, Aug 10, 2026 at 8:26 AM Kyle Evans <kevans@freebsd.org> wrote:
> >
> > 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 <markj@freebsd.org> 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 <asomers@freebsd.org> wrote:
> > >>>>>
> > >>>>> On Tue, Aug 4, 2026 at 12:58 PM Mark Johnston <markj@freebsd.org> 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 <bhatijitendra2022@gmail.com>
> > >>>>>>> AuthorDate: 2026-06-12 17:07:55 +0000
> > >>>>>>> Commit:     Alan Somers <asomers@FreeBSD.org>
> > >>>>>>> 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
>
> The "too many open file descriptors" problem should be fixed by
> https://github.com/freebsd/freebsd-src/pull/2360 , and I'm doing the
> final pre-commit testing of that PR right now.

"Too many open files" should be fixed in revision dd532ad133 .