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 smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 64CB2CFC289 for ; Tue, 15 Oct 2024 10:52:47 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 197E540192; Tue, 15 Oct 2024 10:52:47 +0000 (UTC) X-Virus-Scanned: amavis at osuosl.org Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavis, port 10024) with ESMTP id DXXZKRSa_J_T; Tue, 15 Oct 2024 10:52:45 +0000 (UTC) X-Comment: SPF check N/A for local connections - client-ip=140.211.166.34; helo=ash.osuosl.org; envelope-from=intel-wired-lan-bounces@osuosl.org; receiver= DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org CFCC840274 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=osuosl.org; s=default; t=1728989565; bh=dN7oaOwNEIx92nEf3A5VB6FzVv6Zzr3Fp2qH1sLAWLE=; h=Date:To:References:From:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc:From; b=LomDhxnYp4i85zKXrad1FdNb1KanSJMsvDMMJGnb0WeaH1lBDTpftbVocezcXl2cm l+fXwflpyyDZuYkmrIVwf8Vua6mDG7XoxR8PXkUp83wfqdTmYtdb+ezMx6EPcOjjrm L2rw9VDW60RE3aMTdCble0o7ttVhk5oup7K4F3EwgNSXq+o5+LdUW/Xi1EljDD3ywd D6gt8+KQSyF+8T7gxj0rOipo1r7ZQDmAyDgcehnt77nkoFReAaPYGPoBKSChzIaLRi yVShMMnaqjWfp11mWt0biGbAlPwcjba6sRwfRRitEykTYvDhsC6WrA8MQGt8+K75Ca 6rYUa/JqNFGeg== Received: from ash.osuosl.org (ash.osuosl.org [140.211.166.34]) by smtp4.osuosl.org (Postfix) with ESMTP id CFCC840274; Tue, 15 Oct 2024 10:52:45 +0000 (UTC) Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by ash.osuosl.org (Postfix) with ESMTP id 8FDAF1BF5DC for ; Tue, 15 Oct 2024 10:52:44 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 89F4A40430 for ; Tue, 15 Oct 2024 10:52:44 +0000 (UTC) X-Virus-Scanned: amavis at osuosl.org Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavis, port 10024) with ESMTP id qJAM1lhbwWro for ; Tue, 15 Oct 2024 10:52:43 +0000 (UTC) Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=45.249.212.188; helo=szxga02-in.huawei.com; envelope-from=linyunsheng@huawei.com; receiver= DMARC-Filter: OpenDMARC Filter v1.4.2 smtp2.osuosl.org 325AC403FF DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 325AC403FF Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by smtp2.osuosl.org (Postfix) with ESMTPS id 325AC403FF for ; Tue, 15 Oct 2024 10:52:41 +0000 (UTC) Received: from mail.maildlp.com (unknown [172.19.88.105]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4XSW8J5gS7zfdGR; Tue, 15 Oct 2024 18:50:08 +0800 (CST) Received: from dggpemf200006.china.huawei.com (unknown [7.185.36.61]) by mail.maildlp.com (Postfix) with ESMTPS id 5FC56140257; Tue, 15 Oct 2024 18:52:35 +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; Tue, 15 Oct 2024 18:52:35 +0800 Message-ID: <5d9ea7bd-67bb-4a9d-a120-c8f290c31a47@huawei.com> Date: Tue, 15 Oct 2024 18:52:34 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: Jakub Kicinski References: <20240925075707.3970187-1-linyunsheng@huawei.com> <20241014171406.43e730c9@kernel.org> Content-Language: en-US From: Yunsheng Lin In-Reply-To: <20241014171406.43e730c9@kernel.org> 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-Mailman-Original-Authentication-Results: smtp2.osuosl.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Subject: Re: [Intel-wired-lan] [PATCH net v2 0/2] fix two bugs related to page_pool X-BeenThere: intel-wired-lan@osuosl.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel Wired Ethernet Linux Kernel Driver Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-mediatek@lists.infradead.org, Jesper Dangaard Brouer , Daniel Borkmann , netdev@vger.kernel.org, John Fastabend , Alexei Starovoitov , Alexander Duyck , linux-kernel@vger.kernel.org, Alexander Lobakin , IOMMU , liuyonglong@huawei.com, Matthias Brugger , intel-wired-lan@lists.osuosl.org, zhangkun09@huawei.com, fanghaiqing@huawei.com, bpf@vger.kernel.org, pabeni@redhat.com, Robin Murphy , davem@davemloft.net, linux-arm-kernel@lists.infradead.org, AngeloGioacchino Del Regno Errors-To: intel-wired-lan-bounces@osuosl.org Sender: "Intel-wired-lan" On 2024/10/15 8:14, Jakub Kicinski wrote: > On Sat, 12 Oct 2024 20:05:31 +0800 Yunsheng Lin wrote: >> 1. Semantics changing of supporting unlimited inflight pages >> to limited inflight pages that are as large as the pool_size >> of page_pool. > > How can this possibly work? As a similar comment in [1], do we really need unlimited inflight pages for the page_pool to work? If we do, it seems there is something really need fixing here. I am agreed changing of semantics here might introduce regressions here because there may be some subsystem depending on the previous semantics or incorrect calculating of how many inflight pages it is needed, so I am agreed that it might be better to target the net-next tree to give some cycles of testing before backporting it. 1. https://lore.kernel.org/all/842c8cc6-f716-437a-bc98-70bc26d6fd38@huawei.com/ > > The main thing stopping me from reposting my fix that it'd be nice to > figure out if a real IOMMU device is bound or not. If we don't have device_iommu_mapped() might be used to check if a real IOMMU device is bound or not. I am afraid it is not just about IOMMU here as there might be other resource behind the dma mapping, like the bounce buffer memory as below: https://elixir.bootlin.com/linux/v6.7-rc8/source/drivers/iommu/dma-iommu.c#L1204 https://elixir.bootlin.com/linux/v6.7-rc8/source/kernel/dma/direct.h#L125 And we may argue is_swiotlb_active() can be used check if there is any bounce buffer memory behind the dma mapping as the device_iommu_mapped() does, but I am not sure if there is any other resource besides iommu and bounce buffer. > real per-device mappings we presumably don't have to wait. If we can For not having to wait part: I am not sure if the page_pool_destroy()/__page_pool_release_page_dma() need to synchronize with arch_teardown_dma_ops() or how to synchronize with it, as it seems to be called when driver unloading even if we have ensured that there is no IOMMU or bounce buffer memory behind the device by the above checking: __device_release_driver -> device_unbind_cleanup -> arch_teardown_dma_ops > check this condition we are guaranteed not to introduce regressions, > since we would be replacing a crash by a wait, which is strictly better. For the waiting part: The problem is how much time we need to wait when device_iommu_mapped() or is_swiotlb_active() return true here, as mentioned in [2], [3]. And currently the waiting might be infinite as the testing in [4]. > > If we'd need to fiddle with too many internals to find out if we have > to wait - let's just always wait and see if anyone complains. Does the testing report in [4] classify as someone complaining? As the driver unloading seems to be stalling forever, and the cause of the infinite stalling is skb_attempt_defer_free() by debugging as mentioned in [2]. 2. https://lore.kernel.org/all/2c5ccfff-6ab4-4aea-bff6-3679ff72cc9a@huawei.com/ 3. https://lore.kernel.org/netdev/d50ac1a9-f1e2-49ee-b89b-05dac9bc6ee1@huawei.com/ 4. https://lore.kernel.org/netdev/758b4d47-c980-4f66-b4a4-949c3fc4b040@huawei.com/ >