diff options
| author | Paul E. McKenney <paulmck@us.ibm.com> | 2006-02-01 03:06:42 -0800 |
|---|---|---|
| committer | Linus Torvalds <torvalds@g5.osdl.org> | 2006-02-01 08:53:25 -0800 |
| commit | d19720a909b4443f78cbb03f4f090180e143ad9d (patch) | |
| tree | 56e579612d82f4b30d5cb943df1079b0b5f4700a /Documentation/RCU/listRCU.txt | |
| parent | 53d8be5c144ece5d48745810b14248968e73eaf2 (diff) | |
[PATCH] RCU documentation fixes (January 2006 update)
Updates to in-tree RCU documentation based on comments over the past few
months.
Signed-off-by: "Paul E. McKenney" <paulmck@us.ibm.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Diffstat (limited to 'Documentation/RCU/listRCU.txt')
| -rw-r--r-- | Documentation/RCU/listRCU.txt | 21 |
1 files changed, 12 insertions, 9 deletions
diff --git a/Documentation/RCU/listRCU.txt b/Documentation/RCU/listRCU.txt index f8a54fa0d8ab..1fd175368a87 100644 --- a/Documentation/RCU/listRCU.txt +++ b/Documentation/RCU/listRCU.txt @@ -232,7 +232,7 @@ entry does not exist. For this to be helpful, the search function must return holding the per-entry spinlock, as ipc_lock() does in fact do. Quick Quiz: Why does the search function need to return holding the -per-entry lock for this deleted-flag technique to be helpful? + per-entry lock for this deleted-flag technique to be helpful? If the system-call audit module were to ever need to reject stale data, one way to accomplish this would be to add a "deleted" flag and a "lock" @@ -275,8 +275,8 @@ flag under the spinlock as follows: { struct audit_entry *e; - /* Do not use the _rcu iterator here, since this is the only - * deletion routine. */ + /* Do not need to use the _rcu iterator here, since this + * is the only deletion routine. */ list_for_each_entry(e, list, list) { if (!audit_compare_rule(rule, &e->rule)) { spin_lock(&e->lock); @@ -304,9 +304,12 @@ function to reject newly deleted data. Answer to Quick Quiz - -If the search function drops the per-entry lock before returning, then -the caller will be processing stale data in any case. If it is really -OK to be processing stale data, then you don't need a "deleted" flag. -If processing stale data really is a problem, then you need to hold the -per-entry lock across all of the code that uses the value looked up. + Why does the search function need to return holding the per-entry + lock for this deleted-flag technique to be helpful? + + If the search function drops the per-entry lock before returning, + then the caller will be processing stale data in any case. If it + is really OK to be processing stale data, then you don't need a + "deleted" flag. If processing stale data really is a problem, + then you need to hold the per-entry lock across all of the code + that uses the value that was returned. |