From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id F0235C433F5 for ; Thu, 2 Dec 2021 19:08:58 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1441A6B0072; Thu, 2 Dec 2021 14:08:48 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 0F32C6B0074; Thu, 2 Dec 2021 14:08:48 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EFD6D6B0075; Thu, 2 Dec 2021 14:08:47 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0056.hostedemail.com [216.40.44.56]) by kanga.kvack.org (Postfix) with ESMTP id E2E346B0072 for ; Thu, 2 Dec 2021 14:08:47 -0500 (EST) Received: from smtpin02.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id B03611811328A for ; Thu, 2 Dec 2021 19:08:37 +0000 (UTC) X-FDA: 78873790674.02.5020217 Received: from mail-pj1-f48.google.com (mail-pj1-f48.google.com [209.85.216.48]) by imf31.hostedemail.com (Postfix) with ESMTP id 659EA1046300 for ; Thu, 2 Dec 2021 19:08:37 +0000 (UTC) Received: by mail-pj1-f48.google.com with SMTP id x7so523376pjn.0 for ; Thu, 02 Dec 2021 11:08:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=1hDOoMBGSN6kabG9MIsrdbw1zEiInbB097CJy1sxekA=; b=fRdahR+cm2DQ61b0GVnE9C2akBv5/+imaMxGdjBCmOdwU1Je3To8WFoP3teXAsMszj /24+VNRBMfuyVZ74nVKJgYJaBo/w7nWrdBElFwuH+HSXjBuCqlruUQjhH0bwHM60TGI3 9PrvHDdqrDhFfT0kv1EJq+1qblKeewWtDwwe4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=1hDOoMBGSN6kabG9MIsrdbw1zEiInbB097CJy1sxekA=; b=oA41d3XW940AFuGhpKnHe5F8PMYQebhpDSkwbCKdD+LmVa7dleK1ewUhWb8lz9tVDr oDNfmzs5XTK3HMvU/v7llPJN/V9mHukiW7QiPY6hNJSxIb6owM01sTuj9MC+T4MO8fjl IGIOabsIy1wSocvFPBj4l0Go1WDYpeFl5IwWeSJ7YLCMY7eJjQWLIvSIXsnTKvPZPotj Eb7kaONGVmxKjLf2tMDupDuHnSNG9D0KGAu2PkoKD49bb0vQhGTu7+mIaIWSFhn0gtn8 +Jy/db+IWYgZ+5baDf+rSiCb19ofhwAwQGb7nGCaMldRfJXlIgZbbpw5ID9W+CKf+P6Q Mqgw== X-Gm-Message-State: AOAM533XeP1rXIqljEV4n30JJV/95i+CRHspR/7BGQsMXzY+3g6+NN9F WwQp2antnbgvZkLy+ApVaqLGjA== X-Google-Smtp-Source: ABdhPJzR7Cx57RXSCzSLhVy8YTHO2hrexUvipOpFPVgN8+TxWM0fTP8EXYPzrQJo7/Ae/wnpdM5ccA== X-Received: by 2002:a17:90b:4a43:: with SMTP id lb3mr8107258pjb.222.1638472116294; Thu, 02 Dec 2021 11:08:36 -0800 (PST) Received: from www.outflux.net (smtp.outflux.net. [198.145.64.163]) by smtp.gmail.com with ESMTPSA id j34sm347058pgj.42.2021.12.02.11.08.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 02 Dec 2021 11:08:35 -0800 (PST) Date: Thu, 2 Dec 2021 11:08:34 -0800 From: Kees Cook To: Leon Romanovsky Cc: Matthew Wilcox , Andrew Morton , Bixuan Cui , linux-mm@kvack.org, linux-kernel@vger.kernel.org, torvalds@linux-foundation.org, w@1wt.eu Subject: Re: [PATCH -next] mm: delete oversized WARN_ON() in kvmalloc() calls Message-ID: <202112021105.C9E64318F@keescook> References: <1638410784-48646-1-git-send-email-cuibixuan@linux.alibaba.com> <20211201192643.ecb0586e0d53bf8454c93669@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: 659EA1046300 X-Stat-Signature: bfnmx1jokn8pr4z8h9gmmqokerw3wxat Authentication-Results: imf31.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=fRdahR+c; spf=pass (imf31.hostedemail.com: domain of keescook@chromium.org designates 209.85.216.48 as permitted sender) smtp.mailfrom=keescook@chromium.org; dmarc=pass (policy=none) header.from=chromium.org X-HE-Tag: 1638472117-465061 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 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