Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp434061ybi; Fri, 7 Jun 2019 10:25:29 -0700 (PDT) X-Google-Smtp-Source: APXvYqyFxgXWx5pfawi++r1JosX9aVKLuiGVQKc3BD8IKC8NGOyoKHN+Y0mSJkICKJbs1rzuO4rc X-Received: by 2002:a63:b547:: with SMTP id u7mr4061908pgo.322.1559928329649; Fri, 07 Jun 2019 10:25:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1559928329; cv=none; d=google.com; s=arc-20160816; b=eolmEq3GvQv6oAvbO05Q1uG3cDbpqWEkHC6jLjQPccVUOQ6PrBD5Mn3Gizn8H6PiK7 vrTFvD/FCIz/t8G9EqfkLnzFHEr16PrdO1s9k+gTbp6M2znodRoymhzEvN+QLnHnusP1 U30JWIYFDSiZDEE+QMxHoQBC3PXuMrPXVDvWIxOay89hF9Q7NBQv+XKRosnfx+Bxl2Zm Xm9CNLK1PxOqA+XrAsmWvBtRnxOMU1d3jNIgC1E/Zva/g7C+5DJ3vTf3LerOoRP7DDED 94Mkqdyo7wAFOJ4sj7Av9kVfxl+LqMZEicYzrkLIfgWthZLyoYzPyOSbqcdSCQCKY7dH kvjQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=ECQiMpH2pU4ni/frr5VGeoPwYlJwV51HUxIm7LLq+nY=; b=hIZKr+k6kxKqZAoT2IgsVT5HzW89T2mm7FJxSIuhPK75cv/OXkRDBDPUauc6+V5xPQ WhqiMuDQc7zxzUgXQJG8Y05kwXNPze5xKyO9idC2Ms0BUux9TkzqzOMK64LkKQwF7H5+ maEffu7yqHk6jrUsCYJLbnqOag+SJQ7NP0WWurY5cPrmI7w6BG4g87PNaxw7F+qk93nR 2IaQqsN6uekJkIU2tt12XMSycqUkWf9zz6Uq6W59BZb/Ph5XlSHAF0iwZtOIJ/Zjmh35 25ux7gNuwe7Q9C6Q6aRfVWzPNYEx1pYYldRBtOYHtNElAmbEvPmbziEMIG5COv4KJZiv GSVQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m5si2560349pgc.136.2019.06.07.10.25.12; Fri, 07 Jun 2019 10:25:29 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729951AbfFGPcr (ORCPT + 99 others); Fri, 7 Jun 2019 11:32:47 -0400 Received: from helcar.hmeau.com ([216.24.177.18]:44212 "EHLO deadmen.hmeau.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728797AbfFGPcr (ORCPT ); Fri, 7 Jun 2019 11:32:47 -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 1hZGr6-0000Wb-T4; Fri, 07 Jun 2019 23:32:36 +0800 Received: from herbert by gondobar with local (Exim 4.89) (envelope-from ) id 1hZGqw-0007N0-7k; Fri, 07 Jun 2019 23:32:26 +0800 Date: Fri, 7 Jun 2019 23:32:26 +0800 From: Herbert Xu To: Eric Dumazet Cc: Linus Torvalds , Alan Stern , "Paul E. McKenney" , Boqun Feng , Frederic Weisbecker , Fengguang Wu , LKP , LKML , Netdev , "David S. Miller" , Andrea Parri , Luc Maranget , Jade Alglave Subject: Re: inet: frags: Turn fqdir->dead into an int for old Alphas Message-ID: <20190607153226.gzt4yeq5c5i6bpqd@gondor.apana.org.au> References: <20190603200301.GM28207@linux.ibm.com> <20190607140949.tzwyprrhmqdx33iu@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: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jun 07, 2019 at 08:26:12AM -0700, Eric Dumazet wrote: > > There is common knowledge among us programmers that bit fields > (or bool) sharing a common 'word' need to be protected > with a common lock. > > Converting all bit fields to plain int/long would be quite a waste of memory. > > In this case, fqdir_exit() is called right before the whole > struct fqdir is dismantled, and the only cpu that could possibly > change the thing is ourself, and we are going to start an RCU grace period. > > Note that first cache line in 'struct fqdir' is read-only. > Only ->dead field is flipped to one at exit time. > > Your patch would send a strong signal to programmers to not even try using > bit fields. > > Do we really want that ? If this were a bitfield then I'd think it would be safer because anybody adding a new bitfield is unlikely to try modifying both fields without locking or atomic ops. However, because this is a boolean, I can certainly see someone else coming along and adding another bool right next to it and expecting writes them to still be atomic. As it stands, my patch has zero impact on memory usage because it's simply using existing padding. Should this become an issue in future, we can always revisit this and use a more appropriate method of addressing it. But the point is to alert future developers that this field is not an ordinary boolean. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt