| 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
| ||
|
Message-ID: <A0A1E7539300DF49AA383E614C7827BC04930A0DBB@HQMAIL01.nvidia.com> Date: Tue, 30 Mar 2010 08:58:47 -0700 From: Gary King <GKing@...dia.com> To: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org> CC: "tglx@...utronix.de" <tglx@...utronix.de>, Gary King <GKing@...dia.com> Subject: Bug in hrtimer_get_next_event? I am implementing idle state controls (CPU_IDLE) for Tegra SoCs, and one of the idle states is not awakened by the hrtimer interrupt. There is a system-wide high-resolution timer which can be used as a wakeup source, but I need the high-resolution sleep time to configure the alarm. To fix this, I want to use hrtimer_get_next_event; however, the code that is in the tree only walks the hrtimer bases when hres mode is not active; when hres mode is active, hrtimer_get_next_event always returns KTIME_MAX. Is there any reason for the negative comparison, or is this a bug? After changing this locally, I encountered one other problem on dynamic-tick systems: get_next_timer_interrupt is called to determine whether or not it is safe to enter nohz mode; however, hrtimer_get_next_event (which is used by get_next_timer_interrupt) will always return <=1 jiffy, since the emulated tick scheduler event will be armed when tick_nohz_stop_sched_tick queries the sleep time. As a result, tick_nohz_stop_sched_tick will never enter nohz mode. I can think of a couple ways to address this (cancel the tick timer before querying the event and rearm if necessary from either the arch cpu_idle code or nohz_stop_sched_tick; ignore the tick timer in hrtimer_get_next_event); does anyone have a recommendation for a preferred approach? - Gary gking@...dia.com ----------------------------------------------------------------------------------- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ----------------------------------------------------------------------------------- -- 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