linux-kernel - Re: Why exported const value modified by another driver not updated in original driver

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: <1346760392.5081.19.camel@thorin>
Date:	Tue, 04 Sep 2012 14:06:31 +0200
From:	Bernd Petrovitsch <bernd@...rovitsch.priv.at>
To:	Manavendra Nath Manav <mnm.kernel@...il.com>
Cc:	linux-kernel@...r.kernel.org, kernelnewbies@...nelnewbies.org
Subject: Re: Why exported const value modified by another driver not updated
 in original driver

Hi!

On Die, 2012-09-04 at 15:00 +0530, Manavendra Nath Manav wrote:
[....]
> I have declared a static const int variable in one driver and exported
> that variable symbol.

Exporting a "static" variable makes conceptually no sense whatsoever -
either you want it exported (so you should remove the "static") or you
want it not exported - which is precisely the definition of "static".

> retains the original value. When both virtual and physical addresses
> of the variable as seen by both drivers are same, how is this even
> possible. Is it a kernel bug?

It's a bug in your drivers.
The C compiler sees an initialized "static const" variable. So the C
compiler knows that it is not accessible from other compilation units
(because it is "static") and the variable isn't changing within the
current compilation unit (because the variable as such is "const" and
their is no non-const pointer to it or similar).
Since this is the only compilation unit, it knows that no one will/can
change it's value.
So the C compiler happily replaces all references to the variable with
it's value - just as if you would have #define'd that value.

Obviously, later on it is exported and the variable actually exists and
you can change it in the other file. But since the value has been
replaced literally by "123" at compile (more precise: optimizer time),
you don't see a change in the printk()s.

> Interestingly, when i change the declaration of variable to "volatile"
> in driver.c as "static const volatile int" then the driver.ko prints
> modified value "987" during rmmod and the original value "123" is
> lost. What is the difference between this and previous declaration?

"volatile" tells the C compiler that a variable may change it's value
without explicit code.
A typical use case are hardware registers which are changed by the
underlying hardware.
In user space, variables may be modified by signal handlers (which can
occur at any time in a program - unless specifcally blocked).

So the optimizer must not accesses to "volatile" variables because they
may change their value at any time.

> Please forgive if you find this question silly?

That all is actually pure (K&R-)C and has nothing to do with the kernel.

> static const int value = 123;
[...]
> EXPORT_SYMBOL(value);

I wonder if we can modify EXPORT_SYMBOL() so that it compile-time-fails
for "static" variables.
And if we actually want that.

	Bernd
-- 
Bernd Petrovitsch                  Email : bernd@...rovitsch.priv.at
                     LUGA : http://www.luga.at

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