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, 20 Sep 2023 14:33:18 +0200
From:   "Linux regression tracking (Thorsten Leemhuis)" 
        <regressions@...mhuis.info>
To:     Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>,
        Jiaxun Yang <jiaxun.yang@...goat.com>
Cc:     Huacai Chen <chenhuacai@...nel.org>, linux-pci@...r.kernel.org,
        bhelgaas@...gle.com, linux-kernel@...r.kernel.org, kw@...ux.com,
        lpieralisi@...nel.org, stable@...r.kernel.org,
        Linux kernel regressions list <regressions@...ts.linux.dev>
Subject: Re: [PATCH v2] pci: loongson: Workaround MIPS firmware MRRS settings

[CCing the regression list, as it should be in the loop for regressions:
https://docs.kernel.org/admin-guide/reporting-regressions.html]

On 07.09.23 07:08, Manivannan Sadhasivam wrote:
> On Thu, Sep 07, 2023 at 11:13:00AM +0800, Jiaxun Yang wrote:
>> 在 2023/9/7 9:18, Manivannan Sadhasivam 写道:
>> [...]
>>> Why do you need to walk through every single device instead of just bridges?
>>> I'm not the maintainer, but my suggestion is to go for Huacai Chen's solution.
>>
>> Thanks for your reply, unfortunately Huacai's solution is impractical in
>> this case.
>>
>> The problem we have, is firmware (or BIOS) setting improper MRRS for devices
>> attached under those bridges. So we have to fix up MRRS for every single
>> device.
>> We can't iterate child device in bridge quirk because there is no guarantee
>> that
>> bridge will be probed before  it's child device, partly due to hotplug.
> 
> Okay, this clarifies and also warrants improvement in commit message.
> 
> You could also use pci_walk_bus() after pci_host_probe() to iterate over the
> child devices under root bridge and set MRRS. IMO that would look neat.

Hi, Thorsten here, the Linux kernel's regression tracker. What's the
status here? The regression that was supposed to be fixed by the patched
that started this thread was reported 9 weeks ago[1] and the culprit
made it to many stable kernels as well. Would be really good to finally
fix this, as a regression like this should ideally be fixed within 2 to
3 weeks (in both mainline and stable). With a revert if necessary -- is
this maybe still a option, or would that cause more trouble then it
solved (I guess that's the case).

[1] https://bugzilla.kernel.org/show_bug.cgi?id=217680

Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
--
Everything you wanna know about Linux kernel regression tracking:
https://linux-regtracking.leemhuis.info/about/#tldr
If I did something stupid, please tell me, as explained on that page.

>> This quirk has been in tree for a while, until Huacai refactored it and
>> broke some
>> systems in 8b3517f88ff2 ("PCI: loongson: Prevent LS7A MRRS increases").
>>
>> Also to note that ks_pcie_quirk in drivers/pci/controller/dwc/pci-keystone.c
>> uses similar approach.
>>> This avoids iterating over bridges/devices two times.
>>>
>>> Also, please rename firmware to BIOS, as firmware commonly represents the
>>> software running on PCIe endpoint devices.
>> Ack, will fix in next reversion.
>>
>> Thanks
>> - Jiaxun
>>>
>>> - Mani
>> [...]
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ