[PATCH roland/nptl] NPTL: Don't (re)validate sched_priority in pthread_create.

[Carlos O'Donell]

On 11/18/2014 03:52 PM, Roland McGrath wrote:
> Now that pthread_attr_setschedparam validates the value, it should no
> longer be possible to see an invalid value in pthread_create.  I've
> verified that in Linux the min/max values depend only on the policy
> selection and not on any dynamic factors that might have changed between
> pthread_attr_setschedparam and pthread_create.
> 
> The one wrinkle is if the user called pthread_attr_setschedparam before
> pthread_attr_setschedpolicy and the sched_priority value was valid for the
> old policy but invalid for the new one.  POSIX does not seem to provide for
> pthread_attr_setschedpolicy being able to return an error in this case, or
> for it to do something else like reset the sched_param bits to defaults on
> pthread_attr_setschedpolicy if the old bits don't make sense for the new
> policy.  So in this situation, pthread_create failing with EINVAL appears
> to be the best we can do--and that's what we do now.  But removing this
> check in pthread_create doesn't change that behavior observably: the thread
> will be started up and then create_thread will cancel it when the
> sched_setscheduler syscall fails, propagating the error code (presumably
> still EINVAL) back to pthread_create.  So this user misuse of the API is
> detected with significantly more overhead, but I don't think that matters.
> 
> Tested x86_64-linux-gnu.
> 
> If nobody objects soon, I'll commit this.
 
Failure is certainly not what we want to optimize, and removing this
code is certain to make pthread_create faster, and I agree that EINVAL
is the best we can do here.

What would like to know is: Have you tested the failure mode?
If you haven't, please do, and if it works sanely, then LGTM.

What is the impetus behind this change?

Cheers,
Carlos.