On Thu, Dec 02, 2021 at 02:03:43PM -0800, Andrew Morton wrote:
On Thu, 2 Dec 2021 13:23:13 -0800 Kees Cook [off-list ref] wrote:
quoted
quoted
quoted
I think we have two cases:
- limiting kvmalloc allocations to INT_MAX
- issuing a WARN when that limit is exceeded
The argument for the having the WARN is "that amount should never be
allocated so we want to find the pathological callers".
But if the actual issue is that >INT_MAX is _acceptable_, then we have
to do away with the entire check, not just the WARN.
First we need to get rid from WARN_ON(), which is completely safe thing to do.
Removal of the check can be done in second step as it will require audit
of whole kvmalloc* path.
If those are legit sizes, I'm fine with dropping the WARN. (But I still
think if they're legit sizes, we must also drop the INT_MAX limit.)
Can we suppress the WARN if the caller passed __GFP_NOWARN?
I don't think that's a good idea. NOWARN is for allocation failure
messages whereas this warning is more of a "You're doing something
wrong" -- ENOMEM vs EINVAL.
I'm still agnostic on whether this should be a check at all, or whether
we should let people kvmalloc(20GB). But I don't like conditioning the
warning on GFP_NOWARN.