unofficial mirror of libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
To: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Cc: nd <nd@arm.com>, "libc-alpha@sourceware.org" <libc-alpha@sourceware.org>
Subject: Re: [PATCH v2 4/6] Do not use HP_TIMING_NOW for random bits
Date: Wed, 20 Mar 2019 15:32:50 +0000	[thread overview]
Message-ID: <AM6PR08MB5078533B125C22BD6E3C889B83410@AM6PR08MB5078.eurprd08.prod.outlook.com> (raw)
In-Reply-To: <6ea276af-aa62-2bfe-ee6c-83c8eeaf283a@linaro.org>

Hi Adhemerval,

> +# include <random-bits.h>
> +# define RANDOM_BITS(Var) ((Var) = random_bits ())
> 
> This define is not used (removed above).

> I think we need to still define it if we eventually decide to sync it back
> to gnulib.

Well this is the question - do we really need all this clutter just for gnulib?
It looks to me we should keep the code as clean as possible (so we don't
need any the !_LIBC code given these files are always in LIBC).

> I fact the new line should not be added, since random_time_bits should already
> get the random_bits() value. In any case I think we can remove random_time_bits
> altogether and just call RANDOM_BITS on value instead.

Agreed.

> And it seems 'value' is static by design, but I do agree there is no impeding
> reason to continue to do so.

Indeed.

---
diff --git a/sysdeps/posix/tempname.c b/sysdeps/posix/tempname.c
index 5217cb38e1..d062e4b82f 100644
--- a/sysdeps/posix/tempname.c
+++ b/sysdeps/posix/tempname.c
@@ -73,6 +73,13 @@
 #ifdef _LIBC
 # include <random-bits.h>
 # define RANDOM_BITS(Var) ((Var) = random_bits ())
+# else
+# define RANDOM_BITS(Var) \
+    {                                                                         \
+      struct timeval tv;                                                      \
+      __gettimeofday (&tv, NULL);                                             \
+      (Var) = ((uint64_t) tv.tv_usec << 16) ^ tv.tv_sec;                      \
+    }
 #endif
 
I don't see the point of this, especially using gettimeofday. If we want to export
these changes to gnulib, we could just add random_bits to gnulib.


-  value += random_time_bits ^ __getpid ();
-  value += random_bits () ^ __getpid ();
+  RANDOM_BITS (value);
+  value ^= __getpid ();
+  /* Shuffle the lower bits to minimize the pid bias due low maximum value.  */
+  value = (value << 24) | (value >> 8);

random_bits already does that shuffle, so doing it again doesn't help. It's better
to avoid the aliasing of getpid with the random bits, eg. value ^= __get_pid << 32
so we end up with more than 32 random bits.

Wilco


    

  reply	other threads:[~2019-03-20 15:32 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-07 17:09 [PATCH v2 4/6] Do not use HP_TIMING_NOW for random bits Wilco Dijkstra
2019-03-19 16:52 ` Adhemerval Zanella
2019-03-20 15:32   ` Wilco Dijkstra [this message]
2019-03-20 17:42     ` Adhemerval Zanella
  -- strict thread matches above, loose matches on Subject: below --
2019-02-18 21:11 [PATCH v2 1/6] nptl: Remove pthread_clock_gettime pthread_clock_settime Adhemerval Zanella
2019-02-18 21:11 ` [PATCH v2 4/6] Do not use HP_TIMING_NOW for random bits Adhemerval Zanella

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/libc/involved.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=AM6PR08MB5078533B125C22BD6E3C889B83410@AM6PR08MB5078.eurprd08.prod.outlook.com \
    --to=wilco.dijkstra@arm.com \
    --cc=adhemerval.zanella@linaro.org \
    --cc=libc-alpha@sourceware.org \
    --cc=nd@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).