From: Paul Jackson <[email protected]>
Fix cpuset comment involving case of a tasks cpuset
pointer being NULL. Thanks to "the_top_cpuset_hack",
this code no longer sees NULL task->cpuset pointers.
Signed-off-by: Paul Jackson <[email protected]>
---
kernel/cpuset.c | 10 ++++------
1 file changed, 4 insertions(+), 6 deletions(-)
--- 2.6.16-mm1.orig/kernel/cpuset.c 2006-03-27 08:44:45.794087744 -0800
+++ 2.6.16-mm1/kernel/cpuset.c 2006-03-28 16:06:02.862014854 -0800
@@ -616,12 +616,10 @@ static void guarantee_online_mems(const
* current->cpuset if a task has its memory placement changed.
* Do not call this routine if in_interrupt().
*
- * Call without callback_mutex or task_lock() held. May be called
- * with or without manage_mutex held. Doesn't need task_lock to guard
- * against another task changing a non-NULL cpuset pointer to NULL,
- * as that is only done by a task on itself, and if the current task
- * is here, it is not simultaneously in the exit code NULL'ing its
- * cpuset pointer. This routine also might acquire callback_mutex and
+ * Call without callback_mutex or task_lock() held. May be
+ * called with or without manage_mutex held. Thanks in part to
+ * 'the_top_cpuset_hack', the tasks cpuset pointer will never
+ * be NULL. This routine also might acquire callback_mutex and
* current->mm->mmap_sem during call.
*
* Reading current->cpuset->mems_generation doesn't need task_lock
--
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]
