Skip to content

Commit 145f12e

Browse files
berrangehuth
authored andcommitted
crypto: fix bogus error benchmarking pbkdf on fast machines
We're seeing periodic reports of errors like: $ qemu-img create -f luks --object secret,data=123456,id=sec0 \ -o key-secret=sec0 luks-info.img 1M Formatting 'luks-info.img', fmt=luks size=1048576 key-secret=sec0 qemu-img: luks-info.img: Unable to get accurate CPU usage This error message comes from a recent attempt to workaround a kernel bug with measuring rusage in long running processes: commit c72cab5 Author: Tiago Pasqualini <[email protected]> Date: Wed Sep 4 20:52:30 2024 -0300 crypto: run qcrypto_pbkdf2_count_iters in a new thread Unfortunately this has a subtle bug on machines which are very fast. On the first time around the loop, the 'iterations' value is quite small (1 << 15), and so will run quite fast. Testing has shown that some machines can complete this benchmarking task in as little as 7 milliseconds. Unfortunately the 'getrusage' data is not updated at the time of the 'getrusage' call, it is done asynchronously by the scheduler. The 7 millisecond completion time for the benchmark is short enough that 'getrusage' sometimes reports 0 accumulated execution time. As a result the 'delay_ms == 0' sanity check in the above commit is triggering non-deterministically on such machines. The benchmarking loop intended to run multiple times, increasing the 'iterations' value until the benchmark ran for > 500 ms, but the sanity check doesn't allow this to happen. To fix it, we keep a loop counter and only run the sanity check after we've been around the loop more than 5 times. At that point the 'iterations' value is high enough that even with infrequent updates of 'getrusage' accounting data on fast machines, we should see a non-zero value. Fixes: https://lore.kernel.org/qemu-devel/[email protected]/ Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=2336437 Reported-by: Thomas Huth <[email protected]> Reported-by: Richard W.M. Jones <[email protected]> Tested-by: Thomas Huth <[email protected]> Signed-off-by: Daniel P. Berrangé <[email protected]> Message-ID: <[email protected]> Signed-off-by: Thomas Huth <[email protected]>
1 parent b94893a commit 145f12e

File tree

1 file changed

+13
-2
lines changed

1 file changed

+13
-2
lines changed

crypto/pbkdf.c

+13-2
Original file line numberDiff line numberDiff line change
@@ -107,7 +107,7 @@ static void *threaded_qcrypto_pbkdf2_count_iters(void *data)
107107
size_t nsalt = iters_data->nsalt;
108108
size_t nout = iters_data->nout;
109109
Error **errp = iters_data->errp;
110-
110+
size_t scaled = 0;
111111
uint64_t ret = -1;
112112
g_autofree uint8_t *out = g_new(uint8_t, nout);
113113
uint64_t iterations = (1 << 15);
@@ -131,7 +131,17 @@ static void *threaded_qcrypto_pbkdf2_count_iters(void *data)
131131

132132
delta_ms = end_ms - start_ms;
133133

134-
if (delta_ms == 0) { /* sanity check */
134+
/*
135+
* For very small 'iterations' values, CPU (or crypto
136+
* accelerator) might be fast enough that the scheduler
137+
* hasn't incremented getrusage() data, or incremented
138+
* it by a very small amount, resulting in delta_ms == 0.
139+
* Once we've scaled 'iterations' x10, 5 times, we really
140+
* should be seeing delta_ms != 0, so sanity check at
141+
* that point.
142+
*/
143+
if (scaled > 5 &&
144+
delta_ms == 0) { /* sanity check */
135145
error_setg(errp, "Unable to get accurate CPU usage");
136146
goto cleanup;
137147
} else if (delta_ms > 500) {
@@ -141,6 +151,7 @@ static void *threaded_qcrypto_pbkdf2_count_iters(void *data)
141151
} else {
142152
iterations = (iterations * 1000 / delta_ms);
143153
}
154+
scaled++;
144155
}
145156

146157
iterations = iterations * 1000 / delta_ms;

0 commit comments

Comments
 (0)