Messages in this thread | | | Date | Fri, 4 Feb 2022 20:02:26 -0800 | From | Sultan Alsawaf <> | Subject | Re: [PATCH RFC v1] random: do not take spinlocks in irq handler |
| |
On Fri, Feb 04, 2022 at 09:47:23PM +0100, Sebastian Andrzej Siewior wrote: > No need for atomic. If this is truly per-CPU then there will be no > cross-CPU access, right? > Therefore I would suggest to use __this_cpu_inc_return() which would avoid > the sync prefix for the inc operation. Same for __this_cpu_or(). And you > could use unsigned int.
Hi,
The __this_cpu_{ATOMIC_OP}() functions are for atomically performing a single per-CPU operation for the current CPU from contexts that permit CPU migration. Since this code is safe from CPU migrations (add_interrupt_randomness() runs in hardirq context), the atomic per-CPU helpers are unneeded. Instead of using __this_cpu_inc_return() and __this_cpu_or(), we can operate on the per-CPU pointer directly without any extra safety (e.g., `++fast_pool->count` can be used in place of `__this_cpu_inc_return(irq_randomness.count)`).
Sultan
| |