From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from szxga05-in.huawei.com (szxga05-in.huawei.com [45.249.212.191]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 298EB18B466 for ; Mon, 11 Nov 2024 11:31:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=45.249.212.191 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1731324687; cv=none; b=PwulqcqO9eYnNWMVHDKbXQSSYqO9VVuk7/NbRtbap0i5HuxxAP2Z3RYvXBlGbj9QBRWtDHN0kzfW6DvqrbdF9apbOwOnBwwHdkhiEPScZmIbwSIbZc1gKMQjAH1iM1+utrykfWW8lsYWTvaTT2M9JzjmHf8mO7YYYHXYYzVs8JY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1731324687; c=relaxed/simple; bh=byO06VlftwJVrxXzWWMMcmptQKF3tyHFGekyDgcW5LY=; h=Message-ID:Date:MIME-Version:Subject:From:To:CC:References: In-Reply-To:Content-Type; b=FK25pDdnGYiAbT0RZ33bdpkflTF0U3YaVffS2ETSAfNFmsVjstLXu3bLnlb2l5zGl26gl2/+DeVJoiPgGy9lrS/ikoFllaCpPFODcI57CuXiiKxayaTdHs030yYyr3sqk4XG/1KkmEqZpDqtZi+Yf1aVh2roTWxecoqJZgBx6+c= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; arc=none smtp.client-ip=45.249.212.191 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Received: from mail.maildlp.com (unknown [172.19.163.17]) by szxga05-in.huawei.com (SkyGuard) with ESMTP id 4Xn6h05zhdz28fSh; Mon, 11 Nov 2024 19:26:40 +0800 (CST) Received: from dggpemf200006.china.huawei.com (unknown [7.185.36.61]) by mail.maildlp.com (Postfix) with ESMTPS id 6929B1A0188; Mon, 11 Nov 2024 19:31:22 +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; Mon, 11 Nov 2024 19:31:22 +0800 Message-ID: <4564c77b-a54d-4307-b043-d08e314c4c5f@huawei.com> Date: Mon, 11 Nov 2024 19:31:21 +0800 Precedence: bulk X-Mailing-List: iommu@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: 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 From: Yunsheng Lin To: Jesper Dangaard Brouer , =?UTF-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= , , , CC: , , , Robin Murphy , Alexander Duyck , IOMMU , Andrew Morton , Eric Dumazet , Ilias Apalodimas , , , , kernel-team 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> Content-Language: en-US In-Reply-To: <204272e7-82c3-4437-bb0d-2c3237275d1f@huawei.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-ClientProxiedBy: dggems706-chm.china.huawei.com (10.3.19.183) To dggpemf200006.china.huawei.com (7.185.36.61) On 2024/10/26 15:33, Yunsheng Lin wrote: ... >>> >>> AFAIU Jakub's comment on his RFC patch for waiting, he was suggesting >>> exactly this: Add the wait, and see if the cases where it can stall turn >>> out to be problems in practice. >> >> +1 >> >> I like Jakub's approach. > > As mentioned in Toke's comment, I am still not convinced that there is some > easy way of waiting here, doing the kick in the kernel space is hard enough, > I am not even sure if kick need to be done or how it can be done in the user > space if some page_pool owned page is held from user space for the cases of zero > rx copy, io_uring and devmem tcp? killing the userspace app? > > If you and Toke still think the waiting is the way out for the problem here, maybe > we should wait for jakub's opinion and let him decide if he want to proceed with > his waiting patch. Is there any other suggestion/concern about how to fix the problem here? >From the previous discussion, it seems the main concern about tracking the inflight pages is about how many inflight pages it is needed. If there is no other suggestion/concern , it seems the above concern might be addressed by using pre-allocated memory to satisfy the mostly used case, and use the dynamically allocated memory if/when necessary.