| 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
| ||
|
Message-ID: <Yyh7U/QgJXmOr6Ff@dev-arch.thelio-3990X>
Date: Mon, 19 Sep 2022 07:23:15 -0700
From: Nathan Chancellor <nathan@...nel.org>
To: Geert Uytterhoeven <geert@...ux-m68k.org>
Cc: Stephen Rothwell <sfr@...b.auug.org.au>,
Dave Airlie <airlied@...hat.com>,
DRI <dri-devel@...ts.freedesktop.org>,
Alex Deucher <alexander.deucher@....com>,
Hamza Mahfooz <hamza.mahfooz@....com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Linux Next Mailing List <linux-next@...r.kernel.org>,
Rodrigo Siqueira <Rodrigo.Siqueira@....com>
Subject: Re: linux-next: manual merge of the drm tree with Linus' tree
Hi Geert,
On Mon, Sep 19, 2022 at 09:58:01AM +0200, Geert Uytterhoeven wrote:
> Hi Stephen,
>
> On Mon, Sep 19, 2022 at 3:07 AM Stephen Rothwell <sfr@...b.auug.org.au> wrote:
> > Today's linux-next merge of the drm tree got a conflict in:
> >
> > drivers/gpu/drm/amd/display/dc/dml/dcn30/display_mode_vba_30.c
> >
> > between commit:
> >
> > 41012d715d5d ("drm/amd/display: Mark dml30's UseMinimumDCFCLK() as noinline for stack usage")
> >
> > from Linus' tree and commit:
> >
> > a0f7e7f759cf ("drm/amd/display: fix i386 frame size warning")
> >
> > from the drm tree.
> >
> > I fixed it up (see below) and can carry the fix as necessary. This
> > is now fixed as far as linux-next is concerned, but any non trivial
> > conflicts should be mentioned to your upstream maintainer when your tree
> > is submitted for merging. You may also want to consider cooperating
> > with the maintainer of the conflicting tree to minimise any particularly
> > complex conflicts.
> >
> > --
> > Cheers,
> > Stephen Rothwell
> >
> > diff --cc drivers/gpu/drm/amd/display/dc/dml/dcn30/display_mode_vba_30.c
> > index 1cb858dd6ea0,b7fa003ffe06..000000000000
> > --- a/drivers/gpu/drm/amd/display/dc/dml/dcn30/display_mode_vba_30.c
> > +++ b/drivers/gpu/drm/amd/display/dc/dml/dcn30/display_mode_vba_30.c
> > @@@ -6610,66 -6497,11 +6497,11 @@@ static double CalculateUrgentLatency
> > return ret;
> > }
> >
> > -static void UseMinimumDCFCLK(
> > +static noinline_for_stack void UseMinimumDCFCLK(
>
> While this looks like the correct merge resolution, it does mean that
> both stack size mitigations are now applied, and probably one of them
> can be dropped?
Thanks for taking a look! As I note in the commit message of
41012d715d5d:
"Commit a0f7e7f759cf ("drm/amd/display: fix i386 frame size warning")
aimed to address this for i386 but it did not help x86_64.
... The aforementioned change does help reduce UseMinimumDCFCLK()'s
stack usage so it should not be reverted in favor of this change."
While it is possible that 41012d715d5d fixes the warning for both 32-bit
and 64-bit x86 (I did not check), a0f7e7f759cf is still a good change in
my opinion so neither should be reverted.
Cheers,
Nathan
> > struct display_mode_lib *mode_lib,
> > - int MaxInterDCNTileRepeaters,
> > + struct vba_vars_st *v,
> > int MaxPrefetchMode,
> > - double FinalDRAMClockChangeLatency,
> > - double SREnterPlusExitTime,
> > - int ReturnBusWidth,
> > - int RoundTripPingLatencyCycles,
> > - int ReorderingBytes,
> > - int PixelChunkSizeInKByte,
> > - int MetaChunkSize,
> > - bool GPUVMEnable,
> > - int GPUVMMaxPageTableLevels,
> > - bool HostVMEnable,
> > - int NumberOfActivePlanes,
> > - double HostVMMinPageSize,
> > - int HostVMMaxNonCachedPageTableLevels,
> > - bool DynamicMetadataVMEnabled,
> > - enum immediate_flip_requirement ImmediateFlipRequirement,
> > - bool ProgressiveToInterlaceUnitInOPP,
> > - double MaxAveragePercentOfIdealSDPPortBWDisplayCanUseInNormalSystemOperation,
> > - double PercentOfIdealDRAMFabricAndSDPPortBWReceivedAfterUrgLatencyPixelMixedWithVMData,
> > - double PercentOfIdealDRAMFabricAndSDPPortBWReceivedAfterUrgLatencyVMDataOnly,
> > - double PercentOfIdealDRAMFabricAndSDPPortBWReceivedAfterUrgLatencyPixelDataOnly,
> > - int VTotal[],
> > - int VActive[],
> > - int DynamicMetadataTransmittedBytes[],
> > - int DynamicMetadataLinesBeforeActiveRequired[],
> > - bool Interlace[],
> > - double RequiredDPPCLK[][2][DC__NUM_DPP__MAX],
> > - double RequiredDISPCLK[][2],
> > - double UrgLatency[],
> > - unsigned int NoOfDPP[][2][DC__NUM_DPP__MAX],
> > - double ProjectedDCFCLKDeepSleep[][2],
> > - double MaximumVStartup[][2][DC__NUM_DPP__MAX],
> > - double TotalVActivePixelBandwidth[][2],
> > - double TotalVActiveCursorBandwidth[][2],
> > - double TotalMetaRowBandwidth[][2],
> > - double TotalDPTERowBandwidth[][2],
> > - unsigned int TotalNumberOfActiveDPP[][2],
> > - unsigned int TotalNumberOfDCCActiveDPP[][2],
> > - int dpte_group_bytes[],
> > - double PrefetchLinesY[][2][DC__NUM_DPP__MAX],
> > - double PrefetchLinesC[][2][DC__NUM_DPP__MAX],
> > - unsigned int swath_width_luma_ub_all_states[][2][DC__NUM_DPP__MAX],
> > - unsigned int swath_width_chroma_ub_all_states[][2][DC__NUM_DPP__MAX],
> > - int BytePerPixelY[],
> > - int BytePerPixelC[],
> > - int HTotal[],
> > - double PixelClock[],
> > - double PDEAndMetaPTEBytesPerFrame[][2][DC__NUM_DPP__MAX],
> > - double DPTEBytesPerRow[][2][DC__NUM_DPP__MAX],
> > - double MetaRowBytes[][2][DC__NUM_DPP__MAX],
> > - bool DynamicMetadataEnable[],
> > - double VActivePixelBandwidth[][2][DC__NUM_DPP__MAX],
> > - double VActiveCursorBandwidth[][2][DC__NUM_DPP__MAX],
> > - double ReadBandwidthLuma[],
> > - double ReadBandwidthChroma[],
> > - double DCFCLKPerState[],
> > - double DCFCLKState[][2])
> > + int ReorderingBytes)
> > {
> > double NormalEfficiency = 0;
> > double PTEEfficiency = 0;
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> -- Linus Torvalds
Powered by blists - more mailing lists