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 D7217C433EF for ; Thu, 2 Dec 2021 16:09:07 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4FCB76B0072; Thu, 2 Dec 2021 11:08:57 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 4AA9D6B0073; Thu, 2 Dec 2021 11:08:57 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3729F6B0074; Thu, 2 Dec 2021 11:08:57 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0149.hostedemail.com [216.40.44.149]) by kanga.kvack.org (Postfix) with ESMTP id 249256B0072 for ; Thu, 2 Dec 2021 11:08:57 -0500 (EST) Received: from smtpin05.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id E45D48A3F3 for ; Thu, 2 Dec 2021 16:08:46 +0000 (UTC) X-FDA: 78873337452.05.FCF31D0 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf30.hostedemail.com (Postfix) with ESMTP id 83BFCE00199D for ; Thu, 2 Dec 2021 16:08:46 +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 dfw.source.kernel.org (Postfix) with ESMTPS id 575E1626CA; Thu, 2 Dec 2021 16:08:45 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id EE86AC00446; Thu, 2 Dec 2021 16:08:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1638461324; bh=p2KZgqN80W7bcbxbxXbmgjm5dt5Eb5v4ahxcjc2zNsA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=i2NWBKrh/rOMYSo3cpVbBs032u3wIInxX+tCB91LqMeHHCh+QDlgOhQ5EMOyRDM6R cy/TRhAbC0bZ/VRvuEO4ryHYfRlRgJ0rdS45P8v8FGM5HrYCG6PB9++q1Kred/Y8eI sEg4xF78miGqqwzJ9Ax75rqeJdxLoyS3Bw2KuE0liwkBixsYUDer7MCHnRabMcU8MF /GvMbtoCI1XvDZRHCS0ItkenUnEOFbOEeDKcHrdFo3WOdufpR9/Td6v99JeiJ0rcwK gVncFE6bUH7cPlIWEmtkWV+6BLuUONmkxyD98zj8a6U0m1FAz3DaxSZXw6GlvpkmYq r9veprvgTtaEA== Date: Thu, 2 Dec 2021 18:08:40 +0200 From: Leon Romanovsky To: Matthew Wilcox Cc: Andrew Morton , 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: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 83BFCE00199D X-Stat-Signature: izgf7bcdg1d6g4j6bb4ejw1k6s3e1xp8 Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=i2NWBKrh; spf=pass (imf30.hostedemail.com: domain of leon@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=leon@kernel.org; dmarc=pass (policy=none) header.from=kernel.org X-HE-Tag: 1638461326-401566 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 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. > > > 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); > > Does it really make sense for the user to specify 2^31 PFNs in a single > call? I mean, that's 8TB of memory. Should RDMA put its own limit > in here, or should it rely on kvmalloc returning -ENOMEM? I heard about such systems with so many available RAM. I don't know about their usage pattern, most likely they will use hugepages, but it is my guess. The thing is that it is not RDMA-specific. You are asking to place same if (size > KVMALLOC...) check in all subsystems. Thanks