diff options
| author | Al Viro <viro@zeniv.linux.org.uk> | 2025-08-26 17:27:47 -0400 |
|---|---|---|
| committer | Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 2025-08-28 16:22:59 +0200 |
| commit | 6ca3f8a9c442243918bb1f1f2f375b4dd68b6e4a (patch) | |
| tree | dd9e108f120263581e6759282743c3ab1a242df1 /security | |
| parent | 7b8b503c06274ef3c6c1a107743f1ec0d0a53ef8 (diff) | |
| download | linux-6ca3f8a9c442243918bb1f1f2f375b4dd68b6e4a.tar.gz linux-6ca3f8a9c442243918bb1f1f2f375b4dd68b6e4a.tar.bz2 linux-6ca3f8a9c442243918bb1f1f2f375b4dd68b6e4a.zip | |
alloc_fdtable(): change calling conventions.
[ Upstream commit 1d3b4bec3ce55e0c46cdce7d0402dbd6b4af3a3d ]
First of all, tell it how many slots do we want, not which slot
is wanted. It makes one caller (dup_fd()) more straightforward
and doesn't harm another (expand_fdtable()).
Furthermore, make it return ERR_PTR() on failure rather than
returning NULL. Simplifies the callers.
Simplify the size calculation, while we are at it - note that we
always have slots_wanted greater than BITS_PER_LONG. What the
rules boil down to is
* use the smallest power of two large enough to give us
that many slots
* on 32bit skip 64 and 128 - the minimal capacity we want
there is 256 slots (i.e. 1Kb fd array).
* on 64bit don't skip anything, the minimal capacity is
128 - and we'll never be asked for 64 or less. 128 slots means
1Kb fd array, again.
* on 128bit, if that ever happens, don't skip anything -
we'll never be asked for 128 or less, so the fd array allocation
will be at least 2Kb.
Reviewed-by: Christian Brauner <brauner@kernel.org>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Diffstat (limited to 'security')
0 files changed, 0 insertions, 0 deletions
