summaryrefslogtreecommitdiff
path: root/community/gsoc/project_ideas/libdiskfs_locking.mdwn
blob: faac8bd963c43dcdefa01b07135d0a26b210cf3b (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
[[!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"]]

[[!tag open_issue_hurd]]

Nowadays the most often encountered cause of Hurd crashes seems to be lockups
in the [[hurd/translator/ext2fs]] server.  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 [[open_issues/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|open_issues/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|open_issues/multithreading]] applications.

Tools have been written for automated [[open_issues/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...