Re: [RFC][PATCH] delay rq_lock acquisition in setscheduler

[Chris Wright]

* Andrea Arcangeli (andrea@xxxxxxxxxx) wrote:
> On Wed, Oct 20, 2004 at 06:32:38PM -0700, Chris Wright wrote:
> > +	rq = task_rq_lock(p, &flags);
> > +	/* recheck policy now with rq lock held */
> > +	retval = -EPERM;
> > +	if (unlikely(oldpolicy != -1 && oldpolicy != p->policy))
> > +		goto out_unlock_rq;
> 
> to be really backwards compatible you should return 0 methinks, the only
> case when this race can trigger is with non deterministic usage, and the
> current kernel would never return -EPERM in such a non deterministic
> usage. However the -EPERM will signal the non deterministic usage, but I
> doubt it worth to return -EPERM there, since it makes it looks like the
> other side that didn't get EPERM is safe while it's not, since the other
> side isn't deterministic either.

true.  another alternative is to drop rq_lock and do the checks over.
i didn't convince myself yet that there's no chance for livelock,
although it seems unlikely.
-
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/