blob: 039140783746009baf6ab1eae46a67be4cdfcc2e (
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
|
[[meta copyright="Copyright © 2008, 2009 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"]]
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
exmple instrumenting the code to check locking correctness constantly at
runtime. Or implementing a unit testing framework that explicitely checks
locking in various code paths. (The latter could serve as a template for
implementing unit checks in other parts of the Hurd codebase...)
(A systematic code review 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
applications.
Possible mentors: ?
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...
|
