[uml-devel] Re: [patch 1/1] x86_64: make string func definition work as intended
> I agree this can be a bit kludgy, so if you want add another solution. Patch is ok for me, but you have a good chance of having broken other archs too due to the string.c changes. Probably needs some testing. -Andi --- This SF.Net email is sponsored by: NEC IT Guy Games. Get your fingers limbered up and give it your best shot. 4 great events, 4 opportunities to win big! Highest score wins.NEC IT Guy Games. Play to win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20 ___ 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: [patch 1/1] Uml: kludgy compilation fixes for x86-64 subarch modules support [for -mm]
On Sun, May 01, 2005 at 08:45:15PM +0200, [EMAIL PROTECTED] wrote: > > From: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]> > Cc: Andi Kleen <[EMAIL PROTECTED]> > > These are some trivial fixes for the x86-64 subarch module support. The only > potential problem is that I have to modify arch/x86_64/kernel/module.c, to > avoid copying the whole of it. > > I can't use it verbatim because it depends on a special vmalloc-like area for > modules, which for now (maybe that's to fix, I guess not) UML/x86-64 has not. > I went the easy way and reused the i386 vmalloc()-based allocator. Patch is ok for me. Another way would have been to use __attribute__((weak)), but I guess the ifdef is ok too. -Andi --- This SF.Net email is sponsored by: NEC IT Guy Games. Get your fingers limbered up and give it your best shot. 4 great events, 4 opportunities to win big! Highest score wins.NEC IT Guy Games. Play to win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20 ___ 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: [UML] Compile error when building with seperate source and object directories
On Sunday 01 May 2005 18:07, Al Viro wrote: > On Sun, May 01, 2005 at 01:30:57PM +0200, Blaisorblade wrote: > > For now I've added an #ifdef to re-include that code for x86, while > > excluding it for x86_64. Also, is that up-to-date wrt. 2.6.12-rc3? > > Yes, it is. As for the ptrace.c... IMO the right thing is > per-architecture helper here. Such ifdefs are OK when it's just i386 and > amd64. As soon as e.g. uml/s390 gets merged or uml/ia64 and uml/ppc get > resurrected... Agreed, I've done it this way to reintroduce for now the code for i386. It's anyway kludgy, since amd64 has too its debug registers to handle (at least it should); it's just that UML does not handle them yet. -- Paolo Giarrusso, aka Blaisorblade Skype user "PaoloGiarrusso" Linux registered user n. 292729 http://www.user-mode-linux.org/~blaisorblade --- This SF.Net email is sponsored by: NEC IT Guy Games. Get your fingers limbered up and give it your best shot. 4 great events, 4 opportunities to win big! Highest score wins.NEC IT Guy Games. Play to win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20 ___ 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] [patch 1/1] uml: remove jail mode + other leftovers
This var is currently useless, as it's apparent from reading the code. Until
2.6.11 it was used in some code related to jail mode, in the same proc.:
if(jail){
while(!reading) sched_yield();
}
jail mode has been dropped, together with that use, so let's finish dropping
this.
Also, remove some other useless definitions I met.
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
---
linux-2.6.12-paolo/arch/um/kernel/tt/process_kern.c |6 --
linux-2.6.12-paolo/arch/um/kernel/um_arch.c |6 --
linux-2.6.12-paolo/include/asm-um/pgtable.h |8
3 files changed, 20 deletions(-)
diff -puN arch/um/kernel/tt/process_kern.c~uml-remove-jail-rem
arch/um/kernel/tt/process_kern.c
--- linux-2.6.12/arch/um/kernel/tt/process_kern.c~uml-remove-jail-rem
2005-05-01 18:34:35.0 +0200
+++ linux-2.6.12-paolo/arch/um/kernel/tt/process_kern.c 2005-05-01
18:34:35.0 +0200
@@ -32,10 +32,6 @@ void *switch_to_tt(void *prev, void *nex
unsigned long flags;
int err, vtalrm, alrm, prof, cpu;
char c;
- /* jailing and SMP are incompatible, so this doesn't need to be
-* made per-cpu
-*/
- static int reading;
from = prev;
to = next;
@@ -59,12 +55,10 @@ void *switch_to_tt(void *prev, void *nex
c = 0;
set_current(to);
- reading = 0;
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);
- reading = 1;
if((from->exit_state == EXIT_ZOMBIE) ||
(from->exit_state == EXIT_DEAD))
os_kill_process(os_getpid(), 0);
diff -puN arch/um/kernel/um_arch.c~uml-remove-jail-rem arch/um/kernel/um_arch.c
--- linux-2.6.12/arch/um/kernel/um_arch.c~uml-remove-jail-rem 2005-05-01
18:34:54.0 +0200
+++ linux-2.6.12-paolo/arch/um/kernel/um_arch.c 2005-05-01 18:36:42.0
+0200
@@ -110,12 +110,6 @@ struct seq_operations cpuinfo_op = {
.show = show_cpuinfo,
};
-pte_t * __bad_pagetable(void)
-{
- panic("Someone should implement __bad_pagetable");
- return(NULL);
-}
-
/* Set in linux_main */
unsigned long host_task_size;
unsigned long task_size;
diff -puN include/asm-um/pgtable.h~uml-remove-jail-rem include/asm-um/pgtable.h
--- linux-2.6.12/include/asm-um/pgtable.h~uml-remove-jail-rem 2005-05-01
18:35:18.0 +0200
+++ linux-2.6.12-paolo/include/asm-um/pgtable.h 2005-05-01 18:36:33.0
+0200
@@ -114,17 +114,9 @@ extern unsigned long end_iomem;
extern unsigned long pg0[1024];
/*
- * BAD_PAGETABLE is used when we need a bogus page-table, while
- * BAD_PAGE is used for a bogus page.
- *
* ZERO_PAGE is a global shared page that is always zero: used
* for zero-mapped memory areas etc..
*/
-extern pte_t __bad_page(void);
-extern pte_t * __bad_pagetable(void);
-
-#define BAD_PAGETABLE __bad_pagetable()
-#define BAD_PAGE __bad_page()
#define ZERO_PAGE(vaddr) virt_to_page(empty_zero_page)
_
---
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
___
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] The source to that firmware-uml thing is now up...
On Monday 02 May 2005 07:14, Rob Landley wrote: > On Sunday 01 May 2005 07:06 am, Blaisorblade wrote: > > > (That said, if you do use -p to get get a setuid bash, there's several > > > other things you should do to make this marginally less dangerous. And > > > I wouldn't trust myself to remember them all off the top of my head...) > > No, I'm not saying that a setuid bash won't work because of the bash > > special code. > > I'm saying that setuid script plain don't work (the kernel ignores the > > setuid bit). Except for perl, which has a special mechanism to make them > > work anyway. > I got this to work once, a few years back (under an early 2.4 kernel). The > setuid bit wasn't on the bash executable (that would be insane), it was on > the script. > I don't remember the details (it was a few years ago now) but at one point > it was possible. I vaguely remember tracing through both bash and the > kernel code to see what the heck it was actually doing, and I think there > was something funky and non-obvious about permissions, or some such... > And if the perl executable isn't itself suid, then what special mechanism > can the perl executable have to execute stuff as root if the kernel isn't > passing it root access when you run the script? This "special mechanism" > would either have to be the suid bit on the perl executable (which my > /usr/bin/perl hasn't got) or some mechanism for cracking root access as a > normal user, doesn't it? This mechanism involves having the setuid bit set on /usr/bin/suidperl. Though it's documented in man perl, here's the basics: *) the kernel can't allow a setuid script to work. There's an inherent race condition: fork(), execve() the script, the kernel runs the shell with id = 0, you modify the file to be nasty and it loses its setuid bit, but still the shell is going to open and execute it. *) perl checks if the script is setuid, and if suidperl is installed, it avoids the problem (probably by copying the source somewhere where it can't be modified, or something smarter, I don't know). > No, if I remember correctly bash was the problem, in the same holier than > thou "we are the FSF, we know better than you because you are dumb and we > must protect you from yourself" way that gcc's collect2 won't search the > path for ld if the $PATH has "." in it (even at the end), > which is the > default path in UML by the way. Sorry, what you mean here? It's the default PATH in your guest image or there is actually something in UML leading to that (which would be a bug?). > (That took a while to track down...) Ah, I remember your very early message "gcc does not find LD, I can find it by hand and it's in the PATH". > I got that to work once too. I vaguely recall I had to specify -E Ignore env. vars such as PYTHONPATH... makes sense to avoid exploits. > , and > possibly some other stuff... -- Paolo Giarrusso, aka Blaisorblade Skype user "PaoloGiarrusso" Linux registered user n. 292729 http://www.user-mode-linux.org/~blaisorblade --- This SF.Net email is sponsored by: NEC IT Guy Games. Get your fingers limbered up and give it your best shot. 4 great events, 4 opportunities to win big! Highest score wins.NEC IT Guy Games. Play to win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20 ___ 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: [patch 1/1] uml: remove jail mode + other leftovers
On Sun, May 01, 2005 at 06:38:15PM +0200, [EMAIL PROTECTED] wrote:
>
> This var is currently useless, as it's apparent from reading the code. Until
> 2.6.11 it was used in some code related to jail mode, in the same proc.:
>
> if(jail){
> while(!reading) sched_yield();
> }
>
> jail mode has been dropped, together with that use, so let's finish dropping
> this.
>
> Also, remove some other useless definitions I met.
>
> Signed-off-by: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
Acked-by: Jeff Dike <[EMAIL PROTECTED]>
---
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
___
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] Kernel panic with 2.6.11.6
Okay, I was in the process of attempting to recreate this when I encountered the following. Is this your "stack trace"? It occured on a slightly newer version of both the host kernel and guest kernel. This guest is 2.6.11.7 with the bs4 patches applied. The host is 2.6.11.7-skas3-v8. Of course, I'm now baffled by why THIS instance would dump a stack trace while the other instance doesn't. *sigh* This crashed occurred immediately after boot. I had entered login credentials and was typing a "cat /proc/cmdline" command when it crashed (I never made it to the key). I can supply a kernel config file or other information if requested. Also, I've removed the /lib/tls directory. Tony Kernel panic - not syncing: Kernel mode fault at addr 0xcfcfcfd7, ip 0x0 EIP: :[<>] CPU: 0 Not tainted EFLAGS: Not tainted EAX: EBX: ECX: EDX: ESI: EDI: EBP: DS: ES: Call Trace: 08297338: [<0808c30d>] notifier_call_chain+0x2d/0x50 08297348: [<0818fe16>] bust_spinlocks+0x46/0x50 08297358: [<0807d131>] panic+0x71/0x120 08297378: [<08066997>] segv+0x217/0x250 08297390: [<0806505d>] set_signals+0x7d/0x130 082973d8: [<08064eb5>] change_signals+0x65/0x90 08297468: [<08066cb7>] segv_handler+0xd7/0xe0 08297488: [<080697f0>] sig_handler_common_skas+0x90/0xe0 082974b8: [<08075e87>] sig_handler+0x17/0x20 08297508: [<0806b21f>] chan_interrupt+0xf/0x130 08297530: [<08064f70>] enable_mask+0x50/0x70 08297550: [<08064fc3>] get_signals+0x33/0x50 082975a0: [<081c3bf4>] kfree_skbmem+0x24/0x30 082975b0: [<081c3c95>] __kfree_skb+0x95/0x150 082975d0: [<0806d14c>] uml_net_start_xmit+0x6c/0x110 082975f0: [<08082a98>] local_bh_enable+0x8/0x90 08297610: [<081c9c25>] dev_queue_xmit+0x145/0x220 08297630: [<081cf7f8>] neigh_resolve_output+0xe8/0x1c0 08297670: [<0c85cb46>] ip6_output2+0x176/0x280 [ipv6] 08297680: [<0c86caae>] ndisc_fill_addr_option+0x1e/0xc0 [ipv6] 08297690: [<0c85d28a>] ip6_nd_hdr+0xaa/0x100 [ipv6] 082976b0: [<0c86dec8>] ndisc_send_rs+0x2a8/0x4d0 [ipv6] 082976e0: [<08064eb5>] change_signals+0x65/0x90 08297750: [<08064e2a>] change_sig+0x6a/0x90 082977d0: [<0806b85f>] line_interrupt+0x2f/0x40 082977f0: [<08099900>] handle_IRQ_event+0x30/0x80 08297820: [<080999f8>] __do_IRQ+0xa8/0xf0 08297840: [<0805fea3>] do_IRQ+0x33/0x50 08297850: [<0806004a>] sigio_handler+0xda/0x140 08297870: [<080697f0>] sig_handler_common_skas+0x90/0xe0 08297894: [<080690e0>] start_kernel_proc+0x0/0x40 0829789c: [<08068cc0>] new_thread_handler+0x0/0x120 082978a0: [<08075e87>] sig_handler+0x17/0x20 082978cc: [<080690e0>] start_kernel_proc+0x0/0x40 082978d0: [<08068cc0>] new_thread_handler+0x0/0x120 08297a40: [<08068937>] switch_threads+0x87/0x90 08297a70: [<08064eb5>] change_signals+0x65/0x90 08297b10: [<08064f0f>] unblock_signals+0xf/0x20 08297b20: [<080799e7>] finish_task_switch+0x27/0x70 08297b40: [<08244353>] schedule+0x2e3/0x4e0 08297b90: [<08065e93>] idle_sleep+0x23/0x30 08297bac: [<08068cc0>] new_thread_handler+0x0/0x120 08297bb0: [<08062f37>] default_idle+0x67/0x70 08297bd0: [<080690d8>] init_idle_skas+0x28/0x30 08297bd4: [<0805f210>] init+0x0/0x110 08297be0: [<080495b3>] start_kernel+0x163/0x1a0 08297bf4: [<08049130>] unknown_bootoption+0x0/0x200 08297c00: [<0806910b>] start_kernel_proc+0x2b/0x40 08297c04: [<080690e0>] start_kernel_proc+0x0/0x40 08297c10: [<08062978>] run_kernel_thread+0x78/0x80 08297c28: [<080690e0>] start_kernel_proc+0x0/0x40 08297c30: [<08068cc0>] new_thread_handler+0x0/0x120 08297c38: [<08062940>] run_kernel_thread+0x40/0x80 08297cd4: [<080690e0>] start_kernel_proc+0x0/0x40 08297cdc: [<08068cc0>] new_thread_handler+0x0/0x120 08297ce0: [<08068d8e>] new_thread_handler+0xce/0x120 08297ce4: [<080690e0>] start_kernel_proc+0x0/0x40 08297d40: [<08068cc0>] new_thread_handler+0x0/0x120 Quoting Jeff Dike <[EMAIL PROTECTED]>: > On Wed, Apr 27, 2005 at 01:33:24PM -0700, Anthony Brock wrote: >> Kernel panic - not syncing: Kernel mode fault at addr 0x19, ip 0x402eb2d2 >> >> This only happens when I reconnect to the guest console by attaching to the >> associated "screen" session. Also, it is erradic at best and happens >> about once >> out of every 15-20 times I reconnect to the screen. Fortunately, the >> apparent >> trigger (connecting to the console) ensures that I'm aware of the crash and >> able to immediately restart the instance. >> >> Any ideas on how to troubleshoot this? Is it a known issue that I've somehow >> missed on the list? Thanks! > > My usual request - can you get a stack trace from it? > > Jeff > --- This SF.Net email is sponsored by: NEC IT Guy Games. Get your fingers limbered up and give it your best shot. 4 great events, 4 opportunities to win big! Highest score wins.NEC IT Guy Games. Play to win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20 _
[uml-devel] Re: [patch 1/1] Uml: kludgy compilation fixes for x86-64 subarch modules support [for -mm]
[EMAIL PROTECTED] wrote: > > These are some trivial fixes for the x86-64 subarch module support. The only > potential problem is that I have to modify arch/x86_64/kernel/module.c, to > avoid copying the whole of it. > > I can't use it verbatim because it depends on a special vmalloc-like area for > modules, which for now (maybe that's to fix, I guess not) UML/x86-64 has not. > I went the easy way and reused the i386 vmalloc()-based allocator. Why is this "for -mm" and not for -linus? --- This SF.Net email is sponsored by: NEC IT Guy Games. Get your fingers limbered up and give it your best shot. 4 great events, 4 opportunities to win big! Highest score wins.NEC IT Guy Games. Play to win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20 ___ 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] Kernel panic with 2.6.11.6
[EMAIL PROTECTED] said: > Is this your "stack trace"? Close. What I'd really like is to get it to crash when it's running under gdb, with a breakpoint on panic. Then, 'bt' to gdb at that point. That gives the true call trace, plus line number information. > 08297488: [<080697f0>] sig_handler_common_skas+0x90/0xe0 > 082974b8: [<08075e87>] sig_handler+0x17/0x20 > 08297508: [<0806b21f>] chan_interrupt+0xf/0x130 > 08297530: [<08064f70>] enable_mask+0x50/0x70 This tells me that chan_interrupt segfaulted, but not necessarily exactly where, and a lot of the other stuff on the stack isn't in the true call chain. Jeff --- This SF.Net email is sponsored by: NEC IT Guy Games. Get your fingers limbered up and give it your best shot. 4 great events, 4 opportunities to win big! Highest score wins.NEC IT Guy Games. Play to win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20 ___ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
