From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932322AbdJZJEg (ORCPT ); Thu, 26 Oct 2017 05:04:36 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:36722 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751009AbdJZJEe (ORCPT ); Thu, 26 Oct 2017 05:04:34 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org 3FAE0602BC Authentication-Results: pdx-caf-mail.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: pdx-caf-mail.web.codeaurora.org; spf=none smtp.mailfrom=neeraju@codeaurora.org To: tglx@linutronix.de Cc: sramana@codeaurora.org, sboyd@codeaurora.org, linux-kernel@vger.kernel.org From: Neeraj Upadhyay Subject: Query regarding __hrtimer_get_next_event() Message-ID: <2981b733-84ea-b46f-b16c-91aaa5a96c6c@codeaurora.org> Date: Thu, 26 Oct 2017 14:34:29 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, We have one query regarding the __hrtimer_get_next_event(). The expires_next.tv64 is set to 0 if it is < 0. We observed an hrtimer interrupt storm for one of the hrtimers with below properties: * Expires for the hrtimer was set to KTIME_MAX. * cpu base was HRTIMER_BASE_REALTIME with negative base->offset. * Due to below sub, expires overflowed to a negative value and expires_next.tv64 was set to 0 expires = ktime_sub(hrtimer_get_expires(timer), base->offset); * Due to this, clockevent was programmed to min_delta_ns, everytime as __hrtimer_get_next_event() returned 0. static ktime_t __hrtimer_get_next_event(...) { for (; active; base++, active >>= 1) { timer = container_of(next, struct hrtimer, node); expires = ktime_sub(hrtimer_get_expires(timer), base->offset); if (expires.tv64 < expires_next.tv64) { expires_next = expires; hrtimer_update_next_timer(cpu_base, timer); } } if (expires_next.tv64 < 0) expires_next.tv64 = 0; return expires_next; } This may not be a valid use case (queuing a hrtimer with KTIME_MAX) expires, but should we guard the hrtimer next event code against this by using KTIME_MAX upper bound. Is something like below a proper way to guard it? Or am I missing something here? expires = ktime_sub(hrtimer_get_expires(timer), base->offset); + /* + * if expires is a very high positive value and base->offset is + * negative, expires can overflow and get negative value. Set + * expires to KTIME_MAX, if we encounter this. + */ + if (hrtimer_get_expires(timer).tv64 > 0 && + base->offset.tv64 < 0 && expires.tv64 < 0) + expires.tv64 = KTIME_MAX; + Thanks Neeraj -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation