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 06B98CEBF9A for ; Fri, 27 Sep 2024 11:29:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6634F6B00D1; Fri, 27 Sep 2024 07:29:31 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 613106B00D3; Fri, 27 Sep 2024 07:29:31 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4B33A6B00D4; Fri, 27 Sep 2024 07:29:31 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 2C7D26B00D1 for ; Fri, 27 Sep 2024 07:29:31 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id CAC7AA9454 for ; Fri, 27 Sep 2024 11:29:30 +0000 (UTC) X-FDA: 82610297700.14.384C7A0 Received: from szxga05-in.huawei.com (szxga05-in.huawei.com [45.249.212.191]) by imf15.hostedemail.com (Postfix) with ESMTP id E73F5A0007 for ; Fri, 27 Sep 2024 11:29:27 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=none; spf=pass (imf15.hostedemail.com: domain of linyunsheng@huawei.com designates 45.249.212.191 as permitted sender) smtp.mailfrom=linyunsheng@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1727436446; 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=f/WFEz0A5bvXUvo45jjUU1d1+FxqRULkPKv8aYb2Y+c=; b=VxFrSptSZ2HPqSrnh7N9NbmX2cPB5gVpztRROjnKpu788ZSpiHlwqSSqLiTe//jI8XcGUT O2u9o481Ag2+g2wBt41vtnCkhKzKJt3xBgHv63N4y9mQHj8WSfld60/uuRTc27tk7UWsbj pxaxJnyFfKCVeN3VUdtCZQuiOGbMOJ4= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1727436446; a=rsa-sha256; cv=none; b=4hsL3+IRa8lu/N0teceYVTv9qktL7/ooVEr1K2xlZlGir91rUaQ/BmZw7Zn8QLem71tA/U 5nzXu3AJm/TPnYlJ81yNh9qr/g26kGDNrjcXPCX3HVNh0D3xkPkwO9FIEmB81htBzwN5Oo eakkw9iBvjKMPQhRXztqkq+Z9EyC6aE= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=none; spf=pass (imf15.hostedemail.com: domain of linyunsheng@huawei.com designates 45.249.212.191 as permitted sender) smtp.mailfrom=linyunsheng@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com Received: from mail.maildlp.com (unknown [172.19.88.214]) by szxga05-in.huawei.com (SkyGuard) with ESMTP id 4XFSrx2nMcz2QTtc; Fri, 27 Sep 2024 19:28:33 +0800 (CST) Received: from dggpemf200006.china.huawei.com (unknown [7.185.36.61]) by mail.maildlp.com (Postfix) with ESMTPS id 2ACA31A016C; Fri, 27 Sep 2024 19:29:23 +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; Fri, 27 Sep 2024 19:29:22 +0800 Message-ID: <934d601f-be43-4e04-b126-dc86890a4bfa@huawei.com> Date: Fri, 27 Sep 2024 19:29:22 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH net v2 2/2] page_pool: fix IOMMU crash when driver has already unbound To: Ilias Apalodimas CC: Mina Almasry , , , , , , , Robin Murphy , Alexander Duyck , IOMMU , Wei Fang , Shenwei Wang , Clark Wang , Eric Dumazet , Tony Nguyen , Przemek Kitszel , Alexander Lobakin , Alexei Starovoitov , Daniel Borkmann , Jesper Dangaard Brouer , John Fastabend , Saeed Mahameed , Leon Romanovsky , Tariq Toukan , Felix Fietkau , Lorenzo Bianconi , Ryder Lee , Shayne Chen , Sean Wang , Kalle Valo , Matthias Brugger , AngeloGioacchino Del Regno , Andrew Morton , , , , , , , , , , References: <20240925075707.3970187-1-linyunsheng@huawei.com> <20240925075707.3970187-3-linyunsheng@huawei.com> <842c8cc6-f716-437a-bc98-70bc26d6fd38@huawei.com> <0ef315df-e8e9-41e8-9ba8-dcb69492c616@huawei.com> 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: dggems706-chm.china.huawei.com (10.3.19.183) To dggpemf200006.china.huawei.com (7.185.36.61) X-Stat-Signature: opfxwq3jexzg8kjmx8zgpdp5uad9ycg4 X-Rspamd-Queue-Id: E73F5A0007 X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1727436567-921899 X-HE-Meta: U2FsdGVkX19eCddXMFokAWep8G0qkvJ1xhrJm22gzQN0iPaKiPwc7IXddpNKd62TuDOQNsXi29gqY0pwGiSVJX6dQ64iffJHs0sph0C1BQmGQ2pQXQw0kwRj1Terzycj7qO0v9zxbJDpbLvwWsPLzUca0ZFTtiUIiXTUHmDINPwoOkMfPCTwUUu9HGTlqLw5Lwtg4fTLw3gy5jFtzPtfcVDEKsNIEfdsohrcyl3npJa7bSluiD85PPVAQn4INRu7cD1icqW6YzYudW1Fb+H8CUMPDgXSHyytVef8beIc/APSwwxsyLlAGdrCvZaW+Yk50oR7KovVK5JdZmFxbXKgS80Tpqu+C4tz+tbklq6XxKE7NEnmFeAaypz7DNubBs/56TGc7xuUQi3qZckdJ/duuBC0V0cXKTEtHgxx+3i9Cn3QF2ojlPMvIEErUbq/5ZslcUDZJZ4FhrS4RdHIhYQDQ/ExQFW92CtjuYcqMbq2FQggWf3zdSv84JMrecHrYPiNuFcR4rJkybPBL/Ai8r4XJSkT3dQugtCmcHXe4d/5btXLm/uHG87qtGHBS6xvvek7qOR4SG/MXvIafmcOc9XcK0D+XLy4kwIqhAUcV5estU6+m334VPnyE0c8gyvUl0V1uN6mlBpgxE5Dk7eioCQiKP6g0vu27LpSwq3MBJcmX+dcT+R61Lp4CNvmm2OtrsdXZO3iRyrETbxo4WBxrgI5mVAIK3yyMz8DrpgxyAreOqsGziLkllHSxdm5p8Ot8uWX3H2RiYuFpGG8lXNU6TCd98rYLl7T5Q/YRDW5Tk5VDZtv97tkKmQuwtU6kNJLu9IqZIFYq4NRGtEQymgMxShyoG+gVaVEIGZqpcc5cldgJx4PHAwHJ3V4Ii5PnJYeXcB7xjsZaJ9XVKraCYvS4trNqJbPdtODnI9PNQ+cvbhxuNfVsp+OnE4t+04dCxYxh1NB/FieHMVNKzRuQ4gD8Dp Fc3JDYt+ rvYZxMOr0gStOdKBkZvM40GMJZf2OUmTsBWgnydVjixHocBuktKDQ3cLP/OmuDJ2phMbyRVTPzDm9oniiXx/aQDnSSAOR7rGS7wyzMNTYvrQ0KeS7nQGboYyx2sh0mDIpTPfY/+EfZSnXSeTE5P4aYfQ0/F1uXaxJc9GlAbn5LfDIYIAYet4cBmYAGJCfqxZX9IAaJ3kHU9LhKb4gdH51FQ/U0cBbD44z3FCBfWXEwJl5iDWZmfcANkA8pFo1ckdfKxWfPHQCkqbzQjzrVyQVgQTpe8oI5MWUjlOdGDRAy59FeebIhkFhV4NPFIOA8Idt+Oda4/vq++Sk2vOw8e3j4rPbo2eJCDnqozae 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/9/27 17:58, Ilias Apalodimas wrote: ... >> >>> importantly, though, why does struct page need to know about this? >>> Can't we have the same information in page pool? >>> When the driver allocates pages it does via page_pool_dev_alloc_XXXXX >>> or something similar. Cant we do what you suggest here ? IOW when we >>> allocate a page we put it in a list, and when that page returns to >>> page_pool (and it's mapped) we remove it. >> >> Yes, that is the basic idea, but the important part is how to do that >> with less performance impact. > > Yes, but do you think that keeping that list of allocated pages in > struct page_pool will end up being more costly somehow compared to > struct page? I am not sure if I understand your above question here. I am supposing the question is about what's the cost between using single/doubly linked list for the inflight pages or using a array for the inflight pages like this patch does using pool->items? If I understand question correctly, the single/doubly linked list is more costly than array as the page_pool case as my understanding. For single linked list, it doesn't allow deleting a specific entry but only support deleting the first entry and all the entries. It does support lockless operation using llist, but have limitation as below: https://elixir.bootlin.com/linux/v6.7-rc8/source/include/linux/llist.h#L13 For doubly linked list, it needs two pointer to support deleting a specific entry and it does not support lockless operation. For pool->items, as the alloc side is protected by NAPI context, and the free side use item->pp_idx to ensure there is only one producer for each item, which means for each item in pool->items, there is only one consumer and one producer, which seems much like the case when the page is not recyclable in __page_pool_put_page, we don't need a lock protection when calling page_pool_return_page(), the 'struct page' is also one consumer and one producer as the pool->items[item->pp_idx] does: https://elixir.bootlin.com/linux/v6.7-rc8/source/net/core/page_pool.c#L645 We only need a lock protection when page_pool_destroy() is called to check if there is inflight page to be unmapped as a consumer, and the __page_pool_put_page() may also called to unmapped the inflight page as another consumer, there is why the 'destroy_lock' is added for protection when pool->destroy_cnt > 0. > > Thanks > /Ilias