On Thu, Dec 02, 2021 at 02:03:43PM -0800, Andrew Morton wrote: > On Thu, 2 Dec 2021 13:23:13 -0800 Kees Cook <keescook@xxxxxxxxxxxx> wrote: > > > > > 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.
