This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

On 11/19/2014 08:24 PM, Roland McGrath wrote:
>> 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.
> I've written up a test for the expected EINVAL diagnosis.  It depends
> on constructing a pthread_attr_t with invalid scheduling parameters,
> which AFAIK is possible only by using pthread_attr_setschedparam while
> the pthread_attr_t is set to one scheduling policy where a given
> struct sched_param is valid and then using pthread_attr_setschedpolicy
> to switch it to a policy where those values are invalid.  This
> requires some assumptions about the policies and their parameters, but
> those are predictable enough at least for Linux.

Should this even be possible?

> I'll (post and) put the new test in first, then verify this change
> doesn't regress it and commit.

Awesome, I couldn't ask for anything more.

>> What is the impetus behind this change?
> As I've been doing for some time now, I'm moving errant unconditional
> Linuxisms (such as direct INTERNAL_SYSCALL use) out of NPTL code.
> Mostly I'm just refactoring things to have Linuxisms in appropriate
> sysdeps files, but I'm not doing that blindly.  This was a case where
> what the Linuxism was doing didn't seem worth keeping.

Makes perfect sense.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]