1 files changed, 47 insertions, 0 deletions
diff --git a/community/gsoc/project_ideas/libdiskfs_locking.mdwn b/community/gsoc/project_ideas/libdiskfs_locking.mdwn
new file mode 100644
index 00000000..0e38b6a0
--- /dev/null
+++ b/community/gsoc/project_ideas/libdiskfs_locking.mdwn
@@ -0,0 +1,47 @@
+[[!meta copyright="Copyright © 2008, 2009, 2010, 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]]."]]"""]]
+
+[[!meta title="Fix libdiskfs Locking Issues"]]
+
+Every now and then, new locking issues are discovered in
+[[hurd/libdiskfs]] or [[hurd/translator/ext2fs]], for example.  Nowadays
+these in fact seem to be the most often encountered cause of Hurd crashes
+/ lockups.
+
+One of these could be traced
+recently, and turned out to be a lock inside [[hurd/libdiskfs]] that was taken
+and not released in some cases.  There is reason to believe that there are more
+faulty paths causing these lockups.
+
+The task is systematically checking the [[hurd/libdiskfs]] code for this kind of locking
+issues. To achieve this, some kind of test harness has to be implemented: For
+example instrumenting the code to check locking correctness constantly at
+runtime. Or implementing a [[unit testing]] framework that explicitly checks
+locking in various code paths. (The latter could serve as a template for
+implementing unit tests in other parts of the Hurd codebase...)
+
+(A [[systematic code review|security]] would probably suffice to find the
+existing locking
+issues; but it wouldn't document the work in terms of actual code produced, and
+thus it's not suitable for a GSoC project...)
+
+This task requires experience with debugging locking issues in
+[[multithreaded|multithreading]] applications.
+
+Tools have been written for automated [[code analysis]]; these can help to
+locate and fix such errors.
+
+Possible mentors: Samuel Thibault (youpi)
+
+Exercise: If you could actually track down and fix one of the existing locking
+errors before the end of the application process, that would be excellent. This
+might be rather tough though, so probably you need to talk to us about an
+alternative exercise task...