From: Andrew Morton <akpm@osdl.org>

Eric cant spel

Cc: Eric W. Biederman <ebiederm@xmission.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
---

 include/linux/pid.h |   28 ++++++++++++++++------------
 kernel/pid.c        |    5 +++--
 2 files changed, 19 insertions(+), 14 deletions(-)

diff -puN include/linux/pid.h~pidhash-refactor-the-pid-hash-table-fixes include/linux/pid.h
--- 25/include/linux/pid.h~pidhash-refactor-the-pid-hash-table-fixes	Fri Mar 10 15:45:36 2006
+++ 25-akpm/include/linux/pid.h	Fri Mar 10 15:45:36 2006
@@ -11,23 +11,24 @@ enum pid_type
 	PIDTYPE_MAX
 };
 
-/* What is struct pid?
+/*
+ * What is struct pid?
  *
- * A struct pid is the kernels internal notion of a process identier.
+ * A struct pid is the kernel's internal notion of a process identifier.
  * It refers to individual tasks, process groups, and sessions.  While
  * there are processes attached to it the struct pid lives in a hash
- * table, so it and then the processes that it refers to it can be found
+ * table, so it and then the processes that it refers to can be found
  * quickly from the numeric pid value.  The attached processes may be
- * quickly access by following pointers from struct pid.
+ * quickly accessed by following pointers from struct pid.
  *
  * Storing pid_t values in the kernel and refering to them later has a
- * problem.  The process originally with that pid may have exited the
+ * problem.  The process originally with that pid may have exited and the
  * pid allocator wrapped, and another process could have come along
  * and been assigned that pid.
  *
- * Refering to user space process by holding a reference to struct
- * task_struct has a problem.  When the user space process exit
- * the now useless task_struct still kept.  A task_struct plus a
+ * Referring to user space processes by holding a reference to struct
+ * task_struct has a problem.  When the user space process exits
+ * the now useless task_struct is still kept.  A task_struct plus a
  * stack consumes around 10K of low kernel memory.  More precisely
  * this is THREAD_SIZE + sizeof(struct task_struct).  By comparison
  * a struct pid is about 64 bytes.
@@ -35,7 +36,7 @@ enum pid_type
  * Holding a reference to struct pid solves both of these problems.
  * It is small so holding a reference does not consume a lot of
  * resources, and since a new struct pid is allocated when the numeric
- * pid value is reused when don't mistakenly refer to new process.
+ * pid value is reused we don't mistakenly refer to new processes.
  */
 
 struct pid
@@ -64,13 +65,15 @@ static inline struct pid *get_pid(struct
 
 extern void FASTCALL(put_pid(struct pid *pid));
 extern struct task_struct *FASTCALL(pid_task(struct pid *pid, enum pid_type));
-extern struct task_struct *FASTCALL(get_pid_task(struct pid *pid, enum pid_type));
+extern struct task_struct *FASTCALL(get_pid_task(struct pid *pid,
+						enum pid_type));
 
 /*
  * attach_pid() and detach_pid() must be called with the tasklist_lock
  * write-held.
  */
-extern int FASTCALL(attach_pid(struct task_struct *task, enum pid_type type, int nr));
+extern int FASTCALL(attach_pid(struct task_struct *task,
+				enum pid_type type, int nr));
 
 extern void FASTCALL(detach_pid(struct task_struct *task, enum pid_type));
 
@@ -92,7 +95,8 @@ extern void FASTCALL(free_pid(struct pid
 	((task)->pids[(type)].node.next)
 
 #define pid_next_task(task, type) 				\
-	hlist_entry(pid_next(task, type), struct task_struct, pids[(type)].node)
+	hlist_entry(pid_next(task, type), struct task_struct,	\
+			pids[(type)].node)
 
 
 /* We could use hlist_for_each_entry_rcu here but it takes more arguments
diff -puN kernel/pid.c~pidhash-refactor-the-pid-hash-table-fixes kernel/pid.c
--- 25/kernel/pid.c~pidhash-refactor-the-pid-hash-table-fixes	Fri Mar 10 15:45:36 2006
+++ 25-akpm/kernel/pid.c	Fri Mar 10 15:45:36 2006
@@ -61,12 +61,13 @@ typedef struct pidmap {
 static pidmap_t pidmap_array[PIDMAP_ENTRIES] =
 	 { [ 0 ... PIDMAP_ENTRIES-1 ] = { ATOMIC_INIT(BITS_PER_PAGE), NULL } };
 
-/* Note: disable interrupts while the pidmap_lock is held as an
+/*
+ * Note: disable interrupts while the pidmap_lock is held as an
  * interrupt might come in and do read_lock(&tasklist_lock).
  *
  * If we don't disable interrupts there is a nasty deadlock between
  * detach_pid()->free_pid() and another cpu that does
- * spin_lock(&pidmap_lock) followed by an interrupt routing that does
+ * spin_lock(&pidmap_lock) followed by an interrupt routine that does
  * read_lock(&tasklist_lock);
  *
  * After we clean up the tasklist_lock and know there are no
_