This is the mail archive of the libc-alpha@sourceware.org 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.


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

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

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


Thanks,
Roland


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