linux-kernel - Re: [PATCH] sched.c : correct comment for this_rq

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: <Pine.LNX.4.64.0611010252460.28051@localhost.localdomain>
Date:	Wed, 1 Nov 2006 03:01:31 -0500 (EST)
From:	"Robert P. J. Day" <rpjday@...dspring.com>
To:	Nick Piggin <nickpiggin@...oo.com.au>
cc:	Borislav Petkov <petkov@...h.uni-muenster.de>,
	David Rientjes <rientjes@...washington.edu>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] sched.c : correct comment for this_rq_lock() routine

On Wed, 1 Nov 2006, Nick Piggin wrote:

> Robert P. J. Day wrote:
>
> > example, i was just poking around the source for the various
> > "atomic.h" files and noticed a couple possible cleanups:
> >
> >  1) make sure *everyone* uses "volatile" in the typedef struct (which
> > 	i actually submitted recently)
> >
>
> I don't see why. There is nothing in atomic (eg. atomic_read) that
> says there must be a compiler barrier around the operation.
>
> Have you checked that the architecture implementation actually needs
> the volatile where you've added it?

as just one example, you can read in include/asm-alpha/atomic.h:

/*
 * Counter is volatile to make sure gcc doesn't try to be clever
 * and move things around on us. We need to use _exactly_ the address
 * the user gave us, not some alias that contains the same information.
 */

now it may be that *some* architectures don't specifically require a
volatile counter but, AFAIK, it doesn't actually hurt if it isn't
necessary.  OTOH, if it isn't necessary *at all* for *any*
architecture, then that storage class should be *removed* in its
entirety.

in any event, all this is is another example of what appears to be
niggling and unnecessary differences between arch-specific header
files that could easily be turned into a single, standard definition
that would work for everyone with very little effort (and perhaps some
day be included from a single generic header file to avoid all that
duplication in the first place).

rday
-
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/