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-next>] [day] [month] [year] [list]
Message-ID: <5575911c82b96b23fdcaeb71bde87e9e.squirrel@www.codeaurora.org>
Date:	Wed, 21 Jan 2015 12:56:06 -0000
From:	vigneshr@...eaurora.org
To:	tglx@...utronix.de, stfomichev@...dex-team.ru
Cc:	linux-kernel@...r.kernel.org, john.stultz@...aro.org,
	viresh.kumar@...aro.org, fweisbec@...il.com, mingo@...nel.org,
	cl@...ux.com, psodagud@...eaurora.org, sboyd@...eaurora.org
Subject: RE: [PATCH v3] hrtimers: calculate expires_next after all timers are
 executed

Hi Thomas,

In this patch, we are only setting the flag
cpu_base->in_hrtirq = 1; in hrtimer_interrupt() and not resetting it.


> @@ -1251,9 +1251,9 @@ void hrtimer_interrupt(struct clock_even
> dev->next_event.tv64 = KTIME_MAX;
>
> raw_spin_lock(&cpu_base->lock);
> + cpu_base->in_hrtirq = 1;

Since this is the case, after the hrtimer_interrupt routine completes and
new timer is started and say it happens to be leftmost,
we don't allow hrtimer_reprogram() since we bail out given that
cpu_base->in_hrtirq=1 :

timer irq comes
--->hrtimer_interrupt()
---->cpu_base->in_hrtirq flag is set
------>Interrupt is serviced

After sometime

-->__hrtimer_start_range_ns()
--->happens to be leftmost hence call hrtimer_enqueue_reprogram()
----->hrtimer_reprogram()
------->bail out since cpu_base->in_hrtirq flag is stil set

At the end of hrtimer interrupt routine, i think we should also clear this
flag.

Something like the following can be added ?

diff --git a/kernel/time/hrtimer.c b/kernel/time/hrtimer.c
index 8c94a55..b663653 100644
--- a/kernel/time/hrtimer.c
+++ b/kernel/time/hrtimer.c
@@ -1251,9 +1251,9 @@ void hrtimer_interrupt(struct clock_event_device *dev)
        dev->next_event.tv64 = KTIME_MAX;

        raw_spin_lock(&cpu_base->lock);
-       cpu_base->in_hrtirq = 1;
        entry_time = now = hrtimer_update_base(cpu_base);
 retry:
+       cpu_base->in_hrtirq = 1;
        /*
         * We set expires_next to KTIME_MAX here with cpu_base->lock
         * held to prevent that a timer is enqueued in our queue via
@@ -1304,6 +1304,7 @@ retry:
         * against it.
         */
        cpu_base->expires_next = expires_next;
+       cpu_base->in_hrtirq = 0;
        raw_spin_unlock(&cpu_base->lock);

        /* Reprogramming necessary ? */

Thanks and regards,
vignesh Radhakrishnan

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ