diff options
author | Nathan Lynch <nathanl@linux.ibm.com> | 2023-01-24 17:04:48 +0300 |
---|---|---|
committer | Michael Ellerman <mpe@ellerman.id.au> | 2023-01-30 09:53:05 +0300 |
commit | 12fd66651df6c807b7b6f420ee0fd420f54991f4 (patch) | |
tree | df61e5f84f38c1bf61259f2545863515e8979f31 /crypto/echainiv.c | |
parent | 599af49155467148afaf0bc3c0114bd80fd4491f (diff) | |
download | linux-12fd66651df6c807b7b6f420ee0fd420f54991f4.tar.xz |
powerpc/rtas: upgrade internal arch spinlocks
At the time commit f97bb36f705d ("powerpc/rtas: Turn rtas lock into a
raw spinlock") was written, the spinlock lockup detection code called
__delay(), which will not make progress if the timebase is not
advancing. Since the interprocessor timebase synchronization sequence
for chrp, cell, and some now-unsupported Power models can temporarily
freeze the timebase through an RTAS function (freeze-time-base), the
lock that serializes most RTAS calls was converted to arch_spinlock_t
to prevent kernel hangs in the lockup detection code.
However, commit bc88c10d7e69 ("locking/spinlock/debug: Remove spinlock
lockup detection code") removed that inconvenient property from the
lock debug code several years ago. So now it should be safe to
reintroduce generic locks into the RTAS support code, primarily to
increase lockdep coverage.
Making rtas_lock a spinlock_t would violate lock type nesting rules
because it can be acquired while holding raw locks, e.g. pci_lock and
irq_desc->lock. So convert it to raw_spinlock_t. There's no apparent
reason not to upgrade timebase_lock as well.
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20230124140448.45938-5-nathanl@linux.ibm.com
Diffstat (limited to 'crypto/echainiv.c')
0 files changed, 0 insertions, 0 deletions