lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 13 Jul 2022 08:06:02 +0200
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     Phil Auld <pauld@...hat.com>
Cc:     linux-kernel@...r.kernel.org,
        "Rafael J . Wysocki" <rafael@...nel.org>,
        Tian Tao <tiantao6@...ilicon.com>,
        Barry Song <song.bao.hua@...ilicon.com>
Subject: Re: [PATCH] drivers/base/node.c: fix userspace break from using
 bin_attributes for cpumap and cpulist

On Tue, Jul 12, 2022 at 05:43:01PM -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. 
> 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.

Does userspace care about that size, or can we just put any value in
there and it will be ok?  How about just returning to the original
PAGE_SIZE value to keep things looking identical, will userspace not
read more than that size from the file then?

> On an 80 cpu 4-node sytem (NR_CPUS == 8192)

We have systems running Linux with many more cpus than that, and your
company knows this :)

thanks,

greg k-h

Powered by blists - more mailing lists