From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S965548AbcAUQJ6 (ORCPT <rfc822;w@1wt.eu>);
	Thu, 21 Jan 2016 11:09:58 -0500
Received: from mx1.redhat.com ([209.132.183.28]:39499 "EHLO mx1.redhat.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S964802AbcAUQJ5 (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Thu, 21 Jan 2016 11:09:57 -0500
Message-ID: <56A102D2.2040009@redhat.com>
Date: Thu, 21 Jan 2016 11:09:54 -0500
From: Prarit Bhargava <prarit@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Thomas Gleixner <tglx@linutronix.de>, Petr Mladek <pmladek@suse.com>
CC: linux-kernel@vger.kernel.org, John Stultz <john.stultz@linaro.org>,
        Xunlei Pang <pang.xunlei@linaro.org>,
        Baolin Wang <baolin.wang@linaro.org>,
        Andrew Morton <akpm@linux-foundation.org>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Tejun Heo <tj@kernel.org>, Peter Hurley <peter@hurleysoftware.com>,
        Vasily Averin <vvs@virtuozzo.com>, Joe Perches <joe@perches.com>
Subject: Re: [PATCH 0/2] printk, Add printk.clock kernel parameter [v2]
References: <1452688466-14877-1-git-send-email-prarit@redhat.com> <alpine.DEB.2.11.1601131443380.3575@nanos> <569660FA.2020802@redhat.com> <alpine.DEB.2.11.1601131550410.3575@nanos> <20160114125238.GU731@pathway.suse.cz> <alpine.DEB.2.11.1601141543130.3575@nanos>
In-Reply-To: <alpine.DEB.2.11.1601141543130.3575@nanos>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org



On 01/14/2016 09:44 AM, Thomas Gleixner wrote:
> On Thu, 14 Jan 2016, Petr Mladek wrote:
>> On Wed 2016-01-13 18:28:50, Thomas Gleixner wrote:
>>> You can solve the whole business by changing the timestamp in printk_log to
>>>
>>>    u64	    mono;
>>>    u64	    offset_real;
>>
>> This is not so easy because the structure is proceed by userspace tool,
>> e.g. crash, see log_buf_kexec_setup(). We would need to update all
>> the tools as well.
> 
> Fair enough.
>  
>>> and have a function which does:
>>>
>>> u64 ktime_get_log_ts(u64 *offset_real)
>>> {
>>> 	*offset_real = tk_core.timekeeper.offs_real;
>>>
>>> 	if (timekeeping_active)
>>> 		return ktime_get_mono_fast_ns();
>>> 	else
>>> 		return local_clock();
>>> }
>>
>> A solution would be to apply the offset_real immediately. I wonder if
>> any tool expects the messages to be sorted by a monotonic clock. In
>> fact, it might be useful to see that some messages are disordered
>> against the real time, e.g. because of the leaf second.

I've tested v2 with the leap second and haven't seen anything unusual on Fedora23.

> 
> Not only leap seconds, it's also settimeofday and NTP might make the wall time
> jump under certain conditions.

Also tried this as well to set the time to different timezones as well as
setting the RTC in BIOS to the wrong time to see if there were any issues.
Again, nothing seemed to happen.

... noting of course the previously mentioned issue with /var/log/messages &
systemd that Petr found.

So IIUC ... I want real time to be reported (not boot or TAI), use tglx's
suggestion of ktime_get_log_ts(), and implement printk.time=1 (local_clock())
and printk.time=2 (real clock).

Is that correct?

P.

> 
> Thanks,
> 
> 	tglx
>