Bug 147083 - sigcontext->FS changes running ia32 on x86_64 (rhel4-rc2)
sigcontext->FS changes running ia32 on x86_64 (rhel4-rc2)
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel (Show other bugs)
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Roland McGrath
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2005-02-04 04:41 EST by David Simms
Modified: 2007-11-30 17:07 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-08-21 11:00:23 EDT
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 04:42 EST, David Simms
no flags Details

  None (edit)
Description David Simms 2005-02-04 04:41:26 EST
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 04:42:37 EST
Created attachment 110640 [details]
repro case

Compile on ia32 and run on x86_64
Comment 3 Roland McGrath 2005-02-04 19:21:37 EST
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 03:56:45 EST
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 14:18:23 EST
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 08:52:49 EST
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.