On 5/28/19 10:40 PM, Herbert Xu wrote:
> I see now that it is actually relying on the barrier/locking
> semantics of call_rcu vs. rcu_read_lock. So the smp_store_release
> and READ_ONCE are simply unnecessary and could be confusing to
> future readers.
>
> ---8<---
> The smp_store_release call in fqdir_exit cannot protect the setting
> of fqdir->dead as claimed because its memory barrier is only
> guaranteed to be one-way and the barrier precedes the setting of
> fqdir->dead.
>
> IOW it doesn't provide any barriers between fq->dir and the following
> hash table destruction.
>
> In fact, the code is safe anyway because call_rcu does provide both
> the memory barrier as well as a guarantee that when the destruction
> work starts executing all RCU readers will see the updated value for
> fqdir->dead.
>
> Therefore this patch removes the unnecessary smp_store_release call
> as well as the corresponding READ_ONCE on the read-side in order to
> not confuse future readers of this code. Comments have been added
> in their places.
>
> Signed-off-by: Herbert Xu <herb...@gondor.apana.org.au>
>
SGTM, thanks.
Reviewed-by: Eric Dumazet <eduma...@google.com>
David, this targets net-next tree :)
