Blaisorblade wrote:
On Tuesday 13 September 2005 18:51, Bodo Stroesser wrote:
Jeff Dike wrote:
On Sun, Sep 04, 2005 at 05:02:18PM +0200, Blaisorblade wrote:
I would be tempted to leave it in and fix it before 2.6.14. We need
different ptrace codes so that UML knows how to switch interception
types, I take it?
Yes, that's the idea.
UML is the only user, so there aren't really any compatibility issues.
On the host side, instead, supporting both the broken API and the new one
is more difficult.
Yeah, and it shouldn't be done. This is one reason I'd like to use the
same ptrace codes - it doesn't leave a hole in the codes that says there
was a broken ABI there once.
Do you see contiguos codes? We jump from 24 to 31-32 (it was done for
something like having a common ABI with 2.4 and 2.6 hosts - don't ask me what
filled previous slots, however), so you shouldn't worry for this.
What's your opinion on this? The options are:
1) merge it as-is
2) take it back for now, fix it and merge it for 2.6.15.
Merge as-is, fix it before 2.6.13, and you get the same thing, except
a release earlier. I think this shouldn't be a problem, as after the
floodgates close, you still get to fix things you merged early. This
came about as a result of feedback received because after it went into
-mm, and it seems to me that this is a legitimate change for 2.6.14.
And then
2a) drop the trick, and avoid changing ptrace call numbers. Old UMLs
will run fast, but crash with /proc/sysemu (only root-accessible).
We should drop /proc/sysemu, if it's there at all, since it's only for
debugging sysemu, and maintain it as a private patch. So this doesn't
seem like much of an issue.
Jeff
It would be enough to make /proc/sysemu readonly.
Yes, but my main concern is compatibility with existing binaries. They'll work
as long as nobody tries to write on /proc/sysemu if the API is changed.
However, I've put something together, so I've attached the host patch (I'm
also a bit ill this days, so I want to make sure there's at least the
possibility for anybody else to fix it).
This has not yet been tested (I'm gonna do it) - but it seems that it's little
enough to make the new behaviour a ptrace option, if needed.
I wouldn't like to break in *anything* behaviour of old binaries, if possible.
But we need to change check_sysemu(). The current implementation will work
with the old API only.
Would it refuse using sysemu or refuse to run at all? That's another
interesting point.
If we talk about using a new ptrace code for the new API, old UML binaries
running
on a host supporting the new API will recognize that there is no SYSEMU they can
use. So /proc/sysemu will not allow to switch on or off anything (IIRC, the file
will not even be created). That means, that an old binary will run safe but slow
in this case. One could argue, that this is a changed behaviour of the old
binary.
OTOH, if the new API would reuse the same ptrace code, check_sysemu of the old
binaries will fail on i386 (and I hope on x86_64, too). That means, sysemu again
will be disabled. AFAICS, it will not refuse to run at all. (Not tested, taken
from
the code only)
On s390 the check even might succeed accidentally, but that's no problem, as
s390
isn't mainline yet, we can change check_sysemu() to avoid problems. There will
never be an old binary for s390.
Resume: it doesn't matter if a new ptrace code is used or the old one is reused.
Usage of sysemu will be restricted to "new UML on new host" or "old UML on old
host"
as long as host doesn't support _both_ APIs (selectable by two separate ptrace
codes
or by a new flag to PTRACE_SETOPTIONS). AFAICS, there is no reason to change
/proc/sysemu at all, right?
Bodo
------------------------------------------------------------------------
sysemu-new-interface
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
---
linux-2.6.git-paolo/arch/i386/kernel/ptrace.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletion(-)
diff -puN arch/i386/kernel/ptrace.c~sysemu-new-interface
arch/i386/kernel/ptrace.c
--- linux-2.6.git/arch/i386/kernel/ptrace.c~sysemu-new-interface
2005-07-27 20:38:35.000000000 +0200
+++ linux-2.6.git-paolo/arch/i386/kernel/ptrace.c 2005-07-27
20:40:25.000000000 +0200
@@ -749,7 +749,9 @@ int do_syscall_trace(struct pt_regs *reg
send_sig(current->exit_code, current, 1);
current->exit_code = 0;
}
- ret = is_sysemu;
+ /* The debugger might have changed the syscall intercepting mode. Apply
+ * this update now, rather than at next syscall. */
+ ret = test_thread_flag(TIF_SYSCALL_EMU);
out:
if (unlikely(current->audit_context) && !entryexit)
audit_syscall_entry(current, AUDIT_ARCH_I386, regs->orig_eax,
_
-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
User-mode-linux-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
