On Thu, Feb 10, 2022 at 9:57 AM Dan Carpenter <dan.carpenter@xxxxxxxxxx> wrote:
>
> Wait that would make the allocation succeed... We don't want that.
> That was a dumb idea. Forget I said that.
Well, sometimes that _can_ be the right model.
That said, pretty much every time this has come up, the kernel warning
has shown that yes, the code was broken and there really wasn't a
reason for doing allocations that big.
Of course, some people would be perfectly fine with the allocation
failing, they just don't want the warning. I didn't want __GFP_NOWARN
to shut it up originally because I wanted people to see all those
cases, but these days I think we can just say "yeah, people can shut
it up explicitly by saying 'go ahead and fail this allocation, don't
warn about it'".
So enough time has passed that by now I'd certainly be ok with something like
--- a/mm/util.c
+++ b/mm/util.c
@@ -587,8 +587,10 @@ void *kvmalloc_node(size_t size,
return ret;
/* Don't even allow crazy sizes */
- if (WARN_ON_ONCE(size > INT_MAX))
+ if (unlikely(size > INT_MAX)) {
+ WARN_ON_ONCE(!(flags & __GFP_NOWARN));
return NULL;
+ }
return __vmalloc_node(size, 1, flags, node,
__builtin_return_address(0));
(which is obviously COMPLETELY UNTESTED as well as being
whitespace-damaged, but you get the idea).
If somebody tests that patch and verifies it works, and writes a
little commit blurb for it, I'll apply it.
Linus
