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=-2.5 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_MUTT 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 6E4D7C28CC5 for ; Sat, 8 Jun 2019 15:32:52 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 3F3E021537 for ; Sat, 8 Jun 2019 15:32:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727273AbfFHPcu (ORCPT ); Sat, 8 Jun 2019 11:32:50 -0400 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:59268 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727220AbfFHPct (ORCPT ); Sat, 8 Jun 2019 11:32:49 -0400 Received: from pps.filterd (m0098421.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x58FQkgC016440; Sat, 8 Jun 2019 11:32:32 -0400 Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com with ESMTP id 2t090rap3p-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 08 Jun 2019 11:32:32 -0400 Received: from m0098421.ppops.net (m0098421.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.27/8.16.0.27) with SMTP id x58FSses019803; Sat, 8 Jun 2019 11:32:31 -0400 Received: from ppma01dal.us.ibm.com (83.d6.3fa9.ip4.static.sl-reverse.com [169.63.214.131]) by mx0a-001b2d01.pphosted.com with ESMTP id 2t090rap3f-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 08 Jun 2019 11:32:31 -0400 Received: from pps.filterd (ppma01dal.us.ibm.com [127.0.0.1]) by ppma01dal.us.ibm.com (8.16.0.27/8.16.0.27) with SMTP id x58DVEBe013007; Sat, 8 Jun 2019 13:39:47 GMT Received: from b01cxnp23034.gho.pok.ibm.com (b01cxnp23034.gho.pok.ibm.com [9.57.198.29]) by ppma01dal.us.ibm.com with ESMTP id 2t04n5kgsm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 08 Jun 2019 13:39:47 +0000 Received: from b01ledav003.gho.pok.ibm.com (b01ledav003.gho.pok.ibm.com [9.57.199.108]) by b01cxnp23034.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id x58FWTG542598856 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 8 Jun 2019 15:32:29 GMT Received: from b01ledav003.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id BC68BB2065; Sat, 8 Jun 2019 15:32:29 +0000 (GMT) Received: from b01ledav003.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 9F6A7B205F; Sat, 8 Jun 2019 15:32:29 +0000 (GMT) Received: from paulmck-ThinkPad-W541 (unknown [9.85.180.36]) by b01ledav003.gho.pok.ibm.com (Postfix) with ESMTP; Sat, 8 Jun 2019 15:32:29 +0000 (GMT) Received: by paulmck-ThinkPad-W541 (Postfix, from userid 1000) id 8DB3916C3421; Sat, 8 Jun 2019 08:27:07 -0700 (PDT) Date: Sat, 8 Jun 2019 08:27:07 -0700 From: "Paul E. McKenney" To: Linus Torvalds Cc: Eric Dumazet , Herbert Xu , Alan Stern , 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: <20190608152707.GF28207@linux.ibm.com> Reply-To: paulmck@linux.ibm.com 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: Mutt/1.5.21 (2010-09-15) X-TM-AS-GCONF: 00 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-06-08_07:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1906080116 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 09:19:42AM -0700, Linus Torvalds wrote: > On Fri, Jun 7, 2019 at 8:26 AM 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. > > Yeah, and we really don't care about alpha. So 'char' should be safe. > > No compiler actually turns a 'bool' in a struct into a bitfield, > afaik, because you're still supposed to be able to take the address of > a boolean. > > But on the whole, I do not believe that we should ever use 'bool' in > structures anyway, because it's such a badly defined type. I think > it's 'char' in practice on just about all architectures, but there > really were traditional use cases where 'bool' was int. > > But: > > - we shouldn't turn them into 'int' anyway - alpha is dead, and no > sane architecture will make the same mistake anyway. People learnt. > > - we might want to make sure 'bool' really is 'char' in practice, to > double-check that fthe compiler doesn't do anything stupid. > > - bitfields obviously do need locks. 'char' does not. > > If there's somebody who really notices the alpha issue in PRACTICE, we > can then bother to fix it. But there is approximately one user, and > it's not a heavy-duty one. C11 and later compilers are supposed to use read-modify-write atomic operations in this sort of situation anyway because they are not supposed to introduce data races. So if this problem comes up, the fix should be in GCC rather than the Linux kernel, right? Thanx, Paul