No, that's leaking implementation details to the caller. And no, increasing
the range and eventually allocating something bigger (e.g., placing a huge
page where it might not have been possible) is not acceptable for KASAN.
If you're terribly unhappy with this patch,
Sorry to say but it simple does not make sense.
Let's agree to disagree.
find_vmap_lowest_match() is imprecise now and that's an issue for exact
allocations. We can either make it fully precise again (eventually
degrading allocation performance) or just special-case exact allocations
to fix the regression.
I decided to go the easy path and do the latter; I do agree that making
find_vmap_lowest_match() fully precise again might be preferred -- we
could have other allocations failing right now although there are still
suitable holes.
I briefly thought about performing the search in
find_vmap_lowest_match() twice. First, start the search without an
extended range, and fallback to the extended range if that search fails.
Unfortunately, I think that still won't make the function completely
precise due to the way we might miss searching some suitable subtrees.
please suggest something reasonable to fix exact allocations:
a) Fixes the KASAN use case.
b) Allows for automatic placement of huge pages for exact allocations.
c) Doesn't leak implementation details into the caller.
I am looking at it.
Thanks!
--
Thanks,
David / dhildenb
