| 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
| ||
|
Message-Id: <E9CF24C7-3080-4720-B540-BAF03068336B@gmail.com> Date: Fri, 21 Jul 2023 03:59:33 +0800 From: Alan Huang <mmpgouride@...il.com> To: Eric Dumazet <edumazet@...gle.com> Cc: linux-kernel@...r.kernel.org, netdev@...r.kernel.org, rcu@...r.kernel.org, "Paul E. McKenney" <paulmck@...nel.org>, roman.gushchin@...ux.dev Subject: Re: Question about the barrier() in hlist_nulls_for_each_entry_rcu() > 2023年7月21日 03:22，Eric Dumazet <edumazet@...gle.com> 写道： > > On Thu, Jul 20, 2023 at 8:54 PM Alan Huang <mmpgouride@...il.com> wrote: >> >> Hi, >> >> I noticed a commit c87a124a5d5e(“net: force a reload of first item in hlist_nulls_for_each_entry_rcu”) >> and a related discussion [1]. >> >> After reading the whole discussion, it seems like that ptr->field was cached by gcc even with the deprecated >> ACCESS_ONCE(), so my question is: >> >> Is that a compiler bug? If so, has this bug been fixed today, ten years later? >> >> What about READ_ONCE(ptr->field)? > > Make sure sparse is happy. It caused a problem without barrier(), and the deprecated ACCESS_ONCE() didn’t help: https://lore.kernel.org/all/519D19DA.50400@yandex-team.ru/ So, my real question is: With READ_ONCE(ptr->field), are there still some unusual cases where gcc decides not to reload ptr->field? > > Do you have a patch for review ? Possibly next month. :) > > >> >> >> [1] https://lore.kernel.org/all/1369699930.3301.494.camel@edumazet-glaptop/ >> >> Thanks, >> Alan
Powered by blists - more mailing lists