linux-kernel - Re: [RFC PATCH v7 4/5] tracing: Measure delayed hrtimer offset 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] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.20.1609211720520.5573@nanos>
Date:   Wed, 21 Sep 2016 17:58:34 +0200 (CEST)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Binoy Jayan <binoy.jayan@...aro.org>
cc:     Carsten Emde <C.Emde@...dl.org>,
        "Steven Rostedt (Red Hat)" <rostedt@...dmis.org>,
        Ingo Molnar <mingo@...hat.com>,
        Daniel Wagner <daniel.wagner@...-carit.de>,
        Arnd Bergmann <arnd@...db.de>,
        Linux kernel mailing list <linux-kernel@...r.kernel.org>,
        Masami <masami.hiramatsu@...aro.org>,
        Mark Brown <mark.brown@...aro.org>
Subject: Re: [RFC PATCH v7 4/5] tracing: Measure delayed hrtimer offset
 latency

On Wed, 21 Sep 2016, Binoy Jayan wrote:
> On 20 September 2016 at 19:49, Thomas Gleixner <tglx@...utronix.de> wrote:
> > You still fail to explain why this get_time() magic is required.
> 
> Sorry, I missed to address this comment from you. From what I understand
> why the get_time() is needed is to get the more accurate current time
> when the hrtimer base is changed (from the cpu in which it was fired on,
> to the current cpu on which it is currently made to run or restarted)
> wherein the hrtimer base needs to be switched to the new cpu provided
> that it is not running in pinned mode.

Sorry. This has nothing to do with changing the hrtimer_base, simply
because the time base is the same on all cpus.

> Carsten, Could you please comment on that?

It's not Carstens repsonsibility to explain the nature of the change.

You are submitting that code and so it's your job to provide proper
explanations and justifications. If you can't do that, then how do you
think that the review process, which is a feedback loop between the
reviewer and the submitter, should work?

Answer: It cannot work that way. I hope I don't have to explain why.

Thanks,

	tglx