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: <20220629191250.mg3dybgl6hnlnqee@bogus>
Date:   Wed, 29 Jun 2022 20:12:50 +0100
From:   Sudeep Holla <sudeep.holla@....com>
To:     Conor.Dooley@...rochip.com
Cc:     linux-kernel@...r.kernel.org, gregkh@...uxfoundation.org,
        atishp@...shpatra.org, atishp@...osinc.com,
        Sudeep Holla <sudeep.holla@....com>,
        vincent.guittot@...aro.org, dietmar.eggemann@....com,
        wangqing@...o.com, robh+dt@...nel.org, rafael@...nel.org,
        ionela.voinescu@....com, pierre.gondois@....com,
        linux-arm-kernel@...ts.infradead.org,
        linux-riscv@...ts.infradead.org, gshan@...hat.com,
        Valentina.FernandezAlanis@...rochip.com
Subject: Re: [PATCH v5 09/19] arch_topology: Use the last level cache
 information from the cacheinfo

On Wed, Jun 29, 2022 at 06:56:29PM +0000, Conor.Dooley@...rochip.com wrote:
> On 29/06/2022 19:47, Sudeep Holla wrote:
> > On Wed, Jun 29, 2022 at 06:18:25PM +0000, Conor.Dooley@...rochip.com wrote:
> >> On 29/06/2022 18:49, Conor.Dooley@...rochip.com wrote:
> >>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> >>>
> >>> On 27/06/2022 17:50, Sudeep Holla wrote:
> >>>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> >>>>
> >>>> The cacheinfo is now initialised early along with the CPU topology
> >>>> initialisation. Instead of relying on the LLC ID information parsed
> >>>> separately only with ACPI PPTT elsewhere, migrate to use the similar
> >>>> information from the cacheinfo.
> >>>>
> >>>> This is generic for both DT and ACPI systems. The ACPI LLC ID information
> >>>> parsed separately can now be removed from arch specific code.
> >>>
> >>> Hey Sudeep,
> >>> I bisected broken boot on PolarFire SoC to this patch in next-20220629 :/
> >>> I suspect the issue is a missing "next-level-cache" in the the dt:
> >>> arch/riscv/boot/dts/microchip/mpfs.dtsi
> > 
> > Good that I included this in -next, I had not received any feedback from
> > RISC-V even after 5 iterations.
> 
> I'll be honest, I saw the titles and CC list and made some incorrect
> assumptions as to whether looking at it was worthwhile! I am not at
> this all too long and what is/isn't important to look at often is not
> obvious to me.

No worries, that's why I thought better to include in -next to get some
attention and I did get it this time, hurray! 😄

> But hey, our CI boots -next every day for a reason ;)
>

Good to know and that is really great. Anyways let me know if the diff I sent
helps. I strongly suspect that is the reason, but I may be wrong.

> > I also see this DTS is very odd. It also
> > states CPU0 doesn't have L1-D$ while the other 4 CPUs have L1-D$. Is that
> > a mistake or is it the reality ?
> 
> AFAIK, reality. It's the same for the SiFive fu540 (with which this shares
> a core complex. See page 12:
> https://static.dev.sifive.com/FU540-C000-v1.0.pdf
> 
> > Another breakage in userspace cacheinfo
> > sysfs entry of cpu0 has both I$ and D$.
> 
> Could you clarify what this means please?

Ignore me if the cpu0 really doesn't have L1-D$. However the userspace
sysfs cacheinfo is incomplete without linking L2, so it can be considered
as wrong info presented to the user.

Check /sys/devices/system/cpu/cpu<n>/cache/index<i>/*.
L2 won't be present there as the link with next-level-cache is missing.
So userspace can interpret this as absence of L2.

-- 
Regards,
Sudeep

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ