[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <28815527-83bd-b139-a162-0ed927b88fe5@gmail.com>
Date: Wed, 29 May 2019 14:30:16 -0700
From: Eric Dumazet <eric.dumazet@...il.com>
To: Herbert Xu <herbert@...dor.apana.org.au>,
Eric Dumazet <edumazet@...gle.com>
Cc: David Miller <davem@...emloft.net>,
netdev <netdev@...r.kernel.org>,
Eric Dumazet <eric.dumazet@...il.com>,
syzbot <syzkaller@...glegroups.com>
Subject: Re: [PATCH] inet: frags: Remove unnecessary
smp_store_release/READ_ONCE
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 <herbert@...dor.apana.org.au>
>
SGTM, thanks.
Reviewed-by: Eric Dumazet <edumazet@...gle.com>
David, this targets net-next tree :)
Powered by blists - more mailing lists