Re: [RFC 12/12][PATCH] SCHED_DEADLINE: modified sched_*_ex API

[Peter Zijlstra]

On Fri, 2009-10-16 at 17:48 +0200, Raistlin wrote:
> This commit amends the new API introduced to deal with the new sched_param_ex
> scheduling parameter data structure.
> 
> What we add is one more parameter to all the functions, containing the size of
> sched_param_ex. It might turn out useful in possible future extensions of
> sched_param_ex itself, to avoid issue with ABI of legacy applications.
> 
> Signed-off-by: Raistlin <raistlin@xxxxxxxx>

> @@ -6807,9 +6811,10 @@ out_unlock:
>  /**
>   * sys_sched_getparam - get the DEADLINE task parameters of a thread
>   * @pid: the pid in question.
> + * @len: size of data pointed by param_ex.
>   * @param_ex: structure containing the new parameters (deadline, runtime, etc.).
>   */
> -SYSCALL_DEFINE2(sched_getparam_ex, pid_t, pid,
> +SYSCALL_DEFINE3(sched_getparam_ex, pid_t, pid, unsigned, len,
>  		struct sched_param_ex __user *, param_ex)
>  {
>  	struct sched_param_ex lp;
> @@ -6818,6 +6823,8 @@ SYSCALL_DEFINE2(sched_getparam_ex, pid_t, pid,
>  
>  	if (!param_ex || pid < 0)
>  		return -EINVAL;
> +	if (len < sizeof(struct sched_param_ex))
> +		return -EINVAL;
>  
>  	read_lock(&tasklist_lock);
>  	p = find_process_by_pid(pid);
> @@ -6837,7 +6844,7 @@ SYSCALL_DEFINE2(sched_getparam_ex, pid_t, pid,
>  	/*
>  	 * This one might sleep, we cannot do it with a spinlock held ...
>  	 */
> -	retval = copy_to_user(param_ex, &lp, sizeof(*param_ex)) ? -EFAULT : 0;
> +	retval = copy_to_user(param_ex, &lp, len) ? -EFAULT : 0;
>  
>  	return retval;
>  

I think this doesn't even do what it claims to do, namely provide a
flexible ABI, since you fail the operation when there is not enough room
provided. Hence, when we grow the struct an older program that was
compiled against the smaller one will become an insta-fail.

What this should do is deal with smaller structs by ensuring the tail is
0 and simply copying out the head.

New bits in the flags field are also an interesting challenge.

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