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
next prev parent 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).