diff options
Diffstat (limited to 'open_issues/locking.mdwn')
| -rw-r--r-- | open_issues/locking.mdwn | 53 |
1 files changed, 53 insertions, 0 deletions
diff --git a/open_issues/locking.mdwn b/open_issues/locking.mdwn new file mode 100644 index 00000000..1717133a --- /dev/null +++ b/open_issues/locking.mdwn @@ -0,0 +1,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/> |