Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 24 Feb 2015 07:56:24 -0700
From:      Warner Losh <imp@bsdimp.com>
To:        Konstantin Belousov <kostikbel@gmail.com>
Cc:        Harrison Grundy <harrison.grundy@astrodoggroup.com>, freebsd-arch@freebsd.org
Subject:   Re: locks and kernel randomness...
Message-ID:  <DD06E2EA-68D6-43D7-AA17-FB230750E55A@bsdimp.com>
In-Reply-To: <20150224024250.GV74514@kib.kiev.ua>
References:  <20150224012026.GY46794@funkthat.com> <20150224015721.GT74514@kib.kiev.ua> <54EBDC1C.3060007@astrodoggroup.com> <20150224024250.GV74514@kib.kiev.ua>

next in thread | previous in thread | raw e-mail | index | archive | help

> On Feb 23, 2015, at 7:42 PM, Konstantin Belousov <kostikbel@gmail.com> =
wrote:
>=20
> On Mon, Feb 23, 2015 at 06:04:12PM -0800, Harrison Grundy wrote:
>>=20
>>=20
>> On 02/23/15 17:57, Konstantin Belousov wrote:
>>> On Mon, Feb 23, 2015 at 05:20:26PM -0800, John-Mark Gurney wrote:
>>>> I'm working on simplifying kernel randomness interfaces.  I would
>>>> like to get read of all weak random generators, and this means
>>>> replacing read_random and random(9) w/ effectively arc4rand(9)
>>>> (to be replaced by ChaCha or Keccak in the future).
>>>>=20
>>>> The issue is that random(9) is called from any number of
>>>> contexts, such as the scheduler.  This makes locking a bit more
>>>> interesting.  Currently, both arc4rand(9) and yarrow/fortuna use
>>>> a default mtx lock to protect their state.  This obviously isn't
>>>> compatible w/ the scheduler, and possibly other calling
>>>> contexts.
>>>>=20
>>>> I have a patch[1] that unifies the random interface.  It converts
>>>> a few of the locks from mtx default to mtx spin to deal w/ this.
>>> This is definitely an overkill. The rebalancing minor use of
>>> randomness absolutely does not require cryptographical-strenght
>>> randomness to select a moment to rebalance thread queue. Imposing
>>> the spin lock on the whole random machinery just to allow the same
>>> random gathering code to be used for balance_ticks is detriment to
>>> the system responsivness. Scheduler is fine even with congruential
>>> generators, as you could see in the cpu_search(), look for the
>>> '69069'.
>>>=20
>>> Please do not enforce yet another spinlock for the system.=20
>>> _______________________________________________
>>=20
>> The patch attached to
>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D197922 switches
>> sched_balance to use get_cyclecount, which is also a suitable source
>> of entropy for this purpose.
>>=20
>> It would also be possible to make the scheduler deterministic here,
>> using cpuid or some such thing to make sure all CPUs don't fire the
>> balancer at the same time.
>>=20
>=20
> The patch in the PR is probably in the right direction, but might be =
too
> simple, unless somebody dispel my fallacy. I remember seeing claims =
that
> on the very low-end embedded devices the get_cyclecount() method may
> be non-functional, i.e. returning some constant, probably 0. I somehow
> associate MIPS arch with this bias.

arm v4/v5 don=E2=80=99t have get_cyclecount() in hardware. It simply =
doesn=E2=80=99t exist.

However, this patch is only for SMP, which also isn=E2=80=99t available =
on arm v4/v5
in our tree.

MIPS=E2=80=99 get cycle count, though, has been defined since R4k days =
and so much
software depends on it, it would surprise me if that was eliminated to =
save silicon.

Then again, if you want to change random(), provide a weak_random() =
that=E2=80=99s
the traditional non-crypto thing that=E2=80=99s fast and lockless. That =
would make it easy
to audit in our tree. The scheduler doesn=E2=80=99t need cryptographic =
randomness, it
just needs to make different choices sometimes to ensure its notion of =
fairness.

Warner




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?DD06E2EA-68D6-43D7-AA17-FB230750E55A>