libthr patch

[Tim Robbins]

On Fri, Feb 20, 2004 at 10:38:30AM +0300, Mike Makonnen wrote:

> On Fri, Feb 20, 2004 at 12:47:33AM +1100, Tim Robbins wrote:
> > On Thu, Feb 19, 2004 at 09:28:50AM +0300, Mike Makonnen wrote:
> > 
> > Make sure you fix thr_wake() to check that uap->id is valid before you
> > commit this patch. Something like this would be safer but slower:
> 
> Hmm, you're right. I should've thought of that. Thanks for catching it.
> 
> > 
> > 	struct thread *td1;
> > 
> > 	PROC_LOCK(td->td_proc);
> > 	FOREACH_THREAD_IN_PROC(td->td_proc, td1)
> > 		if (td1 == (struct thread *)uap->id)
> > 			break;
> > 	if (td1 == NULL) {
> > 		PROC_UNLOCK(td->td_proc);
> > 		return (ESRCH);
> > 	}
> > 	td1->td_lthrflags |= LTF_THRWAKEUP;
> > 	wakeup_one(td1);
> > 	PROC_UNLOCK(td->td_proc);
> > 	return (0);
> > 
> > (I'm not sure that it's safe to call wakeup_one() on a thread pointer
> > that isn't curthread without holding the proc lock, so I changed that too.)
> 
> Sorry, I don't follow. How can a thread call wakeup_one() on itself (if it's
> supposed to be asleep)?
> 
> A cursory look through the call path doesn't show anything that needs a
> proc lock. There is access to p->p_state but either sched_lock or proc lock
> is sufficient for that (and the accessing function does hold sched_lock).

What I mean is: I don't know whether you can be sure that the thread hasn't
already been freed between the time unlock the proc and when you call
wakeup_one(). I assumed the list of threads associated with a process was
protected by the proc lock.


Tim