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 E007DC3601E for ; Mon, 7 Apr 2025 11:26:41 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CC07B6B0005; Mon, 7 Apr 2025 07:26:39 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C49506B0007; Mon, 7 Apr 2025 07:26:39 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AC3676B0008; Mon, 7 Apr 2025 07:26:39 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 8A5176B0005 for ; Mon, 7 Apr 2025 07:26:39 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 9A63EBAEBB for ; Mon, 7 Apr 2025 11:26:40 +0000 (UTC) X-FDA: 83307020160.05.EE18009 Received: from szxga05-in.huawei.com (szxga05-in.huawei.com [45.249.212.191]) by imf08.hostedemail.com (Postfix) with ESMTP id 0AA6F160007 for ; Mon, 7 Apr 2025 11:26:37 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=none; spf=pass (imf08.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=1744025198; 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=d/bgo7RZTffKXGyW96jTKF1dhhe1AvND2kKMZQC7Kno=; b=bOIv6QQ/Fa7fqllp7HAfm48dzE73Tf18yNftQC6aLKhjqyQs6erTZNhYj6cGCWwWsJVnt3 lusL/77MGQasy+Mvt373VGGONZBVegwT+UhPYTHU7HQ4t/++23nvo2vT8ujVAPYZElmhth GMEQwyh/UOAht04S48/eKgyPG/p5SUo= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=none; spf=pass (imf08.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-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1744025198; a=rsa-sha256; cv=none; b=Ir4ZTE1XJxPKshlc2umCtK69QcK5cYV5W7Vt2cO6d8f7ZtItARRObHeGp+MElF7fxdqAT1 4FAOySlXRq72cCHgv/J/Gii0/9VTVOOO5Gkf0gH5WAi0i2Y447/EBSE3IxAFb8O1PghAcW b7KhXY4dHzkbnk/jfkyO4vckzgW5VX0= Received: from mail.maildlp.com (unknown [172.19.162.112]) by szxga05-in.huawei.com (SkyGuard) with ESMTP id 4ZWRcM21ZGz1k1BJ; Mon, 7 Apr 2025 19:21:39 +0800 (CST) Received: from dggpemf200006.china.huawei.com (unknown [7.185.36.61]) by mail.maildlp.com (Postfix) with ESMTPS id D5CFB1400DA; Mon, 7 Apr 2025 19:26:33 +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, 7 Apr 2025 19:26:33 +0800 Message-ID: Date: Mon, 7 Apr 2025 19:26:33 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH net-next v7 2/2] page_pool: Track DMA-mapped pages and unmap them when destroying the pool To: =?UTF-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= , Alexander Lobakin CC: "David S. Miller" , Jakub Kicinski , Jesper Dangaard Brouer , Saeed Mahameed , Leon Romanovsky , Tariq Toukan , Andrew Lunn , Eric Dumazet , Paolo Abeni , Ilias Apalodimas , Simon Horman , Andrew Morton , Mina Almasry , Yonglong Liu , Pavel Begunkov , Matthew Wilcox , , , , , Qiuling Ren , Yuying Ma References: <20250404-page-pool-track-dma-v7-0-ad34f069bc18@redhat.com> <20250404-page-pool-track-dma-v7-2-ad34f069bc18@redhat.com> <3b933890-7ff2-4aaf-aea5-06e5889ca087@intel.com> <87jz7yhix3.fsf@toke.dk> Content-Language: en-US From: Yunsheng Lin In-Reply-To: <87jz7yhix3.fsf@toke.dk> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit 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-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: 0AA6F160007 X-Stat-Signature: 9je3hpuwiip6s4bidrgyso5dz19gub9b X-Rspam-User: X-HE-Tag: 1744025197-995015 X-HE-Meta: U2FsdGVkX19hVb0rITmY+76ov+9O16G5f+ijdwQDkbMQAc8UDr8xp0kAN+Oukf3eoVe7Q/S3o1GSMIR3t6SgtH1o7LnwmY2qmfW1pNBp2tbXDUMtX1rTIirifaKnzjodhD05L7v5yqUSUH7NoL6A3Dho0bBf63ReZeGc88QWhACQHwsIQcM6SUUjd6tKfCz7KZ0b5DjILZIXkjKWLulzyCKF7pByQOR3uyY9lS1my3dEza/+pUHS+KCrxDNz1Jpyy1pj2DpNDfMs4Y6IudTS96yAlpJwo7LvRWiI5ocjSd3cWJlT7zcdari5/4dWYYOhD6u/ZnEDBqufn7QUX+958hoyIm5Xus5CjTDYH/+9LILGvN0q2mxGf1BMLmlY7divuSgwI0ioljqU7YnXVkq8231IanMzHHpM7bDafumdMaVsqrvj9KCUUz0Q0kQaSQQwb3FA12aT1L8HG5FSq6LifMOZgHVQp6ivKLbr8+QgZLmS6dZjySnDN9Z184p29eWPlk/gOoLp8cFGqWQ/Zqb5SgHqPlEBd9+oXP7Baef/rMrexkgHywSZM6kY2pe011vWcw/tFJimNZMvGU56lbLpLCMiJ0NPQ0pVx7KD1UOY2+OqKMLmm53RtqVMpXHMjWgzkTgGu6lg4MIUW7gZkPhH0Xcv4QUp0jQa1fVMqki2KX4NROBcHkuV07dUhvbPN3CA8x0Io6kTFevPybhTKy+Xl1WjDjHqcIFCgcA/9+dilJnuSk9yDk8qYVdF3sQvzqVjhtKNQ31klD93X3ueKMcDq/Jw1ThZOnFWiF3BuyuiARAgTt+faW6U4RSF6tDTCIluYgsUSg+vXpoYg07KzWyPDLSdWDdgmX+Wkc6Y1dUDz/TPDHby6fqssRHV4dKyGKpdYw+jhgTtRdo8WFkOpNjIJRTC9rAVCGYcxmtDf3MVx3Z0Ec3SQkbg7loiDLKa3Fw0G5dvhyizeCqNPlkeyGx uKjYnic0 j1JKjssYo2QDyOEEU+bHkML9ZvQFbmn4uLcpAtZH+MT9/RYSG6R6lopo2D8YLLoreh8IlUlPAaIuum4MiApiVph1/awjJ0+CiLgQyiE9z9IO6hy4oB6QCbxZrMpSosk2iUGF8IUSeNQsa80XIPWME9jLVUyyvxZ1SX7e4rLP3uWK2GqVOwBOcTHdEGJzTlRD2I6RKQ0Sq2DRcrGoQdtwiu9VDzEGd2g0hBi8hK7qy6NXvTy/rZASvDI1QjeFH6eLK8JtJjWz4l4KRWjwi6qYbt8WhNhMwhf9zP4OtfV/qxNiWFwCzCnzp3IYzTSNkYInnkd7CvEaTO/Fg/vrR7zBU7udpDbC5HaXKarzmxl2bKz2HoSXKm0RAjjfQ4Q== 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 2025/4/5 20:50, Toke Høiland-Jørgensen wrote: > Alexander Lobakin writes: > >> From: Alexander Lobakin >> Date: Fri, 4 Apr 2025 17:55:43 +0200 >> >>> From: Toke Høiland-Jørgensen >>> Date: Fri, 04 Apr 2025 12:18:36 +0200 >>> >>>> When enabling DMA mapping in page_pool, pages are kept DMA mapped until >>>> they are released from the pool, to avoid the overhead of re-mapping the >>>> pages every time they are used. This causes resource leaks and/or >>>> crashes when there are pages still outstanding while the device is torn >>>> down, because page_pool will attempt an unmap through a non-existent DMA >>>> device on the subsequent page return. >>> >>> [...] >>> >>>> -#define PP_MAGIC_MASK ~0x3UL >>>> +#define PP_MAGIC_MASK ~(PP_DMA_INDEX_MASK | 0x3UL) >>>> >>>> /** >>>> * struct page_pool_params - page pool parameters >>>> @@ -173,10 +212,10 @@ struct page_pool { >>>> int cpuid; >>>> u32 pages_state_hold_cnt; >>>> >>>> - bool has_init_callback:1; /* slow::init_callback is set */ >>>> + bool dma_sync; /* Perform DMA sync for device */ >>> >>> Yunsheng said this change to a full bool is redundant in the v6 thread >>> ¯\_(ツ)_/¯ > > AFAIU, the comment was that the second READ_ONCE() when reading the > field was redundant, because of the rcu_read_lock(). Which may be the > case, but I think keeping it makes the intent of the code clearer. And > in any case, it has nothing to do with changing the type of the field... For changing the type of the field part, there are only two outcomes here when using bit field here: 1. The reading returns a correct value. 2. The reading returns a incorrect value. So the question seems to be what would possibly go wrong when the reading return an incorrect value when there is an additional reading under the rcu read lock and there is a rcu sync after clearing pool->dma_sync? Considering we only need to ensure there is no dma sync API called after rcu sync. And it seems data_race() can be used to mark the above reading so that KCSAN will not complain. IOW, changing the type of the field part isn't that necessary as my understanding.