Re: [PATCH] AB-BA deadlock between uidhash_lock and tasklist_lock.

[Andrew Morton]

Jesper Juhl <juhl-lkml@xxxxxx> wrote:
>
> On Thu, 23 Dec 2004, Andrew Morton wrote:
> 
> > +/*
> > + * uidhash_lock is taken inside write_lock_irq(&tasklist_lock).  If a timer
> > + * interrupt were to occur while we hold uidhash_lock, and that interrupt takes
> > + * read_lock(&tasklist_lock) then we have an ab/ba deadlock scenario.  Hence
> > + * uidhash_lock must always be taken in an ir-qsafe manner to hold off the
> > + * timer interrupt.
> > + */
> 

hrm.  Why don't we just do this?

--- 25/kernel/exit.c~a	Thu Dec 23 15:29:57 2004
+++ 25-akpm/kernel/exit.c	Thu Dec 23 15:30:04 2004
@@ -242,9 +242,8 @@ void reparent_to_init(void)
 	memcpy(current->signal->rlim, init_task.signal->rlim,
 	       sizeof(current->signal->rlim));
 	atomic_inc(&(INIT_USER->__count));
-	switch_uid(INIT_USER);
-
 	write_unlock_irq(&tasklist_lock);
+	switch_uid(INIT_USER);
 }
 
 void __set_special_pids(pid_t session, pid_t pgrp)
_

I see no reason why switch_uid() needs tasklist_lock.  set_user() doesn't
hold it?

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/