On Thu, 21 Sep 2017, Jakub Jelinek wrote: > Why isn't init_local_tick done at the get_random_seed time too? > I.e. inlined into get_random_seed by hand like you've done for > init_random_seed?
init_local_tick initializes the 'local_tick' global variable that is directly accessed from coverage.c. Thus, changes in coverage.c would be needed to avoid init_local_tick at each startup. > If one is unlucky, this can still yield 0 and multiple get_random_seed > invocations will open /dev/urandom multiple times and what is worse, > one can return 0 and the other some completely different number. > So either we should for the case the above is still 0 set random_seed > to some hardcoded constant other than 0 or return getpid () in that case, > or allow 0 to be returned, but arrange for the initialization to be done > at most once. Yes (there are pre-existing issues like this too). The minimal fix could be random_seed += !random_seed; after the getpid fallback, but really this internal random_seed business is currently a mess and could benefit from some more TLC. Would you be interested to review further patches in this area? Thanks. Alexander
