Received: by 2002:a25:f815:0:0:0:0:0 with SMTP id u21csp1317674ybd; Wed, 26 Jun 2019 15:29:05 -0700 (PDT) X-Google-Smtp-Source: APXvYqxSCBjXIV6zkU4iXVaeHQgBTUNybWizaydaHjPfhedBQpTSTlg5w0ocQPmbwcR3LfZuLH7H X-Received: by 2002:a65:645a:: with SMTP id s26mr348296pgv.70.1561588145365; Wed, 26 Jun 2019 15:29:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1561588145; cv=none; d=google.com; s=arc-20160816; b=qqLrHBr4T55iYybbao7i9AJ7aUilJp1wH/TZCStddcf2xqRXeL6tQFtReyEytSREyO evuA/Kds3T2JKqU52S+iwS7DHoSKH6LUUaE2YWN4viWn30zdNiw8me7b+Wkp/Y43Q1Nb 0a4TFjEh/NBSR/M6mlDS5a/HXV8MHvcJfxVAvRkv9X1b0b0gWj1gvL5nTcLl9zkpGFxr ynx7EWWXpclexHhFU9jyfLS+lNL0c9PxongY5+vdDkhhfgiLfgzAMUijZtBU/n1qFltZ GK8G0Thk/YGGOx3gZpgYTYzXE5C7p/CJsr4OX0SlSxNZCZef7uXcPqpCH8iEsotQU1iJ M1zg== 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:dkim-signature; bh=DwzTuPrM5y/zYXjPFzke4laOtSF8hSFyaDatsrv6uos=; b=lDKErZMzlJD+N6ImzuKOv3wA9SiydTpDZlXZJ8DzcqA8n/gQqQGlWrxcPPqhf1iuqT z6spMRo7ZeheDbvKEpooCy48ZyAwEogD/iBdrSLCBcpIKtqfpAiAzdJ4IqwBvCKB3Veh FbzHzGA3OJXwTtIey49IvUGOZhNcWwbmsOuawQ77BLPO/5IkuZzVLoxPzx4AOIZzaRdH iys79FCrUknvNiIWWWds5Q4RZao/KBC9brzbH/3GGkcNpqHamVn62ouy09W6+t4vzX0w LyR3Dr7VpccOno16NLW47YmLrOAU9MVhP0gPhZNmsE3HrurWmWXaDym8PKxiJjRXwBVa SJQQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@android.com header.s=20161025 header.b=XQNDqrzb; 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=android.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d32si270225pgm.570.2019.06.26.15.28.48; Wed, 26 Jun 2019 15:29:05 -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=@android.com header.s=20161025 header.b=XQNDqrzb; 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=android.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726619AbfFZW0u (ORCPT + 99 others); Wed, 26 Jun 2019 18:26:50 -0400 Received: from mail-oi1-f195.google.com ([209.85.167.195]:41224 "EHLO mail-oi1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726441AbfFZW0t (ORCPT ); Wed, 26 Jun 2019 18:26:49 -0400 Received: by mail-oi1-f195.google.com with SMTP id g7so47999oia.8 for ; Wed, 26 Jun 2019 15:26:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=android.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DwzTuPrM5y/zYXjPFzke4laOtSF8hSFyaDatsrv6uos=; b=XQNDqrzbXYaPBBsJx63e5kskO3z/7Uwv/QEJ8JEt7xCZjGxh81eoh0HK597FB/HXkl j6btL1dKeedIUYIgtsOftSrRmAXmaZfKOpwDSiELWVtzazJhfu+Uo7qclfvQhhYuXNlR y9TPDFBs7ZlHWlusDpRjFJgGnd/YC6IKeNNPXp952G7yqVoxqNHgjaRrp/qFAAM77xvw zA2kpSYd4hR92yB2+1i77CvASSAFudf2iFenBnL/yuVmoSu5yyVBMveC3Xo/kWws5RqP ozPqwCLs4ZwHkNFd7Xouks3u9uNTw8qn3NBapKd/S1OJRLwV657bHPVneIohdvKFBN5D 2KoQ== 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=DwzTuPrM5y/zYXjPFzke4laOtSF8hSFyaDatsrv6uos=; b=mI7CmTLMqPkV2GctRBDDlDcqgcw3Go6Cfvxs8oCf1gadqchfEbDYIlWq5pZzhQqgPS 40KwVzp751tX4toyccuaNZhU+dv1NOOFKLCrePQ6Jc5lHwXb6+pE8u7/v38XdWeKsDJQ XfdnRgsR0O3GPfyhb/JW5C30wbwQb+U/O4qhon3frqirIkSb3LHPLZr2eAIrc9yTjPBC fLRyNZxddZIxamLjA1I5j49t11ekdkVo1vm1RfZjrVwnhaWSUeXUuWVqt36zlvSs0549 Kn4hLa9/7S4f56Sv4JZGrSEaIyA4uyWfxVpQm9P5zpItnPfIbSzgumJM6mkqLR5dokW+ m7Pw== X-Gm-Message-State: APjAAAVblbt96/PBd/ZcI6HYSK5b8IkqAy9ny55d8yQtgg//zKDDowlf yrAKiwX6n02iaOSJ+Vpsl+Sfj0i+rzoLDpYnVUgefQ== X-Received: by 2002:aca:50c6:: with SMTP id e189mr415988oib.63.1561588008912; Wed, 26 Jun 2019 15:26:48 -0700 (PDT) MIME-Version: 1.0 References: <20190626005449.225796-1-trong@android.com> <20190626011221.GB22454@kroah.com> <20190626014633.GA22610@kroah.com> In-Reply-To: <20190626014633.GA22610@kroah.com> From: Tri Vo Date: Wed, 26 Jun 2019 15:26:38 -0700 Message-ID: Subject: Re: [PATCH] PM / wakeup: show wakeup sources stats in sysfs To: Greg KH Cc: "Rafael J. Wysocki" , Viresh Kumar , "Rafael J. Wysocki" , Hridya Valsaraju , Sandeep Patil , LKML , Linux PM , "Cc: Android Kernel" 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 Tue, Jun 25, 2019 at 6:48 PM Greg KH wrote: > > On Tue, Jun 25, 2019 at 06:33:08PM -0700, Tri Vo wrote: > > On Tue, Jun 25, 2019 at 6:12 PM Greg KH wrote: > > > > +static ssize_t wakeup_source_count_show(struct wakeup_source *ws, > > > > + struct wakeup_source_attribute *attr, > > > > + char *buf) > > > > +{ > > > > + unsigned long flags; > > > > + unsigned long var; > > > > + > > > > + spin_lock_irqsave(&ws->lock, flags); > > > > + if (strcmp(attr->attr.name, "active_count") == 0) > > > > + var = ws->active_count; > > > > + else if (strcmp(attr->attr.name, "event_count") == 0) > > > > + var = ws->event_count; > > > > + else if (strcmp(attr->attr.name, "wakeup_count") == 0) > > > > + var = ws->wakeup_count; > > > > + else > > > > + var = ws->expire_count; > > > > + spin_unlock_irqrestore(&ws->lock, flags); > > > > + > > > > + return sprintf(buf, "%lu\n", var); > > > > +} > > > > > > Why is this lock always needed to be grabbed? You are just reading a > > > value, who cares if it changes inbetween reading it and returning the > > > buffer string as it can change at that point in time anyway? > > > > Right, we don't care if the value changes in between us reading and > > printing it. However, IIUC not grabbing this lock results in a data > > race, which is undefined behavior. > > A data race where? Writing to the value? How can that happen? All you > are doing is incrementing this variable elsewhere, what is the worst > that can happen? Ok, I'll remove the locks.