Re: A field in files_struct has been used without initialization

[Al Viro <viro@zeniv.linux.org.uk>]

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...