On Wed, Aug 12, 2026 at 2:22 AM Kees Cook <[email protected]> wrote: > On Tue, Aug 11, 2026 at 05:42:05PM +0200, Jann Horn wrote: > > On Tue, Aug 11, 2026 at 2:16 AM Kees Cook <[email protected]> wrote: > > > On Mon, Aug 10, 2026 at 08:41:13PM +0000, Bill Wendling wrote: > > > > +static void fdtable_test_alloc(struct kunit *test) > > > > +{ > > > > + struct fdtable *fdt; > > > > + unsigned int slots = 64; > > > > + > > > > + fdt = alloc_fdtable(slots); > > > > + KUNIT_ASSERT_NOT_ERR_OR_NULL(test, fdt); > > > > + > > > > + /* Check that max_fds is set correctly and is >= slots */ > > > > + KUNIT_EXPECT_GE(test, fdt->max_fds, slots); > > > > + > > > > + /* Check that fd is allocated */ > > > > + KUNIT_EXPECT_NOT_ERR_OR_NULL(test, fdt->fd); > > > > > > Nice to add these tests! Can you add one for each of the conditionals > > > in alloc_fdtable (e.g. ENOMEM, EMFILE, and the power-of-two rounding-up > > > logic, etc)? > > > > Wouldn't tests for stuff like the rounding-up logic get into > > implementation details too much, and break if implementation choices > > change? > > It seemed to me like we'd want to notice if that behavior changed?
Why? File descriptor tables are often power-of-two sized, but they aren't always. That is an implementation choice that doesn't impact correctness, it just affects performance somewhat. So I don't see what the point of a test for this would be - it seems like it would just be in the way of making changes, a "Change-Detector Test"?
