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:   Thu, 22 Sep 2022 09:18:47 -0400
From:   Phil Auld <pauld@...hat.com>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     Petr Štetiar <ynezz@...e.cz>,
        linux-kernel@...r.kernel.org, yury.norov@...il.com,
        rafael@...nel.org
Subject: Re: aarch64 5.15.68 regression in topology/thread_siblings (huge
 file size and no content)

On Thu, Sep 22, 2022 at 02:40:00PM +0200 Greg Kroah-Hartman wrote:
> On Thu, Sep 22, 2022 at 08:32:10AM -0400, Phil Auld wrote:
> > On Thu, Sep 22, 2022 at 01:32:17PM +0200 Petr Štetiar wrote:
> > > Hi,
> > > 
> > > we've got a recent bug report[1], that lscpu segfaults on aarch64 board running
> > > 5.15.y kernel. It is working fine on 5.10.y kernel. 
> > > 
> > > I've tracked it down[2] to the issue with `topology/thread_siblings` which
> > > apart from very strange file size returns empty content. I assume, that it's
> > > somehow related to the changes done in commit bb9ec13d156e ("topology: use
> > > bin_attribute to break the size limitation of cpumap ABI"), but I didn't tried
> > > to revert it yet to verify it.
> > >
> > 
> > This is actually due to a fix for that since returning 0 size breaks
> > things as well.
> > 
> >   7ee951acd31a drivers/base: fix userspace break from using bin_attributes for cpumap and cpulist
> > 
> > The fix for small number of cpus as you have is now in Greg's driver core tree
> > 
> >   d7f06bdd6ee8 drivers/base: Fix unsigned comparison to -1 in CPUMAP_FILE_MAX_BYTES
> > 
> > and should work it's way back to stable trees soon.
> 
> That should fix up the file size issue.
> 
> The main problem being reported here is:
> 
> > > Kernel 5.15.68:
> > > 
> > >   root@...nWrt:/# uname -a
> > >   Linux OpenWrt 5.15.68 #0 SMP Wed Sep 21 05:54:21 2022 aarch64 GNU/Linux
> > > 
> > >   root@...nWrt:/# find /sys -name thread_siblings -exec ls -al {} \;
> > >   -r--r--r--    1 root     root     18446744073709551615 Sep 22 08:37 /sys/devices/system/cpu/cpu1/topology/thread_siblings
> > >   -r--r--r--    1 root     root     18446744073709551615 Sep 22 08:37 /sys/devices/system/cpu/cpu0/topology/thread_siblings
> > > 
> > >   root@...nWrt:/# find /sys -name thread_siblings -exec cat {} \;
> > >   root@...nWrt:/# 
> 
> Nothing in the file in 5.15, yet 5.10:
> 
> > > 
> > > Kernel 5.10.138:
> > > 
> > >   root@...nWrt:/# uname -a
> > >   Linux OpenWrt 5.10.138 #0 SMP Sat Sep 3 02:55:34 2022 aarch64 GNU/Linux
> > > 
> > >   root@...nWrt:/# find /sys -name thread_siblings -exec cat {} \;
> > >   2
> > >   1
> 
> Has data in the files.
>

Good point. My eyes latched on to that huge file size for some reason ;)

> What caused that change?

I've seen the size cause problems for tools. Are we sure that it's the empty file and not
the size causing issues?  Maybe something is treating that as signed again for a count of
-1 bytes (which seems like it would be a bug anyway)?


Cheers,
Phil

>
> thanks,
> 
> greg k-h
> 

-- 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ