> Given that I'm not going to change the way the existing predicates > work, if I move the "fallback" setting `max_bhb_k` to 32 to > spectre_bhb_enable_mitigation() then when we set `max_bhb_k` becomes > inconsistent between recognized and unrecognized CPUs. A clean way to fix that could be to change spectre_bhb_loop_affected() to just return the K-value (rather than change max_bhb_k directly), and then set max_bhb_k to the max() of that return value and the existing value when it is called from spectre_bhb_enable_mitigation(). That way, max_bhb_k would only be updated from spectre_bhb_enable_mitigation(). > I would also say that having `max_bhb_k` get set in an inconsistent > place opens us up for bugs in the future. Even if it works today, I > imagine someone could change things in the future such that > spectre_bhb_enable_mitigation() reads `max_bhb_k` and essentially > caches it (maybe it constructs an instruction based on it). If that > happened things could be subtly broken for the "unrecognized CPU" case > because the first CPU would "cache" the value without it having been > called on all CPUs. This would likely already be a problem with the current code, since spectre_bhb_enable_mitigations() is called one at a time for each CPU and the max_bhb_k value is only valid once it has been called on all CPUs. If someone tried to just immediately use the value inside the function that would just be a bug either way. (Right now this should not be a problem because max_bhb_k is only used by spectre_bhb_patch_loop_iter() which ends up being called through apply_alternatives_all(), which should only run after all those CPU errata cpu_enable callbacks have been called.)
