linux-kernel - Re: [PATCH RFC] sched: deferred set priority (dprio)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CA+80gGbOx9istV4UG7PF+qam81u+HzJyjznE5sjVV82jjWa=MQ@mail.gmail.com>
Date:	Sat, 2 Aug 2014 17:47:52 -0700
From:	Sergey Oboguev <oboguev.public@...il.com>
To:	Pavel Machek <pavel@....cz>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [PATCH RFC] sched: deferred set priority (dprio)

On Wed, Jul 30, 2014 at 6:02 AM, Pavel Machek <pavel@....cz> wrote:
> Hi!
>
>> One of the intended purposes of this facility (but its not sole purpose) is to
>> render a lightweight mechanism for priority protection of lock-holding critical
>> sections that would be an adequate match for lightweight locking primitives
>> such as futex, with both featuring a fast path completing within the
>> userspace.

> Do we get a manpage describing the interface...?

At this point it is just an RFC, and the only available write-up is an article
(URL is in the original message).

There has been no word from the maintainers yet whether the proposal appears
to be a "go" or "no-go" in general.

Assuming the response was favorable, final polishing on the patch can be done
(such as perhaps replacing or augmenting authlist by a capability), and man page
can be added at this point as well.

> Would it make sense to make set_priority a "vsyscall" so it is fast enough,
and delayed_set_priority does not need to be exposed to userspace?

Regular "set priority" cannot be wrapped around "deferred set priority".

"Deferred set priority" acts only on current thread.

Even more importantly, its use also relies on a thread caching the application's
current knowledge of the thread priority in the userspace, and if the thread
priority had been changed from the outside of the application (or even by
another thread within the same application), this knowledge becomes invalid,
and then the application is responsible for performing whatever recovery action
is appropriate.

Thus DPRIO is not a replacement for fully-functional "set priority",
but rather a
specialized tool for certain use cases.

- Sergey
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/