[uml-devel] What to send to Andrew next

[uml-devel] What to send to Andrew next

[Jeff Dike]

We've pretty much got -mm and -linus caught up with the updates that had been
sitting around.

At this point, my patch list is a mix of things that both are and aren't ready
for prime time.  So, I'd like opinions on what's ready.

The names below are the ones at 
	http://user-mode-linux.sourceforge.net/patches.html

Here's my take on it:

Ready -
	catch_eintr_generic_console_write
	fix-some-warnings - some things left over from your patch
	need-bash - I changed the comment :-)
	syscall-returns - the start of the x86_64 stuff, this one cleans up
int -> long declarations in the system calls
	type-sizes - ditto for some other types
	syscalls - factors the system calls between generic and arch-specific
a bit better, I consider this safe because you can look at sys_call_table before
and after and see that they're the same
	tmp-exec
	defconfig
	smp-link
	fix-ptrace-interfaces - straightforward interface fixes
	no-chans - makes sure something hits the screen when someone makes
a bogus config
	no-timestamp
	comments

Uncertain -
	use-va_end - looks good to me, but have you figured out why it causes
crashes?
	export-Symbols - I need to look at that phys_t change, which doesn't
belong there
	Single_Linking_Step - leftovers, build linux, add archhelp, you
sent something like this to Andrew, so this may be essentially already there
	do_signal and the rest of Bodo's fixes - I want his test cases before
I send these anywhere, although the ones that make UML look like the other
arches might be OK.

Dangerous -
	3-level-pagetables and the rest of the x86_64 stuff

				Jeff



-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
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] What to send to Andrew next

[BlaisorBlade]

On Friday 22 October 2004 07:16, Jeff Dike wrote:
> We've pretty much got -mm and -linus caught up with the updates that had
> been sitting around.
Yes, our new development way is very effective.
> At this point, my patch list is a mix of things that both are and aren't
> ready for prime time.  So, I'd like opinions on what's ready.

> The names below are the ones at
> 	http://user-mode-linux.sourceforge.net/patches.html

> Here's my take on it:
>
> Ready -
> 	catch_eintr_generic_console_write
I changed slightly the comment:
               /* The terminal becomes a bit less raw, to handle \n also as
                * "Carriage Return", not only as "New Line".
And added:

Otherwise, the new
                * line won't start at the first column.*/

I'm sending it now.
> 	fix-some-warnings - some things left over from your patch
> 	need-bash - I changed the comment :-)
Both already applied.
> 	syscall-returns - the start of the x86_64 stuff, this one cleans up
> int -> long declarations in the system calls
> 	type-sizes - ditto for some other types

> 	syscalls - factors the system calls between generic and arch-specific
> a bit better, I consider this safe because you can look at sys_call_table
> before and after and see that they're the same
I think this is not needed for now - however, I'll write some script for doing 
the check by hand.

And why on x86_64 you do:
#define NR_syscalls 1024
?

> 	tmp-exec
Agreed
> 	defconfig
Probably outdated - I already updated the defconfig here and I'll merge that.
> 	smp-link
Agreed, but I added the same change to the dyn.lds.S script, so I'll send this 
myself. Don't answer "SKAS does not support SMP" - it does not hurt, so let's 
avoid fixing it only when we start SKAS + SMP support.

> 	fix-ptrace-interfaces - straightforward interface fixes
Yes, agreed.

> 	no-chans - makes sure something hits the screen when someone makes
> a bogus config
NO: But why does not the no_config prints a meaningful message? We could also 
insert some #error directives when nothing of this is selected.
When you select no Block Scheduler (no deadline, no CFQ, nothing...) you get a 
#error, in fact.

> 	no-timestamp
Ok.
> 	comments
Ok.

Missing at least:

irq-bits - needed for mainline updates at least since -bk4, but not complete.
Other stuff, which I have here:
-some stuff about SYSEMU support, coming from Bodo work, to fix bugs 
introduced by me/you/Laurent.
- some patches I already sent to the ML and to you to review, which got no 
answer. I want them reviewed, but you should give a look to your mails...

1) FOR INSTANCE, I sent the patch avoiding SIGPROF being touched by 
change_signals(). Why did not you bother at it?
2) copy_from_user_skas() does not make sense. When accessing the page tables, 
they would be happy to get some locking. If you want to take a look to the 
4G-4G patch from Ingo Molnar, which must do something identical, 

> Uncertain -
> 	use-va_end - looks good to me, but have you figured out why it causes
> crashes?
No, I'm busy with other work - SYSEMU. It will be sorted out before 2.6.10, 
however.

> 	export-Symbols - I need to look at that phys_t change, which doesn't
> belong there
Everything apart the "phys_t" change is already merged.

> 	Single_Linking_Step - leftovers, build linux, add archhelp, you
> sent something like this to Andrew, so this may be essentially already
> there

Yes, already in 2.6.9.

> do_signal and the rest of Bodo's fixes - I want his test cases before 
> I send these anywhere, although the ones that make UML look like the other
> arches might be OK.
Well, yes, but let's try to be fast on these. They are very good patches and 
fix also security problems.
> Dangerous -
> 	3-level-pagetables and the rest of the x86_64 stuff
Yes, it must wait.

-- 
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
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] What to send to Andrew next

[Jeff Dike]

blaisorblade_spam@yahoo.it said:
> 1) FOR INSTANCE, I sent the patch avoiding SIGPROF being touched by
> change_signals(). Why did not you bother at it? 
> 2) copy_from_user_skas() does not make sense. When accessing the page
> tables,  they would be happy to get some locking. If you want to take
> a look to the  4G-4G patch from Ingo Molnar, which must do something
> identical,  

Because I lost them, probably.  I'll go look for them.

> Well, yes, but let's try to be fast on these. They are very good
> patches and  fix also security problems. 

Yeah, syscall-security-* can go in now.  I want to see his test cases before
pushing the signal delivery stuff though.

> And why on x86_64 you do: #define NR_syscalls 1024 

> irq-bits - needed for mainline updates at least since -bk4, but not
> complete. 

?  That's removing code that's duplicated now in -mm but not mainline.

Not sure, that was in the patch I have left over from earlier this year, and
I don't remember why it's there.

Looks like we largely agree.  I'm not going to get to push stuff Andrew-ward 
until Sunday at least, so feel free to send stuff in beforehand.

				Jeff




-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
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] What to send to Andrew next

[BlaisorBlade]

On Friday 22 October 2004 23:28, Jeff Dike wrote:
> blaisorblade_spam@yahoo.it said:
> > 1) FOR INSTANCE, I sent the patch avoiding SIGPROF being touched by
> > change_signals(). Why did not you bother at it?
> > 2) copy_from_user_skas() does not make sense. When accessing the page
> > tables,  they would be happy to get some locking. If you want to take
> > a look to the  4G-4G patch from Ingo Molnar, which must do something
> > identical,
>
> Because I lost them, probably.  I'll go look for them.
>
> > Well, yes, but let's try to be fast on these. They are very good
> > patches and  fix also security problems.

> Yeah, syscall-security-* can go in now.  I want to see his test cases
> before pushing the signal delivery stuff though.

> > And why on x86_64 you do: #define NR_syscalls 1024

> > irq-bits - needed for mainline updates at least since -bk4, but not
> > complete.

> ?  That's removing code that's duplicated now in -mm but not mainline.

You refer to irq-bits here. No, it was merged at least since -bk4. Give a look 
at linux.bkbits.com - there is a nice web-interface for checking changelogs. 
Go to either 2.5 or 2.6 - they are the same repository.

> Not sure, that was in the patch I have left over from earlier this year,
> and I don't remember why it's there.
You refer to x86_64.
> Looks like we largely agree.  I'm not going to get to push stuff
> Andrew-ward until Sunday at least, so feel free to send stuff in
> beforehand.

I'm sending some trivial Kconfig changes just now - I'll be away on weekend.

We are also solving the problem on host 2.6.9 - the explaination seems to be 
that we should use PTRACE_KILL instead of just a SIGKILL. Is there any reason 
against that?

If you agree, I'll also merge some of these changes. You can also find, below, 
some issues I've not yet solved, but that I think I've tracked down. They are 
for later, however.

- rename the headers like  arch/um/kernel/skas/include/mmu.h and 
arch/um/kernel/tt/include/mmu.h to mmu-skas and mmu-tt, and update includes.
Including them with #include "../.. [....]" is ugly.

- This patch (apply by hand):

-static void winch_handler(int sig)
-{
-}
-
[...]
-       signal(SIGWINCH, winch_handler);
+       signal(SIGWINCH, SIG_IGN);

-

- not blocking SIGPROF in change_signals.

- I'm moving almost all code away from ubd_user.c to ubd_kern.c. This will 
allow using the new bio's, if needed, for the actual IO. Btw, a BIO contains 
multiple chunks of data; with AIO, we could even try to send them at once and 
see if performance increases (it should, but right now AIO is poorly 
supported).

- why do we disable kmalloc_ok in one piece of code?
I first didn't try answering and sent the patch allowing using kfree() in 
__wrap_free (the one about KMALLOC_START and KMALLOC_STOP, whose real aim was 
this).
While actually looking at this, the only explaination I found was that in that 
point we must be atomic, while kmalloc is not called atomically normally. So, 
we could simply add a global flag for using an atomic kmalloc, instead. 
However, the second way avoids any memory leak, but is still racy when UML is 
SMP. So a spinlock around those flags should be added.

- use the safe mconsole_proc() from Gerd Knorr. I'm just commenting out your 
version, until it's fixed. I understand your point, but until the proc 
command is broken, it's useless. Plus, try compiling HPPFS. It's so broken 
that it mistakes a <type> * for a <type>**, or something such. I have not 
fixed it because if it's so rotten, it will be better rewritten using 
externfs later. I marked it as BROKEN.
-- 
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
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] What to send to Andrew next

[Bodo Stroesser]

Jeff Dike wrote:
> blaisorblade_spam@yahoo.it said:
> 
>>1) FOR INSTANCE, I sent the patch avoiding SIGPROF being touched by
>>change_signals(). Why did not you bother at it? 
>>2) copy_from_user_skas() does not make sense. When accessing the page
>>tables,  they would be happy to get some locking. If you want to take
>>a look to the  4G-4G patch from Ingo Molnar, which must do something
>>identical,  
> 
> 
> Because I lost them, probably.  I'll go look for them.
> 
> 
>>Well, yes, but let's try to be fast on these. They are very good
>>patches and  fix also security problems. 
> 
> 
> Yeah, syscall-security-* can go in now.  I want to see his test cases before
> pushing the signal delivery stuff though.
> 
> 
I'm working to integrate the bulk of tiny tests into a few more handy programs,
they will be mailed as fast as possible.

On your list of incremental patches, there are still missing syscall-security-4
and -5, which fix a bug and a incorrect interpretation in the previos patches.
Is this intentionally?

And to close all holes I've seen so far, the TRACESYSGOOD patches are needed
(Test-case included in breakout.c).

Bodo


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel