On 20/07/2021 22:40, Konstantin Belousov wrote:
On Tue, Jul 20, 2021 at 05:30:33PM +0000, Alexander Motin wrote:
The branch main has been updated by mav:

URL: 
https://cgit.FreeBSD.org/src/commit/?id=28d70deaafa62c5d1602de5272c0aad0fcca8aff

commit 28d70deaafa62c5d1602de5272c0aad0fcca8aff
Author:     Alexander Motin <m...@freebsd.org>
AuthorDate: 2021-07-20 17:15:08 +0000
Commit:     Alexander Motin <m...@freebsd.org>
CommitDate: 2021-07-20 17:30:28 +0000

     Fix race between first rand(3) calls.
Before this patch there was a chance for thread that called rand(3)
     slightly later to see rand3_state already allocated, but not yet
     initialized.  While this API is not expected to be thread-safe, it
     is not expected to crash.  ztest on 64-thread system reproduced it
     reliably for me.
MFC after: 1 month
---
  lib/libc/stdlib/rand.c | 9 +++++++--
  1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/lib/libc/stdlib/rand.c b/lib/libc/stdlib/rand.c
index bddb0f040302..353f59349e1d 100644
--- a/lib/libc/stdlib/rand.c
+++ b/lib/libc/stdlib/rand.c
@@ -44,6 +44,7 @@ __FBSDID("$FreeBSD$");
  #include <stdbool.h>
  #include <stdlib.h>
  #include <syslog.h>
+#include <machine/atomic.h>
  #include "un-namespace.h"
#include "random.h"
@@ -68,11 +69,15 @@ static struct __random_state *rand3_state;
  static void
  initialize_rand3(void)
  {
+       struct __random_state *state;
        int error;
- rand3_state = allocatestate(TYPE_3);
-       error = initstate_r(rand3_state, 1, rand3_state->rst_randtbl, BREAK_3);
+       state = allocatestate(TYPE_3);
+       error = initstate_r(state, 1, state->rst_randtbl, BREAK_3);
        assert(error == 0);
+       if (!atomic_cmpset_rel_ptr((volatile uintptr_t *)&rand3_state,
+           (uintptr_t)NULL, (uintptr_t)state))
+               free(state);
For this to have effect on less ordered architectures (AKA non-x86), at
least reads of rand3_state should be atomic_load_acq().

But consider using _once() in libc, which takes care about ordering/threads.

FWIW, I've been using the following patch locally.
And the reason for the patched is discussed here: https://www.mail-archive.com/freebsd-current@freebsd.org/msg182365.html

commit cc38290d14a5bbab64e419a2d6d8c34f61840829
Author:     Andriy Gapon <a...@freebsd.org>
AuthorDate: Mon Apr 5 17:33:07 2021 +0300
Commit:     Andriy Gapon <a...@freebsd.org>
CommitDate: Tue Jun 8 10:34:28 2021 +0300

    [tmp?] make rand/srand initialization thread safe

    But rand(3) still remains non-thread-safe in general.
    This is only to prevent an initialization time crash in ztest.
    Probably should be fixed there, e.g. by using a different random number
    API or by adding some locking.

diff --git a/lib/libc/stdlib/rand.c b/lib/libc/stdlib/rand.c
index bddb0f040302..0d3ed2230e10 100644
--- a/lib/libc/stdlib/rand.c
+++ b/lib/libc/stdlib/rand.c
@@ -41,11 +41,13 @@ __FBSDID("$FreeBSD$");
 #include <sys/param.h>
 #include <sys/sysctl.h>
 #include <assert.h>
+#include <pthread.h>
 #include <stdbool.h>
 #include <stdlib.h>
 #include <syslog.h>
 #include "un-namespace.h"

+#include "libc_private.h"
 #include "random.h"

 /*
@@ -64,6 +66,7 @@ __FBSDID("$FreeBSD$");
  * the advantage of being the one already in the tree.
  */
 static struct __random_state *rand3_state;
+static pthread_once_t  __random_state_once = PTHREAD_ONCE_INIT;

 static void
 initialize_rand3(void)
@@ -78,16 +81,14 @@ initialize_rand3(void)
 int
 rand(void)
 {
-       if (rand3_state == NULL)
-               initialize_rand3();
+       _once(&__random_state_once, initialize_rand3);
        return ((int)random_r(rand3_state));
 }

 void
 srand(unsigned seed)
 {
-       if (rand3_state == NULL)
-               initialize_rand3();
+       _once(&__random_state_once, initialize_rand3);
        srandom_r(rand3_state, seed);
 }



--
Andriy Gapon
_______________________________________________
dev-commits-src-main@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/dev-commits-src-main
To unsubscribe, send any mail to "dev-commits-src-main-unsubscr...@freebsd.org"

Reply via email to