spapr_rng: fix race with main loop
Since commit "60253ed1e6ec rng: add request queue support to rng-random",
the use of a spapr_rng device may hang vCPU threads.
The following path is taken without holding the lock to the main loop mutex:
h_random()
rng_backend_request_entropy()
rng_random_request_entropy()
qemu_set_fd_handler()
The consequence is that entropy_available() may be called before the vCPU
thread could even queue the request: depending on the scheduling, it may
happen that entropy_available() does not call random_recv()->qemu_sem_post().
The vCPU thread will then sleep forever in h_random()->qemu_sem_wait().
This could not happen before 60253ed1e6
because entropy_available() used
to call random_recv() unconditionally.
This patch ensures the lock is held to avoid the race.
Signed-off-by: Greg Kurz <gkurz@linux.vnet.ibm.com>
Reviewed-by: Cédric Le Goater <clg@fr.ibm.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
This commit is contained in:
parent
c18ad9a54b
commit
f1a6cf3ef7
@ -77,13 +77,13 @@ static target_ulong h_random(PowerPCCPU *cpu, sPAPRMachineState *spapr,
|
||||
hrdata.val.v64 = 0;
|
||||
hrdata.received = 0;
|
||||
|
||||
qemu_mutex_unlock_iothread();
|
||||
while (hrdata.received < 8) {
|
||||
rng_backend_request_entropy(rngstate->backend, 8 - hrdata.received,
|
||||
random_recv, &hrdata);
|
||||
qemu_mutex_unlock_iothread();
|
||||
qemu_sem_wait(&hrdata.sem);
|
||||
}
|
||||
qemu_mutex_lock_iothread();
|
||||
}
|
||||
|
||||
qemu_sem_destroy(&hrdata.sem);
|
||||
args[0] = hrdata.val.v64;
|
||||
|
Loading…
Reference in New Issue
Block a user