Received: by 2002:a05:6a10:9e8c:0:0:0:0 with SMTP id y12csp1079933pxx; Fri, 30 Oct 2020 01:07:53 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwPJAjqtRwU1rBWAdPFQmXHnWGGcjCc4oJHuvgkyeVzgyN1XcjxIEYi+TsZ426CcEOz9w96 X-Received: by 2002:a05:6402:1042:: with SMTP id e2mr1050195edu.320.1604045273067; Fri, 30 Oct 2020 01:07:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1604045273; cv=none; d=google.com; s=arc-20160816; b=Noc6rJRwNdkEUaceBmpSGhvSVH0AtmffG37dx4qEb36ROCg0uINrermgoUwLGwus5R bIh5CKZSChtJ2efZbXjxeqW/rWCzbUCYBpk7mW+ArFmQzuACXCtsEW8XQ/LFW5Q2HkJ/ WR/ck7HJec/wEexNpTlh5oaSH7vJ9KG07m0kUAh5AZl6rUAXxWLMZoJctZNdvp7YFth1 cWDjOajwXWP5QKGqSuWTsC2vdGIpI9OZK8vXRBVyOUNFV7GJjwDD+N95YUeoHD/32Bgw MIfQmquLnlLg4Y+sppwpQKErJ55U59OaycdPBNjn5IzBN+kmERx7/kwLrjFDCP2pPvjD oESg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=ZDYsROgQBQO3ZS8LCEcLdYvo2Q9HuIFCHh4z2uFK/uQ=; b=hAgPLcalJRSSUgeoVFeM4hV+nFtsQRcBIRUraM5B0s5ET+9Q2wqZV4jQvqcTaWINQg uUPGR04eVGN3EJXFOKXlDbhmHQ1Yq/7EySeH0vxapg40pazz2fRI3JsxF8o6N9pPW397 JBAmwxukT4MEweH2SXtNTwayqEEfeUG2XwnWWbb5F6dbI4V5a3QFlxhoGI+mLfbLlg7x lE7smd6yvwOy5tSXwM32TmWIcT206oWOLJK7GKtULQYIluKGPu57GT3ZGYAYYut4E+pf 8Xqm9AJemvP7AVNOGzIftUbRYet0jW35Wp/j+v46w1EOidPxlsT9E8XMEbEHXYEK9elV YIvw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=R6VW27tE; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id qo14si3474087ejb.663.2020.10.30.01.07.29; Fri, 30 Oct 2020 01:07:53 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=R6VW27tE; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726003AbgJ3IEH (ORCPT + 99 others); Fri, 30 Oct 2020 04:04:07 -0400 Received: from mail.kernel.org ([198.145.29.99]:34696 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725808AbgJ3IEG (ORCPT ); Fri, 30 Oct 2020 04:04:06 -0400 Received: from localhost (83-86-74-64.cable.dynamic.v4.ziggo.nl [83.86.74.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 7E018206DD; Fri, 30 Oct 2020 08:04:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1604045045; bh=Sn3dA1VSNSN5lgi26Pj5nHNRUhr7ixjp5QdHMAE3z0E=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=R6VW27tE3iq36TLQY+OPia0HlP8XY9AMUEUeebXLiOpnjQKeqSwGbToBxehyBZYQx aqJnaa2roCO+le/qMzJg7/ZKlhgabKxyR1R6Nze1ZhSSaUhFQMFf24x5PVjNhYh9bS bSOK0Bcd4cyUfIU4z4qmQn2S7EWYkcK0CNub504s= Date: Fri, 30 Oct 2020 09:04:53 +0100 From: Greg Kroah-Hartman To: "Anand K. Mistry" Cc: linux-kernel@vger.kernel.org, "Rafael J. Wysocki" Subject: Re: [PATCH 1/1] debugfs: Add a helper to export atomic64_t values Message-ID: <20201030080453.GB1612206@kroah.com> References: <20201030070442.457739-1-amistry@google.com> <20201030180403.1.I9c36fd7a0e4d52e300c1004a0f6f2fc705e2b065@changeid> <20201030072118.GB1495407@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Oct 30, 2020 at 06:30:49PM +1100, Anand K. Mistry wrote: > On Fri, 30 Oct 2020 at 18:20, Greg Kroah-Hartman > wrote: > > > > On Fri, Oct 30, 2020 at 06:04:42PM +1100, Anand K Mistry wrote: > > > This mirrors support for exporting atomic_t values. > > > > > > Signed-off-by: Anand K Mistry > > > > > > --- > > > > > > fs/debugfs/file.c | 37 +++++++++++++++++++++++++++++++++++++ > > > include/linux/debugfs.h | 6 ++++++ > > > 2 files changed, 43 insertions(+) > > > > > > diff --git a/fs/debugfs/file.c b/fs/debugfs/file.c > > > index a768a09430c3..798bd3bdedec 100644 > > > --- a/fs/debugfs/file.c > > > +++ b/fs/debugfs/file.c > > > @@ -770,6 +770,43 @@ void debugfs_create_atomic_t(const char *name, umode_t mode, > > > } > > > EXPORT_SYMBOL_GPL(debugfs_create_atomic_t); > > > > > > +static int debugfs_atomic64_t_set(void *data, u64 val) > > > +{ > > > + atomic64_set((atomic64_t *)data, val); > > > + return 0; > > > +} > > > +static int debugfs_atomic64_t_get(void *data, u64 *val) > > > +{ > > > + *val = atomic64_read((atomic64_t *)data); > > > + return 0; > > > +} > > > +DEFINE_DEBUGFS_ATTRIBUTE(fops_atomic64_t, debugfs_atomic64_t_get, > > > + debugfs_atomic64_t_set, "%lld\n"); > > > +DEFINE_DEBUGFS_ATTRIBUTE(fops_atomic64_t_ro, debugfs_atomic64_t_get, NULL, > > > + "%lld\n"); > > > +DEFINE_DEBUGFS_ATTRIBUTE(fops_atomic64_t_wo, NULL, debugfs_atomic64_t_set, > > > + "%lld\n"); > > > + > > > +/** > > > + * debugfs_create_atomic64_t - create a debugfs file that is used to read and > > > + * write an atomic64_t value > > > + * @name: a pointer to a string containing the name of the file to create. > > > + * @mode: the permission that the file should have > > > + * @parent: a pointer to the parent dentry for this file. This should be a > > > + * directory dentry if set. If this parameter is %NULL, then the > > > + * file will be created in the root of the debugfs filesystem. > > > + * @value: a pointer to the variable that the file should read to and write > > > + * from. > > > + */ > > > +void debugfs_create_atomic64_t(const char *name, umode_t mode, > > > + struct dentry *parent, atomic64_t *value) > > > +{ > > > + debugfs_create_mode_unsafe(name, mode, parent, value, > > > + &fops_atomic64_t, &fops_atomic64_t_ro, > > > + &fops_atomic64_t_wo); > > > +} > > > +EXPORT_SYMBOL_GPL(debugfs_create_atomic64_t); > > > + > > > ssize_t debugfs_read_file_bool(struct file *file, char __user *user_buf, > > > size_t count, loff_t *ppos) > > > { > > > diff --git a/include/linux/debugfs.h b/include/linux/debugfs.h > > > index 851dd1f9a8a5..0fac84c53eab 100644 > > > --- a/include/linux/debugfs.h > > > +++ b/include/linux/debugfs.h > > > @@ -126,6 +126,8 @@ void debugfs_create_size_t(const char *name, umode_t mode, > > > struct dentry *parent, size_t *value); > > > void debugfs_create_atomic_t(const char *name, umode_t mode, > > > struct dentry *parent, atomic_t *value); > > > +void debugfs_create_atomic64_t(const char *name, umode_t mode, > > > + struct dentry *parent, atomic64_t *value); > > > struct dentry *debugfs_create_bool(const char *name, umode_t mode, > > > struct dentry *parent, bool *value); > > > > > > @@ -291,6 +293,10 @@ static inline void debugfs_create_atomic_t(const char *name, umode_t mode, > > > atomic_t *value) > > > { } > > > > > > +static inline void debugfs_create_atomic64_t(const char *name, umode_t mode, > > > + struct dentry *parent, atomic64_t *value) > > > +{ } > > > + > > > static inline struct dentry *debugfs_create_bool(const char *name, umode_t mode, > > > struct dentry *parent, > > > bool *value) > > > > Looks good, but where is the user of this code? I can't add new apis > > without a user. > > Fair enough. Right now, the user is just some local > debugging/performance measuring which will never be upstreamed. > Happy to let this drop. Now dropped! > > And are you _SURE_ you want to be using an atomic64_t in the first > > place? We are starting to reduce the "raw" usage of atomic variables as > > almost no one needs them, they should be using something else instead, > > or just a u64 as atomics are not needed for simple statistics. > > I understand, and would generally never use atomics in real code. I > used an atomic since I wanted accuracy (for some of the benchmarks I > want to run) but can't use anything that blocks (spinlock/mutex) since > the code is somewhere inside the scheduler. You can't be "accurate" for a single value from a single file read by userspace as you don't know if it changed right after you read the value :) Again, people abuse atomic values thinking they are something they really aren't... thanks, greg k-h