[[!meta copyright="Copyright © 2008, 2009, 2010 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_hurd]]

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.