chore: pre-generate keyswitching keys for shortint tests

[IceTDrinker]

• we run in a cross process race condition which fucks up the key file
• no rust crate seems to help and linux locks are just a fucking mess
• also avoid truncating file when we are going to write to it, get a lock first

Added the key gen for the test as well to avoid issues

[nsarlin-zama]

Reviewable status: 0 of 2 files reviewed, 1 unresolved discussion

---

tfhe/src/keycache/mod.rs line 114 at r1 (raw file):

                let file = File::open(&path_buf).unwrap();
                // TODO Manage file locking for inter process stuff, unfortunately linux locks are a
                // mess and nothing seems to work

looks like there is a File::lock method in std that will be stabilized with 1.87: rust-lang/rust#136794
Maybe it will be worth retrying when this is released

---

tfhe/examples/utilities/generates_test_keys.rs line 59 at r1 (raw file):

    // Always generate those as they may be used in the different cases
    generate_ksk_keys(&KSK_PARAMS);

This is not directly linked to this pr but I think it should be "generate_ks_keys"

[IceTDrinker]

@nsarlin-zama need changes or approved ?

[nsarlin-zama]

Depends on if you want to fix the function name.

But this is not really important so approved anyways, thanks!

[IceTDrinker]

Depends on if you want to fix the function name.

But this is not really important so approved anyways, thanks!

In the current case, even if the failure is rare I'd rather have it merged sooner than later :)

[nsarlin-zama]

Oh I was thinking maybe instead of doing the truncate after lock thing we could use create_new and skip in case of error ?

[nsarlin-zama]

I think it's specifically made for this kind of situations

[IceTDrinker]

Oh I was thinking maybe instead of doing the truncate after lock thing we could use create_new and skip in case of error ?

Can be done later if you want to, I don't think it mattered much anyways as we pre generated the keys, not sure in terms of cache consistency what our various tests expect

[IceTDrinker]

I mean create_new probably would have avoided the issue we had most likely, but then what are we supposed to do if the write fails ? Meaning two test processes have generated keys

[nsarlin-zama]

I think if the second process just uses its own key but does not store it this is equivalent as what's happening here where the first key is overwritten by the second ?

Or worst case the second process could drop its generated key and reload the one from the file

[IceTDrinker]

I think if the second process just uses its own key but does not store it this is equivalent as what's happening here where the first key is overwritten by the second ?

Or worst case the second process could drop its generated key and reload the one from the file

I don't think the second option would work with how the keycache is organized