Messages in this thread | | | From | "Jason A. Donenfeld" <> | Date | Mon, 20 Dec 2021 15:38:58 +0100 | Subject | Re: [PATCH 5/5] random: Defer processing of randomness on PREEMPT_RT. |
| |
Hey Sebastian,
Sorry for the delay getting back to you.
I think I understand the motivation for this patchset, and maybe it'll turn out to be the only way of accomplishing what RT needs. But I really don't like complicating the irq ingestion flow like that, splitting the captured state into two pieces, and having multiple entry points. It makes the whole thing more difficult to analyze and maintain. Again, maybe we'll *have* to do this ultimately, but I want to make sure we at least explore the alternatives fully.
One thing you brought up is that the place where a spinlock becomes problematic for RT is if userspace goes completely nuts with RNDRESEEDCRNG. If that's really the only place where contention might be harmful, can't we employ other techniques there instead? For example, just ratelimiting the frequency at which RNDRESEEDCRNG can be called _before_ taking that lock, using the usual ratelimit.h structure? Or, alternatively, what about a lock that very heavily prioritizes acquisitions from the irq path rather than from the userspace path? I think Herbert might have had a suggestion there related to the net stack's sock lock?
Jason
| |