All of lore.kernel.org
 help / color / mirror / Atom feed
From: Phil Auld <pauld@redhat.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: linux-kernel@vger.kernel.org,
	"Rafael J . Wysocki" <rafael@kernel.org>,
	Barry Song <21cnbao@gmail.com>, Tian Tao <tiantao6@hisilicon.com>
Subject: Re: [PATCH v2] drivers/base/node.c: fix userspace break from using bin_attributes for cpumap and cpulist
Date: Wed, 13 Jul 2022 10:48:15 -0400	[thread overview]
Message-ID: <Ys7bL/OG6EJrZDdU@lorien.usersys.redhat.com> (raw)
In-Reply-To: <Ys7V2oW82qW75x6X@kroah.com>

On Wed, Jul 13, 2022 at 04:25:30PM +0200 Greg Kroah-Hartman wrote:
> On Wed, Jul 13, 2022 at 10:13:28AM -0400, Phil Auld wrote:
> > On Wed, Jul 13, 2022 at 03:58:43PM +0200 Greg Kroah-Hartman wrote:
> > > On Wed, Jul 13, 2022 at 09:45:45AM -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. Use direct
> > > > comparison and a worst-case maximum to ensure compile time constants. For cpulist the
> > > > max is on the order of NR_CPUS * (ceil(log10(NR_CPUS)) + 1) which for 8192 is 40960
> > > > (8192 * 5). In order to get near that you'd need a system with every other CPU on one
> > > > node or something similar. e.g. (0,2,4,... 1024,1026...). To simplify the math and
> > > > support larger NR_CPUS we are using NR_CPUS * 6. We also set it to a min of PAGE_SIZE
> > > > to retain the older behavior for smaller NR_CPUS. The cpumap file wants to be something
> > > > like NR_CPUS/4 + NR_CPUS/32, for the ","s so for simplicity we are using NR_CPUS/2.
> > > > 
> > > > On an 80 cpu 4-node sytem (NR_CPUS == 8192)
> > > > 
> > > > before:
> > > > 
> > > > -r--r--r--. 1 root root 0 Jul 12 14:08 /sys/devices/system/node/node0/cpulist
> > > > -r--r--r--. 1 root root 0 Jul 11 17:25 /sys/devices/system/node/node0/cpumap
> > > > 
> > > > after:
> > > > 
> > > > -r--r--r--. 1 root root 49152 Jul 13 09:26 /sys/devices/system/node/node0/cpulist
> > > > -r--r--r--. 1 root root  4096 Jul 13 09:24 /sys/devices/system/node/node0/cpumap
> > > > 
> > > > Fixes: 75bd50fa841 ("drivers/base/node.c: use bin_attribute to break the size limitation of cpumap ABI")
> > > > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > > > Cc: "Rafael J. Wysocki" <rafael@kernel.org>
> > > > Signed-off-by: Phil Auld <pauld@redhat.com>
> > > > ---
> > > >  drivers/base/node.c | 4 ++--
> > > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > > > 
> > > > diff --git a/drivers/base/node.c b/drivers/base/node.c
> > > > index 0ac6376ef7a1..3577f4eb4ac6 100644
> > > > --- a/drivers/base/node.c
> > > > +++ b/drivers/base/node.c
> > > > @@ -45,7 +45,7 @@ static inline ssize_t cpumap_read(struct file *file, struct kobject *kobj,
> > > >  	return n;
> > > >  }
> > > >  
> > > > -static BIN_ATTR_RO(cpumap, 0);
> > > > +static BIN_ATTR_RO(cpumap, (((NR_CPUS>>1) > PAGE_SIZE) ? NR_CPUS >> 1 : PAGE_SIZE));
> > > 
> > > Why not just PAGE_SIZE?
> > >
> > 
> > This one is likely to grow beyond page size if NR_CPUS is larger than 8192. It's about 2300 bytes
> > at 8192 if my math is right.
> > 
> > Let me ask again before I write the comments... what values of NR_CPUS are you seeing? Are people
> > using an order of magnitude above 8192? Two orders?  This patch (with the 6 below) handles about 1
> > order more.
> 
> One order for now that we know of, probably larger that we don't :)

Fair enough. I'll go with 7 then. Thanks!

> 
> > > >  static inline ssize_t cpulist_read(struct file *file, struct kobject *kobj,
> > > >  				   struct bin_attribute *attr, char *buf,
> > > > @@ -66,7 +66,7 @@ static inline ssize_t cpulist_read(struct file *file, struct kobject *kobj,
> > > >  	return n;
> > > >  }
> > > >  
> > > > -static BIN_ATTR_RO(cpulist, 0);
> > > > +static BIN_ATTR_RO(cpulist, (((NR_CPUS * 6) > PAGE_SIZE) ? NR_CPUS *6 : PAGE_SIZE));
> > > 
> > > "* 6" in both places here?
> > >
> > 
> > It's compile time so it's cheap. But yes, 6 in both places.  That's to support NR_CPUS=100000.
> 
> Sorry, I was trying to point out to use a " " before the "6" in both
> places.  Not questioning the math.
>

Right! Sorry, misunderstood, obviously :)

Cheers,
Phil

> thanks,
> 
> greg k-h
> 

-- 


      reply	other threads:[~2022-07-13 14:48 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-13 13:45 [PATCH v2] drivers/base/node.c: fix userspace break from using bin_attributes for cpumap and cpulist Phil Auld
2022-07-13 13:58 ` Greg Kroah-Hartman
2022-07-13 14:13   ` Phil Auld
2022-07-13 14:25     ` Greg Kroah-Hartman
2022-07-13 14:48       ` Phil Auld [this message]

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=Ys7bL/OG6EJrZDdU@lorien.usersys.redhat.com \
    --to=pauld@redhat.com \
    --cc=21cnbao@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rafael@kernel.org \
    --cc=tiantao6@hisilicon.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.