Re: chroot in its own ext2fs?
Hi :) Quoting Samuel Thibault (2014-05-02 02:22:01) > Does anybody remember precisely why chroots should have their own > ext2fs? I can build packages fine from inside a chroot which doesn't > have its own ext2fs, for instance. I thought only subhurds need their own translator? Justus
Re: chroot in its own ext2fs?
Justus Winter, le Fri 02 May 2014 09:15:44 +0200, a écrit : > Quoting Samuel Thibault (2014-05-02 02:22:01) > > Does anybody remember precisely why chroots should have their own > > ext2fs? I can build packages fine from inside a chroot which doesn't > > have its own ext2fs, for instance. > > I thought only subhurds need their own translator? That does make sense, yes, but I see it mentioned on the wiki in ./hurd/running/chroot.mdwn Samuel
Re: GCC's -fsplit-stack disturbing Mach's vm_allocate
On Fri, 2014-05-02 at 00:45 +0200, Samuel Thibault wrote: > Hello, > > Svante Signell, le Thu 24 Apr 2014 10:39:10 +0200, a écrit : > > - Without split stack enabled around 70 libgo tests pass and 50 fails, > > most of them with a segfault. > > - Enabling split stack and using the libc Samuel built all 122 libgo > > tests fail with a segfault. > > Please provide segfault backtrace, rpctrace, etc. Otherwise we won't be > able to help you. You already have one in this thread, analysed by Justus: http://gcc.gnu.org/ml/gcc-patches/2014-04/msg01736.html The full rpctrace and gdb backtrace for that case was published on paste.debian.net, but are gone now. I can upload again if you need them, or do you want it attached to a mail?
Re: chroot in its own ext2fs?
Hi, On Fri, May 02, 2014 at 02:22:01AM +0200, Samuel Thibault wrote: > Does anybody remember precisely why chroots should have their own > ext2fs? I can build packages fine from inside a chroot which doesn't > have its own ext2fs, for instance. I don't recall why we did that, maybe it was purely for operational reasons (offline filesystem checking of just the chroot when still had lots of corruption) and is no longer applicable today. Michael
Re: GCC's -fsplit-stack disturbing Mach's vm_allocate
Svante Signell, le Fri 02 May 2014 10:18:12 +0200, a écrit : > Thread 4 (Thread 1205.4): > #0 0x019977b7 in _hurd_intr_rpc_msg_in_trap () at intr-msg.c:132 > err = > err = > user_option = 3 > user_timeout = 48 > m = 0x532370 > msgh_bits = 0 > remote_port = 268509186 > msgid = 21118 > save_data = > __PRETTY_FUNCTION__ = "_hurd_intr_rpc_mach_msg" Ok, reading this again, this looks like what Justus analyzed. Samuel
Re: GCC's -fsplit-stack disturbing Mach's vm_allocate
Svante Signell, le Fri 02 May 2014 10:03:23 +0200, a écrit : > On Fri, 2014-05-02 at 00:45 +0200, Samuel Thibault wrote: > > Hello, > > > > Svante Signell, le Thu 24 Apr 2014 10:39:10 +0200, a écrit : > > > - Without split stack enabled around 70 libgo tests pass and 50 fails, > > > most of them with a segfault. > > > - Enabling split stack and using the libc Samuel built all 122 libgo > > > tests fail with a segfault. > > > > Please provide segfault backtrace, rpctrace, etc. Otherwise we won't be > > able to help you. > > You already have one in this thread, analysed by Justus: > http://gcc.gnu.org/ml/gcc-patches/2014-04/msg01736.html Yes, but that stack was without split stack fixed. The backtrace you have just attached seems different. Samuel
Re: GCC's -fsplit-stack disturbing Mach's vm_allocate
Samuel Thibault, le Fri 02 May 2014 11:57:53 +0200, a écrit : > So we just need to fix guardsize in our libpthread. (And I'll have a look at it). Samuel
Re: GCC's -fsplit-stack disturbing Mach's vm_allocate
Svante Signell, le Fri 02 May 2014 10:18:12 +0200, a écrit : > task130(pid1182)->vm_allocate (33562796 8364 0) = 0x3 ((os/kern) no space > available) > task130(pid1182)->vm_allocate (33571160 8364 0) = 0 33570816 While inspecting this, I realized this is from __pthread_stack_alloc, the only caller of vm_allocate with anywhere set to 0 which would have such behavior. 8364 is really small for a stack (but that's expected from -fsplit-stack), and the thing is: we have a bogus libpthread which includes guardsize into stacksize. I guess this is what happens: gcc believes there is 8K, but our libpthread actually removes 4K from it for guardsize, so the process will crash as soon as 4K are used on the stack. So we just need to fix guardsize in our libpthread. Samuel
Re: GCC's -fsplit-stack disturbing Mach's vm_allocate
Justus Winter, le Sat 26 Apr 2014 08:53:08 +0200, a écrit :
> task130(pid1182)->vm_map (0 49880 0 1133<--160(pid1182) 0 1 5 7 1) = 0
> 2453504
>
> We map that somewhere.
>
> task130(pid1182)->mach_port_deallocate (pn{ 25}) = 0
>
> Deallocate the port. Again, for some strange reason 133 == pn{ 25}.
>
> 158<--157(pid1182)->io_map_request () = 0133<--162(pid1182) (null)
>
> Some more io_map.
>
> task130(pid1182)->vm_map (2498560 8192 0 0133<--162(pid1182) 40960 1 3 7
> 1) = 0x3 ((os/kern) no space available)
> task130(pid1182)->vm_deallocate (2498560 8192) = 0
>
> Hum?
>
> task130(pid1182)->vm_map (2498560 8192 0 0133<--162(pid1182) 40960 1 3 7
> 1) = 0 2498560
> task130(pid1182)->mach_port_deallocate (pn{ 25}) = 0
>
> Success!
See the logic in elf/dl-load.c's _dl_map_object_from_fd and
sysdeps/mach/hurd/mmap.c. _dl_map_object_from_fd first gets somewhere
to map the SO (first __mmap call), and then, if bss is big, it maps
anonymous pages for it with MAP_FIXED, replacing the bss part of the SO:
2453504 + 49880 = 0x2632d8
2498560 + 8192 = 0x264000
So this seems like just normal behavior.
Samuel
Re: GCC's -fsplit-stack disturbing Mach's vm_allocate
Samuel Thibault, le Fri 02 May 2014 11:57:53 +0200, a écrit : > So we just need to fix guardsize in our libpthread. It was not so difficult actually. Svante, could you try this libpthread: http://people.debian.org/~sthibault/tmp/libpthread.so.0.3 Thanks, Samuel
Re: GCC's -fsplit-stack disturbing Mach's vm_allocate
On Fri, 2014-05-02 at 12:00 +0200, Samuel Thibault wrote: > Samuel Thibault, le Fri 02 May 2014 11:57:53 +0200, a écrit : > > So we just need to fix guardsize in our libpthread. > > (And I'll have a look at it). Maybe this can fix the around 40 segfaults (of 50 failures) when split stack is disabled too? The segfaults are always around the same place in libpthread.
Re: GCC's -fsplit-stack disturbing Mach's vm_allocate
Svante Signell, le Fri 02 May 2014 12:45:56 +0200, a écrit : > On Fri, 2014-05-02 at 12:00 +0200, Samuel Thibault wrote: > > Samuel Thibault, le Fri 02 May 2014 11:57:53 +0200, a écrit : > > > So we just need to fix guardsize in our libpthread. > > > > (And I'll have a look at it). > > Maybe this can fix the around 40 segfaults (of 50 failures) when split > stack is disabled too? The segfaults are always around the same place in > libpthread. Possibly, if libgo uses small stacks already. Samuel
[PATCH 2/3] i386: add io_map_cached
io_map_cached is like io_map, but reuses the old mapping if it is
applicable.
* i386/i386/io_map.c: Add io_map_cached.
---
i386/i386/io_map.c | 29 +
1 file changed, 29 insertions(+)
diff --git a/i386/i386/io_map.c b/i386/i386/io_map.c
index 74e0b47..03d7152 100644
--- a/i386/i386/io_map.c
+++ b/i386/i386/io_map.c
@@ -58,3 +58,32 @@ io_map(
VM_PROT_READ|VM_PROT_WRITE);
return (start);
}
+
+/*
+ * Allocate and map memory for devices that may need to be mapped before
+ * Mach VM is running.
+ *
+ * This maps the all pages containing [PHYS_ADDR:PHYS_ADDR + SIZE].
+ * For contiguous requests to those pages will reuse the previously
+ * established mapping.
+ */
+vm_offset_t
+io_map_cached(
+ vm_offset_t phys_addr,
+ vm_size_t size)
+{
+ static vm_offset_t base;
+ static vm_size_t length;
+ static vm_offset_t map;
+
+ if (! map
+ || (phys_addr < base)
+ || (base + length < phys_addr + size))
+{
+ base = trunc_page(phys_addr);
+ length = round_page(phys_addr - base + size);
+ map = io_map(base, length);
+}
+
+ return map + (phys_addr - base);
+}
--
1.9.2
[PATCH 1/3] ddb: add "halt" command
* ddb/db_command.c (db_command_table): Add "halt" command.
* i386/i386/db_interface.h (db_halt_cpu): New declaration.
* i386/i386at/model_dep.c (db_halt_cpu): New function.
---
ddb/db_command.c | 1 +
i386/i386/db_interface.h | 2 ++
i386/i386at/model_dep.c | 5 +
3 files changed, 8 insertions(+)
diff --git a/ddb/db_command.c b/ddb/db_command.c
index ebb13df..8171119 100644
--- a/ddb/db_command.c
+++ b/ddb/db_command.c
@@ -363,6 +363,7 @@ struct db_command db_command_table[] = {
{ "show", 0, 0, db_show_cmds },
{ "reset", db_reset_cpu, 0, 0 },
{ "reboot", db_reset_cpu, 0, 0 },
+ { "halt", db_halt_cpu,0, 0 },
{ (char *)0, }
};
diff --git a/i386/i386/db_interface.h b/i386/i386/db_interface.h
index 97ff5c7..8d7daea 100644
--- a/i386/i386/db_interface.h
+++ b/i386/i386/db_interface.h
@@ -98,6 +98,8 @@ db_stack_trace_cmd(
const char *modif);
extern void
+db_halt_cpu(void);
+extern void
db_reset_cpu(void);
void
diff --git a/i386/i386at/model_dep.c b/i386/i386at/model_dep.c
index 7d138be..95752fa 100644
--- a/i386/i386at/model_dep.c
+++ b/i386/i386at/model_dep.c
@@ -243,6 +243,11 @@ void exit(int rc)
halt_all_cpus(0);
}
+void db_halt_cpu(void)
+{
+ halt_all_cpus(0);
+}
+
void db_reset_cpu(void)
{
halt_all_cpus(1);
--
1.9.2
Re: [PATCH 1/3] ddb: add "halt" command
Justus Winter, le Fri 02 May 2014 21:33:00 +0200, a écrit :
> * ddb/db_command.c (db_command_table): Add "halt" command.
> * i386/i386/db_interface.h (db_halt_cpu): New declaration.
> * i386/i386at/model_dep.c (db_halt_cpu): New function.
Ack.
> ---
> ddb/db_command.c | 1 +
> i386/i386/db_interface.h | 2 ++
> i386/i386at/model_dep.c | 5 +
> 3 files changed, 8 insertions(+)
>
> diff --git a/ddb/db_command.c b/ddb/db_command.c
> index ebb13df..8171119 100644
> --- a/ddb/db_command.c
> +++ b/ddb/db_command.c
> @@ -363,6 +363,7 @@ struct db_command db_command_table[] = {
> { "show", 0, 0, db_show_cmds },
> { "reset", db_reset_cpu, 0, 0 },
> { "reboot", db_reset_cpu, 0, 0 },
> + { "halt", db_halt_cpu,0, 0 },
> { (char *)0, }
> };
>
> diff --git a/i386/i386/db_interface.h b/i386/i386/db_interface.h
> index 97ff5c7..8d7daea 100644
> --- a/i386/i386/db_interface.h
> +++ b/i386/i386/db_interface.h
> @@ -98,6 +98,8 @@ db_stack_trace_cmd(
> const char *modif);
>
> extern void
> +db_halt_cpu(void);
> +extern void
> db_reset_cpu(void);
>
> void
> diff --git a/i386/i386at/model_dep.c b/i386/i386at/model_dep.c
> index 7d138be..95752fa 100644
> --- a/i386/i386at/model_dep.c
> +++ b/i386/i386at/model_dep.c
> @@ -243,6 +243,11 @@ void exit(int rc)
> halt_all_cpus(0);
> }
>
> +void db_halt_cpu(void)
> +{
> + halt_all_cpus(0);
> +}
> +
> void db_reset_cpu(void)
> {
> halt_all_cpus(1);
> --
> 1.9.2
>
--
Samuel
#ifndef I_WISH_WORLD_WERE_PERFECT
/* It is not :-( All the routers (except for Linux) return only
...
-+- linux/net/ipv4/ipip.c -+-
forgot i386/i386at/acpihalt.h
I forgot to add i386/i386at/acpihalt.h.
