linux-kernel - Re: [PATCH] "volatile considered harmful", take 2

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <a781481a0705101444o4d04bb99xac7cbb587355e56f@mail.gmail.com>
Date:	Fri, 11 May 2007 03:14:50 +0530
From:	"Satyam Sharma" <satyam.sharma@...il.com>
To:	"jimmy bahuleyan" <knight.camelot@...il.com>
Cc:	"Jonathan Corbet" <corbet@....net>, linux-kernel@...r.kernel.org,
	akpm@...ux-foundation.org, "Jesper Juhl" <jesper.juhl@...il.com>,
	"Randy Dunlap" <randy.dunlap@...cle.com>,
	"Heikki Orsila" <shdl@...alwe.fi>, "H. Peter Anvin" <hpa@...or.com>
Subject: Re: [PATCH] "volatile considered harmful", take 2

On 5/11/07, jimmy bahuleyan <knight.camelot@...il.com> wrote:
> Jonathan Corbet wrote:
> [snip..]
> > +
> > +  - The jiffies variable is special in that it can have a different value
> > +    every time it is referenced, but it can be read without any special
> > +    locking.  So jiffies can be volatile, but the addition of other
> > +    variables of this type is strongly frowned upon.  Jiffies is considered
> > +    to be a "stupid legacy" issue in this regard.
>
> Why is it that you consider jiffies to be a "stupid legacy"?

You could find better explanations in previous threads, but to
summarize my understanding of the matter:

Because it is not humanly possible to audit the entire kernel tree to
find all usages of jiffies and fix them appropriately (i.e. "stupid
legacy reasons"). Hence, we just define jiffies as volatile.

> Isn't it natural to have a externally modified variable which is only /read/ to
> be volatile?

No, even in such a case, it would have been saner to simply define the
jiffies _without_ volatile, and only cast _accesses_ to it with the
volatile type qualifier.

Unfortunately, even this is not possible to do in all existing users
in the kernel (i.e. "stupid legacy reasons").

> (or is jiffies supposed to be replaced with something smarter/better :)

Not _replace_ jiffies. But if it were _really_ possible to do so (i.e.
assuming for a moment that we could change all kernel code in one
magic sweep), then again we wouldn't need to use volatile for jiffies
(or even use a volatile cast, IMO).

Just ensure all accesses to jiffies are protected behind an
appropriate barrier() instead, the effects of which are more clearly
defined than the vague and insufficient "volatile", and which
*guarantees* that all memory would be re-read from that point (note
that "volatile" is merely a hint to a C compiler, it comes with no
guarantees at all, which is particularly worrisome these days when
compilers are not the only entities that can re-order code -- hardware
can do so too).

However, yet again, it is _not_ possible to fix the above for all the
existing kernel code that uses jiffies (i.e. "stupid legacy reasons"),
so we just define jiffies as volatile.

My understanding, at least.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/