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

[Andrea Arcangeli]

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.
-
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/