[<prev] [<thread-prev] [day] [month] [year] [list]
Message-ID: <Z2q-ioXcBB-i32_X@voyager>
Date: Tue, 24 Dec 2024 15:00:42 +0100
From: Markus Wichmann <nullplan@....net>
To: musl@...ts.openwall.com
Cc: yan.li.cn@...driver.com
Subject: Re: [PATCH] add check for pthread_attr_setschedparam().
Am Tue, Dec 24, 2024 at 04:41:04AM -0500 schrieb Rich Felker:
> On Tue, Dec 24, 2024 at 10:03:01AM +0800, yan.li.cn@...driver.com wrote:
> > int pthread_attr_setschedparam(pthread_attr_t *restrict a, const struct sched_param *restrict param)
> > {
> > - a->_a_prio = param->sched_priority;
> > - return 0;
> > + int min = sched_get_priority_min (a->_a_policy);
> > + int max = sched_get_priority_max (a->_a_policy);
> > +
> > + if (min < 0 || max < 0 || param->sched_priority < min || param->sched_priority > max){
> > + return EINVAL;
> > + }
> > +
> > + a->_a_prio = param->sched_priority;
> > + return 0;
> > }
> > --
> > 2.34.1
>
> I don't see a good motivation for this change. The error conditions
> are MAY FAIL, not SHALL FAIL, and checking for them incurs two useless
> syscalls on every call to a function that's otherwise syscall-free.
>
> Rich
It is also technically wrong. You are not supposed to relate different
attributes until the attributes actually get used. Intermediate results
are allowed to be invalid. That's just how the entire POSIX *attr* API
works.
In this case, a scheduling priority may be wrong for the currently
selected policy, but you don't know what policy is used in the
pthread_create() call, or if the flags even contain
PTHREAD_EXPLICIT_SCHED at that point. The checking can only happen in
pthread_create(), and it doesn't even have to check these things
explicitly, it can just delegate that to the kernel when it sets the
scheduling attributes of the new thread.
Ciao,
Markus
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
