linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>
To: "Song Bao Hua (Barry Song)" <song.bao.hua@hisilicon.com>
Cc: Dave Hansen <dave.hansen@intel.com>,
	"tiantao (H)" <tiantao6@hisilicon.com>,
	"corbet@lwn.net" <corbet@lwn.net>,
	"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Valentin Schneider <valentin.schneider@arm.com>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	Daniel Bristot de Oliveira <bristot@redhat.com>,
	Linuxarm <linuxarm@huawei.com>
Subject: Re: [PATCH 1/2] CPU, NUMA topology ABIs: clarify the overflow issue of sysfs pagebuf
Date: Fri, 23 Jul 2021 13:28:37 +0200	[thread overview]
Message-ID: <YPqn5SDi6bzLHsOY@kroah.com> (raw)
In-Reply-To: <e9610060a8d046e783ab9a229f35410c@hisilicon.com>

On Fri, Jul 23, 2021 at 11:20:19AM +0000, Song Bao Hua (Barry Song) wrote:
> 
> 
> > -----Original Message-----
> > From: Dave Hansen [mailto:dave.hansen@intel.com]
> > Sent: Friday, April 30, 2021 10:39 AM
> > To: Song Bao Hua (Barry Song) <song.bao.hua@hisilicon.com>; tiantao (H)
> > <tiantao6@hisilicon.com>; corbet@lwn.net; gregkh@linuxfoundation.org
> > Cc: linux-doc@vger.kernel.org; linux-kernel@vger.kernel.org; Rafael J.
> > Wysocki <rafael@kernel.org>; Peter Zijlstra <peterz@infradead.org>; Valentin
> > Schneider <valentin.schneider@arm.com>; Dave Hansen
> > <dave.hansen@linux.intel.com>; Daniel Bristot de Oliveira <bristot@redhat.com>
> > Subject: Re: [PATCH 1/2] CPU, NUMA topology ABIs: clarify the overflow issue
> > of sysfs pagebuf
> > 
> > On 4/29/21 3:32 PM, Song Bao Hua (Barry Song) wrote:
> > > $ strace numactl --hardware  2>&1 | grep cpu
> > > openat(AT_FDCWD, "/sys/devices/system/cpu",
> > > O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
> > > openat(AT_FDCWD, "/sys/devices/system/node/node0/cpumap", O_RDONLY) = 3
> > > openat(AT_FDCWD, "/sys/devices/system/node/node1/cpumap", O_RDONLY) = 3
> > > openat(AT_FDCWD, "/sys/devices/system/node/node2/cpumap", O_RDONLY) = 3
> > > openat(AT_FDCWD, "/sys/devices/system/node/node3/cpumap", O_RDONLY) = 3
> > >
> > > If we move to binary, it means we have to change those applications.
> > 
> > I thought Greg was saying to using a sysfs binary attribute using
> > something like like sysfs_create_bin_file().  Those don't have the
> > PAGE_SIZE limitation.  But, there's also nothing to keep us from spewing
> > nice human-readable text via the "binary" file.
> > 
> > We don't need to change the file format, just the internal kernel API
> > that we produce the files with.
> 
> Sorry for waking-up the old thread.
> 
> I am not sure how common a regular device_attribute will be larger than
> 4KB and have to work around by bin_attribute. But I wrote a prototype
> which can initially support large regular sysfs entry and be able to
> fill the entire buffer by only one show() entry. The other words to say,
> we don't need to call read() of bin_attribute multiple times for a large
> regular file. Right now, only read-only attribute is supported.
> 
> Subject: [RFC PATCH] sysfs: support regular device attr which can be larger than
>  PAGE_SIZE
> 
> A regular sysfs ABI could be more than 4KB, right now, we are using
> bin_attribute to workaround and break this limit. A better solution
> would be supporting long device attribute. In this case, we will
> still be able to enjoy the advantages of buffering and seeking of
> seq file and only need to fill the entire buffer of sysfs entry
> once.

No, please no.  I WANT people to run into this problem and realize that
it went totally wrong because they should not be having more than one
"value" in a sysfs file like this.

Let's not make it easy on people please, moving to a bin attribute is a
big deal, let's keep it that way.

thanks,

greg k-h

  reply	other threads:[~2021-07-23 11:28 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-29  7:03 [PATCH 0/2] clarify and cleanup CPU and NUMA topology ABIs Tian Tao
2021-04-29  7:03 ` [PATCH 1/2] CPU, NUMA topology ABIs: clarify the overflow issue of sysfs pagebuf Tian Tao
2021-04-29 14:21   ` Dave Hansen
2021-04-29 15:46     ` Greg KH
2021-04-29 21:08     ` Song Bao Hua (Barry Song)
2021-04-29 21:38       ` Dave Hansen
2021-04-29 22:32         ` Song Bao Hua (Barry Song)
2021-04-29 22:38           ` Dave Hansen
2021-04-29 22:48             ` Song Bao Hua (Barry Song)
2021-04-30  6:05             ` gregkh
2021-07-23 11:20             ` Song Bao Hua (Barry Song)
2021-07-23 11:28               ` gregkh [this message]
2021-07-23 12:48                 ` Song Bao Hua (Barry Song)
2021-05-06 23:16   ` kernel test robot
2021-04-29  7:03 ` [PATCH 2/2] Documentation/ABI: Move the topology-related sysfs interface to the right place Tian Tao

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YPqn5SDi6bzLHsOY@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=bristot@redhat.com \
    --cc=corbet@lwn.net \
    --cc=dave.hansen@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxarm@huawei.com \
    --cc=peterz@infradead.org \
    --cc=rafael@kernel.org \
    --cc=song.bao.hua@hisilicon.com \
    --cc=tiantao6@hisilicon.com \
    --cc=valentin.schneider@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).