Messages in this thread | | | Date | Fri, 10 Nov 2017 01:46:52 +0100 (CET) | From | Thomas Gleixner <> | Subject | Re: [PATCH] pstore: use ktime_get_real_fast_ns() instead of __getnstimeofday() |
| |
On Fri, 10 Nov 2017, Arnd Bergmann wrote: > On Fri, Nov 10, 2017 at 12:00 AM, Thomas Gleixner <tglx@linutronix.de> wrote: > > Hmm, no. None of the regular accessor functions can be called from NMI > > context safely. > > Right, that's what I mean: it must not get called from NMI context, but it > currently is, at least for this case: > > NMI handler: > something bad > panic() > kmsg_dump() > pstore_dump() > pstore_record_init() > __getnstimeofday() > > I should probably add that to the changelog text ;-)
Indeed.
> Also, I have a related patch series that renames getrawmonotonic64(), > current_kernel_time64() and get_monotonic_coarse64() to > ktime_get_raw_ts64(), ktime_get_coarse_real_ts64() and > ktime_get_coarse_ts64(), for consistency, but then I couldn't > come up with a good name for __getnstimeofday64(), as the > __ktime_get_*() naming is already used for a number of other > things and I did not want to overload that more. Completely > removing __getnstimeofday64() would be handier here.
Oh yes, it's an abomination.
> > The normal timekeeping accessor functions cannot be called between > > timekeeping_suspend() and timekeeping_resume() at all. They will emit a > > warning and can indeed crash and burn in one of the ways you described > > above. This does not happen on x86 because the TSC will just work on > > systems with pstore. > > Sure, except for __getnstimeofday64(), which will intentionally not warn but > could crash in the clocksource driver (on non-x86). We do ignore the result > from __getnstimeofday64() when timekeeping is suspended, but only after > we call into the clocksource driver.
Right, let's get rid of it before it grows another user.
Thanks,
tglx
| |