summaryrefslogtreecommitdiffstats
path: root/drivers/char/tpm
diff options
context:
space:
mode:
authorJason A. Donenfeld <Jason@zx2c4.com>2022-10-01 01:10:50 +0200
committerJason A. Donenfeld <Jason@zx2c4.com>2022-12-04 14:37:08 +0100
commit1c21fe00eda76e4081535c739cf9f4bbb5dcb0ce (patch)
tree82c2465b448f54b4aa202ff1ce0e5124d4541f43 /drivers/char/tpm
parent0e42d14be23f4cdb68a06ea40106eccf7db0b4bc (diff)
downloadlinux-1c21fe00eda76e4081535c739cf9f4bbb5dcb0ce.tar.bz2
random: spread out jitter callback to different CPUs
Rather than merely hoping that the callback gets called on another CPU, arrange for that to actually happen, by round robining which CPU the timer fires on. This way, on multiprocessor machines, we exacerbate jitter by touching the same memory from multiple different cores. There's a little bit of tricky bookkeeping involved here, because using timer_setup_on_stack() + add_timer_on() + del_timer_sync() will result in a use after free. See this sample code: <https://xn--4db.cc/xBdEiIKO/c>. Instead, it's necessary to call [try_to_]del_timer_sync() before calling add_timer_on(), so that the final call to del_timer_sync() at the end of the function actually succeeds at making sure no handlers are running. Cc: Sultan Alsawaf <sultan@kerneltoast.com> Cc: Dominik Brodowski <linux@dominikbrodowski.net> Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Diffstat (limited to 'drivers/char/tpm')
0 files changed, 0 insertions, 0 deletions