Bug 147083 - sigcontext->FS changes running ia32 on x86_64 (rhel4-rc2)
Summary: sigcontext->FS changes running ia32 on x86_64 (rhel4-rc2)
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel   
(Show other bugs)
Version: 4.0
Hardware: x86_64 Linux
Target Milestone: ---
: ---
Assignee: Roland McGrath
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2005-02-04 09:41 UTC by David Simms
Modified: 2007-11-30 22:07 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-08-21 15:00:23 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
repro case (2.02 KB, text/plain)
2005-02-04 09:42 UTC, David Simms
no flags Details

Description David Simms 2005-02-04 09:41:26 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5)
Gecko/20041107 Firefox/1.0

Description of problem:
Running a ia32 compiled program on x86_64 (EMT64); when one thread
continually signals another the FS register value appears to be
modified in the resulting sigcontext, e.g. 

Main thread:

   while (1) {
      pthread_kill(testThread, mySignal);

Test Thread:

mySigHandler(int sig, siginfo_t *sip, void *arg) {
   if ( (scp->fs != myFs) || (scp->fs != getFS()) ) 

Will attach repro, case. It appears that a few fprintf statements
between signalling prevent the problem, but if I just spin and signal
FS appears as 3 in the sigcontext instead of the original 0.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Start a test thread, records the FS value, and spins doing user code
2. Continuously signal the test thread
3. The FS register appears to change when handling the signal.

Test program:

gcc -g -Wall -lpthread -o fsmt fsmt.c && ./fsmt

Actual Results:  Starting
FS: 0
Now hit me with: 10
Main signaling 1st
Main signaling 2nd
Main signaling looping forever
Aborted (core dumped)

Expected Results:  Show loop forever

Additional info:

uname: 2.6.9-1.906_ELsmp #1 SMP Sun Dec 12 23:05:02 EST 2004 x86_64
x86_64 x86_64 GNU/Linux

rpm -q --queryformat '\n%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' glibc:


Comment 1 David Simms 2005-02-04 09:42:37 UTC
Created attachment 110640 [details]
repro case

Compile on ia32 and run on x86_64

Comment 3 Roland McGrath 2005-02-05 00:21:37 UTC
I see the bug.  I'll pursue it upstream.  Aside from the contrived test case, I
don't know of something concrete (and valid) actually broken by this.

Comment 4 David Simms 2005-02-07 08:56:45 UTC
So the originally we were out to repro a problem with an invalid FS
reg  after handling an async signal...this was as close as I could get
so far. Was interested in other possible side-effects that may explain
some other crashes we've experienced with IA32 code on x86_64.

Comment 5 Roland McGrath 2005-02-07 19:18:23 UTC
I don't think the bug shown by your test program could be the source of any
real-world problem.  It only affects selectors that you cannot use without
getting a GP fault.  The only way a user program could be affected is if it
explicitly compares the segment register values rather than trying to use them,
like your test program does.  The bug turns the selector 0 into 3, but both have
the same effect if you use them (to fault).  If the %fs value before the signal
was a valid segment selector, then I don't see how signal handling would change
it (unless of course your handler clobbered that word in the struct sigcontext
on the stack).  If you think there may be a real problem here, then please try
to work up a test case that uses a nonzero %fs value and demonstrates some
erroneous behavior.

Comment 6 David Simms 2005-02-21 13:52:49 UTC
Sorry for the late reply, I agree this isn't "real-world problem" - go
ahead and close this. If FS is intialized, all is well.

Was thinking this could have been related to another problem with a
bad CS register, but upon further inspection, I very much doubt it.

Note You need to log in before you can comment on or make changes to this bug.