> On Jul 20, 2023, at 4:00 PM, Alan Huang <mmpgouride@xxxxxxxxx> wrote: > > >> 2023年7月21日 03:22，Eric Dumazet <edumazet@xxxxxxxxxx> 写道： >> >>> On Thu, Jul 20, 2023 at 8:54 PM Alan Huang <mmpgouride@xxxxxxxxx> 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@xxxxxxxxxxxxxx/ > > So, my real question is: With READ_ONCE(ptr->field), are there still some unusual cases where gcc > decides not to reload ptr->field? I am a bit doubtful there will be strong (any?) interest in replacing the barrier() with READ_ONCE() without any tangible reason, regardless of whether a gcc issue was fixed. But hey, if you want to float the idea… Thanks, - Joel > >> >> Do you have a patch for review ? > > Possibly next month. :) > >> >> >>> >>> >>> [1] https://lore.kernel.org/all/1369699930.3301.494.camel@edumazet-glaptop/ >>> >>> Thanks, >>> Alan >
