From patchwork Fri Nov 21 22:28:46 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Roland McGrath X-Patchwork-Id: 3848 Received: (qmail 12088 invoked by alias); 21 Nov 2014 22:28:51 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Delivered-To: mailing list libc-alpha@sourceware.org Received: (qmail 12079 invoked by uid 89); 21 Nov 2014 22:28:51 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL, BAYES_00 autolearn=ham version=3.3.2 X-HELO: topped-with-meat.com MIME-Version: 1.0 From: Roland McGrath To: Joseph Myers , "GNU C. Library" , "H.J. Lu" , Carlos O'Donell Subject: Re: [COMMITTED PATCH] Test that pthread_create diagnoses invalid scheduling parameters. In-Reply-To: Roland McGrath's message of Friday, 21 November 2014 14:10:34 -0800 <20141121221034.757D62C3BED@topped-with-meat.com> References: <20141120013341.AAEF42C3B18@topped-with-meat.com> <20141121221034.757D62C3BED@topped-with-meat.com> Message-Id: <20141121222846.B38BF2C3BED@topped-with-meat.com> Date: Fri, 21 Nov 2014 14:28:46 -0800 (PST) X-CMAE-Score: 0 X-CMAE-Analysis: v=2.1 cv=SvUDtp+0 c=1 sm=1 tr=0 a=WkljmVdYkabdwxfqvArNOQ==:117 a=14OXPxybAAAA:8 a=kj9zAlcOel0A:10 a=hOe2yjtxAAAA:8 a=LJgFByV20WR-qBjNwxEA:9 a=CjuIK1q_8ugA:10 Fixed thusly. This does change things slightly from the status quo ante, but I suspect the old state was not what we really intended to be doing. Previously, ATTR_FLAG_{POLICY,SCHED}_SET would not be set in PD->flags at creation time when IATTR->flags had the bit set (and so PD->schedfoo has value copied from IATTR->schedfoo) but *would* be set when IATTR->flags had the bit clear (and so PD->schedfoo has a value gleaned via the sched_getfoo syscall on the pthread_create caller). Logically that seems backwards at best. Practically, I think the only effect is whether pthread_getschedparam, __pthread_tpp_change_priority, and __pthread_current_priority yield values already cached in the calling thread's struct pthread or refresh that cache by making syscalls (so there is no effect on the second or later repeated call to one of those). Per the comment in pthread_getschedparam, no kosher program could notice the difference. I think the status quo ante was just an oversight. Thanks, Roland 2014-11-21 Roland McGrath * nptl/pthread_create.c (__pthread_create_2_1): Set ATTR_FLAG_POLICY_SET and/or ATTR_FLAG_SCHED_SET in PD->flags when copying values from IATTR into PD. --- a/nptl/pthread_create.c +++ b/nptl/pthread_create.c @@ -596,10 +596,16 @@ __pthread_create_2_1 (newthread, attr, start_routine, arg) { /* Use the scheduling parameters the user provided. */ if (iattr->flags & ATTR_FLAG_POLICY_SET) - pd->schedpolicy = iattr->schedpolicy; + { + pd->schedpolicy = iattr->schedpolicy; + pd->flags |= ATTR_FLAG_POLICY_SET; + } if (iattr->flags & ATTR_FLAG_SCHED_SET) - /* The values were validated in pthread_attr_setschedparam. */ - pd->schedparam = iattr->schedparam; + { + /* The values were validated in pthread_attr_setschedparam. */ + pd->schedparam = iattr->schedparam; + pd->flags |= ATTR_FLAG_SCHED_SET; + } if ((pd->flags & (ATTR_FLAG_SCHED_SET | ATTR_FLAG_POLICY_SET)) != (ATTR_FLAG_SCHED_SET | ATTR_FLAG_POLICY_SET))