Re: [PATCH -next] mm: delete oversized WARN_ON() in kvmalloc() calls

[Kees Cook <keescook@chromium.org>]

On Thu, Dec 02, 2021 at 06:08:40PM +0200, Leon Romanovsky wrote:
> On Thu, Dec 02, 2021 at 03:29:47PM +0000, Matthew Wilcox wrote:
> > On Thu, Dec 02, 2021 at 05:23:42PM +0200, Leon Romanovsky wrote:
> > > The problem is that this WARN_ON() is triggered by the users.
> > 
> > ... or the problem is that you don't do a sanity check between the user
> > and the MM system.  I mean, that's what this conversation is about --
> > is it a bug to be asking for this much memory in the first place?
> 
> We do a lot of checks, and in this case, user provided valid input.
> He asked size that doesn't cross his address space.
> https://elixir.bootlin.com/linux/v5.16-rc3/source/drivers/infiniband/core/umem_odp.c#L67
> 
> 		start = ALIGN_DOWN(umem_odp->umem.address, page_size);
> 		if (check_add_overflow(umem_odp->umem.address,
> 				       (unsigned long)umem_odp->umem.length,
> 				       &end))
> 			return -EOVERFLOW;
> 
> There is a feature called ODP (on-demand-paging) which is supported
> in some RDMA NICs. It allows to the user "export" their whole address
> space to the other RDMA node without pinning the pages. And once the
> other node sends data to not-pinned page, the RDMA NIC will prefetch
> it.

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.

-- 
Kees Cook