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 D3509C433FE for ; Thu, 2 Dec 2021 15:24:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3C4B36B0072; Thu, 2 Dec 2021 10:24:01 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 34CDD6B0073; Thu, 2 Dec 2021 10:24:01 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1ED486B0074; Thu, 2 Dec 2021 10:24:01 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0036.hostedemail.com [216.40.44.36]) by kanga.kvack.org (Postfix) with ESMTP id 0A9656B0072 for ; Thu, 2 Dec 2021 10:24:01 -0500 (EST) Received: from smtpin04.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id C1600180C3C47 for ; Thu, 2 Dec 2021 15:23:50 +0000 (UTC) X-FDA: 78873224220.04.A9E20EF Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf05.hostedemail.com (Postfix) with ESMTP id 65A02100005 for ; Thu, 2 Dec 2021 15:23:50 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 8E8F8B82398; Thu, 2 Dec 2021 15:23:48 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 75191C00446; Thu, 2 Dec 2021 15:23:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1638458627; bh=DoFQVdCmJ+10smCDr1M4YnkOUL3I84YplyEf7u4N/K8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=quP1VV8RgqGIfGlFDxjvb7grT5Kj08wlTT4Pxz46k19bev2OEMLxovMVvZm57BKhq tqOovp0EQcqrF2Gg0g6LF7vZu0f+Y3yt6MBK7UB5cezzmPydr0iQN7D0jLNWYn8QTW wzxeUfTbh654x5VFqkm5D5IpccLRBOtwSZTpW1q41P9Fi/nGUqXzJwxaSWNoDwF3b8 xQ1WQkxYEsCsncHwWUmZlwOQfPL2sUPeQQbHU5eAR5HCVicYXtBNAZ0SPZMc6sBD+q DwgZ1bYxekU0AsPMeuM0BDpCn8kkZ75eXe5w7o5JZ3HoO5ClloXf8BDtiv+gcNr5Na foKnAtqzDqnEw== Date: Thu, 2 Dec 2021 17:23:42 +0200 From: Leon Romanovsky To: Andrew Morton Cc: Bixuan Cui , linux-mm@kvack.org, linux-kernel@vger.kernel.org, torvalds@linux-foundation.org, w@1wt.eu, keescook@chromium.org 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20211201192643.ecb0586e0d53bf8454c93669@linux-foundation.org> X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 65A02100005 X-Stat-Signature: wb3a1fkb6xig87rkp3ji4fdrx683x716 Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=quP1VV8R; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf05.hostedemail.com: domain of leon@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=leon@kernel.org X-HE-Tag: 1638458630-779870 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 Wed, Dec 01, 2021 at 07:26:43PM -0800, Andrew Morton wrote: > On Thu, 2 Dec 2021 10:06:24 +0800 Bixuan Cui wrote: > > > Delete the WARN_ON() and return NULL directly for oversized parameter > > in kvmalloc() calls. > > Also add unlikely(). > > > > Fixes: 7661809d493b ("mm: don't allow oversized kvmalloc() calls") > > Signed-off-by: Bixuan Cui > > --- > > There are a lot of oversize warnings and patches about kvmalloc() calls > > recently. Maybe these warnings are not very necessary. > > Or maybe they are. Please let's take a look at these warnings, one at > a time. If a large number of them are bogus then sure, let's disable > the runtime test. But perhaps it's the case that calling code has > genuine issues and should be repaired. Andrew, The problem is that this WARN_ON() is triggered by the users. At least in the RDMA world, users can provide huge sizes and they expect to get plain -ENOMEM and not dump stack, because it happens indirectly to them. In our case, these two kvcalloc() generates WARN_ON(). umem_odp->pfn_list = kvcalloc( npfns, sizeof(*umem_odp->pfn_list), GFP_KERNEL); if (!umem_odp->pfn_list) return -ENOMEM; umem_odp->dma_list = kvcalloc( ndmas, sizeof(*umem_odp->dma_list), GFP_KERNEL); https://elixir.bootlin.com/linux/v5.16-rc3/source/drivers/infiniband/core/umem_odp.c#L80 It is not a kernel programmer error to allow "oversized kvmalloc call" . Thanks