[Cbe-oss-dev] [PATCH] spusched: extend list_mutex coverage

Christoph Hellwig hch at lst.de
Wed Jul 23 16:47:05 EST 2008


On Wed, Jul 23, 2008 at 10:48:19AM +1000, Jeremy Kerr wrote:
> Christoph,
> 
> > spu->ctx is only stable while we hold the list_mutex is held.
> 
> We only update spu->ctx with both list_mutex and ctx->state mutex, so 
> I'm a little unclear about how the dangling reference could happen as 
> we hold the victim's state_mutex in find_victim(), and the target 
> context's state_mutex in spusched_tick().

In both cases we take list_mutex check for spu->ctx, the unlock it
<-- race happens here --> then take the state_mutex. 

> > @@ -659,16 +659,15 @@ static struct spu *find_victim(struct sp
> >  				 * restart the search.
> >  				 */
> >  				mutex_unlock(&victim->state_mutex);
> > +				mutex_unlock(&cbe_spu_info[node].list_mutex);
> >  				victim = NULL;
> >  				goto restart;
> >  			}
> 
> This entire if-block should no longer be possible if we hold list_mutex

Indeed.

> > @@ -875,8 +880,13 @@ static noinline void spusched_tick(struc
> >  	struct spu_context *new = NULL;
> >  	struct spu *spu = NULL;
> >
> > -	if (spu_acquire(ctx))
> > -		BUG();	/* a kernel thread never has signals pending */
> > +	/*
> > +	 * If we can't lock the context give it another timeslice.
> > +	 */
> > +	if (!mutex_trylock(&ctx->state_mutex)) {
> > +		ctx->time_slice++;
> 
> No need to increment time_slice, as this will give the context two extra 
> timeslices.

Indeed, this is before we even decrement the time slice.




More information about the cbe-oss-dev mailing list