-
Notifications
You must be signed in to change notification settings - Fork 16
x509storeissuer update #50
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
6398216
15c799b
7448789
ee5fd86
6b108da
2b7fcf4
68a7b91
9c03311
be5de07
2cd00eb
18fab94
b9e8a78
09f24e3
92ca087
8a68e53
319e6ec
aec1748
ca94c96
a600b7e
5acec49
753613f
5444f48
8ba8e6b
176619a
14fa76e
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -68,7 +68,7 @@ | |
| size_t *counts; | ||
| OSSL_TIME max_time; | ||
|
|
||
| int err = 0; | ||
| int error = 0; | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm still at a loss for why this had to be done everywhere. I just reverted the changes to evp_fetch.c regarding this conversion, and with Visual Studio 17 2022, the perftools repo built fine. What compiler version produced errors for you?
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. If I rememer correctly the change was prompted by thread affinity which is gone. so perhaps we can drop this changeset from this PR too.
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I guess any refactoring that introduces usage of this BSD-specific function would lead to that, so I've decided to leave it as is; note, however, that the symbol name "error" also conflicts with the GNU-specific function, so we might want to rethink that rename in favor of something that doesn't hit either of those. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. As mentioned, this is pretty intrusive and should probably be a separate change from this. like with a real issue and stuff about the name of this global symbol in this file and what it conflicts with. To me it seems like changing err to error is just moving the deck chair over one place and waiting for the next conflict. While making a decision to solve that is fine, we should solve it rather than just hacking this just for the purpose of having err() in this test. |
||
| int pq = 0; | ||
|
|
||
| static int threadcount; | ||
|
|
@@ -197,7 +197,7 @@ void do_fetch(size_t num) | |
| fetch_alg = exclusive_fetch_alg; | ||
| } | ||
|
|
||
| if (err == 1) | ||
| if (error == 1) | ||
| return; | ||
|
|
||
| switch (j) { | ||
|
|
@@ -206,7 +206,7 @@ void do_fetch(size_t num) | |
| fetch_entries[j].propq); | ||
| if (md == NULL) { | ||
| fprintf(stderr, "Failed to fetch %s\n", fetch_alg); | ||
| err = 1; | ||
| error = 1; | ||
| return; | ||
| } | ||
| EVP_MD_free(md); | ||
|
|
@@ -217,7 +217,7 @@ void do_fetch(size_t num) | |
| fetch_entries[j].propq); | ||
| if (cph == NULL) { | ||
| fprintf(stderr, "Failed to fetch %s\n", fetch_alg); | ||
| err = 1; | ||
| error = 1; | ||
| return; | ||
| } | ||
| EVP_CIPHER_free(cph); | ||
|
|
@@ -228,7 +228,7 @@ void do_fetch(size_t num) | |
| fetch_entries[j].propq); | ||
| if (kdf == NULL) { | ||
| fprintf(stderr, "Failed to fetch %s\n", fetch_alg); | ||
| err = 1; | ||
| error = 1; | ||
| return; | ||
| } | ||
| EVP_KDF_free(kdf); | ||
|
|
@@ -239,7 +239,7 @@ void do_fetch(size_t num) | |
| fetch_entries[j].propq); | ||
| if (mac == NULL) { | ||
| fprintf(stderr, "Failed to fetch %s\n", fetch_alg); | ||
| err = 1; | ||
| error = 1; | ||
| return; | ||
| } | ||
| EVP_MAC_free(mac); | ||
|
|
@@ -250,7 +250,7 @@ void do_fetch(size_t num) | |
| fetch_entries[j].propq); | ||
| if (rnd == NULL) { | ||
| fprintf(stderr, "Failed to fetch %s\n", fetch_alg); | ||
| err = 1; | ||
| error = 1; | ||
| return; | ||
| } | ||
| EVP_RAND_free(rnd); | ||
|
|
@@ -261,7 +261,7 @@ void do_fetch(size_t num) | |
| fetch_entries[j].propq); | ||
| if (kem == NULL) { | ||
| fprintf(stderr, "Failed to fetch %s\n", fetch_alg); | ||
| err = 1; | ||
| error = 1; | ||
| return; | ||
| } | ||
| EVP_KEM_free(kem); | ||
|
|
@@ -272,14 +272,14 @@ void do_fetch(size_t num) | |
| fetch_entries[j].propq); | ||
| if (sig == NULL) { | ||
| fprintf(stderr, "Failed to fetch %s\n", fetch_alg); | ||
| err = 1; | ||
| error = 1; | ||
| return; | ||
| } | ||
| EVP_SIGNATURE_free(sig); | ||
| break; | ||
| } | ||
| default: | ||
| err = 1; | ||
| error = 1; | ||
| return; | ||
| } | ||
| counts[num]++; | ||
|
|
@@ -392,7 +392,7 @@ int main(int argc, char *argv[]) | |
| goto out; | ||
| } | ||
|
|
||
| if (err) { | ||
| if (error) { | ||
| printf("Error during test\n"); | ||
| goto out; | ||
| } | ||
|
|
||
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm a bit concerned about this reduction in test run time:
thats a 12% increase in average call time just by reducing the test run period from 5 seconds to 0.12 seconds. As to weather thats a more accurate representation of our actual run time, I honestly can't say, but if I had to guess I'd hypothesize that running for such a short period of time makes the library initialization time more prominent in our average figures.
If we have to limit the run time like this, I would suggest running a "warm up round first" to ensure that libcrypto has all its data strctures setup prior to us recording any run times.
Though, if I'm reading the below properly this fanout is indeed huge. I think its the number of combinations for each set element below yes? Meaning we're running 2x3x4x3x3x3x3x4x3=23328 combinations of this test! Theres got to be a way to reduce that. For instance if we unilaterally added the -q 20 and -v option to every test, we could reduce this matrix to 1944 combinations, which should run in about 2.7 hours, which still isn't great, but its on par with how some of our other tests run.
Theres also the question as to which of these test runs do we keep graphing data for on grafana? It might be worth restricting what we run here to just those, as I'm hard pressed to think of who is going to be reviewing all 23,000 of these current outputs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should test only options that are used for the Grafana dashboard.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd rather have all the code we are not going to test be removed, then.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't really have to be that strict in this case.