NetBSD Problem Report #53495
From wiz@yt.nih.at Thu Aug 2 21:36:18 2018
Return-Path: <wiz@yt.nih.at>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
by mollari.NetBSD.org (Postfix) with ESMTPS id 0974E7A167
for <gnats-bugs@gnats.NetBSD.org>; Thu, 2 Aug 2018 21:36:18 +0000 (UTC)
Message-Id: <20180802213550.3008D2AC0E7@yt.nih.at>
Date: Thu, 2 Aug 2018 23:35:50 +0200 (CEST)
From: Thomas Klausner <wiz@NetBSD.org>
Reply-To: Thomas Klausner <wiz@NetBSD.org>
To: gnats-bugs@NetBSD.org
Subject: sched_get_priority_max/sched_get_priority_min not returning useful values
X-Send-Pr-Version: 3.95
>Number: 53495
>Category: lib
>Synopsis: sched_get_priority_max/sched_get_priority_min not returning useful values
>Confidential: no
>Severity: serious
>Priority: low
>Responsible: lib-bug-people
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Thu Aug 02 21:40:00 +0000 2018
>Last-Modified: Thu Aug 16 08:25:01 +0000 2018
>Originator: Thomas Klausner
>Release: NetBSD 8.99.22
>Organization:
Curiosity is the very basis of education and if you tell me that
curiosity killed the cat, I say only that the cat died nobly.
- Arnold Edinborough
>Environment:
Architecture: x86_64
Machine: amd64
>Description:
The man page describes the functions as follows:
sched_get_priority_max(policy)
Returns the maximal priority which may be used for the
scheduling policy specified by policy.
sched_get_priority_min(policy)
Returns the minimal priority which may be used for the
scheduling policy specified by policy.
and later:
sched_get_priority_max() and sched_get_priority_min() return the
maximal/minimal priority value on success. Otherwise, -1 is returned and
errno is set to indicate the error.
So programs check for "-1" to detect errors.
However, in NetBSD, -1 is also returned in other cases, see
/usr/src/lib/libc/sys/sched.c:
int
sched_get_priority_min(int policy)
{
switch (policy) {
case SCHED_OTHER:
return PRI_NONE;
case SCHED_RR:
case SCHED_FIFO:
return (int)sysconf(_SC_SCHED_PRI_MIN);
default:
errno = EINVAL;
return -1;
}
}
and
/usr/include/sys/param.h:#define PRI_NONE (-1)
I'm not sure what the correct fix is. I suggest returning 0 instead of -1;
I don't know what the definition of PRI_NONE is supposed to be and if that
should be changed, or if the return value should just be zero for both
functions and not use PRI_NONE.
>How-To-Repeat:
#include <sched.h>
int main() {
printf("%d-%d\n", sched_get_priority_max(0), sched_get_priority_min(0));
}
gives:
-1--1
Worse, wxGTK30 pops up unnecessary error messages at runtime.
>Fix:
Return 0, and/or redefine PRI_NONE.
>Audit-Trail:
From: Kamil Rytarowski <n54@gmx.com>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: lib/53495: sched_get_priority_max/sched_get_priority_min not
returning useful values
Date: Fri, 3 Aug 2018 03:51:30 +0200
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--7wkq1Z49HiEpb7JPjpaGGal6r1brtfhzd
Content-Type: multipart/mixed; boundary="tiwuuZY8nB3YFgWVuGrDuw6DMCE9AkLs5";
protected-headers="v1"
From: Kamil Rytarowski <n54@gmx.com>
To: gnats-bugs@NetBSD.org
Message-ID: <b103caed-06e4-5267-315b-5a2504955dc8@gmx.com>
Subject: Re: lib/53495: sched_get_priority_max/sched_get_priority_min not
returning useful values
References: <pr-lib-53495@gnats.netbsd.org>
<20180802213550.3008D2AC0E7@yt.nih.at>
<20180802214000.8D1F77A14F@mollari.NetBSD.org>
In-Reply-To: <20180802214000.8D1F77A14F@mollari.NetBSD.org>
--tiwuuZY8nB3YFgWVuGrDuw6DMCE9AkLs5
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
This is not a bug. It works as intended.
NetBSD behavior is compliant with POSIX and 3rd party program has to be
fixed and handle the -1 case on its own, if there is need to distinguish
error and unsupported, there is an option to reset errno and check it
after the call.
On 02.08.2018 23:40, Thomas Klausner wrote:
>> Number: 53495
>> Category: lib
>> Synopsis: sched_get_priority_max/sched_get_priority_min not retu=
rning useful values
>> Confidential: no
>> Severity: serious
>> Priority: low
>> Responsible: lib-bug-people
>> State: open
>> Class: sw-bug
>> Submitter-Id: net
>> Arrival-Date: Thu Aug 02 21:40:00 +0000 2018
>> Originator: Thomas Klausner
>> Release: NetBSD 8.99.22
>> Organization:
> Curiosity is the very basis of education and if you tell me that=20
> curiosity killed the cat, I say only that the cat died nobly.
> - Arnold Edinborough
>> Environment:
> =09
> =09
> Architecture: x86_64
> Machine: amd64
>> Description:
> The man page describes the functions as follows:
>=20
> sched_get_priority_max(policy)
> Returns the maximal priority which may be used for the
> scheduling policy specified by policy.
>=20
> sched_get_priority_min(policy)
> Returns the minimal priority which may be used for the
> scheduling policy specified by policy.
>=20
> and later:
>=20
> sched_get_priority_max() and sched_get_priority_min() return the
> maximal/minimal priority value on success. Otherwise, -1 is retur=
ned and
> errno is set to indicate the error.
>=20
> So programs check for "-1" to detect errors.
>=20
> However, in NetBSD, -1 is also returned in other cases, see
> /usr/src/lib/libc/sys/sched.c:
>=20
> int
> sched_get_priority_min(int policy)
> {
>=20
> switch (policy) {
> case SCHED_OTHER:
> return PRI_NONE;
> case SCHED_RR:
> case SCHED_FIFO:
> return (int)sysconf(_SC_SCHED_PRI_MIN);
> default:
> errno =3D EINVAL;
> return -1;
> }
> }
>=20
>=20
> and
>=20
> /usr/include/sys/param.h:#define PRI_NONE (-1)
>=20
> I'm not sure what the correct fix is. I suggest returning 0 instead of =
-1;
> I don't know what the definition of PRI_NONE is supposed to be and if t=
hat
> should be changed, or if the return value should just be zero for both
> functions and not use PRI_NONE.
>=20
>> How-To-Repeat:
>=20
> #include <sched.h>
> int main() {
> printf("%d-%d\n", sched_get_priority_max(0), sched_get_priority_min(0))=
;
> }
>=20
> gives:
>=20
> -1--1
>=20
>=20
> Worse, wxGTK30 pops up unnecessary error messages at runtime.
>=20
>> Fix:
> Return 0, and/or redefine PRI_NONE.
>=20
>> Unformatted:
> =09
> =09
>=20
--tiwuuZY8nB3YFgWVuGrDuw6DMCE9AkLs5--
--7wkq1Z49HiEpb7JPjpaGGal6r1brtfhzd
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
iQJABAEBCAAqFiEELaxVpweEzw+lMDwuS7MI6bAudmwFAltjtSIMHG41NEBnbXgu
Y29tAAoJEEuzCOmwLnZslF8P/3Q0Vbv8GjJshCmsiRfWjsefvz/bLal4qIReXsz/
qa+ERQRrvBHYUndmiHz7UoAsFzpflr3nUJ1L0FD5fdWwNPfzqBhzqbAuYUTns4XZ
WJwDt8LLFgxsKOSlDmC7EORD5+HSz0pne2pFoFUKc8ISRqZ/19ZZbUL0VpQHldUb
jfWdHvgoNTdNIpXNeIwekcLEoQpjRd53jNnu0WANXA0XOroEAdBVJ1Mj2IiFeoJu
BGyq1RZCQlcFTn7Zi/34Y8dIt2jwc8f0T38564226kBwyuGutUWOqUbyPAnrzHVy
pF3MAqvklqPY//EAASiBhWrFEyZPZWuKFty+iulVlWUXlFFFSlTz34HlNvkB6BXF
1vytwXuGs2gJ7rYZJU1HC/mbHd6dInsL+77Z3wWZ1uPzNlzA+gE1Ak8hwYQ9EZlE
GUo80XvlASzMbn8bRRdUs19Upnpwltpla5XSagML3YZY1e8LcogETWOHZmLczpZe
9yuxE/Lo19FbgIuh6MZQV2Ptt+DNabmFrZThBkJ8+kB81WuNSt7DJxblTaYDrslK
MqJ+Wkv047ytT8Q8mfa0djCdhpE61/dbob9uLscab+xey948qCWE3R28Ab6DTI8K
9tTUhKa5YyVGr5ldRGr3jNp44I7pVFZ99CjbCJFuV89m6gJL+W+kKnS2pT0SWUpU
Xlxf
=PpAf
-----END PGP SIGNATURE-----
--7wkq1Z49HiEpb7JPjpaGGal6r1brtfhzd--
From: matthew green <mrg@eterna.com.au>
To: gnats-bugs@NetBSD.org
Cc: lib-bug-people@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org, Thomas Klausner <wiz@NetBSD.org>
Subject: re: lib/53495: sched_get_priority_max/sched_get_priority_min not returning useful values
Date: Fri, 03 Aug 2018 17:07:24 +1000
> This is not a bug. It works as intended.
>
> NetBSD behavior is compliant with POSIX and 3rd party program has to be
> fixed and handle the -1 case on its own, if there is need to distinguish
> error and unsupported, there is an option to reset errno and check it
> after the call.
this makes no sense to me. opengroup says:
If unsuccessful, they shall return a value of -1 and set errno
to indicate the error.
so "-1" can not be a useful value by definition. clearly our
implementation needs to map between internal values and ones
we return to these functions if "-1" is interanlly useful.
it's also extremely awful to introduce more APIs that abuse errno
like you suggest, and should not be done any time.
.mrg.
From: Kamil Rytarowski <n54@gmx.com>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: lib/53495: sched_get_priority_max/sched_get_priority_min not
returning useful values
Date: Fri, 3 Aug 2018 15:02:17 +0200
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--9YcmKHhE1o9XtOpZRZPeYiiHk59BIXaCx
Content-Type: multipart/mixed; boundary="RsaY29tubPQ1RDJLEhMFZjvjeIX2RK5Wu";
protected-headers="v1"
From: Kamil Rytarowski <n54@gmx.com>
To: gnats-bugs@NetBSD.org
Message-ID: <71bf3c01-8975-8828-08ce-6636199d9f7a@gmx.com>
Subject: Re: lib/53495: sched_get_priority_max/sched_get_priority_min not
returning useful values
References: <12733.1533280044@splode.eterna.com.au>
In-Reply-To: <12733.1533280044@splode.eterna.com.au>
--RsaY29tubPQ1RDJLEhMFZjvjeIX2RK5Wu
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
On 03.08.2018 09:07, matthew green wrote:
>> This is not a bug. It works as intended.
>> =20
>> NetBSD behavior is compliant with POSIX and 3rd party program has to =
be
>> fixed and handle the -1 case on its own, if there is need to distingu=
ish
>> error and unsupported, there is an option to reset errno and check it=
>> after the call.
>=20
> this makes no sense to me. opengroup says:
>=20
> If unsuccessful, they shall return a value of -1 and set errno
> to indicate the error.
>=20
> so "-1" can not be a useful value by definition. clearly our
> implementation needs to map between internal values and ones
> we return to these functions if "-1" is interanlly useful.
>=20
> it's also extremely awful to introduce more APIs that abuse errno
> like you suggest, and should not be done any time.
>=20
>=20
> .mrg.
>=20
I'm referring to a line documented from different pages:
If the current scheduling policy for the target process is not
SCHED_FIFO, SCHED_RR, [SS] [Option Start] or SCHED_SPORADIC, [Option
End] the result is implementation-defined; this case includes the
SCHED_OTHER policy.
http://pubs.opengroup.org/onlinepubs/9699919799/functions/sched_setparam.=
html#
For SCHED_OTHER, the affected scheduling parameters are
implementation-defined.
http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_setsche=
dparam.html
And some other places with similar wording.
Additionally:
For threads executing under this policy, the implementation shall use
only priorities within the range returned by the
sched_get_priority_max() and sched_get_priority_min() functions when
SCHED_OTHER is provided as the parameter.
http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#=
tag_15_08_04_05
-1 indicated that no priority policy (or PRI_NONE one as an
implementation specific type of NetBSD) can be used with SCHED_OTHER.
PRI_NONE is not technically an error, so not errno set - but the result
is the same as it cannot be changed.
--RsaY29tubPQ1RDJLEhMFZjvjeIX2RK5Wu--
--9YcmKHhE1o9XtOpZRZPeYiiHk59BIXaCx
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
iQJABAEBCAAqFiEELaxVpweEzw+lMDwuS7MI6bAudmwFAltkUlkMHG41NEBnbXgu
Y29tAAoJEEuzCOmwLnZskO8QALSYVqrDi/ND1QuUb14HrVJErUq+LC6KPOMsiljf
c7wVSH+rnB0+eXIhw2bY96UYGHGFnPdDkUymSJ11r1a5brkVXmAH4Bnujw+yIpE9
GGpAEV713vbT4LHCHQ05GvHypl6DYK80FibjO2PT5ST0wPzPAiji6dl0wikPbDwH
evHLhoxoio1c/sJyKMaQ/8t7ycu68yhXw528F5nGjocoxNRGJO1fRm0hLFxOAdZN
QUGiOmiGaH5Pokfsu+/+tog4AS0JQ/eFsEbJ1VrncFLJMKDqeFmLgeCApyJMMS+J
3+ntcw+21dfmqv6p9xhOYR6Hwa0Ni2U+UI/RsMAUzezR7cEacRo00lhS4n2WsGq4
wOATJKEXKy5vtWH0jSaJA5LV6x++68GhVg7X6L1g1950K9oTVRKFS1+24q4yUywV
Rf9Y0AgbECKaX052sywipTwb0Yi/E4NWqWg3tQ168bBxjojh2fFsdz0UXLZ7aymJ
pc8HZ3Em7KrrKiw2F4DeuEuo8EcW4hyNAM82QlVKjfxt5hpzTHyAOIs5jmmudYUf
DZg1Mvx3cWJZom1AcNreKACLzzmJg8WyeDb9lZP2GTDMOWV6UPMJ+dlxnFyD8RjY
jL21Z/dnV2r6f8r+UnoTwJ1Yf2IZn0DhYfxNg823snLHruqLWOoeEKxZtd6ibtbC
pOs/
=rUrR
-----END PGP SIGNATURE-----
--9YcmKHhE1o9XtOpZRZPeYiiHk59BIXaCx--
From: Kamil Rytarowski <n54@gmx.com>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: lib/53495: sched_get_priority_max/sched_get_priority_min not
returning useful values
Date: Fri, 3 Aug 2018 15:18:40 +0200
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--ibdZQT2m5JkcugrGH6aF6tg5Bct1G1Otc
Content-Type: multipart/mixed; boundary="eovONmXsGAD9VV3gbLdacQBnYSUE5VL5Q";
protected-headers="v1"
From: Kamil Rytarowski <n54@gmx.com>
To: gnats-bugs@NetBSD.org
Message-ID: <f7079230-b284-ad03-76e2-0d4749689f4b@gmx.com>
Subject: Re: lib/53495: sched_get_priority_max/sched_get_priority_min not
returning useful values
References: <12733.1533280044@splode.eterna.com.au>
<71bf3c01-8975-8828-08ce-6636199d9f7a@gmx.com>
In-Reply-To: <71bf3c01-8975-8828-08ce-6636199d9f7a@gmx.com>
--eovONmXsGAD9VV3gbLdacQBnYSUE5VL5Q
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
On 03.08.2018 15:02, Kamil Rytarowski wrote:
> On 03.08.2018 09:07, matthew green wrote:
>>> This is not a bug. It works as intended.
>>> =20
>>> NetBSD behavior is compliant with POSIX and 3rd party program has to=
be
>>> fixed and handle the -1 case on its own, if there is need to disting=
uish
>>> error and unsupported, there is an option to reset errno and check i=
t
>>> after the call.
>>
>> this makes no sense to me. opengroup says:
>>
>> If unsuccessful, they shall return a value of -1 and set errno
>> to indicate the error.
>>
>> so "-1" can not be a useful value by definition. clearly our
>> implementation needs to map between internal values and ones
>> we return to these functions if "-1" is interanlly useful.
>>
>> it's also extremely awful to introduce more APIs that abuse errno
>> like you suggest, and should not be done any time.
>>
>>
>> .mrg.
>>
>=20
> I'm referring to a line documented from different pages:
>=20
> If the current scheduling policy for the target process is not
> SCHED_FIFO, SCHED_RR, [SS] [Option Start] or SCHED_SPORADIC, [Option
> End] the result is implementation-defined; this case includes the
> SCHED_OTHER policy.
>=20
> http://pubs.opengroup.org/onlinepubs/9699919799/functions/sched_setpara=
m.html#
>=20
> For SCHED_OTHER, the affected scheduling parameters are
> implementation-defined.
>=20
> http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_setsc=
hedparam.html
>=20
> And some other places with similar wording.
>=20
> Additionally:
>=20
>=20
> For threads executing under this policy, the implementation shall use
> only priorities within the range returned by the
> sched_get_priority_max() and sched_get_priority_min() functions when
> SCHED_OTHER is provided as the parameter.
>=20
> http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.htm=
l#tag_15_08_04_05
>=20
> -1 indicated that no priority policy (or PRI_NONE one as an
> implementation specific type of NetBSD) can be used with SCHED_OTHER.
>=20
> PRI_NONE is not technically an error, so not errno set - but the result=
> is the same as it cannot be changed.
>=20
According to my understanding the proper fix to the Thomas' code is to
check type of scheduling policy, if it is SCHED_OTHER - bail out from
other operations (unless setting a new one other than SCHED_OTHER).
--eovONmXsGAD9VV3gbLdacQBnYSUE5VL5Q--
--ibdZQT2m5JkcugrGH6aF6tg5Bct1G1Otc
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
iQJABAEBCAAqFiEELaxVpweEzw+lMDwuS7MI6bAudmwFAltkVjAMHG41NEBnbXgu
Y29tAAoJEEuzCOmwLnZsUHsP/R9twHCEXoiMxHE05kJ3v5LqT7LcsGPqtoGJe6DI
AZZDqfp59CAeyHJ7xQFopA2n87qViuPoEfGGXruNVqHD8H3Hsv49pQ7r2D1usuMB
t/6uCZMTwIPIu5/zTZ8ikbiBTdgTLHLvCQW67SjYcL8qnBN9F6+BQABV/9SM2dpm
yoJV1nPC67KjQnf3W6UF6LzcoRQAaIcnAzaW5VunOTeVo5UtRbO25A9Z6ZovywtP
+50VQOa7PJ0pS0Jl1q35NljD1WLFSVYyNjLLAm35P++9fReIec1NX1Fdl/qY1RUA
mj1pqcLvPN+XRH4aBa306dHu0LFsCl+bYNUZG/TxgZOSwoSRWWOYnm7T0UdrIgO4
Sm/q2VeFuPrHPSvXOHOwFlce8bV1ib/0CkxlGudJXZtnR06M8LLaMWCLgQUdciEL
5yABxx+JmyXqq2/dYFBwcTZfS4OEF7+ZKkqniaCxnJrKFOHvK3W0ux3IE8H0Ny5W
Ir74PyUR1/P77tfyLfFD9tmdjBCptjhQYd0S1MtMOLeBwJN2G8LR9NDqT0+fFHAb
XeVBfuwRQFNqKXZKsUKDF/Z89L1blvuk69bjzX5vYk6zEmZfsvAL113Gd1lEUq5P
DtDtTX2NGXYP0wTkq9c7jE1PgLK3tjVxs7REb98Unbm+++TtRFM/5Igcw/YWpOnL
ZtQK
=EAQc
-----END PGP SIGNATURE-----
--ibdZQT2m5JkcugrGH6aF6tg5Bct1G1Otc--
From: Robert Elz <kre@munnari.OZ.AU>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: lib/53495: sched_get_priority_max/sched_get_priority_min not returning useful values
Date: Fri, 03 Aug 2018 21:54:03 +0700
Date: Fri, 3 Aug 2018 13:20:01 +0000 (UTC)
From: Kamil Rytarowski <n54@gmx.com>
Message-ID: <20180803132001.28AE77A1F9@mollari.NetBSD.org>
| According to my understanding the proper fix to the Thomas' code is to
| check type of scheduling policy, if it is SCHED_OTHER - bail out from
| other operations (unless setting a new one other than SCHED_OTHER).
I know even less about the realtime stuff than some of the other things I
comment about, but this does not seem to line up with some of the other
test you quoted. In particular ...
For threads executing under this policy, the implementation shall use
only priorities within the range returned by the
sched_get_priority_max() and sched_get_priority_min() functions when
SCHED_OTHER is provided as the parameter.
which indicates, to me, that sched_get_priority_max() (and min) are required
to return sane results when passed SCHED_OTHER as a parameter.
Then it should be possible to use a value in the range [min,max] as the
sched parameter (which will be -1, of course, here .. aka PRIO_NONE)
and everything should work.
Whether -1 is a sane valid result I am not sure. The standard does not
say it cannot be.
In this regard ...
mrg@eterna.com.au said:
| it's also extremely awful to introduce more APIs that abuse errno like you
| suggest, and should not be done any time.
The API is not being introduced here, it is in POSIX, and so came from
somewhere else.
When whoever created it did so, I assume they assumed that legitimate
priority results returned would all be >= 0, so that -1 as an error made sense.
Whether POSIX restricts priority values to be >= 0 or not I have no idea,
but I would not be surprised if not, to be more compatible with the ancient
nice() API (though with the sign reversed). That is, they may allow
implementations to support priority values that are < 0, and if so, getting
a (non-error) -1 result from these functions is entirely possible.
And there is nothing we can do about it.
All that said, if PRIO_NONE is not already deeply ingrained as -1, it would
not hurt to change it to be some other value, and make life easier (perhaps -2)
kre
From: Kamil Rytarowski <n54@gmx.com>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: lib/53495: sched_get_priority_max/sched_get_priority_min not
returning useful values
Date: Fri, 3 Aug 2018 18:14:44 +0200
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--IDt3wyhaIzaLB3FYNH0UP8jSph530VhKq
Content-Type: multipart/mixed; boundary="h3HzcMaLZrklShAiHpG0YC7mlgCGCMUQ7";
protected-headers="v1"
From: Kamil Rytarowski <n54@gmx.com>
To: gnats-bugs@NetBSD.org
Message-ID: <f302210b-9ee6-428a-8dd2-e36db9ad395b@gmx.com>
Subject: Re: lib/53495: sched_get_priority_max/sched_get_priority_min not
returning useful values
References: <pr-lib-53495@gnats.netbsd.org>
<20180802213550.3008D2AC0E7@yt.nih.at>
<20180803145501.A148F7A1F7@mollari.NetBSD.org>
In-Reply-To: <20180803145501.A148F7A1F7@mollari.NetBSD.org>
--h3HzcMaLZrklShAiHpG0YC7mlgCGCMUQ7
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
On 03.08.2018 16:55, Robert Elz wrote:
> The following reply was made to PR lib/53495; it has been noted by GNAT=
S.
>=20
> From: Robert Elz <kre@munnari.OZ.AU>
> To: gnats-bugs@NetBSD.org
> Cc:=20
> Subject: Re: lib/53495: sched_get_priority_max/sched_get_priority_min n=
ot returning useful values
> Date: Fri, 03 Aug 2018 21:54:03 +0700
>=20
> Date: Fri, 3 Aug 2018 13:20:01 +0000 (UTC)
> From: Kamil Rytarowski <n54@gmx.com>
> Message-ID: <20180803132001.28AE77A1F9@mollari.NetBSD.org>
> =20
> | According to my understanding the proper fix to the Thomas' code =
is to
> | check type of scheduling policy, if it is SCHED_OTHER - bail out =
from
> | other operations (unless setting a new one other than SCHED_OTHER=
).
> =20
> I know even less about the realtime stuff than some of the other thing=
s I
> comment about, but this does not seem to line up with some of the othe=
r
> test you quoted. In particular ...
> =20
> For threads executing under this policy, the implementation shall us=
e
> only priorities within the range returned by the
> sched_get_priority_max() and sched_get_priority_min() functions when=
> SCHED_OTHER is provided as the parameter.
> =20
> which indicates, to me, that sched_get_priority_max() (and min) are re=
quired
> to return sane results when passed SCHED_OTHER as a parameter.
> =20
> Then it should be possible to use a value in the range [min,max] as th=
e
> sched parameter (which will be -1, of course, here .. aka PRIO_NONE)
> and everything should work.
> =20
> Whether -1 is a sane valid result I am not sure. The standard does n=
ot
> say it cannot be.
> =20
We are returning -1 (PRI_NONE) as the returned value has to be a valid
parameter passed to a routine changing scheduling policy with a
requested priority level.
"The value of the sched_priority member in the sched_param structure
shall be any integer within the inclusive priority range for the
scheduling policy specified by policy."
http://pubs.opengroup.org/onlinepubs/9699919799/functions/sched_setschedu=
ler.html#
-1 is already a valid value documented for a related function
getpriority() and a user is encouraged to reset errno before the call.
These features are different, however designed for a similar purpose.
> In this regard ...
> =20
> mrg@eterna.com.au said:
> | it's also extremely awful to introduce more APIs that abuse errno =
like you
> | suggest, and should not be done any time.=20
> =20
> The API is not being introduced here, it is in POSIX, and so came from=
> somewhere else.
> =20
> When whoever created it did so, I assume they assumed that legitimate
> priority results returned would all be >=3D 0, so that -1 as an error =
made sense.
> =20
> Whether POSIX restricts priority values to be >=3D 0 or not I have no =
idea,
> but I would not be surprised if not, to be more compatible with the an=
cient
> nice() API (though with the sign reversed). That is, they may allow
> implementations to support priority values that are < 0, and if so, ge=
tting
> a (non-error) -1 result from these functions is entirely possible.
> =20
As noted above, this is true.
> And there is nothing we can do about it.
> =20
> All that said, if PRIO_NONE is not already deeply ingrained as -1, it =
would
> not hurt to change it to be some other value, and make life easier (pe=
rhaps -2)
> =20
We are already hardcoding -1 through the PRI_NONE symbol into existing
executables. I don't think it's worth to change it. It's not a bug in
the value.
SCHED_OTHER has to be treated as an implementation specific priority
level. We are requested to just ship it without being fully defined.
A portable code shall not make any assumptions about it, except those
specified.
Linux has a different implementation and people treat is similarly to
SCHED_RR, without testing on all modern OSes. There is a small number of
programs that need adjusting (I've encountered like up to 5 of them).
> kre
> =20
>=20
--h3HzcMaLZrklShAiHpG0YC7mlgCGCMUQ7--
--IDt3wyhaIzaLB3FYNH0UP8jSph530VhKq
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
iQJABAEBCAAqFiEELaxVpweEzw+lMDwuS7MI6bAudmwFAltkf3QMHG41NEBnbXgu
Y29tAAoJEEuzCOmwLnZsfCcP/RAqnQ2Kan66zzyvDHT7OyE9+td1jJSjUzfybJvQ
qj2F+Pgebb5eEVT2uvVv2GQJbKZXmISmhGFACuSCqGlRMLpOrBORft3NLV+1O4es
+Szm3CP5i0eVPy1qlXGsGY7m0qRKc0EX9LmTJ0xzU9cMHtveuv9xW1qv0nXf+bC4
4bOxdg1t1wqtme1ZV9IYH+odCmmfTnA/xEXVWv080xKRNm3nSz6gGr93END0EPD7
pAeZuti1bLNlbF9q4w8KA+RqL/XtoDOwF0u+j12DCtbefPCu0seugRAqXrKcyA/A
N89GdAj/FuuZaDtUhD0p+YkvvZzuUD8do9HzInFu+xlbMzSDlDnFIu/DhVcDMGT/
uFm+LceomlOqQiLzQgShQZocPZrc9Yx1co3lk0Kh2QNWBgAN69ZHjpbA4XgTnRuf
49kRHfiqa46TTgswuhh7c86+hlNB/kZqNwgO1NMovOWx81hRgUSqkR1GrveFvgz2
wmrcuEXKLXyEU5amKmL/WlgTrzIuAOBkTH6+gGFn+6S0WiB70Yk/d/kCqX8tfNtb
1k+AXrtgk4oVWUJESuxwMwxwxR7PHwnEjNvodmfBo86IQmzZojbBfRL8BvKrAKvO
qAO3ZRpsn9g6nkPU83sjPp4rDJt8opxd31g4+G1YqBw7I7u9oZVrcUebp3e/IrU5
+tnr
=qBsg
-----END PGP SIGNATURE-----
--IDt3wyhaIzaLB3FYNH0UP8jSph530VhKq--
From: Thomas Klausner <wiz@NetBSD.org>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: lib/53495: sched_get_priority_max/sched_get_priority_min not
returning useful values
Date: Thu, 16 Aug 2018 10:22:29 +0200
I've filed a wxWidgets bug report about this now:
https://trac.wxwidgets.org/ticket/18195
>Unformatted:
(Contact us)
$NetBSD: query-full-pr,v 1.43 2018/01/16 07:36:43 maya Exp $
$NetBSD: gnats_config.sh,v 1.9 2014/08/02 14:16:04 spz Exp $
Copyright © 1994-2017
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.
Home