summaryrefslogtreecommitdiff
path: root/open_issues/locking.mdwn
blob: 1717133aa7516c27352d6717a56adc67a406848d (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
46
47
48
49
50
51
52
53
[[!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 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.

Tools have been written for static code analysis, than can help to locate
and fix such errors.

  * Coccinelle

      * <http://lwn.net/Articles/315686/>

      * <http://www.google.com/search?q=coccinelle+analysis>

  * clang

      * <http://www.google.com/search?q=clang+analysis>

  * Linux' sparse

      * <https://sparse.wiki.kernel.org/>