linux-kernel - Re: [patch 2.6.19-rc6] Stop gcc 4.1.0 optimizing wait_hpet

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: <A3610BE9-66B4-452A-9EEB-D2620A4958E2@mac.com>
Date:	Fri, 1 Dec 2006 00:50:59 -0500
From:	Kyle Moffett <mrmacman_g4@....com>
To:	davids@...master.com
Cc:	"Linux-Kernel@...r. Kernel. Org" <linux-kernel@...r.kernel.org>
Subject: Re: [patch 2.6.19-rc6] Stop gcc 4.1.0 optimizing wait_hpet_tick away

On Nov 29, 2006, at 20:04:28, David Schwartz wrote:
> Ask yourself this question: Can an assignment to a non-volatile  
> variable be optimized out?  Then ask yourself this question: Does  
> casting away volatile make it not volatile any more?

Hmm, let's put this in a C file:
> int my_global = 0;

And put this in a header:
> extern int my_global;
> static int my_func(int a)
> {
> 	return a + my_global++;
> }

Now put this in another source file
> #include <my_header.h>
>
> int main()
> {
> 	while (my_func(3) < 5)
> 		printf("It hasn't happened yet!\n");
> 	return 0;
> }

The obvious result is that it prints "It hasn't happened yet!"  
twice.  On the third iteration when my_global == 2 it breaks out of  
the loop.  This is all fairly standard C so far.

Imagine we change the code to read from some auto-increment hardware  
at a specific MMIO address instead of a global:
> static int my_func(int a)
> {
> 	return a + *(volatile int *)(0xABCD1234);
> }

But you're telling me that the change in the header file (where the  
new function returns the exact same series of values with every call  
as the old) causes the program to enter an infinite loop?

How do you rationalize this again?

> The 'readl' function should actually assign the value to a volatile  
> variable. Assignments to volatiles cannot be cast away, but casts  
> can and assignments to non-volatile variables can be optimized out.

Actually, no.  The reason for the volatile in the pointer dereference  
is to force the memory access to *always* happen.  It's a guarantee  
that the compiler will do that memory access every time it appears.   
You have a volatile int afterwards and what you do with that nobody  
cares.  The point is the presence of the volatile in a single pointer- 
dereference forcibly turns off any optimization of that specific  
access, including loop unrolling and such.

Cheers,
Kyle Moffett

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