diff options
21 files changed, 303 insertions, 49 deletions
diff --git a/contributing.mdwn b/contributing.mdwn index c006e554..1745b61a 100644 --- a/contributing.mdwn +++ b/contributing.mdwn @@ -16,7 +16,7 @@ Every single contribution is very much encouraged. There are various ways to contribute; read up on contributing to... -[[!toc levels=3]] +[[!toc levels=4]] If someone of you is lurking around here and would like to contribute, but feels she / he could do so better under formal mentoring: please @@ -77,31 +77,47 @@ documents. <a name="porting"></a> ## Porting Packages -Debian is currently the Hurd distribution of choice among Hurd users and -developers. +Please [[contact_us]] before spending a lot of time on the following porting +tasks: some work may already have been done that you can base your work upon. -Here is a -[[list_of_Debian_packages_that_need_porting|hurd/running/debian/porting]]. +For guidelines, please have a look at the dedicated [[porting_page|hurd/porting]]. -You can also just [[install_Debian_GNU/Hurd|hurd/running/debian]] and find what -doesn't work or suit you and try to improve that. -You can also have a look at the [List of failing packages](http://people.debian.org/~sthibault/failed_packages.txt). +### Debian GNU/Hurd -For guidelines, please have a look at the dedicated [[porting_page|hurd/porting]]. +[[!template id=note text="""#### Debian Wheezy Release +There is a goal of getting Debian GNU/Hurd into shape for a proper release with +Debian Wheezy (expected towards the end of 2012 or beginning of 2013). -## Open Issues +The *to do* list is on <http://wiki.debian.org/Debian_GNU/Hurd>."""]] -There is a list of [[open_issues]]. This list includes everything from bug -reports to open-ended research questions. +The following missing packages/missing functionality block a lot of other +packages, and are thus good candidates for porting, in order to increase +archive coverage: +* umount functionality in busybox +* gtest +* hdf5 +* hyperestraier +* sane* +* ghc (ghc6 and ghc7) +* [[open_issues/gnat]] +* ruby1.9.1 -## Debian Wheezy release +Here is a [[list of packages that need porting|hurd/running/debian/porting]]. -We target the Debian Wheezy release! +You can also just [[install_Debian_GNU/Hurd|hurd/running/debian]] and find what +doesn't work or suit you and try to improve that. + +Or, you can pick one from the [list of failing +packages](http://people.debian.org/~sthibault/failed_packages.txt). -The *to do* list is on <http://wiki.debian.org/Debian_GNU/Hurd>. + +## Open Issues + +There is a list of [[open_issues]]. This list includes everything from bug +reports to open-ended research questions. <a name="insta-dev-env"></a> diff --git a/contributing/discussion.mdwn b/contributing/discussion.mdwn new file mode 100644 index 00000000..5a6bfd7c --- /dev/null +++ b/contributing/discussion.mdwn @@ -0,0 +1,21 @@ +[[!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_documentation]] + + +# One-stop Development Environment + +Invent something. + + +# Mailing Lists + +Add link to [[mailing_lists]] to page, and suggest following these. diff --git a/contributing/web_pages/news/moth_next.mdwn b/contributing/web_pages/news/moth_next.mdwn index dec41583..e8a0428a 100644 --- a/contributing/web_pages/news/moth_next.mdwn +++ b/contributing/web_pages/news/moth_next.mdwn @@ -67,4 +67,9 @@ And … * <http://blog.schmehl.info/Debian/hurd-not-default> + * LWN + + * Bits from the Debian GNU/Hurd porters, + id:"20110721172827.GF4057@const.famille.thibault.fr" + """]] diff --git a/hurd/documentation/translator_primer.mdwn b/hurd/documentation/translator_primer.mdwn index 4586a8e6..e5c8c160 100644 --- a/hurd/documentation/translator_primer.mdwn +++ b/hurd/documentation/translator_primer.mdwn @@ -41,7 +41,11 @@ Then you setup the translator /hurd/hello in the file/node hello. After that you check the contents of the file, and the translator returns "Hello World!". -To finish it, you tell the translator to go away from the file "hello" via "settrans -g hello" and verify that now the file is empty again. +To finish it, +you remove the translator from the file "hello" +(and tell any active running instances to go away) +via "settrans -g hello". +Having done that, verify that now the file is empty again. ### Transparent FTP diff --git a/hurd/faq/off.mdwn b/hurd/faq/off.mdwn index 363436b0..64009101 100644 --- a/hurd/faq/off.mdwn +++ b/hurd/faq/off.mdwn @@ -19,3 +19,7 @@ will not work. Simply use the equivalent shortcut $ halt which is provided natively on GNU/Hurd, instead of from SYSV runlevels. + +Note that due to a bug, +we [[recommend you run syncfs|open_issues/sync_but_still_unclean_filesystem]] +prior to issuing the `halt` command. diff --git a/hurd/translator/procfs/jkoenig/discussion.mdwn b/hurd/translator/procfs/jkoenig/discussion.mdwn index b66af7de..64e3776e 100644 --- a/hurd/translator/procfs/jkoenig/discussion.mdwn +++ b/hurd/translator/procfs/jkoenig/discussion.mdwn @@ -166,3 +166,21 @@ IRC, freenode, #hurd, 2011-03-28 mentoring the previous procfs implementation <antrik> (though I never got around to look at his buggy code...) <jkoenig> ok + +IRC, freenode, #hurd, 2011-07-22 + + <pinotree> hm, why /proc/$pid/stat is 600 instead of 644 of linux? + <jkoenig> pinotree, it reveals information which, while not that sensitive, + would not be available to users through the normal proc interface. + <jkoenig> (it's available through the ps command which is setuid root) + <jkoenig> we discussed at some point making it 644, IIRC. + <pinotree> hm, then why is it not a problem on eg linux? + <jkoenig> (btw you can change it with the -s option.) + <jkoenig> pinotree, it's not a problem because the information is not that + sensitive, but when rewriting procfs I preferred to play it self and + consider it's not procfs' job to decide what is sensitive or not. + <jkoenig> IIRC it's not sensitive but you need the task port to query it. + <jkoenig> like, thread times or something. + <pinotree> status is 644 though + <jkoenig> but status contains information which anyone can ask to the proc + server anyway, I think. diff --git a/microkernel/mach/gnumach/hardware_compatibility_list.mdwn b/microkernel/mach/gnumach/hardware_compatibility_list.mdwn index 2152c079..6c984784 100644 --- a/microkernel/mach/gnumach/hardware_compatibility_list.mdwn +++ b/microkernel/mach/gnumach/hardware_compatibility_list.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2007, 2008, 2009 Free Software Foundation, +[[!meta copyright="Copyright © 2007, 2008, 2009, 2011 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable @@ -6,8 +6,8 @@ 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] # CPU Architecture @@ -68,10 +68,11 @@ All common IDE drives should work. Some drive geometries do not work, e.g. drives with hundreds of GiB of storage space, see [[!GNU_Savannah_bug 26425]]. -[[!toggle id="SATA" text="SATA drives may work in compatibility mode."]] -<!-- Sure? --[[tschwinge]] --> -[[!toggleable id="SATA" text=""" +## SATA + +SATA drives may work in compatibility mode. + This is how booting a [[GNU/Hurd_system|hurd]] will typically fail if GNU Mach couldn't connect to the hard disk, e.g., in a SATA system without IDE compatibility mode: @@ -81,7 +82,7 @@ compatibility mode: There *may* be an option in the system's BIOS setup to configure enabling such a compatibility mode. -"""]] + # Device Drivers diff --git a/microkernel/mach/gnumach/hardware_compatibility_list/discussion.mdwn b/microkernel/mach/gnumach/hardware_compatibility_list/discussion.mdwn index 69ca3190..2b65956a 100644 --- a/microkernel/mach/gnumach/hardware_compatibility_list/discussion.mdwn +++ b/microkernel/mach/gnumach/hardware_compatibility_list/discussion.mdwn @@ -1,4 +1,33 @@ +[[!meta copyright="Copyright © 2007, 2008, 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_documentation]] + Further information may still be found on <http://www.nongnu.org/thug/gnumach_hardware.html> and could perhaps be incorporated into that page. --[[tschwinge]] + + +# SATA + +IRC, freenode, +hurd, 2011-07-24 + + <braunr> youpi: concerning the ide compatibility problem, it seems some + bioses provide several modes + <braunr> youpi: "legacy ide" and "native ide" + <braunr> i don't know what native ide really means, but when debugging ide + probing in gnumach, it just looks like there is nothing to detect + <braunr> and even in this mode, linux uses the ahci driver + <youpi> apparently native means it still uses the IDE protocol, but + possibly with other IRQs + <youpi> i.e. you need a PCI driver to handle that + <braunr> ok diff --git a/microkernel/mach/port.mdwn b/microkernel/mach/port.mdwn index ba2e22c2..7f02628d 100644 --- a/microkernel/mach/port.mdwn +++ b/microkernel/mach/port.mdwn @@ -49,7 +49,7 @@ send-once right. These messages are (probably) queued and when the server task tries to receive messages by having a [[thread]] use its port receive right, it gets the message(s). This is called [[IPC]]. -Port rights themselvse can be [[delegate]]d in a [[message]], too. When the +Port rights themselves can be [[delegate]]d in a [[message]], too. When the receiver dequeues the message, the right is made available to it. The delivery of [[message]]s is reliable and strictly ordered. When a diff --git a/news/2011-q2-ps.mdwn b/news/2011-q2-ps.mdwn index be9cef50..cbf039b0 100644 --- a/news/2011-q2-ps.mdwn +++ b/news/2011-q2-ps.mdwn @@ -33,12 +33,12 @@ In the following, we try to clear the situation up a bit. want to help, please see our [[contributing]] page and the *to do* list maintained on <http://wiki.debian.org/Debian_GNU/Hurd>. - * *GNU Hurd developers want the Linux kernel to die*. {X} **Wrong**. All of - us are happy users of the Linux kernel, every day, and GNU/Linux is the - free operating system of choice, which we're using ourselves (unless - sitting in front of a GNU/Hurd system). We don’t work on the GNU Hurd due - to any hatred against the Linux kernel or even Linus; we work on it because - of the [[additional capabilities and clean design|advantages]] that it + * *GNU Hurd developers want the Linux kernel to die*. {X} + **Wrong**. All of us are happy users of the Linux kernel, every + day, and GNU/Linux is the free operating system of choice, which + we're using ourselves (unless sitting in front of a GNU/Hurd + system). We work on the Hurd instead of Linux because of the + [[additional capabilities and clean design|advantages]] it provides. * *Java support for GNU/Hurd is in the works*. (./) **True**. Jérémie 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> |