From 088ca85671518ac9033904dae6444d7d532586d4 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Fri, 22 Jul 2011 09:41:11 +0200 Subject: IRC. --- .../gnumach_vm_map_entry_forward_merging.mdwn | 11 +++++++ open_issues/libpthread_dlopen.mdwn | 36 ++++++++++++++++++++++ 2 files changed, 47 insertions(+) create mode 100644 open_issues/libpthread_dlopen.mdwn (limited to 'open_issues') diff --git a/open_issues/gnumach_vm_map_entry_forward_merging.mdwn b/open_issues/gnumach_vm_map_entry_forward_merging.mdwn index b2b20c5b..f1c8bd6e 100644 --- a/open_issues/gnumach_vm_map_entry_forward_merging.mdwn +++ b/open_issues/gnumach_vm_map_entry_forward_merging.mdwn @@ -171,6 +171,17 @@ License|/fdl]]."]]"""]] entries) +# IRC, freenode, #hurd, 2011-07-21 + + tschwinge: you may remove the forward map entry merging issue :/ + what did you discover? + tschwinge: it's actually much more complicated than i thought, and + needs major changes in the vm, and about the way anonymous memory is + handled + from what i could see, part of the problem still exists in freebsd + for the same reasons (shadow objects being one of them) + + # Procedure * Analyze. diff --git a/open_issues/libpthread_dlopen.mdwn b/open_issues/libpthread_dlopen.mdwn new file mode 100644 index 00000000..f60c81a4 --- /dev/null +++ b/open_issues/libpthread_dlopen.mdwn @@ -0,0 +1,36 @@ +[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_libpthread]] + +IRC, OFTC, #debian-hurd, 2011-07-21. + + there's one known issue with pthreads + you can't dlopen() it + which also means you can't dlopen() a module which depends on it if + the main application hasn't used -lpthread already + (so as to get libpthread initialized early, not at the dlopen() + call) + I get this while building simgrid: + cd /home/lucas/simgrid-3.6.1/obj-i486-gnu/examples/gras/console && + /usr/bin/cmake -E create_symlink + /home/lucas/simgrid-3.6.1/obj-i486-gnu/lib/libsimgrid.so + /home/lucas/simgrid-3.6.1/obj-i486-gnu/examples/gras/console/simgrid.so + cd /home/lucas/simgrid-3.6.1/obj-i486-gnu/examples/gras/console && + lua /home/lucas/simgrid-3.6.1/examples/gras/console/ping_generator.lua + lua: + /home/buildd/build/chroot-sid/home/buildd/byhand/hurd/./libpthread/sysdeps/generic/pt-mutex-timedlock.c:68: + __pthread_mutex_timedlock_internal: Assertion `__pthread_threads' failed. + Aborted (core dumped) + that's it, yes + (or at least it has the same symptoms) + it would need fixing in lua, not in SG, then, right? + yes + ok, thanks -- cgit v1.2.3 From 957cba89001d8d06e681ca493500209c5a151464 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Sat, 23 Jul 2011 08:50:54 +0200 Subject: IRC. --- open_issues/gnumach_memory_management.mdwn | 29 ++++++++++++++++ .../io_system/clustered_page_faults.mdwn | 40 ++++++++++++++++++++-- 2 files changed, 66 insertions(+), 3 deletions(-) (limited to 'open_issues') diff --git a/open_issues/gnumach_memory_management.mdwn b/open_issues/gnumach_memory_management.mdwn index f15c4d25..448aafcc 100644 --- a/open_issues/gnumach_memory_management.mdwn +++ b/open_issues/gnumach_memory_management.mdwn @@ -894,3 +894,32 @@ There is a [[!FF_project 266]][[!tag bounty]] on this task. ok it's tricky mcsim: try to find where the first use of the allocator is made + + +# IRC, freenode, #hurd, 2011-07-22 + + braunr, hello. Kernel with your allocator already compiles and + runs. There still some problems, but, certainly, I'm on the final stage + already. I hope I'll finish in a few days. + mcsim: Oh, cool! Have you done some measurements already? + Not yet + OK. + But if it able to run a GNU/Hurd system, then that already is + something, a big milestone! + nice + although you'll probably need to tweak the garbage collecting + process + tschwinge: thanks + braunr: As back-end for allocating memory I use + kmem_alloc_wired. But in zalloc was an opportunity to use as back-end + kmem_alloc_pageable. Although there was no any zone that used + kmem_alloc_pageable. Do I need to implement this functionality? + mcsim: do *not* use kmem_alloc_pageable() + braunr: Ok. This is even better) + mcsim: in x15, i've taken this even further: there is *no* kernel + vm object, which means all kernel memory is wired and unmanaged + making it fast and safe + pageable kernel memory was useful back when RAM was really scarce + 20 years ago + but it's a source of deadlock + Indeed. I'll won't use kmem_alloc_pageable. diff --git a/open_issues/performance/io_system/clustered_page_faults.mdwn b/open_issues/performance/io_system/clustered_page_faults.mdwn index 37433e06..9e20f8e1 100644 --- a/open_issues/performance/io_system/clustered_page_faults.mdwn +++ b/open_issues/performance/io_system/clustered_page_faults.mdwn @@ -12,7 +12,10 @@ License|/fdl]]."]]"""]] [[community/gsoc/project_ideas/disk_io_performance]]. -IRC, freenode, #hurd, 2011-02-16 +[[!toc]] + + +# IRC, freenode, #hurd, 2011-02-16 exceptfor the kernel, everything in an address space is represented with a VM object @@ -88,9 +91,8 @@ IRC, freenode, #hurd, 2011-02-16 recommend* ok ---- -IRC, freenode, #hurd, 2011-02-16 +# IRC, freenode, #hurd, 2011-02-16 etenil: OSF Mach does have clustered paging BTW; so that's one place to start looking... @@ -103,3 +105,35 @@ IRC, freenode, #hurd, 2011-02-16 can serve as a starting point + + +# IRC, freenode, #hurd, 2011-07-22 + + but concerning clustered pagins/outs, i'm not sure it's a mach + interface limitation + the external memory pager interface does allow multiple pages to + be transfered + isn't it an internal Mach VM problem ? + isn't it simply the page fault handler ? + braunr: are you sure? I was under the impression that changing the + pager interface was among the requirements... + hm... I wonder whether for pageins, it could actually be handled + in the pages instead of Mach... though this wouldn't work for pageouts, + so probably not very helpful + err... in the pagers + antrik: i'm almost sure + but i've be proven wrong many times, so .. + there are two main facts that lead me to think this + 1/ + http://www.gnu.org/software/hurd/gnumach-doc/Memory-Objects-and-Data.html#Memory-Objects-and-Data + says lengths are provided and doesn't mention the limitation + 2/ when reading about UVM, one of the major improvements (between + 10 and 30% of global performance depending on the benchmarks) was + implementing the madvise semantics + and this didn't involve a new pager interface, but rather a new + page fault handler + braunr: hm... the interface indeed looks like it can handle + multiple pages in both directions... perhaps it was at the Hurd level + where the pager interface needs to be modified, not the Mach one?... + antrik: would be nice wouldn't it ? :) + antrik: more probably the page fault handler -- cgit v1.2.3 From efa6b79d26900f8bc6867406962a12cf72454c3c Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Sat, 23 Jul 2011 09:25:35 +0200 Subject: open_issues/multithreading: Event-based Concurrency Control, Tom Van Cutsem, 2009. --- open_issues/multithreading.mdwn | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'open_issues') diff --git a/open_issues/multithreading.mdwn b/open_issues/multithreading.mdwn index 18fc257e..4309494d 100644 --- a/open_issues/multithreading.mdwn +++ b/open_issues/multithreading.mdwn @@ -31,6 +31,10 @@ instead they should be scaled according to the backends' characteristics. The [[hurd/Critique]] should have some more on this. +[*Event-based Concurrency +Control*](http://soft.vub.ac.be/~tvcutsem/talks/presentations/T37_nobackground.pdf), +Tom Van Cutsem, 2009. + # Alternative approaches: -- cgit v1.2.3 From c44863345d9a0ae3c1c9383b0e1243dad7b8faad Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Sat, 23 Jul 2011 22:41:25 +0200 Subject: open_issues/xattr: Add some more links. --- open_issues/xattr.mdwn | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) (limited to 'open_issues') diff --git a/open_issues/xattr.mdwn b/open_issues/xattr.mdwn index 8b08ef1e..40222f78 100644 --- a/open_issues/xattr.mdwn +++ b/open_issues/xattr.mdwn @@ -23,5 +23,14 @@ IRC, freenode, #hurd, 2011-06-01 these instead of our Hurd-specific passive translator information in inodes. -If interested in working on this, see [[!GNU_Savannah_task -#5503]]/[[!GNU_Savannah_patch #5126]], and talk to [[tschwinge]]. +If interested in working on this, talk to [[tschwinge]], and see these resources: + + * [[!GNU_Savannah_task 5503]], [[!GNU_Savannah_patch 5126]] + + * , + , + + + * , + , + -- cgit v1.2.3 From 3596895ffc649893a7f4519e91c096bcecd76d8e Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Sat, 23 Jul 2011 23:08:17 +0200 Subject: open_issues/translators_set_up_by_untrusted_users: Link to Ubuntu, Linux kernel, Symlink and Hardlink Protection. --- open_issues/translators_set_up_by_untrusted_users.mdwn | 9 +++++++++ 1 file changed, 9 insertions(+) (limited to 'open_issues') diff --git a/open_issues/translators_set_up_by_untrusted_users.mdwn b/open_issues/translators_set_up_by_untrusted_users.mdwn index edc92796..cee7a2bc 100644 --- a/open_issues/translators_set_up_by_untrusted_users.mdwn +++ b/open_issues/translators_set_up_by_untrusted_users.mdwn @@ -272,3 +272,12 @@ License|/fdl]]."]]"""]] to solve security issues at all and as braunr already pointed out, this wouldn't help with DoS problems + + +# Linux kernel, Symlink/Hardlink Attack + +Even though not directly comparable, the issues described at [Symlink +Protection](https://wiki.ubuntu.com/SecurityTeam/Roadmap/KernelHardening#Symlink_Protection) +and [Hardlink +Protection](https://wiki.ubuntu.com/SecurityTeam/Roadmap/KernelHardening#Hardlink_Protection) +do bear some similarity with the issue we're discussing here. -- cgit v1.2.3 From 902e82cf34208d5a86f7d0adc2c75aa50b783acb Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Mon, 25 Jul 2011 11:22:53 +0200 Subject: open_issues/gnumach_vm_map_entry_forward_merging: GCC build time using bash vs. dash. --- open_issues/gnumach_vm_map_entry_forward_merging.mdwn | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) (limited to 'open_issues') diff --git a/open_issues/gnumach_vm_map_entry_forward_merging.mdwn b/open_issues/gnumach_vm_map_entry_forward_merging.mdwn index f1c8bd6e..90137766 100644 --- a/open_issues/gnumach_vm_map_entry_forward_merging.mdwn +++ b/open_issues/gnumach_vm_map_entry_forward_merging.mdwn @@ -182,6 +182,11 @@ License|/fdl]]."]]"""]] for the same reasons (shadow objects being one of them) +# GCC build time using bash vs. dash + + + + # Procedure * Analyze. @@ -192,8 +197,4 @@ License|/fdl]]."]]"""]] * Measure again. - * Have [[tschwinge]] measure with gcc build (currently needs 11 h). - [[tschwinge]] will in the mean time figure out the difference between using - bash and dash. - * Have Samuel measure on the buildd. -- cgit v1.2.3 From 7da9f3aeb538481e71513cdaaab68dfdd3322e68 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Mon, 25 Jul 2011 11:23:40 +0200 Subject: open_issues/binutils: Update. --- open_issues/binutils.mdwn | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'open_issues') diff --git a/open_issues/binutils.mdwn b/open_issues/binutils.mdwn index 1c3bc022..b3f58832 100644 --- a/open_issues/binutils.mdwn +++ b/open_issues/binutils.mdwn @@ -30,8 +30,8 @@ though, as explained below. # Configuration -Last reviewed up to the [[Git mirror's 57a1a9e822a763aeeb3ea66fd493aa58888c76c4 -(2011-07-03) sources|source_repositories/binutils]]. +Last reviewed up to the [[Git mirror's 63dd9daf3e4b1fdad043bda3377bc1a078f9bfe1 +(2011-07-22) sources|source_repositories/binutils]]. * Globally -- cgit v1.2.3 From 7c37840931c336b7e33d89911410f945fc30c07e Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Mon, 25 Jul 2011 11:24:19 +0200 Subject: open_issues/gcc: Update. --- open_issues/gcc.mdwn | 11 ++++------- 1 file changed, 4 insertions(+), 7 deletions(-) (limited to 'open_issues') diff --git a/open_issues/gcc.mdwn b/open_issues/gcc.mdwn index f0f2af51..37864524 100644 --- a/open_issues/gcc.mdwn +++ b/open_issues/gcc.mdwn @@ -67,8 +67,8 @@ testsuite. # Configuration -Last reviewed up to the [[Git mirror's 7c9f953a01d23c6b6885dc908d5b1dba8009efd4 -(2011-07-18) sources|source_repositories/gcc]]. +Last reviewed up to the [[Git mirror's 6678cb4ef6c7d8d9232249b5d722a0d6dfd328b5 +(2011-07-22) sources|source_repositories/gcc]]. has documentation for the `configure` switches. @@ -170,14 +170,11 @@ Last reviewed up to the [[Git mirror's 7c9f953a01d23c6b6885dc908d5b1dba8009efd4 `check_effective_target_pie` should include `*-*-gnu*`, too. - * [high] 9b0fef97f18ed5c9f2f9a361262fbb450f2b0b53 - - Very likely needed for us, too. Patch on gcc-patches and in - *config/extra_parts* branch. - # Build + * Waiting: ef3c41c78d877ac478ddaac3942243f9bd0844f3 switches to g++. + Here's a log of a GCC build run; this is from our [[Git repository's 09ba3e78c07654e08c8bef82761dbbb26d3c00c9 (2011-07-18) sources|source_repositories/gcc]], run on kepler.SCHWINGE and coulomb.SCHWINGE. -- cgit v1.2.3 From b687f782572b127e8ae32f0df40250fb19ccd22b Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Mon, 25 Jul 2011 11:27:24 +0200 Subject: IRC. --- open_issues/placement_of_virtual_memory_regions.mdwn | 16 +++++++++++++++- open_issues/rm_fr.mdwn | 12 ++++++++++++ 2 files changed, 27 insertions(+), 1 deletion(-) (limited to 'open_issues') diff --git a/open_issues/placement_of_virtual_memory_regions.mdwn b/open_issues/placement_of_virtual_memory_regions.mdwn index 95b9e545..39478f20 100644 --- a/open_issues/placement_of_virtual_memory_regions.mdwn +++ b/open_issues/placement_of_virtual_memory_regions.mdwn @@ -10,7 +10,7 @@ License|/fdl]]."]]"""]] [[!tag open_issue_gnumach]] -IRC, freenode, #hurd, 2011-07-13 +# IRC, freenode, #hurd, 2011-07-13 does anyone know if posix (or mach) has requirements or a policy about the placement of allocations of virtual space ? @@ -87,3 +87,17 @@ IRC, freenode, #hurd, 2011-07-13 jkoenig: i really want to miss as little as possible on the vm part, so having detailed information about what actually happens on running hurd systems is something i need + + +# IRC, freenode, #hurd, 2011-07-24 + + oh btw, i noticed there are many mappings below the program text + most notably, the stack + except for special applications like wine, could this break + anything ? + i also wonder how libraries are mapped, because there is nothing + to perform top-down allocations + which means if the region below the program text is exhausted, + libraries could be mapped right after the heap + it shouldn't break anything except things like wine & libgc, yes + which could make malloc() fail :/ diff --git a/open_issues/rm_fr.mdwn b/open_issues/rm_fr.mdwn index 89a803ab..aab52d97 100644 --- a/open_issues/rm_fr.mdwn +++ b/open_issues/rm_fr.mdwn @@ -25,3 +25,15 @@ really waits for all I/Os, which basically means strictly serializing file removals: remove one file, wait for the disk to have done it (~10ms), remove the next one, etc. I guess this is for safety reasons against crashes, but isn't the sync option there for such kind of + + +# IRC, freenode, #hurd, 2011-07-23 + + youpi: hm... async deletion does have one downside: I just removed + something to make space, and retried the other command immediately + afterwards, and it still said "no space left on device"... a few seconds + later (after the next regular sync I suppose?) it worked + well, that's sorta expected, yes + we get the same on Linux + Mmm, on second thought, I'm not sure how that can happen + the asynchronous thing is for disk writes, not cache writes -- cgit v1.2.3