Bug 434995
| Summary: | utrace+ptrace: ERESTARTSYS from calling a function from a debugger | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Jan Kratochvil <jan.kratochvil> |
| Component: | kernel | Assignee: | Roland McGrath <roland> |
| Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | low | Docs Contact: | |
| Priority: | low | ||
| Version: | rawhide | CC: | kernel-maint |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2008-03-05 16:05:29 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 434998, 435000, 436183 | ||
|
Description
Jan Kratochvil
2008-02-26 19:08:13 UTC
The setting of orig_eax to -1 in compat mode on x86_64 seems unnecessary; the
program works the same with this patch applied:
#ifdef __i386__
- user.orig_eax = -1L;
+ printf("%X\n", (unsigned int)user.orig_eax);
+// user.orig_eax = -1L;
#endif
ptrace (PTRACE_SETREGS) could be truncating the original internal 64-bit register values to 32 bits. It is, and that was my first thought about orig_ax checks. But a hack for that did not solve the bug. I'm still investigating. got it, fixing upstream Just a reason why the Comment 1 "simplification" is not acceptable: (In reply to comment #1) > The setting of orig_eax to -1 in compat mode on x86_64 seems unnecessary; the > program works the same with this patch applied: "works" that the problem is reproducible. But it would not correctly PASS even after the kernel bug gets fixed. The testcase fails for native x86_64-on-x86_64 with the `orig_rax' reset removed. And also the code does not make much sense without the `orig_[re]ax' reset. Thanks as always, Roland. (In reply to comment #5) > Just a reason why the Comment 1 "simplification" is not acceptable: > > (In reply to comment #1) > > The setting of orig_eax to -1 in compat mode on x86_64 seems unnecessary; the > > program works the same with this patch applied: > > "works" that the problem is reproducible. > But it would not correctly PASS even after the kernel bug gets fixed. > The testcase fails for native x86_64-on-x86_64 with the `orig_rax' reset > removed. And also the code does not make much sense without the `orig_[re]ax' > reset. Well of course... it was just a clue that something was so wrong that setting orig_eax to -1 had no effect one way or the other for 32-on-64 code. :) Is it necessary to fix this very obscure bug in F8 or is just fixing rawhide good enough? This bug has gone unnoticed at least since 2.6.9 and probably since the dawn of time. It is not urgent AFAIK. Upstream fix from Roland: http://www.ussg.iu.edu/hypermail/linux/kernel/0802.3/2516.html Building the patch in rawhide. Verified as fixed for kernel-2.6.25.4-10.fc8.{x86_64,i686}.
|