From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_NEOMUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3EA60C04AB3 for ; Wed, 29 May 2019 05:48:07 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 10C8E20B1F for ; Wed, 29 May 2019 05:48:07 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725888AbfE2FsG (ORCPT ); Wed, 29 May 2019 01:48:06 -0400 Received: from helcar.hmeau.com ([216.24.177.18]:50838 "EHLO deadmen.hmeau.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725856AbfE2FsF (ORCPT ); Wed, 29 May 2019 01:48:05 -0400 Received: from gondobar.mordor.me.apana.org.au ([192.168.128.4] helo=gondobar) by deadmen.hmeau.com with esmtps (Exim 4.89 #2 (Debian)) id 1hVrRT-0004Cn-7n; Wed, 29 May 2019 13:48:03 +0800 Received: from herbert by gondobar with local (Exim 4.89) (envelope-from ) id 1hVrRP-00036h-Sh; Wed, 29 May 2019 13:47:59 +0800 Date: Wed, 29 May 2019 13:47:59 +0800 From: Herbert Xu To: Dmitry Vyukov Cc: Eric Dumazet , David Miller , netdev , Eric Dumazet , syzbot Subject: Re: [PATCH] inet: frags: Remove unnecessary smp_store_release/READ_ONCE Message-ID: <20190529054759.qrw7h73g62mnbica@gondor.apana.org.au> References: <20190524160340.169521-12-edumazet@google.com> <20190528063403.ukfh37igryq4u2u6@gondor.apana.org.au> <20190529054026.fwcyhzt33dshma4h@gondor.apana.org.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Wed, May 29, 2019 at 07:43:51AM +0200, Dmitry Vyukov wrote: > > If fqdir->dead read/write are concurrent, then this still needs to be > READ_ONCE/WRITE_ONCE. Ordering is orthogonal to atomicity. No they do not. READ_ONCE/WRITE_ONCE are basically a more fine-tuned version of barrier(). In this case we already have an implicit barrier() call due to the memory barrier semantics so this is simply unnecessary. It's the same reason you don't need READ_ONCE/WRITE_ONCE when you do: CPU1 CPU2 ---- ---- spin_lock shared_var = 1 spin_lock spin_unlock if (shared_var == 1) ... spin_unlock Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt