This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH roland/nptl] NPTL: Don't (re)validate sched_priority in pthread_create.
- From: Roland McGrath <roland at hack dot frob dot com>
- To: "Carlos O'Donell" <carlos at redhat dot com>
- Cc: "GNU C. Library" <libc-alpha at sourceware dot org>
- Date: Wed, 19 Nov 2014 17:24:34 -0800 (PST)
- Subject: Re: [PATCH roland/nptl] NPTL: Don't (re)validate sched_priority in pthread_create.
- Authentication-results: sourceware.org; auth=none
- References: <20141118205213 dot 90CF92C3B21 at topped-with-meat dot com> <546C19D4 dot 6060409 at redhat dot com>
> 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.