linux-kernel - Re: [PATCH] drm/ssd130x: Fix possible uninitialized usage of crtc

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] [day] [month] [year] [list]

Message-ID: <gyf7vluuecx6nfqbm5x7xg2elxeb2zbipszeyjoklu2r7liroc@ntlwe3zkrgqb>
Date:   Tue, 31 Oct 2023 14:52:32 +0100
From:   Maxime Ripard <mripard@...nel.org>
To:     Geert Uytterhoeven <geert@...ux-m68k.org>
Cc:     Javier Martinez Canillas <javierm@...hat.com>,
        Jocelyn Falempe <jfalempe@...hat.com>,
        linux-kernel@...r.kernel.org,
        Thomas Zimmermann <tzimmermann@...e.de>,
        dri-devel@...ts.freedesktop.org,
        Dan Carpenter <dan.carpenter@...aro.org>
Subject: Re: [PATCH] drm/ssd130x: Fix possible uninitialized usage of
 crtc_state variable

On Tue, Oct 31, 2023 at 02:00:06PM +0100, Geert Uytterhoeven wrote:
> Hi Maxime,
> 
> On Tue, Oct 31, 2023 at 12:53 PM Maxime Ripard <mripard@...nel.org> wrote:
> > On Tue, Oct 31, 2023 at 12:27:05PM +0100, Javier Martinez Canillas wrote:
> > > Geert Uytterhoeven <geert@...ux-m68k.org> writes:
> > > >> >> Pushed to drm-misc (drm-misc-next). Thanks!
> > > >> >
> > > >> > Looks like you introduced an unintended
> > > >> >
> > > >> >     (cherry picked from commit 9e4db199e66d427c50458f4d72734cc4f0b92948)
> > > >> >
> > > >> > ?
> > > >>
> > > >> No, that's intended. It's added by the `dim cherry-pick` command, since I
> > > >> had to cherry-pick to drm-misc-next-fixes the commit that was already in
> > > >> the drm-misc-next branch.
> > > >>
> > > >> You will find that message in many drm commits, i.e:
> > > >>
> > > >> $ git log --oneline --grep="(cherry picked from commit" drivers/gpu/drm/ | wc -l
> > > >> 1708
> > > >
> > > > Ah, so that's why it's (way too) common to have merge conflicts between
> > > > the fixes and non-fixes drm branches :-(
> 
> > That's also not as bad as Geert put it: merging two branches with the
> > exact same commit applied won't create conflict. If the two commits
> > aren't exactly the same then we can indeed create conflicts, but that
> > would have been the case anyway with or without the "double-commits"
> 
> Oh it is, as soon as one branch receives more commits that make changes
> to the same location.  Which is fairly common, too, to the point
> that I am surprised when merging a drm for-next branch does not trigger
> a conflict...
> 
> Cfr. the conflict I had to resolve this morning between commit
> 64ffd2f1d00c6235 ("drm/amd: Disable ASPM for VI w/ all Intel systems")
> already upstream, and commits e5f52a84bf0a8170 ("drm/amd: Disable ASPM
> for VI w/ all Intel systems") and follow-up 2757a848cb0f1848
> ("drm/amd: Explicitly disable ASPM when dynamic switching disabled")
> in drm/drm-next.

I probably don't get what you're saying, sorry, but those two commits
would have conflicted anyway when merging the two branches, with or
without the cherry-pick.

Maxime

Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)