linux-kernel - Re: [PATCH 0/8] Intel PMC Core GBE LTR regression fix

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: <f51a4bc1-b38c-43c0-8e8a-28463c49c1f6@redhat.com>
Date: Thu, 28 Dec 2023 10:35:06 +0100
From: Hans de Goede <hdegoede@...hat.com>
To: Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>,
 "David E. Box" <david.e.box@...ux.intel.com>
Cc: rajvi.jingar@...ux.intel.com, platform-driver-x86@...r.kernel.org,
 LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 0/8] Intel PMC Core GBE LTR regression fix

Hi,

On 12/27/23 19:14, Ilpo Järvinen wrote:
> On Fri, 22 Dec 2023, David E. Box wrote:
> 
>> This patch series addresses the network performance regression caused by
>> commit 804951203aa5 ("platform/x86:intel/pmc: Combine core_init() and
>> core_configure()").
>>
>> Unfortunately, the regression is included in the recent Lunar Lake and
>> Arrow Lake support patches in the review branch. Patches 1 and 2 remove the
>> LTR ignore without a fix. They may be folded into the respective enabling
>> patches indicated in the changelog. This is done so that the next patches
>> fixing the regression can be backported to stable kernels with fewer, if
>> any, conflicts.
>>
>> Patches 3 and 4 provide the support needed for Patch 5 to move the GBE LTR
>> ignore from probe-time to suspend/resume time. All three carry the same
>> Fixes tag so that the stable kernels can pick them up without causing a
>> separate suspend-time PC10 regression.
>>
>> Patches 6 and 7 then add the LTR suspend/resume fix for Arrow Lake and
>> Lunar Lake. Of course, they cannot be folded into the enabling patches
>> unless the LTR fixes (3-5) are applied before. Sorry about this :(.
> 
> Wow, this is messy...
> 
> So the best order would be placing 3-5 before these Arrow Lake and Lunar 
> Lake commits in for-next:
>   119652b855e6 ("platform/x86/intel/pmc: Add Lunar Lake M support to intel_pmc_core driver")
>   f34dcf397286 ("platform/x86/intel/pmc: Add Arrow Lake S support to intel_pmc_core driver")
> ? And then folding 1-2 and 6-7 into those respective commits?
> 
> It makes me wonder though why those two commits couldn't have been delayed 
> slightly to get these fixes included first... :-/

To untangle this mess I have squashed patches 1-2 into the original
commits in for-next, so that there won't be a conflict
between next and fixes when merging patches 3-5 into fixes.

Ilpo can you pick-up patches 3-5 for the fixes branch ?

And maybe also "platform/x86: p2sb: Allow p2sb_bar() calls during PCI
device probe" fix ? I know you have a small review comment on this patch,
but IMHO waiting for the small unrelated cleanup to be split out is not
worth delaying this deadlock fix. As for the missing fixes tag I believe
that should be:

Fixes: 9745fb07474f ("platform/x86/intel: Add Primary to Sideband (P2SB) bridge support")

And then do one more fixes pull-request for the GBT LTR fixes +
the P2SB deadlock fix ?

I know it is the holiday season, but if you feel up to it,
it would be nice to get those fixes on their way to Linus
and the stable kernels a bit earlier then before 6.8-rc1 .

I'll merge patches 6-8 into for-next then after back-merging
the fixes.

Regards,

Hans