Great! We do something similar for mixing input entropy in FreeBSD, but use SHA256 instead (only because the code predates Blake2, and there hasn't been a compelling reason to switch).
undefined
> replace gobs of complicated 1990s-era code with a modern hash function
Uhh ... was the kernel not already using a cryptographically secure hash function to mix new randomness in?!
The commit log message is probably a better link than the (short) thread:
https://git.kernel.org/pub/scm/linux/kernel/git/crng/random....
It's quite detailed.
The nutshell of this is that `mix_pool_bytes` (we'll call it M), the LFSR mixing function in the core of the LRNG, has been replaced with Blake2. The M function is slow doesn't adequately recover security if the state is compromised. This is a well-known problem, but one no longer accepted in new designs as CSPRNGs are increasingly formalized.
The new LRNG is much simpler (a lot of it is simply calls to Blake2 now), easier to reason about, and fast.