On 1/20/23 3:20 PM, "Jason A. Donenfeld" <Jason@xxxxxxxxx> wrote:
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. Hi Babis, As I mentioned to you privately this week, I'm about to be out of town, so I won't be able to look at this until I'm back in a few weeks. I appreciate your patience. But as a cursory look, I'm happy that you've written the hardware-side code for this. That's a great starting point. The plumbing is not so nice, though. This needs to be integrated more closely with random.c itself, similar to how vmgenid works. When I'm back in a few weeks, I'll see if I can either write a description of what I have in mind, or simply integrate the useful hardware work here into an expanded patch series. [Please don't merge anything for now.] Jason
Hey Jason, I agree that the plumbing with random.c needs work. That's why this is an RFC! That's the kind of input I'm looking for. As I mention in the cover letter, IMHO, we need to give to random.c (and other parts of the kernel that they might need it) an API to directly add buffers in the queue, so that we avoid the race-condition here. Any ideas on that front are more than welcome and looking forward to them. Cheers, Babis Amazon Spain Services sociedad limitada unipersonal, Calle Ramirez de Prado 5, 28045 Madrid. Registro Mercantil de Madrid . Tomo 22458 . Folio 102 . Hoja M-401234 . CIF B84570936
