diff options
Diffstat (limited to 'open_issues')
| -rw-r--r-- | open_issues/binutils.mdwn | 4 | ||||
| -rw-r--r-- | open_issues/gcc.mdwn | 11 | ||||
| -rw-r--r-- | open_issues/gnumach_memory_management.mdwn | 29 | ||||
| -rw-r--r-- | open_issues/gnumach_vm_map_entry_forward_merging.mdwn | 20 | ||||
| -rw-r--r-- | open_issues/libpthread_dlopen.mdwn | 36 | ||||
| -rw-r--r-- | open_issues/multithreading.mdwn | 4 | ||||
| -rw-r--r-- | open_issues/performance/io_system/clustered_page_faults.mdwn | 40 | ||||
| -rw-r--r-- | open_issues/placement_of_virtual_memory_regions.mdwn | 16 | ||||
| -rw-r--r-- | open_issues/rm_fr.mdwn | 12 | ||||
| -rw-r--r-- | open_issues/translators_set_up_by_untrusted_users.mdwn | 9 | ||||
| -rw-r--r-- | open_issues/xattr.mdwn | 13 |
11 files changed, 175 insertions, 19 deletions
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 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]]. <http://gcc.gnu.org/install/configure.html> 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. 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. <braunr> ok <braunr> it's tricky <braunr> mcsim: try to find where the first use of the allocator is made + + +# IRC, freenode, #hurd, 2011-07-22 + + <mcsim> 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. + <tschwinge> mcsim: Oh, cool! Have you done some measurements already? + <mcsim> Not yet + <tschwinge> OK. + <tschwinge> But if it able to run a GNU/Hurd system, then that already is + something, a big milestone! + <braunr> nice + <braunr> although you'll probably need to tweak the garbage collecting + process + <mcsim> tschwinge: thanks + <mcsim> 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? + <braunr> mcsim: do *not* use kmem_alloc_pageable() + <mcsim> braunr: Ok. This is even better) + <braunr> mcsim: in x15, i've taken this even further: there is *no* kernel + vm object, which means all kernel memory is wired and unmanaged + <braunr> making it fast and safe + <braunr> pageable kernel memory was useful back when RAM was really scarce + <braunr> 20 years ago + <braunr> but it's a source of deadlock + <mcsim> Indeed. I'll won't use kmem_alloc_pageable. diff --git a/open_issues/gnumach_vm_map_entry_forward_merging.mdwn b/open_issues/gnumach_vm_map_entry_forward_merging.mdwn index b2b20c5b..90137766 100644 --- a/open_issues/gnumach_vm_map_entry_forward_merging.mdwn +++ b/open_issues/gnumach_vm_map_entry_forward_merging.mdwn @@ -171,6 +171,22 @@ License|/fdl]]."]]"""]] entries) +# IRC, freenode, #hurd, 2011-07-21 + + <braunr> tschwinge: you may remove the forward map entry merging issue :/ + <pinotree> what did you discover? + <braunr> 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 + <braunr> from what i could see, part of the problem still exists in freebsd + <braunr> for the same reasons (shadow objects being one of them) + + +# GCC build time using bash vs. dash + +<http://gcc.gnu.org/ml/gcc/2011-07/msg00444.html> + + # Procedure * Analyze. @@ -181,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. 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. + + <youpi> there's one known issue with pthreads + <youpi> you can't dlopen() it + <youpi> which also means you can't dlopen() a module which depends on it if + the main application hasn't used -lpthread already + <youpi> (so as to get libpthread initialized early, not at the dlopen() + call) + <lucas> I get this while building simgrid: + <lucas> 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 + <lucas> 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 + <lucas> 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. + <lucas> Aborted (core dumped) + <youpi> that's it, yes + <youpi> (or at least it has the same symptoms) + <lucas> it would need fixing in lua, not in SG, then, right? + <youpi> yes + <lucas> ok, thanks 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: 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 <braunr> exceptfor the kernel, everything in an address space is represented with a VM object @@ -88,9 +91,8 @@ IRC, freenode, #hurd, 2011-02-16 <braunr> recommend* <etenil> ok ---- -IRC, freenode, #hurd, 2011-02-16 +# IRC, freenode, #hurd, 2011-02-16 <antrik> 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 <http://lists.gnu.org/archive/html/bug-hurd/2010-06/msg00023.html> + + +# IRC, freenode, #hurd, 2011-07-22 + + <braunr> but concerning clustered pagins/outs, i'm not sure it's a mach + interface limitation + <braunr> the external memory pager interface does allow multiple pages to + be transfered + <braunr> isn't it an internal Mach VM problem ? + <braunr> isn't it simply the page fault handler ? + <antrik> braunr: are you sure? I was under the impression that changing the + pager interface was among the requirements... + <antrik> 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 + <antrik> err... in the pagers + <braunr> antrik: i'm almost sure + <braunr> but i've be proven wrong many times, so .. + <braunr> there are two main facts that lead me to think this + <braunr> 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 + <braunr> 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 + <braunr> and this didn't involve a new pager interface, but rather a new + page fault handler + <antrik> 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?... + <braunr> antrik: would be nice wouldn't it ? :) + <braunr> antrik: more probably the page fault handler 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 <braunr> 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 <braunr> 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 + + <braunr> oh btw, i noticed there are many mappings below the program text + <braunr> most notably, the stack + <braunr> except for special applications like wine, could this break + anything ? + <braunr> i also wonder how libraries are mapped, because there is nothing + to perform top-down allocations + <braunr> which means if the region below the program text is exhausted, + libraries could be mapped right after the heap + <youpi> it shouldn't break anything except things like wine & libgc, yes + <braunr> 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 + + <antrik> 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 + <youpi> well, that's sorta expected, yes + <youpi> we get the same on Linux + <youpi> Mmm, on second thought, I'm not sure how that can happen + <youpi> the asynchronous thing is for disk writes, not cache writes 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 <antrik> 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. 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]] + + * <http://lists.gnu.org/archive/html/bug-hurd/2006-02/threads.html#00115>, + <http://lists.gnu.org/archive/html/bug-hurd/2006-01/threads.html#00180>, + <http://lists.gnu.org/archive/html/bug-hurd/2006-05/threads.html#00042> + + * <http://www.spinics.net/lists/linux-ext4/msg07260.html>, + <http://www.spinics.net/lists/linux-ext4/msg07259.html>, + <http://www.spinics.net/lists/linux-ext4/msg07261.html> |