From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 78B2BC19759 for ; Thu, 1 Aug 2019 22:46:47 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 49B102064A for ; Thu, 1 Aug 2019 22:46:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1564699607; bh=UeLNpEixnXbKvwgJpTtAY8hdbUWhDwC44RHkWyuOxdo=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-ID:From; b=l77+M/oLf5hVOxHx4kNzS/IuYla/X0rj+WZ0b6NgeweQto1wsTkOYJWR3Pl/1fJNJ g5U2A+b5sxFhCamgXfCrTauizgdrVtYfjmansSxr3F4B0zI9kfF8qaPbX0i6SATK47 QQ2eI1Ikc9WgT8GMW1vEZb40u4CYD4PfwrnPP4Mk= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1733052AbfHAWqq (ORCPT ); Thu, 1 Aug 2019 18:46:46 -0400 Received: from mail-ot1-f67.google.com ([209.85.210.67]:42294 "EHLO mail-ot1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732187AbfHAWqp (ORCPT ); Thu, 1 Aug 2019 18:46:45 -0400 Received: by mail-ot1-f67.google.com with SMTP id l15so76089427otn.9; Thu, 01 Aug 2019 15:46:45 -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=6/A0oFUJlLeWDW4iRfhcabTxuKQ2E0T/S9GKqy4yr6w=; b=BRFT8UXsCmKc+OO2lHbV7mRLsfKRHlLFZnfbx3esM7Tvh0DSSG/njPGNhXFfdLtinR H3CujCvYD6Fz3mUajjZiESx/yrdDpVbK2GI38lybPxxDQM4vYVAU4r2PsWUTRUkviw8l e/09PQF21TUdQhvCLemgvD0S1RLprfovxqdWzRpUHfywYIl+rW3lZAzjY+PdFO2YOBPd 1TDEFK6hH4ApoOd9805eegNx7+op9SNenBQ33FywpxwB01QMsvXFuDWR/ycGxVIAmsr1 NdKkofCQ5DCnQYi1kYb6lEIyHQbJHjJnVLaOU98yxi9JKSAmgH7difzC9kxvUSFifhNV qLHA== X-Gm-Message-State: APjAAAU5p098XhP2NOzaHG71tauh/i8/93cn5+sD5l4vJSSy9kS3VI4P q3Sxquz8yhmZmTjZmczkYibAIWHkgrhmqDbASJfAIg== X-Google-Smtp-Source: APXvYqxSnifKD3zLTP20OF59FU7o3QBu7uY673X7OYVYnL7YJ6f84BMO1+q791T5S82mWIpAvyCQnCeyFRFn0MrxQMs= X-Received: by 2002:a05:6830:1516:: with SMTP id k22mr92227045otp.189.1564699604701; Thu, 01 Aug 2019 15:46:44 -0700 (PDT) MIME-Version: 1.0 References: <20190731215514.212215-1-trong@android.com> <32598586.Mjd66ZhNnG@kreacher> <6987393.M0uybTKmdI@kreacher> <5d42281c.1c69fb81.bcda1.71f5@mx.google.com> <5d434a23.1c69fb81.c4201.c65b@mx.google.com> <5d4363ae.1c69fb81.b621e.65ed@mx.google.com> In-Reply-To: <5d4363ae.1c69fb81.b621e.65ed@mx.google.com> From: "Rafael J. Wysocki" Date: Fri, 2 Aug 2019 00:46:33 +0200 Message-ID: Subject: Re: [PATCH v6] PM / wakeup: show wakeup sources stats in sysfs To: Stephen Boyd Cc: Tri Vo , "Rafael J. Wysocki" , "Rafael J. Wysocki" , Greg Kroah-Hartman , Viresh Kumar , Hridya Valsaraju , Sandeep Patil , Kalesh Singh , Ravi Chandra Sadineni , 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 Fri, Aug 2, 2019 at 12:11 AM Stephen Boyd wrote: > > Quoting Tri Vo (2019-08-01 14:44:52) > > On Thu, Aug 1, 2019 at 1:23 PM Stephen Boyd wrote: > > > > > > > > > I don't find it awkward or difficult. Just know what the name of the > > > /sys/class/wakeup/ path is and then extract the name from there if it > > > doesn't match wakeupN, otherwise read the 'device' symlink and run it > > > through basename. > > > > The concern was that having both "id" and "name" around might be > > confusing. I don't think that making the presence of "name" > > conditional helps here. And we have to maintain additional logic in > > both kernel and userspace to support this. > > > > Also, say, userspace grabs a wakelock named "wakeup0". In the current > > patch, this results in a name collision and an error. Even assuming > > that userspace doesn't have ill intent, it still needs to be aware of > > "wakeupN" naming pattern to avoid this error condition. > > > > All wakeup sources in the /sys/class/wakeup/ are in the same namespace > > regardless of where they originate from, i.e. we have to either (1) > > inspect the name of a wakeup source and make sure it's unique before > > using it as a directory name OR (2) generate the directory name on > > behalf of whomever is registering a wakeup source, which I think is a > > much simpler solution. > > Ok. If the device name is going to be something generic like 'wakeupN', > then we need to make sure that the wakeup source name is unique. > Otherwise, I'm not able to see how userspace will differentiate between > two of the same named wakelocks. Before this patch the wakeup source > name looks to have been used for debugging, but now it's being used > programmatically to let userspace act upon it somehow. I'm not actually sure if this patch changes the situation with respect to wakeup source names. User space still can use them for whatever it used to use the list in debugfs and that's it. That's what I mean by retaining the names for "backwards compatibility only". > Maybe it's for debug still, but I could see how userspace may want to hunt down the > wakelock that's created in userspace and penalize or kill the task > that's waking up the device. It can't do that right now. > I see that wakelock_lookup_add() already checks the list of wakelock > wakeup sources, but I don't see how I can't create an "alarmtimer" > wakelock again, but this time for userspace, by writing into > /sys/power/wake_lock. > > What happens with namespaces here BTW? Can a wakelock be made in one > namespace and that is the same name as another wakelock in a different > namespace? Right now it doesn't look possible because of the global name > matching, but it probably makes sense to support this? Maybe we just > shouldn't make anything in sysfs for wake sources that can be any random > name created from the wakelock path right now. I don't see how it can be > traced back to the process that created it in any reasonable way. It can't. The assumption was that there would be a "manager" process in user space controlling access to this interface and it would do its own tracking. That predated namespaces though. :-)