Re: [PATCH] fix bitmap corruption on close_range() with CLOSE_RANGE_UNSHARE

Linus Torvalds
2024-08-06T00:04:25Z

On Mon, 5 Aug 2024 at 16:45, Al Viro <viro@zeniv.linux.org.uk> wrote:
>
> So... do we really need that indirect? The problem would be
> seeing ->max_fds update before that of the array pointers.

The reason is simply so that we can have one single allocation.

In fact, quite often, it's zero allocations when you can use the
'struct fdtable fdtab' that is embedded in 'struct files_struct'. But
the 'struct fdtable' was a convenient way to allocate all those
bitmaps _and_ the 'struct file *' array all together.

That said, I agree that we could just then put the pointers to said
single allocation right into 'struct files_struct'. So the actual
indirection after the allocation is pointless.

And yes, I think it's entirely a historical artifact of how that thing
grew to be. Long long long ago there was no secondary allocation at
all, and MAX_OPEN was fixed at 20.

Because dammit, twenty open files is all you ever really need, and all
the bitmaps fit comfortably in one single word even on 32-bit
machines.

Those were the days.

Linus