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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 5 Aug 2024 at 16:45, Al Viro <viro@xxxxxxxxxxxxxxxxxx> 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




[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [NTFS 3]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [NTFS 3]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux