Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp114270imm; Thu, 10 May 2018 16:38:56 -0700 (PDT) X-Google-Smtp-Source: AB8JxZqEQJW+6kwXxD4BBr1+9NgpWC7Yh2/04QrSKmrlQa+puNALWzGUEYPiXXLv9iaaZ/KkbZNT X-Received: by 2002:a62:d38f:: with SMTP id z15-v6mr3183559pfk.100.1525995536216; Thu, 10 May 2018 16:38:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525995536; cv=none; d=google.com; s=arc-20160816; b=NC3/9kTTctck/s+D6Gmw/B9Id/RlsfIwjjHkDJPtl/fT5ymYQWLXgsdZubLOjb2ohd emUw81mHlZ5AUESFmBIszGotjNdKyYGjih/3ybbTm7vxEdk136r8vD9oc3hMex/G7P/P nOHakrIO+xShOghDw2dyGEg6a+9o0r4Wt9FyFoycECc3mwfFwdwlzw1XEhezACzYf+NT dnH+uwmkvRuBUXHVXLBbSyVE5sp4j3X8EYLk8jF4zJ7iX4K4VprL+0GZDEy/4bQNkJKr Vq410tKBGWJuDki4tXMOpepkRRvzxMD58XrM/XF2oqShZ9F8Kwua1o7q+O+0dZ9315bf Ti2g== 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=qIvXZuj2yWw6Thyig86c0TjfW6kH+R3fqXUsHT6iZfM=; b=UfBloW1WvQA5RSUe6k0bfC12lenBQAnQPBI2NRMuKDMEIlaSS6rtpAls4FvqAqEnEd YJ1KNTgibz8MmP75J9Pnt3wO8SFoyZ3uoalqx0T+LW/tIso9e6uiP1eVjroYUbJXSjPd Ddg3SeIlA2rScuficqIUez+QPj1fxVvT+3rMVRqtFFKuFV46Q1LN1e5RkKLFd2NqO4ID tEHJeIpLX1RxuF7/cCBlF+yrggzdpIk5dfVLPCHmRAdG7WChnhgY77A8jX4UqClvcIKA 37leI/jwSrPxIVHHpjn7XH4i6lvnCibcc4FH8gwZPNeudS1S7p6G1bLkeW6r2cYQw4+k lj0w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=uQmke7MC; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 31-v6si1825837pli.404.2018.05.10.16.38.41; Thu, 10 May 2018 16:38:56 -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=@google.com header.s=20161025 header.b=uQmke7MC; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751169AbeEJXhV (ORCPT + 99 others); Thu, 10 May 2018 19:37:21 -0400 Received: from mail-ot0-f194.google.com ([74.125.82.194]:37138 "EHLO mail-ot0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750746AbeEJXhT (ORCPT ); Thu, 10 May 2018 19:37:19 -0400 Received: by mail-ot0-f194.google.com with SMTP id 77-v6so4253422otd.4 for ; Thu, 10 May 2018 16:37:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qIvXZuj2yWw6Thyig86c0TjfW6kH+R3fqXUsHT6iZfM=; b=uQmke7MCYeHS/P/OUIJGWFFvRIhmNqvAAKMNkuP4dVFcl0kO0OihxKvARGgKe9PgA+ cQzvZpf1dJ3pHDU8t8wODCXkUGCyyNcry4lrSo46RR1IzW/nmBA7PMniJXkEqUMhg5fp LRF6nosx+IhM3fRvdXAcMl0QIg7qhFA7lXtxyGlKo1gi89tssmoK8wkcVuhQjhr9XppR 8iSfpsGUoixvAsuGcKLyIIvSwO+Jit7HMoQGJiijnETmdyVRLh9Yf/DUEOdT5hUuA7xg ALotRBOnus3TKIG0rzNSD2FzSkK9nfs+Q7eZvw87NWei3ZNjsaw/Dft6haYx0o8iH43g XkFg== 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=qIvXZuj2yWw6Thyig86c0TjfW6kH+R3fqXUsHT6iZfM=; b=uQb4Nq+E1vl4CgVcrP3Qdn4gjroBNcAVS9ycuErc3qvy9/IDcZZrZLDcVR3xnjVCQ3 Xl4IA4l+gxTQVh0qGM/37v5w6Say8xm0ezi4YxTaZEU0jG5GruNZ8U0hHsodRYABTaBf t80hkMRDxDH2yQhCRsJ7CPBfGvxt/bDp5mXg6SN0RkHlApxjTkH3sPrce6p2VOwwU+E4 bnfbyZABg64VxDDAQKbwtjCiIb1ClkaaHSBecotIbZzTEiKd0ekP6y7bgIxmo/Qn275G coPfNGJbHPcC8fc/zK1i4Mcv3maxWkjvuw+knMgAn8UFOKwfyW3dvIlb3+9fMOFGypm5 AGvA== X-Gm-Message-State: ALKqPwcsg22/x1V7O/p9ZdSEpsb78P68WZONcLe9AhZrd4MT23H8WTVa XpBw4biDbBg7c9Kw2Duc9Eke44IaFtTDBiz5VLngYA== X-Received: by 2002:a9d:4713:: with SMTP id a19-v6mr2456062otf.7.1525995438696; Thu, 10 May 2018 16:37:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.11.87 with HTTP; Thu, 10 May 2018 16:36:38 -0700 (PDT) In-Reply-To: <20180510233426.94514-1-rajatja@google.com> References: <20180508230148.121852-1-rajatja@google.com> <20180510233426.94514-1-rajatja@google.com> From: Rajat Jain Date: Thu, 10 May 2018 16:36:38 -0700 Message-ID: Subject: Re: [PATCH] PM / s2idle: Clear the events_check_enabled flag To: "Rafael J. Wysocki" , Pavel Machek , Len Brown , Linux PM , Linux Kernel Mailing List , Dmitry Torokhov , Rajat Jain Cc: Rajat Jain 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 Sorry, please ignore, sent by mistake. On Thu, May 10, 2018 at 4:34 PM, Rajat Jain wrote: > Problem: This flag does not get cleared currently in the suspend or > resume path in the following cases: > > * In case some driver's suspend routine returns an error. > * Successful s2idle case > * etc? > > Why is this a problem: What happens is that the next suspend attempt > could fail even though the user did not enable the flag by writing to > /sys/power/wakeup_count. This is 1 use case how the issue can be seen > (but similar use case with driver suspend failure can be thought of): > > 1. Read /sys/power/wakeup_count > 2. echo count > /sys/power/wakeup_count > 3. echo freeze > /sys/power/wakeup_count > 4. Let the system suspend, and wakeup the system using some wake source > that calls pm_wakeup_event() e.g. power button or something. > 5. Note that the combined wakeup count would be incremented due > to the pm_wakeup_event() in the resume path. > 6. After resuming the events_check_enabled flag is still set. > > At this point if the user attempts to freeze again (without writing to > /sys/power/wakeup_count), the suspend would fail even though there has > been no wake event since the past resume. > > What this patch does: > > It moves the clearing of the flag to just before a resume is completed, > so that it is always cleared for the corner cases mentioned above. > > Signed-off-by: Rajat Jain > --- > kernel/power/suspend.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/kernel/power/suspend.c b/kernel/power/suspend.c > index ccd2d20e6b06..0685c4499431 100644 > --- a/kernel/power/suspend.c > +++ b/kernel/power/suspend.c > @@ -437,7 +437,6 @@ static int suspend_enter(suspend_state_t state, bool *wakeup) > error = suspend_ops->enter(state); > trace_suspend_resume(TPS("machine_suspend"), > state, false); > - events_check_enabled = false; > } else if (*wakeup) { > error = -EBUSY; > } > @@ -582,6 +581,7 @@ static int enter_state(suspend_state_t state) > pm_restore_gfp_mask(); > > Finish: > + events_check_enabled = false; > pm_pr_dbg("Finishing wakeup.\n"); > suspend_finish(); > Unlock: > -- > 2.15.0.403.gc27cc4dac6-goog >