On 5/6/2025 7:50 PM, Jake Freeland wrote:
It is possible for rte_fbarray_find_next_n_free() to misreport that there
are n contiguous open spots. If we need two contiguous entries for a
hole, make sure that we're not indexing out-of-bounds in the fbarray.
The `arr->len - arr->count < n` condition in fbarray_find_n() is meant to
safeguard against this, but we are not updating arr->count when inserting
holes, so an undesired index may be returned.
Signed-off-by: Jake Freeland <jf...@freebsd.org>
I don't quite get how this happens.
If we "need hole" that means the memseg list isn't empty, and previous
segment is occupied. When we need hole, we request 2 free spots from the
memseg. Let's assume there's only 2 free spots left in the memseg list,
so we get ms_idx equal to (arr->len - 2).
We get ms_idx - that is, the index of where the free spot starts, and
there's 2 spots guaranteed to be free at that point. We need a hole, so
we increment ms_idx once to arrive at last free spot (arr->len - 1).
Where would the overflow come from?
(also, now that I think of it, I suspect we should not be starting our
search from index 0 every time, because if we "don't need a hole"
because the segment is adjacent to previous one, that means
find_next_n(1) starting from 0 will find us a hole we left previously
for some other segment - perhaps we should find first unoccupied spot
from the end, and start the find_next_n search from there?)
--
Thanks,
Anatoly
