[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20251203133854.GB1827@brightrain.aerifal.cx>
Date: Wed, 3 Dec 2025 08:38:55 -0500
From: Rich Felker <dalias@...c.org>
To: Neeraj Sharma <neerajsharma.live@...il.com>
Cc: musl@...ts.openwall.com
Subject: Re: Re: Potential bug in musl in nftw implementation
On Wed, Dec 03, 2025 at 01:04:05PM +0530, Neeraj Sharma wrote:
> On Wed, Dec 3, 2025 at 11:21 AM Neeraj Sharma
> <neerajsharma.live@...il.com> wrote:
> >
> > While evaluating fil-c [1], I noticed a strange issue with a sample C code to list folders and files with sizes (code enclosed below). I used fil-c [1] with musl, but compared the output with stock clang-17, gcc and noticed a difference in output on my system. After much investigation and validation I have come to realize a potential issue with musl nftw implementation. I have not come around finding the actual issue, but reporting this nonetheless in case someone else knows about this or is facing similar issues.
> >
>
> I have identified a bug in nftw.c implementation within musl. At least
> to the extent I understand the functionality of nftw as described
> within https://linux.die.net/man/3/nftw
>
> Line 74 in `musl-1.2.5.orig/src/misc/nftw.c` is the issue. It closes
> the file descriptor and leaves it there. Irrespective continuing
> further without any other action seems incorrect anyways. This means
> that further folder traversal is not done. I confirmed this analysis
> by increasing the value of fd_limit in my calling code (dirworth.c)
> and this time around the undiscovered file earlier was now discovered.
>
> ```
> 70 if (type == FTW_D || type == FTW_DP) {
> 71 dfd = open(path, O_RDONLY);
> 72 err = errno;
> 73 if (dfd < 0 && err == EACCES) type = FTW_DNR;
> 74 if (!fd_limit) close(dfd);
> 75 }
> ```
>
> Modified dirworth.c code which worked for my folder depth.
>
> ```c
> // this works because my fd_limit is higher, which was earlier 10
> nftw(dirpath, process_entry, 20, FTW_PHYS | FTW_DEPTH
> ```
Are you saying you'd deem it a better behavior to return with an error
when it can't traverse within the fd limit, instead of skipping
descent past what it can do within the limit?
That's probably more correct. My understanding is that historically,
the limit was a depth limit, but POSIX repurposed it into a "fd limit"
with an expectation that implementations somehow do the traversal with
fewer fds than the depth if the limit is exceeded (or error out?).
Trying to actually do it seems error-prone (requires unbounded working
space that grows with size of a single directory, vs growth only with
depth for fds, and involves caching potentially-stale data) but maybe
just erroring so the caller knows to use a larger limit would be the
right thing to do here...?
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
