Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp6478038ybi; Wed, 31 Jul 2019 15:20:15 -0700 (PDT) X-Google-Smtp-Source: APXvYqwjNwEMqUUiDg8xteZ43C8PjJ6zo8EeN0uW0tYNRQ2lXjzKbFH23pL3ZxxjZCD+5sICtGfm X-Received: by 2002:a63:1455:: with SMTP id 21mr71761588pgu.116.1564611615579; Wed, 31 Jul 2019 15:20:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1564611615; cv=none; d=google.com; s=arc-20160816; b=jyzvE3i+Tl80YbUonu8Drn6JnWddM0I+idhOpNPgcx4R6lYla7s9So1mMN6qHVzGfH myZ0XCOhv40GZ0gNdQ5rUcbYPM7nGcQSBB/0fQHFdqzIYGrZjLqQwIvge2q9kJwCJZVs PSs36CMQsR4g23IAaVnActwso+xDnibF5XqknoXlM0esNUpnxiYpDHVf7eeFMfsLXivh qnGfzQ9NCgGIzGA2xxfGpV7/bNk2XEHMz8uSubmR3+G2NZSrsN1hcg3SlfzuWbPDycvZ C1ghldJfaqJ+jP6CsWHPGu5WQHVks8+DSbffCOmT1djqf99M0+KmPNsPN3mu/BiwbSJd bKOg== 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 :in-reply-to:references:mime-version; bh=WzyHnanfaOTPxHoF3LKE4Om9lWjz1so8u2/O9AODChE=; b=as6+eGHgoc90pFaLnKLb3Ixtz1Po5TQkYI2tGvbWfGR3eB8wV9JyzpV2sW4YDSJu5q rA94aZd76yIQ6z4pQyQZ9owCuDarPRsmsx8jRgWJccGk9K58ilDRTeTuA5aI07CoJ6RV Wubgj/FQC1TgnkkooRuosTu3aE+vT9G9JjUejguhODUpQ0h6XJtdAEgJHUfpr9NKCiVb zV/CLKybHogACCIQKcEGBQe7uquVgSIoDcsSKaSaOl36aNRkuXFLmorCHPgxP3q3y1P6 CKURPJsK9v6IDFjPUWt/axHn7a/uXg4MJlq5oJHA+wzspXHhvr8ubWWaRc2SwliLLYpz DhFg== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id q191si31725578pfq.63.2019.07.31.15.20.00; Wed, 31 Jul 2019 15:20:15 -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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729586AbfGaVTR (ORCPT + 99 others); Wed, 31 Jul 2019 17:19:17 -0400 Received: from mail-oi1-f194.google.com ([209.85.167.194]:45793 "EHLO mail-oi1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726421AbfGaVTR (ORCPT ); Wed, 31 Jul 2019 17:19:17 -0400 Received: by mail-oi1-f194.google.com with SMTP id m206so51907642oib.12; Wed, 31 Jul 2019 14:19:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WzyHnanfaOTPxHoF3LKE4Om9lWjz1so8u2/O9AODChE=; b=ghAvTr3OQ80WyWlLSfe/bEw50niizuiKx48rnu+0US+jnmKhfTKgzU3/R2fIoq5hEU Yxzf30sy9nsYpzxvtiyrBVONhat/oT/jFj2993pg7seVlUbeX5WMJcwSA+63D1bFisfS U9EN1PNl6LgxPAM8p2iZaMjt5U22RZzp0/qGyCmSbDfzJUZ06pCmnNbZKfFI6qVkO9qE 6Wwf7qP3uo58GfNgZ37fa0sL3SRjNrejW0c0Eo55w5Lv9jchZ+krP9Lg6JQYtzvloocy huZAGPaW8249hprzsDUFmzROrwwEk21v+pVKXhypRmVyO1LjMPlocylhqHSGwpiaCYaF 2Bug== X-Gm-Message-State: APjAAAV420Neo2kDBRgRMjsFEM+1mN0MoK2jY7xnCI1tCnlmkYJ8l4tT Fxf/G31EQRkCrZDAZMPCwDSLHPHMr2H7oxGDvdQ= X-Received: by 2002:aca:cdd3:: with SMTP id d202mr55041731oig.115.1564607956221; Wed, 31 Jul 2019 14:19:16 -0700 (PDT) MIME-Version: 1.0 References: <20190730024309.233728-1-trong@android.com> <5d40d5b3.1c69fb81.6047f.1cc3@mx.google.com> <3963324.N1Qi0Ay72S@kreacher> <5d41cc55.1c69fb81.9480d.8a49@mx.google.com> In-Reply-To: <5d41cc55.1c69fb81.9480d.8a49@mx.google.com> From: "Rafael J. Wysocki" Date: Wed, 31 Jul 2019 23:19:04 +0200 Message-ID: Subject: Re: [PATCH v5] PM / wakeup: show wakeup sources stats in sysfs To: Stephen Boyd Cc: "Rafael J. Wysocki" , Tri Vo , Greg Kroah-Hartman , Viresh Kumar , Hridya Valsaraju , Sandeep Patil , Kalesh Singh , Ravi Chandra Sadineni , Linux Kernel Mailing List , Linux PM , "Cc: Android Kernel" , kbuild test robot 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 Wed, Jul 31, 2019 at 7:14 PM Stephen Boyd wrote: > > Quoting Rafael J. Wysocki (2019-07-31 04:58:36) > > On Wednesday, July 31, 2019 10:34:11 AM CEST Rafael J. Wysocki wrote: > > > On Wed, Jul 31, 2019 at 1:41 AM Stephen Boyd wrote: > > > > > > > > > > > We can run into the same problem when two buses name their devices the > > > > same name and then we attempt to attach a wakeup source to those two > > > > devices. Or we can have a problem where a virtual wakeup is made with > > > > the same name, and again we'll try to make a duplicate named device. > > > > Using something like 'event' or 'wakeup' or 'ws' as the prefix avoids this > > > > problem and keeps things clean. > > > > > > Or suffix, like ". > > > > > > But if prefixes are used by an existing convention, I would prefer > > > "ws-" as it is concise enough and should not be confusing. > > Another possibility is 'eventN', so it reads as /sys/class/wakeup/event0 > > > > > > > > We should probably avoid letting the same virtual wakeup source be made > > > > with the same name anyway, because userspace will be confused about what > > > > virtual wakeup it is otherwise. I concede that using the name of the > > > > wakeup source catches this problem without adding extra code. > > > > > > > > Either way, I'd like to see what you outline implemented so that we > > > > don't need to do more work than is necessary when userspace writes to > > > > the file. > > > > > > Since we agree here, let's make this change first. I can cut a patch > > > for that in a reasonable time frame I think if no one else beats me to > > > that. > > > > So maybe something like the patch below (untested). > > > > Index: linux-pm/drivers/base/power/wakeup.c > > =================================================================== > > --- linux-pm.orig/drivers/base/power/wakeup.c > > +++ linux-pm/drivers/base/power/wakeup.c > > @@ -265,15 +244,29 @@ int device_wakeup_enable(struct device * > > if (pm_suspend_target_state != PM_SUSPEND_ON) > > dev_dbg(dev, "Suspicious %s() during system transition!\n", __func__); > > > > + spin_lock_irq(&dev->power.lock); > > + > > + if (dev->power.wakeup) { > > + spin_unlock_irq(&dev->power.lock); > > + return -EEXIST; > > + } > > + dev->power.wakeup = ERR_PTR(-EBUSY); > > + > > + spin_unlock_irq(&dev->power.lock); > > + > > ws = wakeup_source_register(dev_name(dev)); > > if (!ws) > > return -ENOMEM; > > > > Let's say that device_wakeup_enable() is called twice at around the same > time. First thread gets to wakeup_source_register() and it fails, we > return -ENOMEM. The return is premature. dev->power.wakeup should be reset back to NULL if the wakeup source creation fails. > dev->power.wakeup is assigned to ERR_PTR(-EBUSY). Second > thread is at the spin_lock_irq() above, it grabs the lock and sees > dev->power.wakeup is ERR_PTR(-EBUSY) so it bails out with return > -EEXIST. I'd think we would want to try to create the wakeup source > instead. > > CPU0 CPU1 > ---- ---- > spin_lock_irq(&dev->power.lock) > ... > dev->power.wakeup = ERR_PTR(-EBUSY) > spin_unlock_irq(&dev->power.lock) > ws = wakeup_source_register(...) > if (!ws) > return -ENOMEM; spin_lock_irq(&dev->power.lock) > if (dev->power.wakeup) > return -EEXIST; // Bad > > > Similar problems probably exist with wakeup destruction racing with > creation. I think it might have to be a create and then publish pointer > style of code to keep the spinlock section small? There is a problem when there are two concurrent callers of device_wakeup_enable() running in parallel with a caller of device_wakeup_disable(), but that can be prevented by an extra check in the latter. Apart from that I missed a few if (dev->power.wakeup) checks to convert. I'll update the patch and resend it.