Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 154369 - Thread exits siliently via __RESTORE_ALL exeception for iret
Summary: Thread exits siliently via __RESTORE_ALL exeception for iret
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: rawhide
Hardware: i686
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Roland McGrath
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks: FC4Target
TreeView+ depends on / blocked
 
Reported: 2005-04-11 07:32 UTC by Roland McGrath
Modified: 2007-11-30 22:11 UTC (History)
2 users (show)

Fixed In Version: FC4
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-08-09 07:07:28 UTC


Attachments (Terms of Use)
patch for upstream 2.6.12rc2 kernel (deleted)
2005-04-11 07:32 UTC, Roland McGrath
no flags Details | Diff
updated patch, was posted upstream. (deleted)
2005-04-24 01:15 UTC, Roland McGrath
no flags Details | Diff
FC patch after 2.6.12rc4 rebase (deleted)
2005-05-12 00:32 UTC, Roland McGrath
no flags Details | Diff

Description Roland McGrath 2005-04-11 07:32:22 UTC
Created attachment 112937 [details]
patch for upstream 2.6.12rc2 kernel

Comment 1 Roland McGrath 2005-04-11 07:32:22 UTC
+++ This bug was initially created as a clone of Bug #154221 +++

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:
So related to 152012, I instrumented the kernel to find out how our thread
"disappeared" when running a Java thread test with JRockit. That is the thread
did not complete, but was destroyed by the OS. 

The last thing the thread was doing was trying to execute an illegal
instruction, for which we have a signal handler for
(SA_RESTART|SA_SIGINFO|SA_ONSTACK).

Sure enough the thread went through do_exit, but did not originate from the
system call or a signal. After exhausting all other possibilities I instrumented
the one last candidate, entry.S macro __RESTORE_ALL has a kernel exception fix
up (333,666) for a fail iret (will attach patch with instrumentation).

We are basically faced with two problems:

1) __RESTORE_ALL fixup code simply calls "do_exit(11)", causing my thread to
EXIT SILENTLY. This can't be right ? We need some notification/explanation:
warning in syslog, core dump, kernel dump ?!

2) We have no idea why the iret instruction is failing, further more we have no
simple 1 page repro case, currently running a JVM for repro.

Version-Release number of selected component (if applicable):
kernel-smp-2.6.9-5.EL

How reproducible:
Always

Steps to Reproduce:
1. Run Java thread tests.
2. Start causing general protection faults, via use of an illegal instruction.


Actual Results:  Signal stack is completely unused, the thread has exited, and
it's last instruction is 0x6f (outs).

Expected Results:  Expecting to catch SIGSEGV in a signal handler, and handle
the illegal instruction.

Additional info:

Comment 2 Roland McGrath 2005-04-24 01:14:16 UTC
Patch posted upstream.

Comment 3 Roland McGrath 2005-04-24 01:15:23 UTC
Created attachment 113590 [details]
updated patch, was posted upstream.

Comment 4 Roland McGrath 2005-05-12 00:32:53 UTC
Created attachment 114275 [details]
FC patch after 2.6.12rc4 rebase

A different partial fix for the underlying issue of iret faults went in
upstream in 2.6.12rc4.	Since current rawhide has rebased to that, the fix for
the exec-shield bug now has to look different.

Comment 5 Roland McGrath 2005-08-09 07:07:28 UTC
All good in FC4.


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