[uml-devel] Skas0 general testing?

[uml-devel] Skas0 general testing?

[Blaisorblade]

Would you start preparing a SKAS0 patch-set that I can merge into -bs for 
general testing and that can be merged into -mm at least?

I'd like it to be verifiably "don't touch" about SKAS3 working (i.e. no 
"little changes which won't hurt"). As I already said, I don't mean from the 
"code" viewpoint but from the "what's actually done" viewpoint (in terms of 
strace output, if you want so).
-- 
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894)
http://www.user-mode-linux.org/~blaisorblade

	

	
		
___________________________________ 
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB 
http://mail.yahoo.it



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

[uml-devel] Re: Skas0 general testing?

[Jeff Dike]

On Thu, Jun 23, 2005 at 02:38:35AM +0200, Blaisorblade wrote:
> Would you start preparing a SKAS0 patch-set that I can merge into -bs for 
> general testing and that can be merged into -mm at least?

I'm working on it.  skas0 and skas0-clone are the first to go.  I just
"fixed" skas0 so it gets mm->nr_ptes right without the change to
exit_mmap that used to be there.  I'm banging on that patch now.

The rest still need work.  The setup patches (where we make proc_mm et
al settable on the command line and all combinations will work) are
probably OK.

Some of the later ones are pretty sad.  The ldt patches are probably
not too hard to clean up, but things like add-gate-vma are horrible.

I'm not planning on having a whole good set before starting to send
them to Andrew.  I'll send the ones I'm happiest about, and clean up
the rest, sending them in during the course of 2.6.13.

> I'd like it to be verifiably "don't touch" about SKAS3 working (i.e. no 
> "little changes which won't hurt"). As I already said, I don't mean from the 
> "code" viewpoint but from the "what's actually done" viewpoint (in terms of 
> strace output, if you want so).

That's a good goal, but we can't let it get in the way of keeping the
code clean.  Certainly, anything which touches skas3 should be
carefully looked at, but I don't want to state that we will not touch
any skas3 code.  Bodo's patches which make any combination of
PTRACE_LDT, PTRACE_FAULTINFO, and /proc/mm work are a good example.  I
think that's a worthwhile patch, but it does touch skas3 code.

				Jeff


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

[uml-devel] Re: Skas0 general testing?

[Blaisorblade]

On Thursday 23 June 2005 03:12, Jeff Dike wrote:
> On Thu, Jun 23, 2005 at 02:38:35AM +0200, Blaisorblade wrote:
> > Would you start preparing a SKAS0 patch-set that I can merge into -bs for
> > general testing and that can be merged into -mm at least?

> I'm working on it.  skas0 and skas0-clone are the first to go.  I just
> "fixed" skas0 so it gets mm->nr_ptes right without the change to
> exit_mmap that used to be there.  I'm banging on that patch now.

> The rest still need work.  The setup patches (where we make proc_mm et
> al settable on the command line and all combinations will work) are
> probably OK.
Yes, I agree on that too.
> Some of the later ones are pretty sad.  The ldt patches are probably
> not too hard to clean up, but things like add-gate-vma are horrible.
"Not touching mainline" is not the main purpose, the problem is doing it 
cleanly. Honestly I don't know what you're talking about because I've not had 
the chance to look anyhow at the code.
> I'm not planning on having a whole good set before starting to send
> them to Andrew.  I'll send the ones I'm happiest about, and clean up
> the rest, sending them in during the course of 2.6.13.
Well, if SKAS0 works without them, it's still ok, though I suspect removing 
some patches will hurt SKAS0 stability.
> > I'd like it to be verifiably "don't touch" about SKAS3 working (i.e. no
> > "little changes which won't hurt"). As I already said, I don't mean from
> > the "code" viewpoint but from the "what's actually done" viewpoint (in
> > terms of strace output, if you want so).

> That's a good goal, but we can't let it get in the way of keeping the
> code clean.  Certainly, anything which touches skas3 should be
> carefully looked at, but I don't want to state that we will not touch
> any skas3 code.  Bodo's patches which make any combination of
> PTRACE_LDT, PTRACE_FAULTINFO, and /proc/mm work are a good example.  I
> think that's a worthwhile patch, but it does touch skas3 code.
I specified "operations done on the host" exactly for this purpose. That patch 
will touch SKAS3 code, but if I set all three options to "yes" the code 
should do the same things (again, in terms of strace output).

But however, if to keep the code clean we change (let's say) where a certain 
signal handler is set to later in the boot process, *hoping* that it does not 
hurt, that's against my definition.
-- 
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894)
http://www.user-mode-linux.org/~blaisorblade

	

	
		
___________________________________ 
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB 
http://mail.yahoo.it



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] Re: Skas0 general testing?

[Jeff Dike]

On Thu, Jun 23, 2005 at 03:36:26AM +0200, Blaisorblade wrote:
> I specified "operations done on the host" exactly for this purpose. That patch 
> will touch SKAS3 code, but if I set all three options to "yes" the code 
> should do the same things (again, in terms of strace output).
> 
> But however, if to keep the code clean we change (let's say) where a certain 
> signal handler is set to later in the boot process, *hoping* that it does not 
> hurt, that's against my definition.

OK, you sounded at first like you wanted stronger guarantees of no changes.
strace output being the same isn't that strong, but if you're happy with it,
that's fine by me.

You're OK with sending in skas0 and skas0-clone without first having a
complete, fully-polished patchset?

				Jeff


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

[uml-devel] Re: Skas0 general testing?

[Bodo Stroesser]

Jeff Dike wrote:
> On Thu, Jun 23, 2005 at 02:38:35AM +0200, Blaisorblade wrote:
> 
>>Would you start preparing a SKAS0 patch-set that I can merge into -bs for 
>>general testing and that can be merged into -mm at least?
> 
> 
> I'm working on it.  skas0 and skas0-clone are the first to go.  I just
> "fixed" skas0 so it gets mm->nr_ptes right without the change to
> exit_mmap that used to be there.  I'm banging on that patch now.
About skas0-clone:

Jeff, do you remember our discussion about RCX probably not being restored
correctly, in case a process is scheduled out on a interrupt, but is resumed
because of an other process going to sleep in a syscall?
You asked me, why you didn't see any problems here. Maybe, meanwhile I
know the answer: the problem will come up in skas3, but will be a rare
case in skas0. This is due to the fact, that the problem will happen only,
if the processes run in the same userspace process.
So, in skas0 it can happen only for threads sharing the same mm!
It will be simple, to build a test for this:
1) create a parent and a child process using clone(CLONE_VM)
2) let the child load a "magic number" into RCX, then let it loop for ever.
3) In the loop, child should compare RCX against "magic number" and should
    jump out of the loop, if RCX has changed. Now it should write an error
    message containing the changed RCX-value, and exit.
4) parent should go into a loop of short sleeps. After a certain number of
    sleeps, it should consider the test to not have found a problem. Then it
    should kill the child and exit.
Unfortunately, I have no x86_64 system to create and run the test.

I guess, it will need some modifications in x86_64-host to fix this.

To work around this probable problem, skas0 could have separate userspace-
processes even for threads sharing the same mm. Those processes could be
created by the clone-stub using clone(CLONE_VM), resulting in a new
skas0-clone.
A check of the form proposed above even could be done at UML startup to
make UML work with or without separate userspace-processes.

Maybe, the test and possible changes in the patches should be done before
merging into -mm.

> 
> The rest still need work.  The setup patches (where we make proc_mm et
> al settable on the command line and all combinations will work) are
> probably OK.
> 
> Some of the later ones are pretty sad.  The ldt patches are probably
> not too hard to clean up, but things like add-gate-vma are horrible.
That's true. add-gate-vma never was planned to go into mainline "as is".
I wrote that nasty thing to at the moment avoid changes in arch-independent
code (e.g. mm/memory.c).
For mainline, we need to create a new version, that does the changes for
adding "multi-gate-vma"-support properly in the common soure files. I have
no idea, if this change will be accepted. OTOH, I have no other idea how to
make skas0 consistent.

		Bodo
> 
> I'm not planning on having a whole good set before starting to send
> them to Andrew.  I'll send the ones I'm happiest about, and clean up
> the rest, sending them in during the course of 2.6.13.
> 
> 
>>I'd like it to be verifiably "don't touch" about SKAS3 working (i.e. no 
>>"little changes which won't hurt"). As I already said, I don't mean from the 
>>"code" viewpoint but from the "what's actually done" viewpoint (in terms of 
>>strace output, if you want so).
> 
> 
> That's a good goal, but we can't let it get in the way of keeping the
> code clean.  Certainly, anything which touches skas3 should be
> carefully looked at, but I don't want to state that we will not touch
> any skas3 code.  Bodo's patches which make any combination of
> PTRACE_LDT, PTRACE_FAULTINFO, and /proc/mm work are a good example.  I
> think that's a worthwhile patch, but it does touch skas3 code.
> 
> 				Jeff


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

[uml-devel] Re: Skas0 general testing?

[Jeff Dike]

On Thu, Jun 23, 2005 at 03:36:26AM +0200, Blaisorblade wrote:
> I specified "operations done on the host" exactly for this purpose. That patch 
> will touch SKAS3 code, but if I set all three options to "yes" the code 
> should do the same things (again, in terms of strace output).
> 
> But however, if to keep the code clean we change (let's say) where a certain 
> signal handler is set to later in the boot process, *hoping* that it does not 
> hurt, that's against my definition.

OK, I straced UML booting and shutting down on a skas3 host, with and without
the skas0 patch.

I looked at the initialization, syscall interception, and page fault handing,
and they are identical in the two runs:

Initialization:

	access("/proc/mm", W_OK)                = 0
	write(1, "Checking for /proc/mm...found\n", 30) = 30
	fork()                                  = 25144
	wait4(25144, [WIFSTOPPED(s) && WSTOPSIG(s) == SIGSTOP], WUNTRACED, NULL) = 25144
	--- SIGCHLD (Child exited) ---
	ptrace(PTRACE_???, 25144, 0, 0xbffff7e0) = 0
	write(1, "Checking for the skas3 patch in "..., 49) = 49
	ptrace(PTRACE_???, 25144, 0, 0x823c100) = 0
	ptrace(PTRACE_???, 25144, 0, 0x823c1e0) = 0
	ptrace(PTRACE_CONT, 25144, 0, SIG_0)    = 0

Syscall interception:

	wait4(25145, [WIFSTOPPED(s) && WSTOPSIG(s) == SIGSEGV], WUNTRACED, NULL) = 25145
	ptrace(PTRACE_???, 25145, 0, 0x8a41888) = 0
	ptrace(PTRACE_???, 25145, 0, 0x8a41938) = 0
	ptrace(PTRACE_???, 25145, 0, 0x8a41b38) = 0
	write(14, "6\0\0\0\0\20\0@\0\20\0\0\5\0\0\0\21\0\0\0\3\0\0\0\0p\270"..., 28) = 28
	ptrace(PTRACE_???, 25145, 0, 0x8a41888) = 0
	ptrace(PTRACE_???, 25145, 0, 0x8a41938) = 0
	ptrace(PTRACE_SYSCALL, 25145, 0, SIG_0) = 0

Page fault:

	wait4(25145, [WIFSTOPPED(s) && WSTOPSIG(s) == 133], WUNTRACED, NULL) = 25145
	ptrace(PTRACE_???, 25145, 0, 0x8a41888) = 0
	ptrace(PTRACE_???, 25145, 0, 0x8a41938) = 0
	ptrace(PTRACE_POKEUSER, 25145, 4*ORIG_EAX, 0x14) = 0
	ptrace(PTRACE_SYSCALL, 25145, 0, SIG_0) = 0
	--- SIGCHLD (Child exited) ---
	wait4(25145, [WIFSTOPPED(s) && WSTOPSIG(s) == 133], WUNTRACED, NULL) = 25145
	ptrace(PTRACE_???, 25145, 0, 0x8a41888) = 0
	ptrace(PTRACE_???, 25145, 0, 0x8a41938) = 0
	ptrace(PTRACE_SYSCALL, 25145, 0, SIG_0) = 0

With this, are you OK with skas0 being sent to Andrew?

				Jeff


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] Re: Skas0 general testing?

[Blaisorblade]

On Thursday 30 June 2005 16:31, Jeff Dike wrote:
> On Thu, Jun 23, 2005 at 03:36:26AM +0200, Blaisorblade wrote:
> > I specified "operations done on the host" exactly for this purpose. That
> > patch will touch SKAS3 code, but if I set all three options to "yes" the
> > code should do the same things (again, in terms of strace output).
> >
> > But however, if to keep the code clean we change (let's say) where a
> > certain signal handler is set to later in the boot process, *hoping* that
> > it does not hurt, that's against my definition.

> OK, I straced UML booting and shutting down on a skas3 host, with and
> without the skas0 patch.
Interesting, you'll tell the world how you deleted all the junk out of this... 
(possibly on the Wiki but email is ok).
> I looked at the initialization, syscall interception, and page fault
> handing, and they are identical in the two runs:

> Initialization:

> 	access("/proc/mm", W_OK)                = 0
> 	write(1, "Checking for /proc/mm...found\n", 30) = 30
> 	fork()                                  = 25144
> 	wait4(25144, [WIFSTOPPED(s) && WSTOPSIG(s) == SIGSTOP], WUNTRACED, NULL) =
> 25144 --- SIGCHLD (Child exited) ---
> 	ptrace(PTRACE_???, 25144, 0, 0xbffff7e0) = 0
> 	write(1, "Checking for the skas3 patch in "..., 49) = 49
> 	ptrace(PTRACE_???, 25144, 0, 0x823c100) = 0
> 	ptrace(PTRACE_???, 25144, 0, 0x823c1e0) = 0
> 	ptrace(PTRACE_CONT, 25144, 0, SIG_0)    = 0
>
> Syscall interception:
>
> 	wait4(25145, [WIFSTOPPED(s) && WSTOPSIG(s) == SIGSEGV], WUNTRACED, NULL) =
> 25145 ptrace(PTRACE_???, 25145, 0, 0x8a41888) = 0
> 	ptrace(PTRACE_???, 25145, 0, 0x8a41938) = 0
> 	ptrace(PTRACE_???, 25145, 0, 0x8a41b38) = 0
> 	write(14, "6\0\0\0\0\20\0@\0\20\0\0\5\0\0\0\21\0\0\0\3\0\0\0\0p\270"...,
> 28) = 28 ptrace(PTRACE_???, 25145, 0, 0x8a41888) = 0
> 	ptrace(PTRACE_???, 25145, 0, 0x8a41938) = 0
> 	ptrace(PTRACE_SYSCALL, 25145, 0, SIG_0) = 0
>
> Page fault:
>
> 	wait4(25145, [WIFSTOPPED(s) && WSTOPSIG(s) == 133], WUNTRACED, NULL) =
> 25145 ptrace(PTRACE_???, 25145, 0, 0x8a41888) = 0
> 	ptrace(PTRACE_???, 25145, 0, 0x8a41938) = 0
> 	ptrace(PTRACE_POKEUSER, 25145, 4*ORIG_EAX, 0x14) = 0
> 	ptrace(PTRACE_SYSCALL, 25145, 0, SIG_0) = 0
> 	--- SIGCHLD (Child exited) ---
> 	wait4(25145, [WIFSTOPPED(s) && WSTOPSIG(s) == 133], WUNTRACED, NULL) =
> 25145 ptrace(PTRACE_???, 25145, 0, 0x8a41888) = 0
> 	ptrace(PTRACE_???, 25145, 0, 0x8a41938) = 0
> 	ptrace(PTRACE_SYSCALL, 25145, 0, SIG_0) = 0
>
> With this, are you OK with skas0 being sent to Andrew?
Yes, I'm fine. Send it for -mm now

I'd also like to ship it against 2.6.12 for wider testing.
And the open question is: we (actually you) tested the whole patchset; is 
there any known bug (for skas0) fixed only by patches we are leaving out?
-- 
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894)
http://www.user-mode-linux.org/~blaisorblade

		
___________________________________ 
Yahoo! Messenger: chiamate gratuite in tutto il mondo 
http://it.beta.messenger.yahoo.com



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] Re: Skas0 general testing?

[Jeff Dike]

On Thu, Jun 30, 2005 at 05:14:41PM +0200, Blaisorblade wrote:
> Interesting, you'll tell the world how you deleted all the junk out of this... 
> (possibly on the Wiki but email is ok).

grep -v sigprocmask

> Yes, I'm fine. Send it for -mm now

OK.

> I'd also like to ship it against 2.6.12 for wider testing.
> And the open question is: we (actually you) tested the whole patchset; is 
> there any known bug (for skas0) fixed only by patches we are leaving out?

Until the ldt patches go in, this won't boot some newer filesystems.  My 
Debian 3.0 filesystem, with just skas0 gives me this:

	VFS: Mounted root (ext2 filesystem) readonly.
	cannot set up thread-local storage: cannot set up LDT for thread-local storage

	Kernel panic - not syncing: Attempted to kill init!
 
skas0-clone is also needed to get LDT for children processes correct.  I'm not
sure how much that matters.  I don't remember that ever biting me.

				Jeff


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] Re: Skas0 general testing?

[Blaisorblade]

On Thursday 30 June 2005 18:09, Jeff Dike wrote:
> On Thu, Jun 30, 2005 at 05:14:41PM +0200, Blaisorblade wrote:
> > Interesting, you'll tell the world how you deleted all the junk out of
> > this... (possibly on the Wiki but email is ok).

> grep -v sigprocmask
Hmm, interesting...
> > Yes, I'm fine. Send it for -mm now
>
> OK.

> > I'd also like to ship it against 2.6.12 for wider testing.
> > And the open question is: we (actually you) tested the whole patchset; is
> > there any known bug (for skas0) fixed only by patches we are leaving out?
>
> Until the ldt patches go in, this won't boot some newer filesystems.  My
> Debian 3.0 filesystem, with just skas0 gives me this:
>
> 	VFS: Mounted root (ext2 filesystem) readonly.
> 	cannot set up thread-local storage: cannot set up LDT for thread-local
> storage
>
> 	Kernel panic - not syncing: Attempted to kill init!

> skas0-clone is also needed to get LDT for children processes correct.  I'm
> not sure how much that matters.  I don't remember that ever biting me.

Will hurt for heavily multithreaded apps... Java, Apache, ssh or MySQL would 
be good tests (those are the ones failing with TLS or with the 2.6.9-bb3 
patches for security fixes, until Bodo's fix).

Ok, until that's only for SKAS0, for me it's no problem.
> 				Jeff

-- 
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894)
http://www.user-mode-linux.org/~blaisorblade

	

	
		
___________________________________ 
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB 
http://mail.yahoo.it



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel