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 AD2E3C282EC for ; Mon, 17 Mar 2025 05:53:13 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C3BF2280003; Mon, 17 Mar 2025 01:53:11 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BE943280001; Mon, 17 Mar 2025 01:53:11 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AD7E5280003; Mon, 17 Mar 2025 01:53:11 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 8EFBF280001 for ; Mon, 17 Mar 2025 01:53:11 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 646AF1A1842 for ; Mon, 17 Mar 2025 05:53:12 +0000 (UTC) X-FDA: 83229975024.23.840DF65 Received: from verein.lst.de (verein.lst.de [213.95.11.211]) by imf02.hostedemail.com (Postfix) with ESMTP id 6663D80004 for ; Mon, 17 Mar 2025 05:53:10 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf02.hostedemail.com: domain of hch@lst.de designates 213.95.11.211 as permitted sender) smtp.mailfrom=hch@lst.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1742190790; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=SomPSPmX4pNPUN/QIQtOgpz9QgQ+h/2IVuLvSiC+RM8=; b=z7R5dOjYtw/hbiARMHW1k4QKPAICtYYHOZvNukEX5lcwtX4Aws5RHuyA7CWLSNnpoSEyJl zUHGTYlcZKasHUed+ulNjjqYN/he1b/JjSD2grrAkQk+4204ABFULFIIsXn3ywajeFO8OI FoVyK2+mji2BD7Ks45bm4JBQ5HfN9LQ= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1742190790; a=rsa-sha256; cv=none; b=h+babsIWbCV4t815W2JdboLSrPrcTEQGgSD9Iu+z/q9n5S/3GTT1YSyS5dRPderktgybN6 8cwEgFTBSZFQ143cv8WwGemvrpSL4ld4tV1xx0lO5iEoFtLJI9rP53e5t8KeOfhGUbJjKJ ethyOmT2e20QWZau3jv9dSWtEO2bcsI= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf02.hostedemail.com: domain of hch@lst.de designates 213.95.11.211 as permitted sender) smtp.mailfrom=hch@lst.de Received: by verein.lst.de (Postfix, from userid 2407) id 4F55068D0E; Mon, 17 Mar 2025 06:53:05 +0100 (CET) Date: Mon, 17 Mar 2025 06:53:04 +0100 From: Christoph Hellwig To: Bingbu Cao Cc: Huan Yang , hch@lst.de, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, lorenzo.stoakes@oracle.com, opensource.kernel@vivo.com, rppt@kernel.org, ryan.roberts@arm.com, urezki@gmail.com, ziy@nvidia.com Subject: Re: [PATCH] mm/vmalloc: fix mischeck pfn valid in vmap_pfns Message-ID: <20250317055304.GB26662@lst.de> References: <20250312061836.GA12841@lst.de> <339b0c1f-ce90-449f-a1fc-2656d5a1115c@vivo.com> <79247edd-761c-82e3-b8d2-acdbe31c8205@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <79247edd-761c-82e3-b8d2-acdbe31c8205@linux.intel.com> User-Agent: Mutt/1.5.17 (2007-11-01) X-Rspam-User: X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: 6663D80004 X-Stat-Signature: 8gnkpdpc869zmfz7wbjbondbnpwb7if3 X-HE-Tag: 1742190790-712816 X-HE-Meta: U2FsdGVkX18Lg7+1IuXWBShsjSOMcZUt9Lra1fmS5MChm1EQkAf/fOmLk3bADQVNKB28aPWU46ZOSsyHeD1os7gVH0PfHG+efAA7i591mIUHWqmcmzaBbiSH95+DDSn3mkL6+uEf9aVD2+OAYbu9jD8PNnEGZ/rxBkGPG85RPAvH57123TABrY5pl/9yPn8F8xQpIktAJRJJqAOvdWfNZIW4uivyW/iX7apjMV+ob19rBasKir8lt4atESRdOkbvFMSOc02nRwFeoeulMcRnhZqKPL6qhR3UMw89SF7roq8hJYRcTv/lYF6bM5PigM2vLJDITE2RywA0BvLDvYuttIyQb4Uaia80ybYZTNkMKQnv9KLIyIZ4M7AXS6/Kt6GeXv1V2HoqE2O5zFmc9FMzgPqCCZqLO7IahNn/HPXCV5VWVLRIG18nKubvaEJFIg6ShTZ3w7NMFKNLQ7BpG7QgOeFu5ZZyv+OgeaQ2ruBa/PL0Jh4ALzDBGcMWcFeN2zYA3rv8m5jAOiB6RzxRn3dA5kBzEte/61y5LeXxBjw2kdRn7owAyIlezJxQf1hf4zjZKdws5jLAWLl3HUN3OGkLLkQMH2tMGoKdTkj/Z/6OJ9Es2mxctkRq3jX+Otvp9aQ2mzJTvhmmIQTuMKlAROJbHTyRw/eTcSZmqtSiZeDMCijSc8nVxsKtjdjkNC3+ENdnQ01yseOaDR3NsaUIEiGqtPw9V2LXE5YUoIj9A2JzKRKnQshgj28j7Xg+UqKUOwPFCTwQG/M8yl3CoTKnk0v92NQ4gcdqIj8Mx+pYVX55PbcrKqucyva+Y9EoAtBdrHGA6ldfjNL6m6ZqRJSGq/bqvWuCB02kZO9xr0CCiUD1NUJLgA2MA5HLBheSmfBIwkhcWLOwuED+4mtHUZfoR4SLgTLx4jnsPdC3F4+YfjVyW6rQVRhO3FcijhNet+YOaWI03e18Of3vT583qonXsv1 YoE4x9/+ 252OyHuyzAWxIHvYpJ1Wp70lW29k/3VF32TXwj9oToi9LuQGhoCyEjNtR0QGwKGx0JQL1DCMpmbmBrGGHR8SuI7ka3afp7/5MTxVOiHeLbBxAZdvpU0F2xemiFQ== 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: List-Subscribe: List-Unsubscribe: On Mon, Mar 17, 2025 at 01:29:05PM +0800, Bingbu Cao wrote: > Why not update udmabuf to make it work with both vmap_pfns() and > vmap()? As only the udmabuf knows it is actually working on? > > I don't think it's a good idea to hack the common API, the WARN_ON() > is really a mandatory check, and current case is a good example. What non-page backed memory does udmabuf try to work on, and more importantly how does it actually work on them given that the normal DMA APIs require page backed memory. Or is this just made it up and it doesn't work at all given that it also tries to dma map to the fake miscdevice struct device which can't work for most cases? Mapping non-page memory is difficult and without having coherent theory of what non-page memory you are mapping and being very careful you are extremely unlikely to get it right.