linux-kernel - Re: Negative values in /proc/latency

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Fri, 6 Feb 2009 23:50:44 +0100
From:	Corrado Zoccolo <czoccolo@...il.com>
To:	Arjan van de Ven <arjan@...radead.org>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: Negative values in /proc/latency_stats

On Wed, Feb 4, 2009 at 6:55 AM, Arjan van de Ven <arjan@...radead.org> wrote:
> On Tue, 3 Feb 2009 21:46:09 -0800
>
>> > + * Negative latencies (caused by time going backwards) are also
>> > explicitly
>> > + * skipped.
>>
>> Are we sure that this was the cause of the problem?
>
> not 100%, but if you add only positive numbers..... the only other
> option is an overflow.. but that would be such a huge latency that that
> is not very believable.
>

I can confirm that those huge latencies were not real. I was using the
machine, and it was responsive when this was measured.
Maybe I can suggest an other option.. To measure a latency, you have
to set up a variable when you enter a wait state, and compute the
difference when you exit the waiting. If you forget to initialize the
variable in one of the paths leading to the waiting, when you do the
difference, you can end up with negative (or more generally,
meaningless) numbers.
Anyway, skipping these numbers is surely better than propagating them
to userspace, if the cause cannot be found.

An other random thought: since tracing can have noticeable overheads,
as Ingo noticed, and is likely that distros will ship with various
tracers enabled in the kernel, I think the scheme used to control them
should be more robust.
Currently, you can enable/disable them by writing 1/0 in a pseudo-file
under /proc, but what happens if the userspace program fails to write
the 0 in the file after it finished tracing (it can even not have
chance to do if it is killed -9)? I propose that tracers like this
one, i.e. that record instantaneous data, should remain enabled only
while the userspace process keeps the fd opened. When it's closed (or
after a grace period), the tracer should be automatically disabled.

Corrado
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/