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

Message-ID: <2eh6i4ttpepnpehw47zucgrs3rvzugxiay7eqy65phktcm2m4r@zwzyn5rn55yl>
Date:   Tue, 31 Oct 2023 12:53:35 +0100
From:   Maxime Ripard <mripard@...nel.org>
To:     Javier Martinez Canillas <javierm@...hat.com>
Cc:     Geert Uytterhoeven <geert@...ux-m68k.org>,
        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 12:27:05PM +0100, Javier Martinez Canillas wrote:
> Geert Uytterhoeven <geert@...ux-m68k.org> writes:
> 
> > Hi Javier,
> 
> [...]
> 
> >> >> 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 :-(
> >
> 
> I guess so. In this particular case it was my fault because I pushed to
> drm-misc-next with the expectation that there would be a last PR before
> the drm-next tree was sent to Torvalds but I missed for a few hours...
>
> So then I had the option for the fixes to miss 6.7 and wait to land in
> 6.8, or cherry-pick them to the drm-misc-next-fixes branch and pollute
> the git history log :(

Yeah, it's the downside of having so many committers, we have to expect
that people are going to make small mistakes every now and then and
that's ok.

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"

Maxime

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