Re: [uml-devel] Recent patches of note

Re: [uml-devel] Recent patches of note

[Anthony Brock]

I don't know if this is of interest, but I encountered the following while trying to recreate the freeze. However, the UML will continue to load following this error. For some reason, the freeze doesn't seem repeatable while under the debugger (sigh). Here is the interesting GDB bug:


INIT: Entering runlevel: 2
Starting system log daemon: syslogd.
Starting kernel log daemon: klogd.
Starting OpenLDAP: (db4.2_recover not found),  slapd
Program received signal SIGSEGV, Segmentation fault.
0x080b86d0 in __vmalloc_area (area=0xbd15be0, gfp_mask=210, prot={pgprot = 0}) at string.h:363
363     string.h: No such file or directory.
        in string.h
(gdb) c
Continuing.
BUG: soft lockup detected on CPU#0!

EIP: 0000:[<00000000>] CPU: 0 Not tainted EFLAGS: 00000000
    Not tainted
EAX: 00000000 EBX: 00000000 ECX: 00000000 EDX: 00000000
ESI: 00000000 EDI: 00000000 EBP: 00000000 DS: 0000 ES: 0000
082b76c0:  [<0807c29b>] show_regs+0xeb/0x110
082b76e0:  [<080a0c07>] softlockup_tick+0x57/0x60
082b7700:  [<0808bfa7>] do_timer+0x47/0xd0
082b7710:  [<08063e24>] um_timer+0x14/0xc0
082b7740:  [<080a0e63>] handle_IRQ_event+0x33/0x80
082b7770:  [<080a0f4a>] __do_IRQ+0x9a/0xe0
082b77a0:  [<08060570>] do_IRQ+0x30/0x40
082b77b0:  [<08063d83>] timer_irq+0x113/0x170
082b77e0:  [<080641a8>] timer_handler+0x48/0x50
082b7800:  [<08078d59>] sig_handler_common_skas+0xa9/0x100
082b7830:  [<080747eb>] real_alarm_handler+0x3b/0x60
082b7850:  [<08074857>] alarm_handler+0x47/0x60
082b7870:  [<ffffe420>] _etext+0xf7da0405/0x0
082b7b70:  [<08062356>] default_idle+0x56/0x60
082b7b90:  [<080660a8>] init_idle_skas+0x28/0x30
082b7ba0:  [<0806236b>] cpu_idle+0xb/0x10
082b7bb0:  [<0805f2db>] rest_init+0x2b/0x30
082b7bd0:  [<08049643>] start_kernel+0x173/0x1b0
082b7bf0:  [<080660dc>] start_kernel_proc+0x2c/0x40
082b7c00:  [<0807408c>] run_kernel_thread+0x5c/0x60
082b7ce0:  [<08065dea>] new_thread_handler+0xba/0x110
082b7d20:  [<ffffe420>] _etext+0xf7da0405/0x0


Program received signal SIGSEGV, Segmentation fault.
0x080668ad in copy_chunk_from_user (from=196263936, len=4096, arg=0xbb3bad4) at string.h:199
199     string.h: No such file or directory.
        in string.h
(gdb) bt
#0  0x080668ad in copy_chunk_from_user (from=196263936, len=4096, arg=0xbb3bad4) at string.h:199
#1  0x080666d4 in do_op (addr=196263936, len=4096, is_write=4096, op=0x8066890 <copy_chunk_from_user>, arg=0x1000)
    at arch/um/kernel/skas/uaccess.c:54
#2  0x080667f8 in do_buffer_op (jmpbuf=0x1000, arg_ptr=0x1000) at arch/um/kernel/skas/uaccess.c:95
#3  0x08076aef in setjmp_wrapper (proc=0x80666e0 <do_buffer_op>) at arch/um/os-Linux/util.c:111
#4  0x08066862 in buffer_op (addr=1075109888, len=6102308, is_write=4096, op=0x1000, arg=0x1000)
    at arch/um/kernel/skas/uaccess.c:123
#5  0x08066935 in copy_from_user_skas (to=0xc816000, from=0x4014e000, n=196328148) at arch/um/kernel/skas/uaccess.c:147
#6  0x0809e32f in load_module (umod=0x1000, len=6102308, uargs=0x8050a20 "\211\004$èÜà") at um_uaccess.h:32
#7  0x0809ed85 in sys_init_module (umod=0x1000, len=4096, uargs=0x1000 <Address 0x1000 out of bounds>) at kernel/module.c:1868
#8  0x080662fa in execute_syscall_skas (r=0x5d1d24) at arch/um/kernel/skas/syscall_kern.c:29
#9  0x08066322 in handle_syscall (regs=0xbd0e808) at arch/um/kernel/skas/syscall_kern.c:44
#10 0x08077e4a in handle_trap (pid=19465, regs=0xbd0e808, local_using_sysemu=2) at arch/um/os-Linux/skas/process.c:134
#11 0x080784d2 in userspace (regs=0xbd0e808) at arch/um/os-Linux/skas/process.c:276
#12 0x08065e0c in new_thread_handler (sig=10) at thread_info.h:47
#13 <signal handler called>
#14 0xb7ed9ab1 in kill () from /lib/tls/libc.so.6
#15 0x08073c6a in os_usr1_process (pid=0) at arch/um/os-Linux/process.c:118
#16 0x08074bf1 in set_signals (enable=196310340) at arch/um/os-Linux/signal.c:263
#17 0x08078930 in new_thread (stack=0xbb38000, switch_buf_ptr=0x0, fork_buf_ptr=0x0, handler=0x8065d30 <new_thread_handler>)
    at arch/um/os-Linux/skas/process.c:446
#18 0x08065fc0 in copy_thread_skas (nr=0, clone_flags=8388881, sp=196310340, stack_top=0, p=0xbd0e640, regs=0x0)
    at arch/um/kernel/skas/process_kern.c:125
#19 0x0806227b in copy_thread (nr=0, clone_flags=0, sp=0, stack_top=0, p=0xbb37544, regs=0x0) at arch/um/kernel/process_kern.c:149
#20 0x0bb34000 in ?? ()
#21 0x083da2c0 in ?? ()
#22 0x0bd0e0a0 in ?? ()
#23 0x0bb37a4c in ?? ()
#24 0x08062138 in _switch_to (prev=0x0, next=0x0, last=0xbd0e0a0) at arch/um/kernel/process_kern.c:114
#25 0x0825b191 in schedule () at kernel/sched.c:1642
#26 0x0808522c in do_wait (pid=899, options=4, infop=0x0, stat_addr=0xbdd3a2c, ru=0x0) at kernel/exit.c:1456
#27 0x0808579c in sys_wait4 (pid=0, stat_addr=0x0, options=196310340, ru=0x0) at kernel/exit.c:1532
#28 0x080938b7 in wait_for_helper (data=0xbdd3a14) at kernel/kmod.c:189
#29 0x0807408c in run_kernel_thread (fn=0x8093830 <wait_for_helper>, arg=0xbdd3a14, jmp_ptr=0x0) at arch/um/os-Linux/process.c:215
#30 0x08065dea in new_thread_handler (sig=10) at thread_info.h:47
#31 <signal handler called>
#32 0xb7ed9ab1 in kill () from /lib/tls/libc.so.6
#33 0x08073c6a in os_usr1_process (pid=0) at arch/um/os-Linux/process.c:118
#34 0x08074bf1 in set_signals (enable=144077940) at arch/um/os-Linux/signal.c:263
#35 0x08078930 in new_thread (stack=0xbb34000, switch_buf_ptr=0x0, fork_buf_ptr=0x0, handler=0x8065d30 <new_thread_handler>)
    at arch/um/os-Linux/skas/process.c:446
#36 0x08065fc0 in copy_thread_skas (nr=0, clone_flags=8390417, sp=144077940, stack_top=0, p=0xbd0e0a0, regs=0x0)
    at arch/um/kernel/skas/process_kern.c:125
#37 0x0806227b in copy_thread (nr=0, clone_flags=0, sp=0, stack_top=0, p=0x8967474, regs=0x0) at arch/um/kernel/process_kern.c:149
#38 0xb7ed95fa in siglongjmp () from /lib/tls/libc.so.6
#39 0x08078a24 in switch_threads (me=0x0, next=0xbb37c24) at arch/um/os-Linux/skas/process.c:467
#40 0x08065cdf in switch_to_skas (prev=0x8940040, next=0xbd0e0a0) at arch/um/kernel/skas/process_kern.c:38
---Type <return> to continue, or q <return> to quit---
#41 0x08062138 in _switch_to (prev=0x0, next=0x0, last=0x8940040) at arch/um/kernel/process_kern.c:114
#42 0x0825b191 in schedule () at kernel/sched.c:1642
#43 0x08093e2c in worker_thread (__cwq=0x892c6e0) at kernel/workqueue.c:208
#44 0x080981b9 in kthread (_create=0x8947b24) at kernel/kthread.c:95
#45 0x0807408c in run_kernel_thread (fn=0x8098100 <kthread>, arg=0x8947b24, jmp_ptr=0x0) at arch/um/os-Linux/process.c:215
#46 0x08065dea in new_thread_handler (sig=10) at thread_info.h:47
#47 <signal handler called>
#48 0xb7ed9ab1 in kill () from /lib/tls/libc.so.6
#49 0x00000000 in ?? ()
#50 0x00000000 in ?? ()
#51 0x00000000 in ?? ()
#52 0x00000000 in ?? ()
#53 0x00000000 in ?? ()
#54 0x00000000 in ?? ()
#55 0x00000000 in ?? ()
#56 0x00000000 in ?? ()
#57 0x00000000 in ?? ()
#58 0x08065e80 in release_thread_skas () at arch/um/kernel/skas/process_kern.c:83
Previous frame inner to this frame (corrupt stack?)


Tony


>>> "Anthony Brock" <Anthony_Brock@ous.edu> 06/16/05 03:36PM >>>
Okay, two items of interest:

First, both instances are running the "rngd" daemon for random support. However, this daemon seems to be consuming between 8-15% of the CPU time on a consistent basis. Even after running for 20-30 minutes, the daemon is till busy.

Second, I'm once again enountering problems with launch the UML instance. It likes to hang at:


Checking that ptrace can change system call numbers...OK
Checking syscall emulation patch for ptrace...OK
Checking advanced syscall emulation patch for ptrace...OK
Checking if syscall restart handling in host can be skipped...OK
Checking for the skas3 patch in the host:
  - /proc/mm...found
  - PTRACE_FAULTINFO...found
  - PTRACE_LDT...found
Checking PROT_EXEC mmap in /tmp...OK


I'll see if I can get a backtrace on this...

Tony


>>> Jeff Dike <jdike@addtoit.com> 06/16/05 03:13PM >>>
On Thu, Jun 16, 2005 at 02:26:13PM -0700, Anthony Brock wrote:
> Well, so far this seems to be running fine. However, I'm still
> seeing the load average >= 1 issue. This is a 2.6.12-rc6-mm1 host with
> your patches from this morning running on a 2.6.11.7-skas3-v8 custom
> built host kernel. 

OK, thanks for letting me know.

				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 



-------------------------------------------------------
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_idt77&alloc_id492&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


-------------------------------------------------------
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_idt77&alloc_id\x16492&opÌk
_______________________________________________
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] Recent patches of note

[Jeff Dike]

On Mon, Jun 20, 2005 at 10:19:12AM -0700, Anthony Brock wrote:
> Strange. This option doesn't seem to be available. I'm seeing the following in my .config file:

> # Hardware I/O ports
> #
> # CONFIG_SERIO is not set

It would have been here if you didn't have CONFIG_SERIO disabled.  So that's 
not your problem.

What might be your problem is that the softints patch had a bug which broke
signal handling on x86_64.  Pull the current patchset and try that.

				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] Recent patches of note

[Jeff Dike]

On Thu, Jun 16, 2005 at 03:36:24PM -0700, Anthony Brock wrote:
> Second, I'm once again enountering problems with launch the UML instance. It likes to hang at:
> 
> 
> Checking that ptrace can change system call numbers...OK
> Checking syscall emulation patch for ptrace...OK
> Checking advanced syscall emulation patch for ptrace...OK
> Checking if syscall restart handling in host can be skipped...OK
> Checking for the skas3 patch in the host:
>   - /proc/mm...found
>   - PTRACE_FAULTINFO...found
>   - PTRACE_LDT...found
> Checking PROT_EXEC mmap in /tmp...OK

I remembered what this was about.  Disable CONFIG_I8042, under -
	UML-specific options
	Input device support
	Hardware I/O ports
	i8042 PC Keyboard controller

This is a UML bug which I haven't tracked down yet.

				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] Recent patches of note

[William Stearns]

Good afternoon, all,

On Mon, 20 Jun 2005, Jeff Dike wrote:

> On Thu, Jun 16, 2005 at 03:36:24PM -0700, Anthony Brock wrote:
>> Second, I'm once again enountering problems with launch the UML instance. It likes to hang at:
>>
>>
>> Checking that ptrace can change system call numbers...OK
>> Checking syscall emulation patch for ptrace...OK
>> Checking advanced syscall emulation patch for ptrace...OK
>> Checking if syscall restart handling in host can be skipped...OK
>> Checking for the skas3 patch in the host:
>>   - /proc/mm...found
>>   - PTRACE_FAULTINFO...found
>>   - PTRACE_LDT...found
>> Checking PROT_EXEC mmap in /tmp...OK
>
> I remembered what this was about.  Disable CONFIG_I8042, under -
> 	UML-specific options
> 	Input device support
> 	Hardware I/O ports
> 	i8042 PC Keyboard controller
>
> This is a UML bug which I haven't tracked down yet.

 	Just for reference, that's CONFIG_SERIO_I8042 on 2.6 kernels.
 	I disabled that on the kernel that was giving me the same hang 
point on x86_64 and....  same hang.  I turned off all the other hardware 
options in that menu (serial port, game port) and.... hmmm.  A kernel that 
was at least successfully building before is now:

   CC      arch/um/sys-x86_64/signal.o
arch/um/sys-x86_64/signal.c: In function 'setup_signal_stack_si':
arch/um/sys-x86_64/signal.c:171: error: invalid lvalue in assignment
make[1]: *** [arch/um/sys-x86_64/signal.o] Error 1
make: *** [arch/um/sys-x86_64] Error 2

 	The line in question is the ((unsigned char... :

         frame = (struct rt_sigframe __user *)
                 round_down(stack_top - sizeof(struct rt_sigframe), 16) - 8;
         ((unsigned char *) frame) -= 128;

         if (!access_ok(VERIFY_WRITE, fp, sizeof(struct _fpstate)))
                 goto out;


 	I'm reasonably sure this showed up because I upgraded to fc4 at 
the end of last week - sorry about that.
 	.config attached.
 	Cheers,
 	- Bill

---------------------------------------------------------------------------
     "My PID is Inigo Montoya. You kill -9 my parent process. Prepare to
vi."
     - TVmisGuided on Slashdot
--------------------------------------------------------------------------
William Stearns (wstearns@pobox.com).  Mason, Buildkernel, freedups, p0f,
rsync-backup, ssh-keyinstall, dns-check, more at:   http://www.stearns.org
--------------------------------------------------------------------------


-------------------------------------------------------
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] Recent patches of note

[Blaisorblade]

On Monday 20 June 2005 19:59, William Stearns wrote:
> Good afternoon, all,
>
> On Mon, 20 Jun 2005, Jeff Dike wrote:
> > On Thu, Jun 16, 2005 at 03:36:24PM -0700, Anthony Brock wrote:
> >> Second, I'm once again enountering problems with launch the UML
> >> instance. It likes to hang at:
> >>
> >>
> >> Checking that ptrace can change system call numbers...OK
> >> Checking syscall emulation patch for ptrace...OK
> >> Checking advanced syscall emulation patch for ptrace...OK
> >> Checking if syscall restart handling in host can be skipped...OK
> >> Checking for the skas3 patch in the host:
> >>   - /proc/mm...found
> >>   - PTRACE_FAULTINFO...found
> >>   - PTRACE_LDT...found
> >> Checking PROT_EXEC mmap in /tmp...OK
> >
> > I remembered what this was about.  Disable CONFIG_I8042, under -
> > 	UML-specific options
> > 	Input device support
> > 	Hardware I/O ports
> > 	i8042 PC Keyboard controller
> >
> > This is a UML bug which I haven't tracked down yet.
>
>  	Just for reference, that's CONFIG_SERIO_I8042 on 2.6 kernels.
>  	I disabled that on the kernel that was giving me the same hang
> point on x86_64 and....  same hang.  I turned off all the other hardware
> options in that menu (serial port, game port) and.... hmmm.  A kernel that
> was at least successfully building before is now:
>
>    CC      arch/um/sys-x86_64/signal.o
> arch/um/sys-x86_64/signal.c: In function 'setup_signal_stack_si':
> arch/um/sys-x86_64/signal.c:171: error: invalid lvalue in assignment
> make[1]: *** [arch/um/sys-x86_64/signal.o] Error 1
> make: *** [arch/um/sys-x86_64] Error 2
>
>  	The line in question is the ((unsigned char... :

That's a removed extension with GCC 4, so upgrading to FC4 is exactly the 
reason...

Replace the offending line with

frame -= 128 / sizeof(*frame);

And it should compile. In which case, Jeff may like a patch (or at least an 
ACK to do it himself).

>          frame = (struct rt_sigframe __user *)
>                  round_down(stack_top - sizeof(struct rt_sigframe), 16) -
> 8; ((unsigned char *) frame) -= 128;
>
>          if (!access_ok(VERIFY_WRITE, fp, sizeof(struct _fpstate)))
>                  goto out;

>  	I'm reasonably sure this showed up because I upgraded to fc4 at
> the end of last week - sorry about that.

-- 
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] Recent patches of note

[Jeff Dike]

On Thu, Jun 16, 2005 at 03:59:24PM -0700, Anthony Brock wrote:
> Program received signal SIGSEGV, Segmentation fault.
> 0x080b86d0 in __vmalloc_area (area=0xbd15be0, gfp_mask=210, prot={pgprot = 0}) at string.h:363

Segfaults in vmalloc are completely normal.  They are just page faults.

> BUG: soft lockup detected on CPU#0!

The soft lockups should be fixed by the sched-starve patch.  This one is
likely caused by you sitting in the debugger.

If you do see any that don't involve gdb, and you have sched-starve applied,
let me know.

				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] Recent patches of note

[Jeff Dike]

On Thu, Jun 16, 2005 at 02:26:13PM -0700, Anthony Brock wrote:
> Well, so far this seems to be running fine. However, I'm still
> seeing the load average >= 1 issue. This is a 2.6.12-rc6-mm1 host with
> your patches from this morning running on a 2.6.11.7-skas3-v8 custom
> built host kernel. 

OK, thanks for letting me know.

				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] Recent patches of note

[Jeff Dike]

I'd like to call attention to some recent patches that may be of interest
to people before they hit mainline.  These are all on my incremental patches
page, http://user-mode-linux.sf.net/patches.html

First, sched-starve (http://user-mode-linux.sourceforge.net/work/current/2.6/2.6.12-rc6-mm1/patches/sched-starve)

This fixes a timer initialization botch which resulted in soft lockup
warnings in recent kernels, total non-responsiveness (i.e. nothing
else would be scheduled) under any workload which avoided idling the
kernel, and may be responsible for the load average >= 1 problem.

I don't see that last here for some reason, so I'd like some
confirmation (or not) that this patch fixes that.

Second, I implemented soft interrupts, which reimplements interrupt
enabling and disabling with a flag rather than with sigprocmask.  This
cuts down hugely on the number of system calls that UML makes,
resulting in a very noticable performance increase.  This patch, plus
the other system call reducing patches which immediately follow it,
speed up my kernel builds by 20-25%.  By far the largest piece of this
is softints, although skas-no-flush-kernel also is noticable.

I'd like people to check out softints, at least, and report any
problems.  It's running fine here, but interrupt handling is a
sensitive area, so I'd like to know people are running it without
problems before pushing it to mainline.

				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] Recent patches of note

[Bodo Stroesser]

Jeff Dike wrote:
> I'd like to call attention to some recent patches that may be of interest
> to people before they hit mainline.  These are all on my incremental patches
> page, http://user-mode-linux.sf.net/patches.html
> 
> First, sched-starve (http://user-mode-linux.sourceforge.net/work/current/2.6/2.6.12-rc6-mm1/patches/sched-starve)
> 
> This fixes a timer initialization botch which resulted in soft lockup
> warnings in recent kernels, total non-responsiveness (i.e. nothing
> else would be scheduled) under any workload which avoided idling the
> kernel, and may be responsible for the load average >= 1 problem.
> 
> I don't see that last here for some reason, so I'd like some
> confirmation (or not) that this patch fixes that.
> 
> Second, I implemented soft interrupts, which reimplements interrupt
> enabling and disabling with a flag rather than with sigprocmask.  This
> cuts down hugely on the number of system calls that UML makes,
> resulting in a very noticable performance increase.  This patch, plus
> the other system call reducing patches which immediately follow it,
> speed up my kernel builds by 20-25%.  By far the largest piece of this
> is softints, although skas-no-flush-kernel also is noticable.
Great!

> 
> I'd like people to check out softints, at least, and report any
> problems.  It's running fine here, but interrupt handling is a
> sensitive area, so I'd like to know people are running it without
> problems before pushing it to mainline.
> 
> 				Jeff
Currently my time is *very* limited, so I can't test. Reading the patches
only the one that makes me worry is "dont-save-fpregs".
To not save fpregs on every syscall or interrupt is O.K.
But you also have to modify signal-handling, that currently relies on
fpregs being saved. And you have to save and restore fpregs in switch_to
for SKAS3 and also for SKAS0, if processes share the same mm.
Then, I think special handling is needed for the fpregs in copy_thread
and probably in execve also.

	Bodo


-------------------------------------------------------
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] Recent patches of note

[Jeff Dike]

On Thu, Jun 16, 2005 at 07:36:57PM +0200, Bodo Stroesser wrote:
> Reading the patches
> only the one that makes me worry is "dont-save-fpregs".
> To not save fpregs on every syscall or interrupt is O.K.
> But you also have to modify signal-handling, that currently relies on
> fpregs being saved. And you have to save and restore fpregs in switch_to
> for SKAS3 and also for SKAS0, if processes share the same mm.
> Then, I think special handling is needed for the fpregs in copy_thread
> and probably in execve also.

Good points, I'll fix things accordingly.

				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] Recent patches of note

[Bodo Stroesser]

Jeff Dike wrote:
> I'll fix things accordingly.
> 
Could you please make handling in switch_to subarch-specific,
e.g. in arch_switch_to?
s390 might have some special handling for fpregs and debug-regs
in a single syscall.

	Bodo


-------------------------------------------------------
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] Recent patches of note

[Bodo Stroesser]

Bodo Stroesser wrote:
> Jeff Dike wrote:
> 
>> I'll fix things accordingly.
>>
> Could you please make handling in switch_to subarch-specific,
> e.g. in arch_switch_to?
> s390 might have some special handling for fpregs and debug-regs
> in a single syscall.
> 
>     Bodo
Oh, I guess I forgot to add ptrace to the list of changes. If a
debugger in UML wants to read childs fpregs via ptrace while UML
runs SKAS0 and ptraced child doesn't share it's mm, fpregs need
to be read before they can be given to the debugger.

	Bodo


-------------------------------------------------------
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] Recent patches of note

[Blaisorblade]

[-- Attachment #1: Type: text/plain, Size: 801 bytes --]

On Thursday 16 June 2005 19:55, Bodo Stroesser wrote:
> Jeff Dike wrote:
> > I'll fix things accordingly.

> Could you please make handling in switch_to subarch-specific,
> e.g. in arch_switch_to?
arch_switch already exists (wasn't used for SKAS). About improving it and 
making it more "general-purpose" (I've written this for the TLS code needs), 
could you have a look to the attached patches? do_fork-* is another thing (a 
cleanup discussed some time ago with Jeff) but may be needed to apply the 
second.
> s390 might have some special handling for fpregs and debug-regs
> in a single syscall.

-- 
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

[-- Attachment #2: uml-clean-arch_switch.patch --]
[-- Type: text/x-diff, Size: 7583 bytes --]


Call arch_switch also in switch_to_skas, even if it's a no-op for that case
(and mark this in the comment).

Also, arch_switch for TT mode is actually useless when the PT proxy (a
complicate debugging instrumentation for TT mode) is not enabled. In fact, it
only calls update_debugregs, which checks debugregs_seq against seq (to check
if the registers are up-to-date - seq here means a "version number" of the
registers).

If the ptrace proxy is not enabled, debugregs_seq always stays 0 and
update_debugregs will be a no-op. So, optimize this out (the compiler can't do
it).

Also, I've been disappointed by the fact that it would make a lot of sense if,
after calling a successful
update_debugregs(current->thread.arch.debugregs_seq),
current->thread.arch.debugregs_seq were updated with the new debugregs_seq.
But this is not done. Is this a bug or a feature? For all purposes, it seems a
bug (otherwise the whole mechanism does not make sense, which is also a
possibility to check), which causes some performance only problems (not
correctness), since we write_debugregs when not needed.

Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
---

 linux-2.6.git-paolo/arch/um/include/kern_util.h          |    5 ++++-
 linux-2.6.git-paolo/arch/um/include/sysdep-i386/ptrace.h |    5 +++++
 linux-2.6.git-paolo/arch/um/kernel/skas/process_kern.c   |    4 +++-
 linux-2.6.git-paolo/arch/um/kernel/tt/process_kern.c     |   13 +++++++++++--
 linux-2.6.git-paolo/arch/um/sys-i386/ptrace.c            |    4 ++--
 linux-2.6.git-paolo/arch/um/sys-i386/ptrace_user.c       |   10 +++++++++-
 6 files changed, 34 insertions(+), 7 deletions(-)

diff -puN arch/um/include/sysdep-i386/ptrace.h~uml-clean-arch_switch arch/um/include/sysdep-i386/ptrace.h
--- linux-2.6.git/arch/um/include/sysdep-i386/ptrace.h~uml-clean-arch_switch	2005-06-02 18:46:18.000000000 +0200
+++ linux-2.6.git-paolo/arch/um/include/sysdep-i386/ptrace.h	2005-06-02 18:46:18.000000000 +0200
@@ -12,7 +12,12 @@
 #define MAX_REG_NR (UM_FRAME_SIZE / sizeof(unsigned long))
 #define MAX_REG_OFFSET (UM_FRAME_SIZE)
 
+#ifdef UML_CONFIG_PT_PROXY
 extern void update_debugregs(int seq);
+#else
+static inline void update_debugregs(int seq) {}
+#endif
+
 
 /* syscall emulation path in ptrace */
 
diff -puN arch/um/kernel/skas/process_kern.c~uml-clean-arch_switch arch/um/kernel/skas/process_kern.c
--- linux-2.6.git/arch/um/kernel/skas/process_kern.c~uml-clean-arch_switch	2005-06-02 18:46:18.000000000 +0200
+++ linux-2.6.git-paolo/arch/um/kernel/skas/process_kern.c	2005-06-02 18:46:18.000000000 +0200
@@ -41,10 +41,12 @@ void *switch_to_skas(void *prev, void *n
 	switch_threads(&from->thread.mode.skas.switch_buf, 
 		       to->thread.mode.skas.switch_buf);
 
+	arch_switch(current->thread.prev_sched, current);
+
 	if(current->pid == 0)
 		switch_timers(1);
 
-	return(current->thread.prev_sched);
+	return current->thread.prev_sched;
 }
 
 extern void schedule_tail(struct task_struct *prev);
diff -puN arch/um/sys-i386/ptrace.c~uml-clean-arch_switch arch/um/sys-i386/ptrace.c
--- linux-2.6.git/arch/um/sys-i386/ptrace.c~uml-clean-arch_switch	2005-06-02 18:46:18.000000000 +0200
+++ linux-2.6.git-paolo/arch/um/sys-i386/ptrace.c	2005-06-02 18:46:18.000000000 +0200
@@ -14,9 +14,9 @@
 #include "sysdep/sigcontext.h"
 #include "sysdep/sc.h"
 
-void arch_switch(void)
+void arch_switch(struct task_struct *from, struct task_struct *to)
 {
-	update_debugregs(current->thread.arch.debugregs_seq);
+	CHOOSE_MODE(update_debugregs(to->thread.arch.debugregs_seq), 0);
 }
 
 int is_syscall(unsigned long addr)
diff -puN arch/um/sys-i386/ptrace_user.c~uml-clean-arch_switch arch/um/sys-i386/ptrace_user.c
--- linux-2.6.git/arch/um/sys-i386/ptrace_user.c~uml-clean-arch_switch	2005-06-02 18:46:18.000000000 +0200
+++ linux-2.6.git-paolo/arch/um/sys-i386/ptrace_user.c	2005-06-02 18:46:18.000000000 +0200
@@ -14,6 +14,7 @@
 #include "sysdep/thread.h"
 #include "user.h"
 #include "os.h"
+#include "uml-config.h"
 
 int ptrace_getregs(long pid, unsigned long *regs_out)
 {
@@ -43,6 +44,7 @@ int ptrace_setfpregs(long pid, unsigned 
 	return 0;
 }
 
+/* All the below stuff is of interest for TT mode only */
 static void write_debugregs(int pid, unsigned long *regs)
 {
 	struct user *dummy;
@@ -75,7 +77,6 @@ static void read_debugregs(int pid, unsi
 
 /* Accessed only by the tracing thread */
 static unsigned long kernel_debugregs[8] = { [ 0 ... 7 ] = 0 };
-static int debugregs_seq = 0;
 
 void arch_enter_kernel(void *task, int pid)
 {
@@ -89,6 +90,11 @@ void arch_leave_kernel(void *task, int p
 	write_debugregs(pid, TASK_DEBUGREGS(task));
 }
 
+#ifdef UML_CONFIG_PT_PROXY
+/* Accessed only by the tracing thread */
+static int debugregs_seq = 0;
+
+/* Only called by the ptrace proxy */
 void ptrace_pokeuser(unsigned long addr, unsigned long data)
 {
 	if((addr < offsetof(struct user, u_debugreg[0])) ||
@@ -109,6 +115,7 @@ static void update_debugregs_cb(void *ar
 	write_debugregs(pid, kernel_debugregs);
 }
 
+/* Optimized out in its header when not defined */
 void update_debugregs(int seq)
 {
 	int me;
@@ -118,6 +125,7 @@ void update_debugregs(int seq)
 	me = os_getpid();
 	initial_thread_cb(update_debugregs_cb, &me);
 }
+#endif
 
 /*
  * Overrides for Emacs so that we follow Linus's tabbing style.
diff -puN arch/um/include/kern_util.h~uml-clean-arch_switch arch/um/include/kern_util.h
--- linux-2.6.git/arch/um/include/kern_util.h~uml-clean-arch_switch	2005-06-02 18:46:18.000000000 +0200
+++ linux-2.6.git-paolo/arch/um/include/kern_util.h	2005-06-02 18:46:18.000000000 +0200
@@ -107,7 +107,10 @@ extern void *get_current(void);
 extern struct task_struct *get_task(int pid, int require);
 extern void machine_halt(void);
 extern int is_syscall(unsigned long addr);
-extern void arch_switch(void);
+
+struct task_struct;
+extern void arch_switch(struct task_struct *from, struct task_struct *to);
+
 extern void free_irq(unsigned int, void *);
 extern int um_in_interrupt(void);
 extern int cpu(void);
diff -puN arch/um/kernel/tt/process_kern.c~uml-clean-arch_switch arch/um/kernel/tt/process_kern.c
--- linux-2.6.git/arch/um/kernel/tt/process_kern.c~uml-clean-arch_switch	2005-06-02 18:46:18.000000000 +0200
+++ linux-2.6.git-paolo/arch/um/kernel/tt/process_kern.c	2005-06-02 18:46:18.000000000 +0200
@@ -55,6 +55,13 @@ void *switch_to_tt(void *prev, void *nex
 	c = 0;
 	set_current(to);
 
+	/* Notice that here we "up" the semaphore on which "to" is waiting, and
+	 * below (the read) we wait on this semaphore (which is implemented by
+	 * switch_pipe) and go sleeping. Thus, after that, we have resumed in
+	 * "to", and can't use any more the value of "from" (which is outdated),
+	 * nor the value in "to" (since it was the task which stole us the CPU,
+	 * which we don't care about). */
+
 	err = os_write_file(to->thread.mode.tt.switch_pipe[1], &c, sizeof(c));
 	if(err != sizeof(c))
 		panic("write of switch_pipe failed, err = %d", -err);
@@ -81,12 +88,12 @@ void *switch_to_tt(void *prev, void *nex
 	change_sig(SIGALRM, alrm);
 	change_sig(SIGPROF, prof);
 
-	arch_switch();
+	arch_switch(prev_sched, current);
 
 	flush_tlb_all();
 	local_irq_restore(flags);
 
-	return(current->thread.prev_sched);
+	return prev_sched;
 }
 
 void release_thread_tt(struct task_struct *task)
@@ -147,6 +154,8 @@ static void new_thread_handler(int sig)
 	set_cmdline("(kernel thread)");
 
 	change_sig(SIGUSR1, 1);
+	/* XXX: This is bogus, it's already done in local_irq_enable. Or does
+	 * ordering matters? */
 	change_sig(SIGVTALRM, 1);
 	change_sig(SIGPROF, 1);
 	local_irq_enable();
_

[-- Attachment #3: uml-do_fork-param-cleanup.patch --]
[-- Type: text/x-diff, Size: 8236 bytes --]


Fix the do_fork calling convention: normal arch pass the regs and the new sp
value to do_fork instead of NULL.

Currently the arch-independent code ignores these values, while the UML code
(actually it's copy_thread) gets the right values by itself.

With this patch, things are fixed up.

Low-priority.

Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
---

 linux-2.6.git-paolo/arch/um/kernel/process_kern.c      |    5 ++-
 linux-2.6.git-paolo/arch/um/kernel/skas/process_kern.c |   13 ----------
 linux-2.6.git-paolo/arch/um/kernel/syscall_kern.c      |   19 +++-----------
 linux-2.6.git-paolo/arch/um/kernel/tt/process_kern.c   |   15 +----------
 linux-2.6.git-paolo/arch/um/sys-i386/syscalls.c        |   22 ++---------------
 linux-2.6.git-paolo/arch/um/sys-x86_64/syscalls.c      |   22 ++---------------
 6 files changed, 17 insertions(+), 79 deletions(-)

diff -puN arch/um/sys-i386/syscalls.c~uml-do_fork-param-cleanup arch/um/sys-i386/syscalls.c
--- linux-2.6.git/arch/um/sys-i386/syscalls.c~uml-do_fork-param-cleanup	2005-06-02 05:06:42.000000000 +0200
+++ linux-2.6.git-paolo/arch/um/sys-i386/syscalls.c	2005-06-02 05:06:42.000000000 +0200
@@ -69,15 +69,10 @@ long sys_clone(unsigned long clone_flags
 {
 	long ret;
 
-	/* XXX: normal arch do here this pass, and also pass the regs to
-	 * do_fork, instead of NULL. Currently the arch-independent code
-	 * ignores these values, while the UML code (actually it's
-	 * copy_thread) does the right thing. But this should change,
-	 probably. */
-	/*if (!newsp)
-		newsp = UPT_SP(current->thread.regs);*/
+	if (!newsp)
+		newsp = UPT_SP(&current->thread.regs.regs);
 	current->thread.forking = 1;
-	ret = do_fork(clone_flags, newsp, NULL, 0, parent_tid, child_tid);
+	ret = do_fork(clone_flags, newsp, &current->thread.regs, 0, parent_tid, child_tid);
 	current->thread.forking = 0;
 	return(ret);
 }
@@ -197,14 +192,3 @@ long sys_sigaction(int sig, const struct
 
 	return ret;
 }
-
-/*
- * Overrides for Emacs so that we follow Linus's tabbing style.
- * Emacs will notice this stuff at the end of the file and automatically
- * adjust the settings for this buffer only.  This must remain at the end
- * of the file.
- * ---------------------------------------------------------------------------
- * Local variables:
- * c-file-style: "linux"
- * End:
- */
diff -puN arch/um/kernel/tt/process_kern.c~uml-do_fork-param-cleanup arch/um/kernel/tt/process_kern.c
--- linux-2.6.git/arch/um/kernel/tt/process_kern.c~uml-do_fork-param-cleanup	2005-06-02 05:06:42.000000000 +0200
+++ linux-2.6.git-paolo/arch/um/kernel/tt/process_kern.c	2005-06-02 18:47:47.000000000 +0200
@@ -266,8 +266,8 @@ int copy_thread_tt(int nr, unsigned long
 	}
 
 	if(current->thread.forking){
-		sc_to_sc(UPT_SC(&p->thread.regs.regs), 
-			 UPT_SC(&current->thread.regs.regs));
+		sc_to_sc(UPT_SC(&p->thread.regs.regs),
+			 UPT_SC(&regs->regs));
 		SC_SET_SYSCALL_RETURN(UPT_SC(&p->thread.regs.regs), 0);
 		if(sp != 0) SC_SP(UPT_SC(&p->thread.regs.regs)) = sp;
 	}
@@ -459,14 +459,3 @@ int is_valid_pid(int pid)
 	read_unlock(&tasklist_lock);
 	return(0);
 }
-
-/*
- * Overrides for Emacs so that we follow Linus's tabbing style.
- * Emacs will notice this stuff at the end of the file and automatically
- * adjust the settings for this buffer only.  This must remain at the end
- * of the file.
- * ---------------------------------------------------------------------------
- * Local variables:
- * c-file-style: "linux"
- * End:
- */
diff -puN arch/um/kernel/skas/process_kern.c~uml-do_fork-param-cleanup arch/um/kernel/skas/process_kern.c
--- linux-2.6.git/arch/um/kernel/skas/process_kern.c~uml-do_fork-param-cleanup	2005-06-02 05:06:42.000000000 +0200
+++ linux-2.6.git-paolo/arch/um/kernel/skas/process_kern.c	2005-06-02 18:47:47.000000000 +0200
@@ -107,7 +107,7 @@ int copy_thread_skas(int nr, unsigned lo
 
 	if(current->thread.forking){
 	  	memcpy(&p->thread.regs.regs.skas, 
-		       &current->thread.regs.regs.skas, 
+		       &regs->regs.skas,
 		       sizeof(p->thread.regs.regs.skas));
 		REGS_SET_SYSCALL_RETURN(p->thread.regs.regs.skas.regs, 0);
 		if(sp != 0) REGS_SP(p->thread.regs.regs.skas.regs) = sp;
@@ -196,14 +196,3 @@ int thread_pid_skas(struct task_struct *
 #warning Need to look up userspace_pid by cpu
 	return(userspace_pid[0]);
 }
-
-/*
- * Overrides for Emacs so that we follow Linus's tabbing style.
- * Emacs will notice this stuff at the end of the file and automatically
- * adjust the settings for this buffer only.  This must remain at the end
- * of the file.
- * ---------------------------------------------------------------------------
- * Local variables:
- * c-file-style: "linux"
- * End:
- */
diff -puN arch/um/kernel/syscall_kern.c~uml-do_fork-param-cleanup arch/um/kernel/syscall_kern.c
--- linux-2.6.git/arch/um/kernel/syscall_kern.c~uml-do_fork-param-cleanup	2005-06-02 05:06:42.000000000 +0200
+++ linux-2.6.git-paolo/arch/um/kernel/syscall_kern.c	2005-06-02 05:06:42.000000000 +0200
@@ -31,7 +31,8 @@ long sys_fork(void)
 	long ret;
 
 	current->thread.forking = 1;
-        ret = do_fork(SIGCHLD, 0, NULL, 0, NULL, NULL);
+	ret = do_fork(SIGCHLD, UPT_SP(&current->thread.regs.regs),
+			&current->thread.regs, 0, NULL, NULL);
 	current->thread.forking = 0;
 	return(ret);
 }
@@ -41,8 +42,9 @@ long sys_vfork(void)
 	long ret;
 
 	current->thread.forking = 1;
-	ret = do_fork(CLONE_VFORK | CLONE_VM | SIGCHLD, 0, NULL, 0, NULL,
-		      NULL);
+	ret = do_fork(CLONE_VFORK | CLONE_VM | SIGCHLD,
+			UPT_SP(&current->thread.regs.regs), &current->thread.regs, 0,
+			NULL, NULL);
 	current->thread.forking = 0;
 	return(ret);
 }
@@ -162,14 +164,3 @@ int next_syscall_index(int limit)
 	spin_unlock(&syscall_lock);
 	return(ret);
 }
-
-/*
- * Overrides for Emacs so that we follow Linus's tabbing style.
- * Emacs will notice this stuff at the end of the file and automatically
- * adjust the settings for this buffer only.  This must remain at the end
- * of the file.
- * ---------------------------------------------------------------------------
- * Local variables:
- * c-file-style: "linux"
- * End:
- */
diff -puN arch/um/kernel/process_kern.c~uml-do_fork-param-cleanup arch/um/kernel/process_kern.c
--- linux-2.6.git/arch/um/kernel/process_kern.c~uml-do_fork-param-cleanup	2005-06-02 05:06:42.000000000 +0200
+++ linux-2.6.git-paolo/arch/um/kernel/process_kern.c	2005-06-02 05:06:42.000000000 +0200
@@ -95,8 +95,9 @@ int kernel_thread(int (*fn)(void *), voi
 
 	current->thread.request.u.thread.proc = fn;
 	current->thread.request.u.thread.arg = arg;
-	pid = do_fork(CLONE_VM | CLONE_UNTRACED | flags, 0, NULL, 0, NULL,
-		      NULL);
+	pid = do_fork(CLONE_VM | CLONE_UNTRACED | flags,
+			0, &current->thread.regs, 0,
+			NULL, NULL);
 	if(pid < 0)
 		panic("do_fork failed in kernel_thread, errno = %d", pid);
 	return(pid);
diff -puN arch/um/sys-x86_64/syscalls.c~uml-do_fork-param-cleanup arch/um/sys-x86_64/syscalls.c
--- linux-2.6.git/arch/um/sys-x86_64/syscalls.c~uml-do_fork-param-cleanup	2005-06-02 05:06:42.000000000 +0200
+++ linux-2.6.git-paolo/arch/um/sys-x86_64/syscalls.c	2005-06-02 05:06:42.000000000 +0200
@@ -174,26 +174,10 @@ long sys_clone(unsigned long clone_flags
 {
 	long ret;
 
-	/* XXX: normal arch do here this pass, and also pass the regs to
-	 * do_fork, instead of NULL. Currently the arch-independent code
-	 * ignores these values, while the UML code (actually it's
-	 * copy_thread) does the right thing. But this should change,
-	 probably. */
-	/*if (!newsp)
-		newsp = UPT_SP(current->thread.regs);*/
+	if (!newsp)
+		newsp = UPT_SP(&current->thread.regs.regs);
 	current->thread.forking = 1;
-	ret = do_fork(clone_flags, newsp, NULL, 0, parent_tid, child_tid);
+	ret = do_fork(clone_flags, newsp, &current->thread.regs, 0, parent_tid, child_tid);
 	current->thread.forking = 0;
 	return(ret);
 }
-
-/*
- * Overrides for Emacs so that we follow Linus's tabbing style.
- * Emacs will notice this stuff at the end of the file and automatically
- * adjust the settings for this buffer only.  This must remain at the end
- * of the file.
- * ---------------------------------------------------------------------------
- * Local variables:
- * c-file-style: "linux"
- * End:
- */
_

Re: [uml-devel] Recent patches of note

[Bodo Stroesser]

Blaisorblade wrote:
> arch_switch already exists (wasn't used for SKAS). About improving it and 
> making it more "general-purpose" (I've written this for the TLS code needs), 
> could you have a look to the attached patches? do_fork-* is another thing (a 
> cleanup discussed some time ago with Jeff) but may be needed to apply the 
> second.
Wouldn't it be better to have separate arch_switch_tt and arch_switch_skas?
I think, arch_switch has to do different things for tt and skas (and maybe even
for skas0 and skas3)

	Bodo


-------------------------------------------------------
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] Recent patches of note

[Blaisorblade]

On Thursday 16 June 2005 20:31, Bodo Stroesser wrote:
> Blaisorblade wrote:
> > arch_switch already exists (wasn't used for SKAS). About improving it and
> > making it more "general-purpose" (I've written this for the TLS code
> > needs), could you have a look to the attached patches? do_fork-* is
> > another thing (a cleanup discussed some time ago with Jeff) but may be
> > needed to apply the second.
>
> Wouldn't it be better to have separate arch_switch_tt and arch_switch_skas?
> I think, arch_switch has to do different things for tt and skas (and maybe
> even for skas0 and skas3)
Let's not go creating too many layers. switch_to_* calls arch_switch, then it 
can use CHOOSE_MODE if it needs (see the TLS patch I'm working on, it's in 
the -devel tarball here:

http://www.user-mode-linux.org/~blaisorblade/patches/devel-guest/

(pick the latest)
).
-- 
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] Recent patches of note

[Bodo Stroesser]

Blaisorblade wrote:
> On Thursday 16 June 2005 20:31, Bodo Stroesser wrote:
> 
>>Blaisorblade wrote:
>>
>>>arch_switch already exists (wasn't used for SKAS). About improving it and
>>>making it more "general-purpose" (I've written this for the TLS code
>>>needs), could you have a look to the attached patches? do_fork-* is
>>>another thing (a cleanup discussed some time ago with Jeff) but may be
>>>needed to apply the second.
>>
>>Wouldn't it be better to have separate arch_switch_tt and arch_switch_skas?
>>I think, arch_switch has to do different things for tt and skas (and maybe
>>even for skas0 and skas3)
> 
> Let's not go creating too many layers. switch_to_* calls arch_switch, then it 
> can use CHOOSE_MODE if it needs (see the TLS patch I'm working on, it's in 
> the -devel tarball here:
Then swtich_to_tt should call arch_switch_tt and switch_to_skas should call
arch_switch_skas. This avoids a CHOOSE_MODE and a function call.
And also it makes tt a bit more removable, if Jeff decides to.

	Bodo
> 
> http://www.user-mode-linux.org/~blaisorblade/patches/devel-guest/
> 
> (pick the latest)
> ).


-------------------------------------------------------
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] Recent patches of note

[Blaisorblade]

On Thursday 16 June 2005 20:40, Bodo Stroesser wrote:
> Blaisorblade wrote:
> > On Thursday 16 June 2005 20:31, Bodo Stroesser wrote:
> >>Blaisorblade wrote:
> >>>arch_switch already exists (wasn't used for SKAS). About improving it
> >>> and making it more "general-purpose" (I've written this for the TLS
> >>> code needs), could you have a look to the attached patches? do_fork-*
> >>> is another thing (a cleanup discussed some time ago with Jeff) but may
> >>> be needed to apply the second.
> >>
> >>Wouldn't it be better to have separate arch_switch_tt and
> >> arch_switch_skas? I think, arch_switch has to do different things for tt
> >> and skas (and maybe even for skas0 and skas3)
> >
> > Let's not go creating too many layers. switch_to_* calls arch_switch,
> > then it can use CHOOSE_MODE if it needs (see the TLS patch I'm working
> > on, it's in the -devel tarball here:
>
> Then swtich_to_tt should call arch_switch_tt and switch_to_skas should call
> arch_switch_skas. This avoids a CHOOSE_MODE and a function call.
Hmm, yes, I thought too but for common code you have anyway a call... but it 
can be inlined, so it may make sense.

> And also it makes tt a bit more removable, if Jeff decides to.
Well, on this point I'd be cautious.

Currently there is no way to even test UML in SMP mode other than using TT 
mode, so at least this must be solved.

-- 
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] Recent patches of note

[Jeff Dike]

On Thu, Jun 16, 2005 at 08:51:20PM +0200, Blaisorblade wrote:
> > And also it makes tt a bit more removable, if Jeff decides to.
> Well, on this point I'd be cautious.
> 
> Currently there is no way to even test UML in SMP mode other than using TT 
> mode, so at least this must be solved.

Yeah, we need to provide SMP on skas.  That, and the performance of page fault
handling were the only two things stopping me from removing tt mode in favor
of skas0.

Bodo and have talked about this, and it seems that skas0 SMP is impractical
because a malicious threaded app could interfere with the stub operation.

However, skas3 SMP is quite doable, and I think an unsafe skas0 SMP mode
that you can enable with a switch might be OK, too.

I've since decided that page fault performance is not a show-stopper.  It
appears that tt mode is not supportable in recent libcs due to the errno
problem. 

We can get page fault performance back by pushing PTRACE_FAULTINFO into 
mainline, which should have been done a long time ago.  Same for sysemu, 
BTW.

At this point, I'm -><- this close to deciding to get rid of tt mode in
2.6.13 or 2.6.14.  I want skas0 in mainline early in 2.6.13 so it can
be exercised.  Getting skas SMP fixed, and PTRACE_FAULTINFO in mainline
would make me happy about trashing tt mode at some later point.

				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] Recent patches of note

[Bodo Stroesser]

Jeff Dike wrote:
> On Thu, Jun 16, 2005 at 08:51:20PM +0200, Blaisorblade wrote:
> 
>>>And also it makes tt a bit more removable, if Jeff decides to.
>>
>>Well, on this point I'd be cautious.
>>
>>Currently there is no way to even test UML in SMP mode other than using TT 
>>mode, so at least this must be solved.
> 
> 
> Yeah, we need to provide SMP on skas.  That, and the performance of page fault
> handling were the only two things stopping me from removing tt mode in favor
> of skas0.
> 
> Bodo and have talked about this, and it seems that skas0 SMP is impractical
> because a malicious threaded app could interfere with the stub operation.
> 
> However, skas3 SMP is quite doable, and I think an unsafe skas0 SMP mode
> that you can enable with a switch might be OK, too.
> 
> I've since decided that page fault performance is not a show-stopper.  It
> appears that tt mode is not supportable in recent libcs due to the errno
> problem. 
> 
> We can get page fault performance back by pushing PTRACE_FAULTINFO into 
> mainline, which should have been done a long time ago.  Same for sysemu, 
> BTW.
> 
> At this point, I'm -><- this close to deciding to get rid of tt mode in
> 2.6.13 or 2.6.14.  I want skas0 in mainline early in 2.6.13 so it can
> be exercised.  Getting skas SMP fixed, and PTRACE_FAULTINFO in mainline
> would make me happy about trashing tt mode at some later point.
> 
> 				Jeff
To make skas3 consistent, we should have a mainline version of add-stub-vmas.
Also, the LDT-changes should go in at the same time.

	Bodo


-------------------------------------------------------
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] Recent patches of note

[Blaisorblade]

On Friday 17 June 2005 00:23, Jeff Dike wrote:
> On Thu, Jun 16, 2005 at 08:51:20PM +0200, Blaisorblade wrote:
> > > And also it makes tt a bit more removable, if Jeff decides to.

> > Well, on this point I'd be cautious.

> > Currently there is no way to even test UML in SMP mode other than using
> > TT mode, so at least this must be solved.

> Yeah, we need to provide SMP on skas.  That, and the performance of page
> fault handling were the only two things stopping me from removing tt mode
> in favor of skas0.
Well, the stub SIGSTOPs itself when it has finished. This is a big-latency 
operation, so using futexes (or POSIX semaphores, which don't seem to be 
implemented in terms of futexes) will increase a lot the stub's speed.
> Bodo and have talked about this, and it seems that skas0 SMP is impractical
> because a malicious threaded app could interfere with the stub operation.

> However, skas3 SMP is quite doable, and I think an unsafe skas0 SMP mode
> that you can enable with a switch might be OK, too.
Yes, we must simply write some for's (I already have in my patches the fixes 
for the #warning you added), fix some semaphores (it appears that I finished 
it, and turning the winch_handler_sem into a spinlock fixed all remaining 
deadlocks with console), and finally implement IPIs, right?

It will be harder to write a SMP-safe version of copy_*_user_skas but that 
exists inside the 4G-4G patch. And at that point, we'll enable PREEMPTION.

Btw, ever tried putting preemption in, just a compile shoot? Well, I'll work 
on all this stuff starting on July (supposing I succeed).

> I've since decided that page fault performance is not a show-stopper.  It
> appears that tt mode is not supportable in recent libcs due to the errno
> problem.

No, it doesn't, I must just trick a bit with the patch to fix that, simply it 
wasn't urgent and I'm busy for other stuff (aka exams).

> We can get page fault performance back by pushing PTRACE_FAULTINFO into
> mainline, which should have been done a long time ago.  Same for sysemu,
> BTW.
Yes, but since FAULTINFO will be recoded in terms of SIGINFO, we must do a bit 
of coding, trivial but a bit lenghty (fixing all SIGSEGVs senders in host 
kernel).

Plus, sysemu is probably causing the debugger problems (a TRAP at every 
instructions) we are getting - I can't think of anything else, at least.

> At this point, I'm -><- this close to deciding to get rid of tt mode in
> 2.6.13 or 2.6.14.  I want skas0 in mainline early in 2.6.13 so it can
> be exercised.
Say 2.6.13-git1. But you must prepare a patch which does not change *at all* 
SKAS3, not in terms of code but in terms of "strace output" (not "well, we 
change this but it won't affect things").

Btw, where did you lost SA_NODEFER for SIGSEGV handling?
> Getting skas SMP fixed, and PTRACE_FAULTINFO in mainline 
> would make me happy about trashing tt mode at some later point.

Deprecating TT mode is Ok, but removing it will cause SMP to stop *compiling* 
at all after a few days of patches, and we would get more work when 
introducing SMP.

So, fir
-- 
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] Recent patches of note

[Jeff Dike]

On Thu, Jun 16, 2005 at 08:09:34PM +0200, Blaisorblade wrote:
> +struct task_struct;
> +extern void arch_switch(struct task_struct *from, struct task_struct *to);

Is the task_struct; needed, considering that there is get_task returning
one a few lines higher?

> +	/* XXX: This is bogus, it's already done in local_irq_enable. Or does
> +	 * ordering matters? */

No, my signal handler initialization is confused and redundant in places.
Just fix that and resend.

> Fix the do_fork calling convention: normal arch pass the regs and the new sp
> value to do_fork instead of NULL.
> 
> Currently the arch-independent code ignores these values, while the UML code   
> (actually it's copy_thread) gets the right values by itself.
> 
> With this patch, things are fixed up.
>     
> Low-priority.

But long-overdue.  This one is applied.



-------------------------------------------------------
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] Recent patches of note

[Blaisorblade]

On Friday 17 June 2005 02:35, Jeff Dike wrote:
> On Thu, Jun 16, 2005 at 08:09:34PM +0200, Blaisorblade wrote:
> > +struct task_struct;
> > +extern void arch_switch(struct task_struct *from, struct task_struct
> > *to);

> Is the task_struct; needed, considering that there is get_task returning
> one a few lines higher?
I've not checked the rest of the header; if it compiles without the line it's 
ok.
> > +	/* XXX: This is bogus, it's already done in local_irq_enable. Or does
> > +	 * ordering matters? */
>
> No, my signal handler initialization is confused and redundant in places.
> Just fix that and resend.
>
> > Fix the do_fork calling convention: normal arch pass the regs and the new
> > sp value to do_fork instead of NULL.
> >
> > Currently the arch-independent code ignores these values, while the UML
> > code (actually it's copy_thread) gets the right values by itself.
> >
> > With this patch, things are fixed up.
> >
> > Low-priority.
>
> But long-overdue.  This one is applied.
Please retest in all configurations, the first version did an innocent change 
to kernel_thread() which killed TT mode. And I did a change to switch_to(), 
replacing prev_sched with current->thread.prev_sched (or something like that) 
after the last testing (if I understood things properly, it won't change 
anything, but give it a bit of testing; it should fail loudly if I did 
something wrong).
-- 
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