From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751507AbeAYOtU (ORCPT ); Thu, 25 Jan 2018 09:49:20 -0500 Received: from mail1.windriver.com ([147.11.146.13]:40010 "EHLO mail1.windriver.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750940AbeAYOtT (ORCPT ); Thu, 25 Jan 2018 09:49:19 -0500 Subject: Re: [PATCH] kdb: Change timespec to use timespec64 To: Daniel Thompson , Baolin Wang CC: Arnd Bergmann , Ingo Molnar , Mark Brown , , Linux Kernel Mailing List References: <20180125113808.3bzgh6zloosw76yv@oak.lan> From: Jason Wessel Message-ID: Date: Thu, 25 Jan 2018 08:49:02 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <20180125113808.3bzgh6zloosw76yv@oak.lan> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 01/25/2018 05:38 AM, Daniel Thompson wrote: > On Thu, Jan 25, 2018 at 05:18:54PM +0800, Baolin Wang wrote: >> On 25 January 2018 at 16:55, Arnd Bergmann wrote: >>> On Thu, Jan 25, 2018 at 9:05 AM, Baolin Wang wrote: >>>> @@ -2554,7 +2554,7 @@ static int kdb_summary(int argc, const char **argv) >>>> kdb_printf("domainname %s\n", init_uts_ns.name.domainname); >>>> kdb_printf("ccversion %s\n", __stringify(CCVERSION)); >>>> >>>> - now = __current_kernel_time(); >>>> + now = current_kernel_time64(); >>>> kdb_gmtime(&now, &tm); >>>> kdb_printf("date %04d-%02d-%02d %02d:%02d:%02d " >>>> "tz_minuteswest %d\n", >>> >>> Thanks for picking this one up again, we should find a permanent solution here. >>> Unfortunately you patch is incorrect, as we cannot safely call >>> current_kernel_time64() >>> from NMI context. >> >> Ah, thanks for pointing out the issue, since I do not know what >> context the function will be called in kdb. >> >>> >>> The __ prefix on __current_kernel_time() indicates that this is a special call >>> that intentionally doesn't read the hardware time to avoid taking locks that >>> might already be held in the context from which we entered the debugger. >>> >>> See https://patchwork.kernel.org/patch/10002097/ for my earlier patch. >> >> This patch had not been merged into mainline? > > Not yet (and I'm afraid it's not in kgdb-next either) but the ack from Jason is from > this kernel cycle so we'll see what can be done! > > I thought for what ever reason this was going through the time keeper subtree. I added it immediately to kgdb-next so it will be evaluated in the linux-next tree in the next day or so, and we can get this merged in the merge window. Thanks, Jason.