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 7AE8DD43341 for ; Thu, 7 Nov 2024 11:11:03 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D92956B009E; Thu, 7 Nov 2024 06:11:02 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D428B6B009F; Thu, 7 Nov 2024 06:11:02 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C09BB6B00A0; Thu, 7 Nov 2024 06:11:02 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id A393F6B009E for ; Thu, 7 Nov 2024 06:11:02 -0500 (EST) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 1F6F8C05FD for ; Thu, 7 Nov 2024 11:11:02 +0000 (UTC) X-FDA: 82759031292.11.ACAE781 Received: from szxga08-in.huawei.com (szxga08-in.huawei.com [45.249.212.255]) by imf27.hostedemail.com (Postfix) with ESMTP id 93FB840003 for ; Thu, 7 Nov 2024 11:10:23 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf27.hostedemail.com: domain of linyunsheng@huawei.com designates 45.249.212.255 as permitted sender) smtp.mailfrom=linyunsheng@huawei.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1730977735; a=rsa-sha256; cv=none; b=m3PwKNsCp23+hydrJZbV4cSgBZ61va3Bs4WuDKV5ie9Edp6gBgzfWiH0b2lGH9nTOFHO5W XbK0i+hr8gahUk/qkSULkkBjfeJijcXFLD2MYmpRrZ7AKn2XaxRbZzeJMthU50OqUaBb4n dJXMOwq3x/a+01uIFS3o83msGqRDA8U= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf27.hostedemail.com: domain of linyunsheng@huawei.com designates 45.249.212.255 as permitted sender) smtp.mailfrom=linyunsheng@huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1730977735; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=BA3QovXQKu16dxiQZLlWphBwOqiHszRBvQ5jCokSiVY=; b=S2IbpFoAA6l2HmduNy7v50YmjSTN3WBn78+at/9yOe8o4/lrOeZRWRz+yRGjgNVSJ5VtzO FFbrtdnrlCczROer/YqES3aaEHsXDFdsOD/4Dl7+rB/I0cydWVCEvljPvg/5uOXz1cDJ/y wYnMVLjjwZz/eakAmUNJrT7b+FDkbyo= Received: from mail.maildlp.com (unknown [172.19.163.48]) by szxga08-in.huawei.com (SkyGuard) with ESMTP id 4XkfSy6VQXz1P9Y4; Thu, 7 Nov 2024 19:08:34 +0800 (CST) Received: from dggpemf200006.china.huawei.com (unknown [7.185.36.61]) by mail.maildlp.com (Postfix) with ESMTPS id 38EB518005F; Thu, 7 Nov 2024 19:10:56 +0800 (CST) Received: from [10.67.120.129] (10.67.120.129) by dggpemf200006.china.huawei.com (7.185.36.61) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Thu, 7 Nov 2024 19:10:55 +0800 Message-ID: Date: Thu, 7 Nov 2024 19:10:55 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH net-next v3 3/3] page_pool: fix IOMMU crash when driver has already unbound To: Alexander Duyck , Jesper Dangaard Brouer CC: =?UTF-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= , , , , , , , Robin Murphy , IOMMU , Andrew Morton , Eric Dumazet , Ilias Apalodimas , , , , kernel-team , Viktor Malik References: <20241022032214.3915232-1-linyunsheng@huawei.com> <20241022032214.3915232-4-linyunsheng@huawei.com> <113c9835-f170-46cf-92ba-df4ca5dfab3d@huawei.com> <878qudftsn.fsf@toke.dk> <87r084e8lc.fsf@toke.dk> <0c146fb8-4c95-4832-941f-dfc3a465cf91@kernel.org> <204272e7-82c3-4437-bb0d-2c3237275d1f@huawei.com> <18ba4489-ad30-423e-9c54-d4025f74c193@kernel.org> Content-Language: en-US From: Yunsheng Lin In-Reply-To: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.67.120.129] X-ClientProxiedBy: dggems703-chm.china.huawei.com (10.3.19.180) To dggpemf200006.china.huawei.com (7.185.36.61) X-Rspamd-Queue-Id: 93FB840003 X-Stat-Signature: 695z8ebmoorxeo6xm5axpx6cwfp5smq3 X-Rspam-User: X-Rspamd-Server: rspam05 X-HE-Tag: 1730977823-713361 X-HE-Meta: U2FsdGVkX1+BYtmNITfUUX3GTvmvekUEedO9U4C2TNeo2YP+DJuDDEHDerfA7w7jw75J4Jr/5E8/rrTPXpibeM9/m6WKiUt3qB4wqZ64cYjVSFdU+Gbqbl/WlrHZsGcfGwORrGmuVrKaW3D3HgHuQJOVE9XNc5yEwp6WmhTBFbrDzugHM2h19expHRbkaR+1vEv4mmX6HsmUJD3dCy+RCIQSvi3I9y8GWi110NI0lnO/+7O5yksBXfDnfXiXS5C/6o5mVxe9DPhP9Mw7iSwVwJI9KESkSgwTxZB8eSdV+wfjkV7limO7GUl/Ex17YnwKZnKZbnoL9229dHyNO0tKEfkU6sLq9TF6DIYxgKtGWhlMXxYUHeILGuEbYhoHUFY7mBbAkWHyRV9gGSx5bT2SeoP63dYlHgU0SUJrZPJpas+yDIZ9acn7/0Fae2HgI9PIaTKFs55p8sX/6FC5bE59Et9YfR/pyaTmmtP8KrWJ/aqJ69R2KLDZx8d825gzOSW0hkoVCj9i11qHz+/f5knDR7SE2sCIJd+jkEByqlx4rEs0fSHcm9hV+VMwfyF63tQ0La8uDzU6SQSmn5YKCWU5vDtdkGhnd4YsncN4nMXqohZNIeGCD02CLagfnbUIxDXmKBcag9k25DSnNGnL5chATpNBGqfTXQHMzG9PXCYj+RtgUuwvKp2vSdpsJ2+CNKyQ7Ecb/9buTyW16sWAOOhq9e8tpBfyl5P4HM6nESl8RExhsXnuQ6jxissBYDtP42qnGZ6bpIlT+2uwpQ90nCLANuc1dhWeo04LWXD2cTgfpMdakp67gZArCQk9J+ZiGlhMCKJvXu9sdRPOUPl7cHfH1fOAhglv+3Bfq1nuHqGQDLZsDuzje7U0njvBrt5NqHChW+jVQOfmYJ8JB/4i3gI0SORkIzmyHrNz04Fe3JvyQo37KEw1Ne5n+XKwT4dysQC+aiZRR3fm0uzvm3Q6f0e h94rnQST SExGNW03YX6FyPruG/kMzvongY/UAC+0saispScgxYnsVCUPOC90gq0gtuo8nKPTxyKe/iyNLLCrcTatv9RVH0yWOj8JdNohTpMXEju1+3/MyUGAEAX0HIeQrgBR+VdVuqCc1Jsij+Bz/4sk+xjQUcjMlSWZB98gxt71BLyGbncFvDXiWD6V6kYtAUZzWbYsThGiI8j84n7bGhiyrIpzCwo8VV/nv2W3wFN3bQbNIojhgt3p26i5XShVg6WSOYuh4WjuncuP3JMQudiKcJ6u7EV7mQq8lY+icG93t 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 2024/11/7 3:55, Alexander Duyck wrote: | ... > > Is there any specific reason for why we need to store the pages > instead of just scanning the page tables to look for them? We should > already know how many we need to look for and free. If we were to just > scan the page structs and identify the page pool pages that are > pointing to our pool we should be able to go through and clean them > up. It won't be the fastest approach, but this should be an > exceptional case to handle things like a hot plug removal of a device > where we can essentially run this in the background before we free the > device. Does 'scanning the page tables' mean scaning the array of 'struct page *', like vmemmap/memmap? I am not sure if there is any existing pattern or API to scan that array? Does it fall under the catalog of poking into the internals of mm subsystem? For exmaple, there seems to be different implemenation for that array depending on CONFIG_SPARSEMEM* config. Also, I am not sure how much time it may take if we have to scan the array of 'struct page *' for all the memory in the system. > > Then it would just be a matter of modifying the pool so that it will > drop support for doing DMA unmapping and essentially just become a > place for the freed pages to go to die. > If I understand it correctly, the above seems to be what this patch is trying to do by clearing pool->dma_map after doing the dma unmapping for the inflight pages.