Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp111824imm; Thu, 10 May 2018 16:35:31 -0700 (PDT) X-Google-Smtp-Source: AB8JxZr3fsqHGjCwVzWF+r5djyHnW1Q94Yjbl6/Wug7NacU87q+lTv/uBftdwigPQigm7fvQi+3d X-Received: by 2002:a17:902:9883:: with SMTP id s3-v6mr3183652plp.179.1525995331518; Thu, 10 May 2018 16:35:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525995331; cv=none; d=google.com; s=arc-20160816; b=F2q9LWfXPkIg9z+5oORDpMBhzeRuK0sMWc+3lBWWLq9sIrkPGTsWEfyllaUuczKXit nna8OQBOsDe97QB6AvJ8A3sHMyG4QCV1gqQX7p2/jeZYY8E56tV5r18JYM7d7oGgTE32 EBCS/zMJ/Wqjmg26rbawiKRuxo3dSxBxMmw1Vo7eMhQKIDsVmwfBq/7pLJGoEn4f3pPj TGrGBm9YkA/KJQ+rni/WDUkIIrx6xsPHsK9hdyX+d6KS1R5+QxW6777ZCpsx+/G9DV3O D0OFWnbfmZClSz0lWL2JGHfMx3IPklK9okDmiMWAd5jpjH/5a1Y5sn57nF5jq4W2/PrJ 9gRw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from:dkim-signature:arc-authentication-results; bh=mZCqjPfjp4rbF273iD6Le+oxUut59v1vQ68rWn4xUBE=; b=R8gfFN1YMBh/w5LnTQsHL6OxbITgHM21/ZHucYgsgA4r2RW2fagJNfJaqlZRtes/ec 2gXzBUNRx7UeB13uxCzyzWAPPXKabKe4suUH2HGIjtY0HkSVelYS2ybn7PzAOKBGILWz 9+plcC1sVig6u9TNTeOtwVI+fEoTVk+siboTfiteLkAoboYuTdmC2WOsKP2EYE8vFNMu xDPtx2Q+P/tvoVDFyqIye/uDcPSSqxr40AAOyaCDpJWnugSAyq5swJqZfexXwsD/4vKj S5GyPqNfg9jxtDHjANdrjHJ3T5+8UcP993oDEHeicL1PQKwlZ+whB85mI9qhDDYKDc+W Kfug== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=Sy1clfh/; 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 z8-v6si1563014pgs.302.2018.05.10.16.35.17; Thu, 10 May 2018 16:35:31 -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=Sy1clfh/; 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 S1751169AbeEJXfB (ORCPT + 99 others); Thu, 10 May 2018 19:35:01 -0400 Received: from mail-pl0-f68.google.com ([209.85.160.68]:46219 "EHLO mail-pl0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750751AbeEJXe7 (ORCPT ); Thu, 10 May 2018 19:34:59 -0400 Received: by mail-pl0-f68.google.com with SMTP id 59-v6so2171544plc.13 for ; Thu, 10 May 2018 16:34:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=mZCqjPfjp4rbF273iD6Le+oxUut59v1vQ68rWn4xUBE=; b=Sy1clfh/gxGlL0/sYlHv7LJ7j4pAN3C8GY4+A21nFh9UitJLSEWu4P6NlILFgBH2wO f3gJYpaVA+2kqqPBqtfIG8tYuD2OrQECluiEsbkbl/cQeOHhxXLyPYThz9GiVFbn0tXL DUUjLuOHDGtCQ9YyQWadFfBdFUXgAYt30CQT13bM2vnXrl8A8UVCpXsHxEeduiXgHQiJ RF5HaLQ5SqLqTDUnflTEKMEzDSBfTAfj9EWcBtriaSRnYogfVI6VvuS3FU2wob1NyjG2 BMQ/zFf4M7o3eJzNYoau3Pcr6gnwktB0kdd5/Du1h8ia0nr2U00AZ1WTMgxPFZEXt7jV bpvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=mZCqjPfjp4rbF273iD6Le+oxUut59v1vQ68rWn4xUBE=; b=G8lOg+iojOwv4RGAUQcfhvcjQE/tNnlhuLJwqsnUx4E73jG5lOCJqdP8BgOBvft9bl ZMEKI4GZq48x74G1NjevEe92SkBLVgRhtgLMLhpnKQZKcmbWk2rr6JQnUQwjU39q+8UL rF42nerVJ2/dxvc0wYTagsF9JgcVhpvZEPfLTQexg9QFOoNPpxyfgrMe91N+9cqor/lr Qn6zSLuhuuPP8EMi9/Bccfd7r+TFD6FisWrncoNWYv9ZthMLrN2hbKBhj6pXMRDJrEo1 BZxr7n0Sn4fkjZNF38DWqA1h1zS0jmWE0cdUyY6rXCA0+R9OQQWxZvuaXWkPgcMHwYSJ JX6A== X-Gm-Message-State: ALKqPwcr82Qs0KqODeStUoFH+hWWiISzWaCLqFKXX3NOa0kkOsTBLGQJ xUX0zvvrQbgSZuoD7tquKFqQYg== X-Received: by 2002:a17:902:bcc4:: with SMTP id o4-v6mr3104417pls.308.1525995298852; Thu, 10 May 2018 16:34:58 -0700 (PDT) Received: from rajat.mtv.corp.google.com ([2620:0:1000:1501:dc81:9a9e:fdee:decf]) by smtp.gmail.com with ESMTPSA id r90-v6sm5617081pfg.122.2018.05.10.16.34.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 10 May 2018 16:34:58 -0700 (PDT) From: Rajat Jain To: "Rafael J. Wysocki" , Pavel Machek , Len Brown , linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, dtor@google.com, rajatxjain@gmail.com Cc: Rajat Jain Subject: [PATCH] PM / s2idle: Clear the events_check_enabled flag Date: Thu, 10 May 2018 16:34:26 -0700 Message-Id: <20180510233426.94514-1-rajatja@google.com> X-Mailer: git-send-email 2.17.0.441.gb46fe60e1d-goog In-Reply-To: <20180508230148.121852-1-rajatja@google.com> References: <20180508230148.121852-1-rajatja@google.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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