On Sat, Aug 24, 2024 at 03:25:04PM +0800, Wen Yang wrote: > > > On 2024/8/20 01:45, Greg KH wrote: > > On Mon, Aug 19, 2024 at 10:59:45PM +0800, Wen Yang wrote: > > > pstore_dump() is called when both preemption and local IRQ are disabled, > > > and a spinlock is obtained, which is problematic for the RT kernel because > > > in this configuration, spinlocks are sleep locks. > > > > > > Replace the spinlock_t with raw_spinlock_t to avoid sleeping in atomic > > > context. > > > > This feels odd, is it only an out-of-tree RT thing? Or does this affect > > in-kernel code as well? What prevents any normal spinlock from sleeping > > in your system configuration as well? > > > > Thank you for your comment. > > If we enable PREEMPT_RT, it will also affect in-kernel code, such as in the > following scenario: > > echo b > /proc/sysrq-trigger > - sysrq_handle_reboot > - emergency_restart > - kmsg_dump > - pstore_dump > Obtained psinfo->buf_lock, if there is a lot of error log in the kernel, it > will last for a long time > > If the system unexpectedly crashes at this time: > - panic() > - kmsg_dump > - pstore_dump > Attempting to obtain psinfo->buf_lock while disabling interrupts and > preemption, but since this lock is already held by the above process, it > will result in illegal sleep.
Reading Documentation/locking/locktypes.rst seems to suggest pstore does want the raw version. I'm surprised there aren't many more cases where this is a problem. :P -- Kees Cook
