Hi Jason, On 22/07/22 22:13, Jason A. Donenfeld wrote: > Hi Valentin, > > On Fri, Jul 22, 2022 at 10:09 PM Valentin Schneider <vschneid@xxxxxxxxxx> wrote: >> I had initially convinced myself this would be somewhat involved, but >> writing the above I thought maybe not... The below is applied on top of >> your v10, would you be able to test whether it actually works? >> It does however mean patching up any sleeping hwrng (a quick search tells >> me there are more, e.g. npcm-rng does readb_poll_timeout()) > > I'm not able to test this easily, no (I don't own any hardware), and > I'm not going to put in the effort to rewrite/audit every sleeping > hwrng. That's not a good use of time, given the numerous other > problems the framework has (briefly discussed with Eric). Instead, > maybe at some point I'll look into overhauling all of this so that > none of this will be required anyway. So I think v10 is my final > submission on this. > I think that's fair, I hope I didn't discourage you too much from contributing in that area. > But if you'd like to attempt more comprehensive changes throughout the > tree on all the drivers and do something large, I guess you can do > that independently (since you mentioned your thing works on top of > v10). And this way v10 still exists to fix the actual bug that's > currently reeking havoc. On the other hand, maybe don't bother, and we > can look into fixing the whole rats nest properly in some months when > I'm more motivated to jump into hwrng. > Just to make sure I'm on the same page as you - is your patch solely for ath9k, or is it supposed to fix other drivers? AFAICT your changes to hw_random/core.c work with any hwnrg driver that does a variant of schedule_timeout() during rng_get_data(), whereas what I suggested only works for "opted-in" drivers (just ath9k ATM), but it doesn't break the other drivers in any way. So if ath9k is widely used / a problem for lots of folks, we could just fix that one and leave the others TBD. What do you think?
