This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Possible race condition with deferred binding on IPF
- From: Cary Coutant <cary at cup dot hp dot com>
- To: binutils at sources dot redhat dot com
- Cc: linux-ia64 at vger dot kernel dot org
- Date: Thu, 4 Mar 2004 16:05:00 -0800
- Subject: Possible race condition with deferred binding on IPF
We (HP) have discovered a missing requirement in the psABI document
with respect to import stubs and inlined import stubs. The deferred
binding sequence relies on careful ordering of the two stores that
update the function descriptor in the dynamic loader's
bind-on-reference routine, and the two loads in the import stub. The
import stub must load the entry point address, followed by the gp
value, while the BOR routine must store the gp value first, followed by
the entry point address. This ensures that one thread cannot interfere
with another thread if both are making the same call at about the same
time. Furthermore, we need to ensure strong ordering with the use of
".acq" and ".rel" completers.
The race condition to be avoided is this:
Thread 1 Thread 2
-------- --------
load (garbage) gp value
store new gp value
store new entry point
load (new) entry point
If the loads become visible out of order, and the stores become visible
between the two loads, we will branch to the actual entry point with a
garbage gp value. Forcing strong ordering between the two stores and
between the two loads eliminates the possibility of this ordering
between the two loads, and therefore eliminates the race condition.
To our knowledge, we have not yet observed an application failure due
to this problem. We discovered this while finding a compiler bug in
which the two loads were physically moved out of order by the compiler,
and came to realize that the psABI does not state any requirement for
strong ordering.
This problem has potential impact on the following Gnu/Linux components:
- gcc is not affected, since it does not inline import stubs (I think).
- The intel compiler needs to be fixed to generate the necessary
ld8.acq in inlined import stubs.
- gld needs to be fixed to generate the necessary ld8.acq in the import
stubs.
- the dynamic loader is not affected, as it uses the required st8.rel
already.
- handcoded assembly language source is at risk, but inlined import
stub sequences in handcoded assembly code are, I hope, rare.
While it's clearly important to fix these components, I believe that
any actual failures due to the missing .acq are so unlikely that there
is no great urgency to encourage a recompile of the world.
I have proposed the following changes to the IA-64 psABI document:
1. In Section 5.3.6 ("Procedure Linkage Table"), the following
additional text is needed:
"An import stub (whether in the procedure linkage table or inlined at
the point of call) must ensure strong ordering between the load of the
first doubleword of the local function descriptor and the load of the
second doubleword. This means that the two loads may not be reordered,
and the first load must have acquire semantics."
...
"When the dynamic loader updates the local function descriptor entry,
it must store the second doubleword of the function descriptor (the
function's gp value) before storing the first doubleword (the function
address), and the second store must have release semantics, ensuring
strong ordering between the two stores."
2. The example code in Figure 5-4 needs the ".acq" completer on the
first load instruction, as follows:
...
.PLT1: (entry for symbol name1)
addl r15 = @pltoff(name1), gp ;;
ld8.acq r16 = [r15], 8
mov r14 = gp ;;
ld8 gp = [r15]
mov b6 = r16
br b6
...
Cary Coutant
HP-UX Runtime Architect