login
Search
Rusty Russell [interview] recently posted an updated version of his "Unreliable Guide To Locking". The introduction begins:
"Welcome, to Rusty's Remarkably Unreliable Guide to Kernel Locking issues. This document describes the locking systems in the Linux Kernel in 2.6. With the wide availability of HyperThreading, and preemption in the Linux Kernel, everyone hacking on the kernel needs to know the fundamentals of concurrency and locking for SMP. "
Rusty's excellent guide is quite informative, helping the reader to grasp concurrency, explaining the common types of locks, providing useful examples, listing common problems, discussing locking speed, and much more. All in all, it's an essential reference.
From: Rusty Russell [email blocked] To: linux-kernel Subject: [PATCH] Update Documentation/DocBook/kernel-locking.tmpl Date: Thu, 11 Dec 2003 19:57:03 +1100 This has needed doing for a while. Reviews welcome. As an attachment because it's about 64k "raw". Cheers, Rusty.
From: "Randy.Dunlap" [email blocked] Subject: Re: [PATCH] Update Documentation/DocBook/kernel-locking.tmpl Date: Thu, 11 Dec 2003 20:00:55 -0800 | | This has needed doing for a while. Reviews welcome. | | As an attachment because it's about 64k "raw". Some could be fuser errors (with docbook stylesheets etc.)... a. uses "gloss-timer" and "gloss-timers": choose one b. docbook complained about many unclosed or unmatched instances of </sect1>, </chapter>, </listitem>, etc. c. docbook complains about some 'C' syntactic items that are inside <LiteralLayout> or <programlisting>. E.g.: - 'cache' in list_for_each_entry(i, &cache, list) - 'obj-' in list_del(&obj->list); - 'cache_lock' in down(&cache_lock); (see the pattern: '&' shouldn't be special inside these blocks, or at least that's how I think about it, but the software disagrees) - docbook (at least my version) dislikes these #includes: #include <linux/list.h> #include <linux/slab.h> #include <linux/string.h> +#include <linux/rcupdate.h> #include <asm/semaphore.h> #include <asm/errno.h> I'd read it for content soonish. Thanks for the update. -- ~Randy
From: Rusty Russell [email blocked] Subject: Re: [PATCH] Update Documentation/DocBook/kernel-locking.tmpl Date: Fri, 12 Dec 2003 17:04:00 +1100 In message <20031211200055.778ca906.rddunlap@osdl.org> you write: > | > | This has needed doing for a while. Reviews welcome. > | > | As an attachment because it's about 64k "raw". > > > Some could be fuser errors (with docbook stylesheets etc.)... Yes, I fixed all these, but I sent out the old one (I'd fixed the ..sgml file, not the .tmpl file!). Here's take II. See also: http://www.kernel.org/pub/linux/kernel/people/rusty/kernel-locking/ Thanks, Rusty. -- Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
From: Rusty Russell [email blocked] Subject: [DOCUMENTATION] Revised Unreliable Kernel Locking Guide Date: Fri, 12 Dec 2003 16:24:18 +1100 OK, I've put the html version up for your reading pleasure: the diff is quite extensive and hard to read. http://www.kernel.org/pub/linux/kernel/people/rusty/kernel-locking/ Feedback welcome, Rusty. -- Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
Source code checking
I am very unfamiliar with the kernel and the tools used, so this may be a stupid question - is there any source code checker for the Kernel that would do a 'super lint'. This would be a tool that checks the code for potential locking issues may exist. It would also check to and unsafe code that may suffer form memory leaks or buffer overruns. I am guessing that you would need to add 'pragmas' around code that is preempt-able, or perhaps the other way - code that could not be pre-empted.
moof
preempt_enable() and preempt_disable()
Yes
There's a tool like that. The people that maintain it run it on the Linux kernel every so often and send a bunch of information to the lkml. It's a university group that does it but I can't recall which one at the moment...possibly Stanford.
Checker
Howdy
It`s indeed called the "Stanford Checker".
Erm, Confused Newbie Here ....
Sorry this is off topic but -
The only person quoting Rusty Russell in their sig seems to be Rusty Russell. Surely this is taking self deprecation a step too far ?
O.K, O.K., I`ll leave you to flame me now while I scamper back to Kernel Newbies. ;-)
Not for an Australian it isn't.
Rusty is providing a perfect example of it with his sig.
re: Erm, Confused Newbie Here ....
For what it's worth, Rusty gives the history behind his sig early on in this interview.