From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Phil Auld <pauld@redhat.com>
Cc: Barry Song <21cnbao@gmail.com>,
LKML <linux-kernel@vger.kernel.org>,
"Rafael J . Wysocki : --cc=" <rafael@kernel.org>,
Tian Tao <tiantao6@hisilicon.com>,
Barry Song <song.bao.hua@hisilicon.com>
Subject: Re: [PATCH] drivers/base/node.c: fix userspace break from using bin_attributes for cpumap and cpulist
Date: Wed, 13 Jul 2022 15:06:25 +0200 [thread overview]
Message-ID: <Ys7DUYXuzwUvQzT6@kroah.com> (raw)
In-Reply-To: <Ys6ud4JmMGjktAlL@lorien.usersys.redhat.com>
On Wed, Jul 13, 2022 at 07:37:27AM -0400, Phil Auld wrote:
> On Wed, Jul 13, 2022 at 11:18:59AM +1200 Barry Song wrote:
> > On Wed, Jul 13, 2022 at 9:58 AM Phil Auld <pauld@redhat.com> 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.
> > > 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...). We set it to a min of PAGE_SIZE
> > > to retain the older behavior. For cpumap, PAGE_SIZE is plenty big.
> > >
> > > On an 80 cpu 4-node system (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
> >
> > it is a fundamental problem of bin_attr, isn't it? when we don't know the
> > exact size of an attribute, and this size might become more than one
> > PAGE_SIZE, we use bin_attr to break the limitation. but the fact is that
> > we really don't know or it is really hard to know the actual size of the
> > attribute.
> >
>
> But it broke userspace applications. I figured rather than revert it maybe
> we can find a max size to put in there and make it continue to work.
Yes, we need to do this, we can't break userspace.
thanks,
greg k-h
next prev parent reply other threads:[~2022-07-13 13:06 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-12 21:43 [PATCH] drivers/base/node.c: fix userspace break from using bin_attributes for cpumap and cpulist Phil Auld
2022-07-12 23:18 ` Barry Song
2022-07-13 11:37 ` Phil Auld
2022-07-13 12:00 ` Barry Song
2022-07-13 12:20 ` Phil Auld
2022-07-13 13:06 ` Greg Kroah-Hartman [this message]
2022-07-13 6:06 ` Greg Kroah-Hartman
2022-07-13 11:47 ` Phil Auld
2022-07-13 13:05 ` Greg Kroah-Hartman
2022-07-13 13:14 ` Phil Auld
2022-07-13 13:10 ` 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=Ys7DUYXuzwUvQzT6@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=song.bao.hua@hisilicon.com \
--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.