diff options
Diffstat (limited to 'community/gsoc/project_ideas/libdiskfs_locking.mdwn')
| -rw-r--r-- | community/gsoc/project_ideas/libdiskfs_locking.mdwn | 45 |
1 files changed, 0 insertions, 45 deletions
diff --git a/community/gsoc/project_ideas/libdiskfs_locking.mdwn b/community/gsoc/project_ideas/libdiskfs_locking.mdwn deleted file mode 100644 index faac8bd9..00000000 --- a/community/gsoc/project_ideas/libdiskfs_locking.mdwn +++ /dev/null @@ -1,45 +0,0 @@ -[[!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... |