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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <eb9c49c5-f74d-7b69-f5ae-2b18d174dfe8@linux.intel.com>
Date: Thu, 28 Dec 2023 17:38:56 +0200 (EET)
From: Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>
To: Hans de Goede <hdegoede@...hat.com>
cc: "David E. Box" <david.e.box@...ux.intel.com>, 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

On Thu, 28 Dec 2023, Hans de Goede wrote:
> 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.

Dream on, there will be conflicts, rest assured...

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

I've now done that and resolved a few conflicts while doing so which 
you'll encounter while back-merging.

> 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 .

They're in the hands of lkp.

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

-- 
 i.