Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp408783ybi; Fri, 7 Jun 2019 10:01:28 -0700 (PDT) X-Google-Smtp-Source: APXvYqzpUHW0ieTO6+WhVDYNgoPgpzyLvpipaR0mdcgCCbzFE+b4ovw4cF4qeEA9wndBDms/VZ1B X-Received: by 2002:a62:5487:: with SMTP id i129mr56954930pfb.68.1559926888673; Fri, 07 Jun 2019 10:01:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1559926888; cv=none; d=google.com; s=arc-20160816; b=enSv51RMePIVuwGW56VutDlFrOGDElzEzZ2oD/6Om+x4F/4NBG2O5MG14xy+vhUAFX p8S95du7Jg51zg1EfWsuzsmPc9+pjbKkE5bT6uTHkUBV/K6/jRaj6N1BxeJXNOUYXsbQ dMKPHbsI7oC7jJLmVL21xBv3eHyfdC7uosGUHMHNrMnl0ezg1gyS0JPTaUrtUZrpjUEK YRrbzfLLuCDbLJy4JXcGdEbaFgNy6xlR+/h5wnh4KJ8HDplbM4oYhmjikUZXd3+qyOHA HOpPunKfi2COA2MjFFkqt59lPG1YWTi8XjeWR8DllrBjAnAEjexmx3i1GUd4BgkGSDqx g2kQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature; bh=XVGisPA/tmje+GMmiDK8OnPmVMVeg+5zpouDsmuezH0=; b=XEAnI3z6Aordfd37MGtnKTamKzHDmigSrfPP+UspfS0Ikzil0Z9wPGurPdS8blK2FF 3SduZwPQV5Msmf3Q7zqVL5ZoYxNXTLO3ONoGwzBm6o0XLfg1IbqAeLBqnbI7W/h4ce4F im3R8GKh93HfD12qW+Pfbuq1g3UUxwvo3MrFmNDPEPmtssBrOZBA7zfVsmuBbEeFMICo Gc8e+REK3Siy9GO3r/YpCdqRH3XmSzAaRK/05LVgv84UIu/brTS3xc2nVB1cohFe+32y LSrgwzzLDTMBokjgvQDy/eew5vqgL4nHe8rX5MmRoyM/TXak/fOjRsLHlqRt9kh8lzLJ p1fA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=Ng9VAdE1; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t4si2257784pjq.54.2019.06.07.10.01.10; Fri, 07 Jun 2019 10:01:28 -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; dkim=pass header.i=@gmail.com header.s=20161025 header.b=Ng9VAdE1; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729910AbfFGP0P (ORCPT + 99 others); Fri, 7 Jun 2019 11:26:15 -0400 Received: from mail-pl1-f195.google.com ([209.85.214.195]:40726 "EHLO mail-pl1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729878AbfFGP0P (ORCPT ); Fri, 7 Jun 2019 11:26:15 -0400 Received: by mail-pl1-f195.google.com with SMTP id a93so962164pla.7; Fri, 07 Jun 2019 08:26:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=XVGisPA/tmje+GMmiDK8OnPmVMVeg+5zpouDsmuezH0=; b=Ng9VAdE1hknVxgMRmGjp2lDv/vnEMUT819mfzZMuI8Vo6TE0MQGzCyXQIXbFSQSR9d mKrNlvkbRFOoWrF67ukGOUJy4jylKGdkI6hIa+PapCfYavrA91o8rolb+/2gcZ89PHi4 TCKXDiJaTwa1LK8hu36NqCpMeFdtpAHiDM4lDcBoesgsWJUQKalZSIuLylNn8fC6ZpPa jrw8KWHCbIrHI4lj+eQDHSVFYpOVYAS1GI7rAz/OImckqC1LWeXKUjZlS5GZhLJXoIQy Q7PudF+uPC57APLwcHvHZjgTe0n5U3Fn6YNewGQKV/dgVXu9sEBuf67YsfvDIaQIy+MF eFNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=XVGisPA/tmje+GMmiDK8OnPmVMVeg+5zpouDsmuezH0=; b=e3CBz1lCutw2gZP9krwcp9x8ZSoI7pD4t8A+sFMv1QK8iRNJH9kDcXmYV0z1IGK+ER 1w7BalgPNMKxhl/R/4S9yQDA1LPW/KvsNRuNCoJBwTrmV+1g8rT1a7d/gpQq2Hxx5CfW 9N2hep08BUmdJ4nLLZ90l249s9YOBW2APIe4r67x72KkrOfKaSJkrm8aPq+9+e2EebU9 eZLg2v/k+8MM5Zp7JlB6DGwckvfIhVnOTQQ+vOHmHr7Yw1BzEambZ2tO0z2uAcrEzvtl F1ciCatdsfK8+CJyoiSyBAPKYKj+qpmyNCTG8uRZq3Jk4C/J/DKc+3dEHI3GGuk9KUWZ jV1w== X-Gm-Message-State: APjAAAWi1FHCt3IfbltsoEJ7c0eehGtAG0dJGabnOx8jK9wGHa37Zzz8 wg5swwcovmIgE7ttHj5apqyX1Brt X-Received: by 2002:a17:902:294a:: with SMTP id g68mr57385663plb.169.1559921174428; Fri, 07 Jun 2019 08:26:14 -0700 (PDT) Received: from ?IPv6:2620:15c:2c1:200:55c7:81e6:c7d8:94b? ([2620:15c:2c1:200:55c7:81e6:c7d8:94b]) by smtp.gmail.com with ESMTPSA id j7sm2461679pfa.184.2019.06.07.08.26.13 (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Fri, 07 Jun 2019 08:26:13 -0700 (PDT) Subject: Re: inet: frags: Turn fqdir->dead into an int for old Alphas To: Herbert Xu , Linus Torvalds Cc: Alan Stern , "Paul E. McKenney" , Boqun Feng , Frederic Weisbecker , Fengguang Wu , LKP , LKML , Netdev , "David S. Miller" , Andrea Parri , Luc Maranget , Jade Alglave References: <20190603200301.GM28207@linux.ibm.com> <20190607140949.tzwyprrhmqdx33iu@gondor.apana.org.au> From: Eric Dumazet Message-ID: Date: Fri, 7 Jun 2019 08:26:12 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <20190607140949.tzwyprrhmqdx33iu@gondor.apana.org.au> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 6/7/19 7:09 AM, Herbert Xu wrote: > On Tue, Jun 04, 2019 at 09:04:55AM -0700, Linus Torvalds wrote: >> >> In fact, the alpha port was always subtly buggy exactly because of the >> "byte write turns into a read-and-masked-write", even if I don't think >> anybody ever noticed (we did fix cases where people _did_ notice, >> though, and we might still have some cases where we use 'int' for >> booleans because of alpha issues.). > > This is in fact a real bug in the code in question that no amount > of READ_ONCE/WRITE_ONCE would have caught. The field fqdir->dead is > declared as boolean so writing to it is not atomic (on old Alphas). > > I don't think it currently matters because padding would ensure > that it is in fact 64 bits long. However, should someone add another > char/bool/bitfield in this struct in future it could become an issue. > > So let's fix it. 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 ? > > ---8<-- > The field fqdir->dead is meant to be written (and read) atomically. > As old Alpha CPUs can't write a single byte atomically, we need at > least an int for it to work. > > Signed-off-by: Herbert Xu > > diff --git a/include/net/inet_frag.h b/include/net/inet_frag.h > index e91b79ad4e4a..8c458fba74ad 100644 > --- a/include/net/inet_frag.h > +++ b/include/net/inet_frag.h > @@ -14,7 +14,9 @@ struct fqdir { > int max_dist; > struct inet_frags *f; > struct net *net; > - bool dead; > + > + /* We can't use boolean because this needs atomic writes. */ > + int dead; > > struct rhashtable rhashtable ____cacheline_aligned_in_smp; > > diff --git a/net/ipv4/inet_fragment.c b/net/ipv4/inet_fragment.c > index 35e9784fab4e..05aa7c145817 100644 > --- a/net/ipv4/inet_fragment.c > +++ b/net/ipv4/inet_fragment.c > @@ -193,7 +193,7 @@ void fqdir_exit(struct fqdir *fqdir) > { > fqdir->high_thresh = 0; /* prevent creation of new frags */ > > - fqdir->dead = true; > + fqdir->dead = 1; > > /* call_rcu is supposed to provide memory barrier semantics, > * separating the setting of fqdir->dead with the destruction >