On 5/27/24 23:38, Tony W Wang-oc wrote: ...> diff --git a/arch/x86/kernel/hpet.c b/arch/x86/kernel/hpet.c > index c96ae8fee95e..ecadd0698d6a 100644 > --- a/arch/x86/kernel/hpet.c > +++ b/arch/x86/kernel/hpet.c > @@ -804,6 +804,12 @@ static u64 read_hpet(struct clocksource *cs) > if (in_nmi()) > return (u64)hpet_readl(HPET_COUNTER); > > + /* > + * Read HPET directly if panic in progress. > + */ > + if (unlikely(atomic_read(&panic_cpu) != PANIC_CPU_INVALID)) > + return (u64)hpet_readl(HPET_COUNTER); > +
There is literally one other piece of the code in the kernel doing something similar: the printk() implementation. There's no other clocksource or timekeeping code that does this on any architecture. Why doesn't this problem apply to any other clock sources? Why should the problem be fixed in the clock sources themselves? Why doesn't printk() deadlock on systems using the HPET? In other words, I think we should fix pstore to be more like printk rather than hacking around this in each clock source.