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]
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ