Re: A field in files_struct has been used without initialization
From: Al Viro
Date: Sun Oct 09 2022 - 14:21:43 EST
On Fri, Oct 07, 2022 at 08:16:11PM +0100, Al Viro wrote:
> array of pointers (from first kvmalloc() in alloc_fdtable()): contains file pointers
> array of unsigned long (from the second kmvalloc() there): hosts the bitmaps
> fdtable (allocated in alloc_fdtable()):
> open_fds points to the beginning of bitmap-hosting array
> close_on_exec points to the middle third of the same array
> full_fd_bits points to the last third of the same array
Rereading that... a bit of clarification: the wording would seem to imply
that these 3 bitmaps are of equal size; they are not - the third one is
smaller.
If fdt->max_fds (table capacity) is equal to N, we have
* N struct file pointers in fdt->fd[]
* N bits in fdt->open_fds[] (i.e. N/BITS_PER_LONG unsigned long)
* N bits in fdt->close_on_exec[] (ditto)
* N/BITS_PER_LONG bits in fdt->full_fd_bits[]
The meaning of bitmaps:
bit k set in open_fds[] - descriptor k is in use
bit k set in close_on_exec[] - descriptor k is to be closed on exec()
bit k set in full_fd_bits[] - all descriptors covered by open_fds[k]
(i.e. BITS_PER_LONG of them,, starting from k * BITS_PER_LONG) are in use.
In other words, "don't even bother looking for clear bits in open_fds[k];
there won't be any".
->full_fd_bits[] is there purely as a way to speed finding unused descriptors,
along with ->next_fd. Some processes have an obscene amount of opened
descriptors and linear search through the mostly full bitmap can get painful.
E.g. 4 millions of descriptors would mean half megabyte worth of bitmap
(in ->open_fds[]). Cheaper to search through 8Kb of ->full_fd_bits, then
check one 64bit word in ->open_fds[]; kinder on the cache as well...