blob: c9d55bb75b7890dad0cafce4b9bedeb28454e0ea (
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
|
[[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...)
This task requires experience with debugging locking issues in multithreaded
applications.
Possible mentors: ?
Exercise: Hack libdiskfs to keep count of the number of locks currently held.
|
