public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Phil Auld <pauld@redhat.com>
Cc: linux-kernel@vger.kernel.org,
	"Rafael J . Wysocki" <rafael@kernel.org>,
	Barry Song <21cnbao@gmail.com>, Tian Tao <tiantao6@hisilicon.com>,
	Yury Norov <yury.norov@gmail.com>,
	stable@vger.kernel.org
Subject: Re: [PATCH v5] drivers/base: fix userspace break from using bin_attributes for cpumap and cpulist
Date: Fri, 15 Jul 2022 17:37:13 +0200	[thread overview]
Message-ID: <YtGJqYrbSPq9q19U@kroah.com> (raw)
In-Reply-To: <20220715134924.3466194-1-pauld@redhat.com>

On Fri, Jul 15, 2022 at 09:49:24AM -0400, Phil Auld wrote:
> Using bin_attributes with a 0 size causes fstat and friends to return that
> 0 size. This breaks userspace code that retrieves the size before reading
> the file. Rather than reverting 75bd50fa841 ("drivers/base/node.c: use
> bin_attribute to break the size limitation of cpumap ABI") let's put in a
> size value at compile time.
> 
> For cpulist the maximum size is on the order of
> 	NR_CPUS * (ceil(log10(NR_CPUS)) + 1)/2
> 
> which for 8192 is 20480 (8192 * 5)/2. In order to get near that you'd need
> a system with every other CPU on one node. For example: (0,2,4,8, ... ).
> To simplify the math and support larger NR_CPUS in the future we are using
> (NR_CPUS * 7)/2. We also set it to a min of PAGE_SIZE to retain the older
> behavior for smaller NR_CPUS.
> 
> The cpumap file the size works out to be NR_CPUS/4 + NR_CPUS/32 - 1
> (or NR_CPUS * 9/32 - 1) including the ","s.
> 
> Add a set of macros for these values to cpumask.h so they can be used in
> multiple places. Apply these to the handful of such files in
> drivers/base/topology.c as well as node.c.
> 
> As an example, on an 80 cpu 4-node system (NR_CPUS == 8192):
> 
> before:
> 
> -r--r--r--. 1 root root 0 Jul 12 14:08 system/node/node0/cpulist
> -r--r--r--. 1 root root 0 Jul 11 17:25 system/node/node0/cpumap
> 
> after:
> 
> -r--r--r--. 1 root root 28672 Jul 13 11:32 system/node/node0/cpulist
> -r--r--r--. 1 root root  4096 Jul 13 11:31 system/node/node0/cpumap
> 
> CONFIG_NR_CPUS = 16384
> -r--r--r--. 1 root root 57344 Jul 13 14:03 system/node/node0/cpulist
> -r--r--r--. 1 root root  4607 Jul 13 14:02 system/node/node0/cpumap
> 
> The actual number of cpus doesn't matter for the reported size since they
> are based on NR_CPUS.
> 
> Fixes: 75bd50fa841 ("drivers/base/node.c: use bin_attribute to break the size limitation of cpumap ABI")
> Fixes: bb9ec13d156 ("topology: use bin_attribute to break the size limitation of cpumap ABI")

Nit, use the full 12 characters otherwise our tools will complain.  I'll
go fix it up by hand...

thanks for sticking with this.

greg k-h

  parent reply	other threads:[~2022-07-15 15:37 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-15 13:49 [PATCH v5] drivers/base: fix userspace break from using bin_attributes for cpumap and cpulist Phil Auld
2022-07-15 13:58 ` Yury Norov
2022-07-15 15:37 ` Greg Kroah-Hartman [this message]
2022-07-15 15:57   ` Phil Auld

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=YtGJqYrbSPq9q19U@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=21cnbao@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pauld@redhat.com \
    --cc=rafael@kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=tiantao6@hisilicon.com \
    --cc=yury.norov@gmail.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