linux-kernel - Re: aarch64 5.15.68 regression in topology/thread

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]

Message-ID: <Yyxgtx/Vr6Ar1xEe@lorien.usersys.redhat.com>
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
> 

--