From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755232AbdKJHEe (ORCPT ); Fri, 10 Nov 2017 02:04:34 -0500 Received: from Galois.linutronix.de ([146.0.238.70]:53897 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750847AbdKJHEd (ORCPT ); Fri, 10 Nov 2017 02:04:33 -0500 Date: Fri, 10 Nov 2017 08:04:24 +0100 (CET) From: Thomas Gleixner To: Kees Cook cc: Arnd Bergmann , Anton Vorontsov , Colin Cross , Tony Luck , John Stultz , Stephen Boyd , Ingo Molnar , LKML Subject: Re: [PATCH] pstore: use ktime_get_real_fast_ns() instead of __getnstimeofday() In-Reply-To: Message-ID: References: <20171108160056.3042976-1-arnd@arndb.de> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 9 Nov 2017, Kees Cook wrote: > On Thu, Nov 9, 2017 at 4:46 PM, Thomas Gleixner wrote: > > On Fri, 10 Nov 2017, Arnd Bergmann wrote: > >> On Fri, Nov 10, 2017 at 12:00 AM, Thomas Gleixner 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. > > Er, so, is this safe to call there? I've had to fix this a few times > now, so if using ktime_get_real_fast_ns() can be used here (and > doesn't return 0) then this is easily an improvement over the existing > "maybe read 0" case pstore has now. ktime_get_real_fast_ns() is NMI safe and returns before timekeeping_suspend(): correct time after timekeeping_suspend(): timestamp which was frozen in timekeeping_suspend() after timekeeping_resume(): correct time Thanks, tglx