[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190608152707.GF28207@linux.ibm.com>
Date: Sat, 8 Jun 2019 08:27:07 -0700
From: "Paul E. McKenney" <paulmck@...ux.ibm.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Eric Dumazet <eric.dumazet@...il.com>,
Herbert Xu <herbert@...dor.apana.org.au>,
Alan Stern <stern@...land.harvard.edu>,
Boqun Feng <boqun.feng@...il.com>,
Frederic Weisbecker <fweisbec@...il.com>,
Fengguang Wu <fengguang.wu@...el.com>, LKP <lkp@...org>,
LKML <linux-kernel@...r.kernel.org>,
Netdev <netdev@...r.kernel.org>,
"David S. Miller" <davem@...emloft.net>,
Andrea Parri <andrea.parri@...rulasolutions.com>,
Luc Maranget <luc.maranget@...ia.fr>,
Jade Alglave <j.alglave@....ac.uk>
Subject: Re: inet: frags: Turn fqdir->dead into an int for old Alphas
On Fri, Jun 07, 2019 at 09:19:42AM -0700, Linus Torvalds wrote:
> On Fri, Jun 7, 2019 at 8:26 AM Eric Dumazet <eric.dumazet@...il.com> 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
Powered by blists - more mailing lists