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 4A6BFC433EF for ; Fri, 3 Dec 2021 04:39:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5319E6B0072; Thu, 2 Dec 2021 23:39:34 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 4DEAD6B0074; Thu, 2 Dec 2021 23:39:34 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3A6036B0075; Thu, 2 Dec 2021 23:39:34 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0144.hostedemail.com [216.40.44.144]) by kanga.kvack.org (Postfix) with ESMTP id 2A5C96B0072 for ; Thu, 2 Dec 2021 23:39:34 -0500 (EST) Received: from smtpin02.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id EC1838249980 for ; Fri, 3 Dec 2021 04:39:23 +0000 (UTC) X-FDA: 78875229006.02.B46B726 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf21.hostedemail.com (Postfix) with ESMTP id 568CAD0369DB for ; Fri, 3 Dec 2021 04:39:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=/KRoia3cIBqZtjCt7bxWdj0hL6Skzyy5MIfAEv1Ig3I=; b=WEq5+5buRsbVe6gVOgg+fZRR3J L9KEOBJ+d3qXyMeC8R56srGULlVQMiEr1+992EJjLT2XGtsy7rx+wOnULja9DsEIa8QjbmBhjsx0A hUn70sfgxoJslf2iDN5QXzLo1LCddn8IKnarsvRnZyBCTz408gHTczNWQ1070rLHzOwDK3aHfaaak 5dNOMCfOdKbaYWxCjrk76FjpM6ZlaLVIGpWOK+mrDP04sE3Ue5A7Q6MHFMWu3cdT+eNjRvxOvBdB4 vAcaFPWTzOzlEvDW5IcXionyEtyPRRW5bGOf71U8pAeruvOVmWoXmSqdZPcx9+BxB5UCPo30Frnxf 8Pr/vWbQ==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1mt0Lq-0071rV-Ko; Fri, 03 Dec 2021 04:39:14 +0000 Date: Fri, 3 Dec 2021 04:39:14 +0000 From: Matthew Wilcox To: Andrew Morton Cc: Kees Cook , Leon Romanovsky , 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: References: <1638410784-48646-1-git-send-email-cuibixuan@linux.alibaba.com> <20211201192643.ecb0586e0d53bf8454c93669@linux-foundation.org> <202112021105.C9E64318F@keescook> <202112021320.87AB40A@keescook> <20211202140343.0fd5dbc41513b1c95661ff8f@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20211202140343.0fd5dbc41513b1c95661ff8f@linux-foundation.org> X-Stat-Signature: sfnek3qiwmdx5o7gdqtu3gigy1grauik Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=WEq5+5bu; dmarc=none; spf=none (imf21.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 568CAD0369DB X-HE-Tag: 1638506362-46183 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 02:03:43PM -0800, Andrew Morton wrote: > On Thu, 2 Dec 2021 13:23:13 -0800 Kees Cook 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.