lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Mon, 08 Feb 2016 11:05:05 -0500
From:	Prarit Bhargava <prarit@...hat.com>
To:	Petr Mladek <pmladek@...e.com>
CC:	linux-kernel@...r.kernel.org, John Stultz <john.stultz@...aro.org>,
	Xunlei Pang <pang.xunlei@...aro.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Baolin Wang <baolin.wang@...aro.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Tejun Heo <tj@...nel.org>,
	Peter Hurley <peter@...leysoftware.com>,
	Vasily Averin <vvs@...tuozzo.com>,
	Joe Perches <joe@...ches.com>
Subject: Re: [PATCH] printk, allow different timestamps for printk.time [v2]



On 02/08/2016 10:51 AM, Petr Mladek wrote:
> On Thu 2016-02-04 12:03:27, Prarit Bhargava wrote:
>>
>>
>> On 02/04/2016 11:48 AM, Petr Mladek wrote:
>>> On Thu 2016-01-28 07:43:49, Prarit Bhargava wrote:
>>>> +static u64 printk_get_ts(void)
>>>> +{
>>>> +	u64 mono, offset_real;
>>>> +
>>>> +	if (printk_time == 0)
>>>> +		return 0;
>>>> +
>>>> +	if (printk_time == 1)
>>>> +		return local_clock();
>>>> +
>>>> +	mono = ktime_get_log_ts(&offset_real);
>>>> +
>>>> +	if (printk_time == 2)
>>>> +		return mono;
>>>> +
>>>> +	return mono + offset_real;
>>>
>>> At least dmesg is not capable to read the absolute size of the
>>> real time. It expects offset against the start of the timekeeping
>>> stuff or so. I get this:
>>>
>>> $> dmesg | tail -n 5
>>> [    7.128924] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
>>> [    0.000000] printk: timestamp set to 0.
>>
>> ^^^ Hmm ... I'll have to think about that.
>>
>>> [  179.983704] printk: timestamp set to 1.
>>> [  181.895655] printk: timestamp set to 2.
>>> [1454602412.026424] printk: timestamp set to 3.
>>>
>>> $dmesg -T -S | tail -n 5
>>> [Thu Feb  4 17:10:34 2016] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
>>> [Thu Feb  4 17:10:27 2016] printk: timestamp set to 0.
>>> [Thu Feb  4 17:13:26 2016] printk: timestamp set to 1.
>>> [Thu Feb  4 17:13:28 2016] printk: timestamp set to 2.
>>> [Fri Mar 10 09:23:59 2062] printk: timestamp set to 3.
>>
>> Yes, this is a known issue that someone else previously brought to my attention
>> on LKML.
> 
> It was me ;-)
> 
>> I will have to modify dmesg once this code is stabilized.
> 
> But how will dmesg detect when the time is a real time or an offset?
> There is still a bit available in struct printk_log in the flags
> variable but...
> 
> Also note that there are more tools that might need to get updated.
> For example, "crash" and maybe "gdb" are able to print the messages
> from the crashdump.
> 
> I still think that it might be easier to convert the real time to
> the offset before storing it.

Hmm ... good point.  I guess I was still thinking about my original patch that
had introduced /sys/modules/printk/parameters/clock which userspace could read.

tglx, any objection to the suggested changes here?  I would have to modify all
the configs, etc. so that CONFIG_PRINTK_TIME was an int instead of a bool.

P.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ