On Tue, 28 May 2024 at 15:12, Thomas Gleixner <t...@linutronix.de> wrote:
>
> I principle it applies to any clocksource which needs a spinlock to
> serialize access. HPET is not the only insanity here.
HPET may be the main / only one we care about.
Because:
> Think about i8253 :)
I see the smiley, but yeah, I don't think we really care about it.
> 1) Should we provide a panic mode read callback for clocksources which
> are affected by this?
The current patch under discussion may be ugly, but looks workable.
Local ugliness isn't necessarily a show-stopper.
So if the HPET is the *only* case which has this situation, I vote for
just doing the ugly thing.
Now, if *other* cases exist, and can't be worked around in similar
ways, then that argues for a more "proper" fix.
And no, I don't think i8253 is a strong enough argument. I don't
actually believe you can realistically find a machine that doesn't
have HPET or the TSC and really falls back on the i8253 any more. And
if you *do* find hw like that, is it SMP-capable? And can you find
somebody who cares?
> 2) Is it correct to claim that a MCE which hits user space and ends up in
> mce_panic() is still just a regular exception or should we upgrade to
> NMI class context when we enter mce_panic() or even go as far to
> upgrade to NMI class context for any panic() invocation?
I do think that an NMI in user space should be considered mostly just
a normal exception. From a kernel perspective, the NMI'ness just
doesn't matter.
That said, I find your suggestion of making 'panic()' just basically
act as an NMI context intriguing. And cleaner than the
atomic_read(&panic_cpu) thing.
Are there any other situations than this odd HPET thing where that
would change semantics?
Linus
