Add a comment noting that unlike usual, we do not need to
guard a dereference of an rcu guarded pointer with a
call to rcu_dereference(), because we don't care if we
see out of order results.
Signed-off-by: Paul Jackson <[email protected]>
---
kernel/cpuset.c | 6 ++++++
1 files changed, 6 insertions(+)
--- 2.6.15-rc3-mm1.orig/kernel/cpuset.c 2005-12-11 22:35:39.051718313 -0800
+++ 2.6.15-rc3-mm1/kernel/cpuset.c 2005-12-12 00:38:25.301117045 -0800
@@ -632,6 +632,12 @@ static void guarantee_online_mems(const
* unmapped. It's ok if attach_task() replaces our cpuset with
* another while we are reading mems_generation, and even frees it.
*
+ * We do -not- need to guard the 'cs' pointer dereference within the
+ * rcu_read_lock section with rcu_dereference(), because we don't
+ * mind getting bogus out-of-order results. New cpuset pointer and
+ * old mems_generation is ok - we'll realize that our cpuset memory
+ * placement changed the next time through here.
+ *
* This routine is needed to update the per-task mems_allowed data,
* within the tasks context, when it is trying to allocate memory
* (in various mm/mempolicy.c routines) and notices that some other
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <[email protected]> 1.650.933.1373
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
