Date: Mon, 30 Dec 2019 05:48:12 +0100 From: Mateusz Guzik <mjguzik@gmail.com> To: Conrad Meyer <cem@freebsd.org> Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r356194 - head/sys/dev/random Message-ID: <CAGudoHFQRkdYychrXApKLaHsc=Nrx4rN8iULAp_Z3GeAW3LBmA@mail.gmail.com> In-Reply-To: <201912300138.xBU1cJqR064429@repo.freebsd.org> References: <201912300138.xBU1cJqR064429@repo.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 12/30/19, Conrad Meyer <cem@freebsd.org> wrote: > Author: cem > Date: Mon Dec 30 01:38:19 2019 > New Revision: 356194 > URL: https://svnweb.freebsd.org/changeset/base/356194 > > Log: > random(4): Make entropy source deregistration safe > > Allow loadable modules that provide random entropy source(s) to safely > unload. Prior to this change, no driver could ensure that their > random_source structure was not being used by random_harvestq.c for any > period of time after invoking random_source_deregister(). > > This change converts the source_list LIST to a ConcurrencyKit CK_LIST and > uses an epoch(9) to protect typical read accesses of the list. The > existing > HARVEST_LOCK spin mutex is used to safely add and remove list entries. > random_source_deregister() uses epoch_wait() to ensure no concurrent > source_list readers are accessing a random_source before freeing the list > item and returning to the caller. > > Callers can safely unload immediately after random_source_deregister() > returns. > What's the point of using epoch for this one instead of rmlocks? rmlocks have the upshot of being faster single-threaded for the case you want (no fences). epoch would make sense if the list was expected to change over time, -- Mateusz Guzik <mjguzik gmail.com>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAGudoHFQRkdYychrXApKLaHsc=Nrx4rN8iULAp_Z3GeAW3LBmA>