netdev - Re: [PATCH net-next v5 2/2] page_pool: Track DMA-mapped pages and unmap them when destroying the pool

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <6cd5a1dc-b938-46f3-8957-c2d99921f95c@huawei.com>
Date: Wed, 2 Apr 2025 19:15:50 +0800
From: Yunsheng Lin <linyunsheng@...wei.com>
To: Alexander Lobakin <aleksander.lobakin@...el.com>
CC: Zhu Yanjun <yanjun.zhu@...ux.dev>,
	Toke Høiland-Jørgensen <toke@...hat.com>, "David S.
 Miller" <davem@...emloft.net>, Jakub Kicinski <kuba@...nel.org>, Jesper
 Dangaard Brouer <hawk@...nel.org>, Saeed Mahameed <saeedm@...dia.com>, Leon
 Romanovsky <leon@...nel.org>, Tariq Toukan <tariqt@...dia.com>, Andrew Lunn
	<andrew+netdev@...n.ch>, Eric Dumazet <edumazet@...gle.com>, Paolo Abeni
	<pabeni@...hat.com>, Ilias Apalodimas <ilias.apalodimas@...aro.org>, Simon
 Horman <horms@...nel.org>, Andrew Morton <akpm@...ux-foundation.org>, Mina
 Almasry <almasrymina@...gle.com>, Yonglong Liu <liuyonglong@...wei.com>,
	Pavel Begunkov <asml.silence@...il.com>, Matthew Wilcox
	<willy@...radead.org>, <netdev@...r.kernel.org>, <bpf@...r.kernel.org>,
	<linux-rdma@...r.kernel.org>, <linux-mm@...ck.org>, Qiuling Ren
	<qren@...hat.com>, Yuying Ma <yuma@...hat.com>
Subject: Re: [PATCH net-next v5 2/2] page_pool: Track DMA-mapped pages and
 unmap them when destroying the pool

On 2025/4/1 19:56, Alexander Lobakin wrote:

...

>> There are two reading of dma_sync in this patch, the first reading is not
>> under rcu read lock and doing the reading without READ_ONCE(), the second
>> reading is under rcu read lock and do the reading with READ_ONCE().
>>
>> The first one seems an optimization to avoid taking the rcu read lock,
>> why might need READ_ONCE() to make KCSAN happy if we do care about making
>> KCSAN happy.
>>
>> The second one does not seems to need the atomicity by using the READ_ONCE()
>> as it is always under RCU read lock(implicit or explicit one), and there is
>> a rcu sync after the clearing of that bit.
> 
> IOW, are you saying this change is not needed at all?

It is not needed unless KCSAN is not happy about this and we really want to make
KCSAN happy about it as my understanding.