Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp1037233imm; Fri, 13 Jul 2018 10:21:30 -0700 (PDT) X-Google-Smtp-Source: AAOMgpeAr0Lfy2scZxiXuLMCSY+vLPg/DooS3AbgQJ3yLIxnhkgq8wn0Zf0FoHxHbHxMsyztVfVn X-Received: by 2002:a62:4704:: with SMTP id u4-v6mr7992698pfa.76.1531502490387; Fri, 13 Jul 2018 10:21:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1531502490; cv=none; d=google.com; s=arc-20160816; b=Ey2Hc/3caGd9JDfsVOsQyrJ2Cf5kHUY/4IaI+IyEGBLQmFytlP8xcWFewsOEknyVVU Fsl+acet4ZxDKSCAt4XF30MWppNXfP1w75ieS96JM3+dW6F6H8TyCjuPiCvLkFZVzc5P orfn61hckjlj7pPZAoqcQ/JAfE78si6lpz/F04Atbt1jX4cS04VK6boqE0y6lZZbezy7 9IuBk5+InfrFvNKjLASdVdYJnbCFChkrHElDyo9RPEmPTOlcx4IGj+7gwmV0/Ig59Y6D 4i+mPk/6CzoOX5InC7rIg7r6tAWGmo1DShsileWi3EEOLDKZfrAIp4cZsyUXKat91GPn vQww== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=dn+Bph2u+s2kvXX976dZhlU7pRRj9I7o9bg1xcEI9V8=; b=yOfy0hY14hFRa+Mctgmr8O4Fdpb9yZcj1XS59+EsUkZLdU3RsOUTROfEfOgoa36Zrn swL1cya9+mmC6Sm+sl8goNjwhUv+nHAjKbWykm6YbANbtRKlE753DsObplvo7ZI69q3m aAGli0WykYobbRCf1wqdogH50DppBH1FFNttbUPi/KMz+Uc5P0w+YTh8ZFMscre/tlbu 7MvQAfrQmRbtVOqxAYcZ2zyoDjc/dCYnJFFxY8mvkC1feagL8F2W8GVeqI0mj9E+qVnP Y4UJ/PgZVm1XnR7dlmJjxL8waR/M/2HNU9ABj1lc1iss+YKW2937rzACV3dI8bJVZTda HkJA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=UIFeDm43; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v24-v6si23677385plo.159.2018.07.13.10.21.15; Fri, 13 Jul 2018 10:21:30 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=UIFeDm43; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731311AbeGMRgF (ORCPT + 99 others); Fri, 13 Jul 2018 13:36:05 -0400 Received: from mail-wr1-f66.google.com ([209.85.221.66]:40472 "EHLO mail-wr1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729783AbeGMRgF (ORCPT ); Fri, 13 Jul 2018 13:36:05 -0400 Received: by mail-wr1-f66.google.com with SMTP id t6-v6so25824279wrn.7 for ; Fri, 13 Jul 2018 10:20:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=dn+Bph2u+s2kvXX976dZhlU7pRRj9I7o9bg1xcEI9V8=; b=UIFeDm43CxdURUVElIuOVNiaPXJvyKB9of4hq3E5vfOOpH0JDTfcISnZyR1iMfJbQ1 dPk0z11mGXIRY4lQYjbcCVw1mbjKZrmQa5Q96ogRkjKlshOOA/qwdOOkT2kutf3d7eiZ Lmy0DVMWgCTYNY65MSS4Fyz0gy/UVv/gl+vUc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=dn+Bph2u+s2kvXX976dZhlU7pRRj9I7o9bg1xcEI9V8=; b=KMcGtVonw9P902+Zl9kmUy5MLrXX2/70LSa3JY84zCEvbwfncvVYRZ5ldwxLlp0Vnz 3XO6uZXlDL43m4Cjg6bFiG+prJh/B9C3GLmzSEYKKeJRqA9v4LW0cIB7O9OUs0BkvCGr LIWNgSiT3dIjVo5As5RDjgcYASFj7+p1HztWkjNHV0BiTVx8O/wp52Qb7YiJVt2dqnpT ZG/3I1ohqkoq9zCC3j1ERZSxoLSg5s3fKw03qVKTyKLZ3RhAEcka+Z3lBXbmZLjlsJxt zapDSy9AKUn392s5U0Qe2ktzsDWQ4Xk86I4Gx2qO4oqSUsW9FJEhlDSk2Or0DS2VhIAC efnw== X-Gm-Message-State: AOUpUlFG1XrcsPSZ9yWYTWOZNA6O0xEejBozHVSK/ftAFPuY6tmdyqPQ NaSCRGhN4j7eQbjiS0U5ob7OpSlfcBSDOd8b0ZabEw== X-Received: by 2002:adf:8296:: with SMTP id 22-v6mr5407757wrc.252.1531502431540; Fri, 13 Jul 2018 10:20:31 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a1c:c202:0:0:0:0:0 with HTTP; Fri, 13 Jul 2018 10:20:30 -0700 (PDT) In-Reply-To: <7e25b63e-cc9b-1f6d-e3d2-087dd484f631@codeaurora.org> References: <1530883047-17452-1-git-send-email-mojha@codeaurora.org> <7e25b63e-cc9b-1f6d-e3d2-087dd484f631@codeaurora.org> From: John Stultz Date: Fri, 13 Jul 2018 10:20:30 -0700 Message-ID: Subject: Re: [PATCH v3] time: Fix incorrect sleeptime injection when suspend fails To: Mukesh Ojha Cc: Thomas Gleixner , lkml , gkohli@codeaurora.org, cpandya@codeaurora.org, neeraju@codeaurora.org, Baolin Wang Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jul 13, 2018 at 12:13 AM, Mukesh Ojha wrote: > Hi John, > > Thanks for your response > Please find my comments inline. > > > On 7/11/2018 1:43 AM, John Stultz wrote: >> >> On Fri, Jul 6, 2018 at 6:17 AM, Mukesh Ojha wrote: >>> >>> Currently, there exists a corner case assuming when there is >>> only one clocksource e.g RTC, and system failed to go to >>> suspend mode. While resume rtc_resume() injects the sleeptime >>> as timekeeping_rtc_skipresume() returned 'false' (default value >>> of sleeptime_injected) due to which we can see mismatch in >>> timestamps. >>> >>> This issue can also come in a system where more than one >>> clocksource are present and very first suspend fails. >>> >>> Fix this by handling `sleeptime_injected` flag properly. >>> >>> Success case: >>> ------------ >>> {sleeptime_injected=false} >>> rtc_suspend() => timekeeping_suspend() => timekeeping_resume() => >>> >>> (sleeptime injected) >>> rtc_resume() >>> >>> Failure case: >>> ------------ >>> {failure in sleep path} {sleeptime_injected=false} >>> rtc_suspend() => rtc_resume() >>> >>> sleeptime injected again which was not required as the suspend failed) >>> >>> Originally-by: Thomas Gleixner >>> Signed-off-by: Mukesh Ojha >>> --- >>> Changes in v3: >>> * Updated commit subject and description. >>> * Updated the patch as per the fix given by Thomas Gleixner. >>> >>> Changes in v2: >>> * Updated the commit text. >>> * Removed extra variable and used the earlier static >>> variable 'sleeptime_injected'. >>> >>> kernel/time/timekeeping.c | 21 ++++++++++++++++++--- >>> 1 file changed, 18 insertions(+), 3 deletions(-) >>> >>> diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c >>> index 4786df9..32ae9ae 100644 >>> --- a/kernel/time/timekeeping.c >>> +++ b/kernel/time/timekeeping.c >>> @@ -1510,8 +1510,20 @@ void __weak read_boot_clock64(struct timespec64 >>> *ts) >>> ts->tv_nsec = 0; >>> } >>> >>> -/* Flag for if timekeeping_resume() has injected sleeptime */ >>> -static bool sleeptime_injected; >>> +/* >>> + * Flag reflecting whether timekeeping_resume() has injected sleeptime. >>> + * >>> + * The flag starts of true and is only cleared when a suspend reaches >>> + * timekeeping_suspend(), timekeeping_resume() sets it when the >>> timekeeper >>> + * clocksource is not stopping across suspend and has been used to >>> update >>> + * sleep time. If the timekeeper clocksource has stopped then the flag >>> + * stays false and is used by the RTC resume code to decide whether >>> sleep >>> + * time must be injected and if so the flag gets set then. >>> + * >>> + * If a suspend fails before reaching timekeeping_resume() then the flag >>> + * stays true and prevents erroneous sleeptime injection. >>> + */ >>> +static bool sleeptime_injected = true; >> >> I worry this upside-down logic is too subtle to be easily reasoned >> about, and will just lead to future mistakes. >> >> Can we instead call this "suspend_timing_needed" and only set it to >> true when we don't inject any sleep time on resume? > > > I did not get your point "only set it to true when we don't inject any sleep > time on resume? " > How do we know this ? > This question itself depends on the "sleeptime_injected" if it is true means > no need to inject else need to inject. > > Also, we need to make this variable back and forth true, false; suspends > path ensures it to make it false. So yea, I'm not saying logically the code is really any different, this is more of a naming nit. So instead of having a variable that is always on that we occasionally turn off, lets invert the naming and have it be a flag that we occasionally turn on. Just the name sleeptime_injected is read a statement, which if we say is defaults to true, becomes confusing to think about when the timekeeping_suspend/resume code hasn't yet run (which is the case where your error cropped up) - and no sleeptime has actually been injected. So instead if we call it suspend_timing_needed and only set it on in timekeeping_resume() after the timekeeping code has not injected any sleep-time, then I think the code will make more sense to read. (And yes, we still need to set suspend_timing_needed false on timekeeping_suspend and in the inject_sleeptime call path - the logic doesn't change, just the naming and boolean state). thanks -john