linux-kernel - Re: [PATCH 5.10 00/62] 5.10.205-rc1 review

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: <2023121951-cement-repaying-f524@gregkh>
Date: Tue, 19 Dec 2023 08:29:18 +0100
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: Dominique Martinet <asmadeus@...ewreck.org>
Cc: Naresh Kamboju <naresh.kamboju@...aro.org>, stable@...r.kernel.org,
	patches@...ts.linux.dev, linux-kernel@...r.kernel.org,
	torvalds@...ux-foundation.org, akpm@...ux-foundation.org,
	linux@...ck-us.net, shuah@...nel.org, patches@...nelci.org,
	lkft-triage@...ts.linaro.org, pavel@...x.de, jonathanh@...dia.com,
	f.fainelli@...il.com, sudipm.mukherjee@...il.com,
	srw@...dewatkins.net, rwarsow@....de, conor@...nel.org,
	allen.lkml@...il.com, Maxime Ripard <maxime@...no.tech>,
	Ville Syrjälä <ville.syrjala@...ux.intel.com>,
	Daniel Vetter <daniel.vetter@...ll.ch>,
	Thomas Zimmermann <tzimmermann@...e.de>,
	Anders Roxell <anders.roxell@...aro.org>
Subject: Re: [PATCH 5.10 00/62] 5.10.205-rc1 review

On Tue, Dec 19, 2023 at 09:54:45AM +0900, Dominique Martinet wrote:
> Naresh Kamboju wrote on Mon, Dec 18, 2023 at 08:54:13PM +0530:
> > commit that is causing build failure,
> > drm/atomic: Pass the full state to CRTC atomic begin and flush
> > [ Upstream commit f6ebe9f9c9233a6114eb922aba9a0c9ccc2d2e14 ]
> 
> I also had to fix up a few nxp-provided drivers because of this commits,
> it seems a bit heavy-handed for stable trees when users can have a
> couple of out of tree modules.
> 
> It's marked as a stable dep of fe4c5f662097 ("drm/mediatek: Add spinlock
> for setting vblank event in atomic_begin") but that looks like it's only
> because of the context and it should be easy to backport that commit
> without the crtc atomic begin/flush rework -- what do you think?

Good catch, I've dropped those two larger dependent patches now and
fixed up the spinlock patch by hand to work properly.

I'll push out a -rc2 now, thanks!

greg k-h