linux-kernel - Re: Determining corresponding mainline patch for stable patches Re: [PATCH 5.10 125/135] drm/i915: avoid uninitialised var in eb

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]

Date:   Fri, 13 Aug 2021 12:24:29 +0200
From:   Pavel Machek <pavel@...x.de>
To:     Willy Tarreau <w@....eu>
Cc:     Pavel Machek <pavel@...x.de>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-kernel@...r.kernel.org, stable@...r.kernel.org,
        jason@...kstrand.net, Jonathan Gray <jsg@....id.au>
Subject: Re: Determining corresponding mainline patch for stable patches Re:
 [PATCH 5.10 125/135] drm/i915: avoid uninitialised var in eb_parse()

On Fri 2021-08-13 11:54:29, Willy Tarreau wrote:
> Hi Pavel,
> 
> On Fri, Aug 13, 2021 at 11:31:04AM +0200, Pavel Machek wrote:
> > > > If we could agree on
> > > > 
> > > > Commit: (SHA)
> > > > 
> > > > in the beggining of body, that would be great.
> > > > 
> > > > Upstream: (SHA)
> > > > 
> > > > in sign-off area would be even better.
> > > 
> > > What exactly are you trying to do when you find a sha1?  For some reason
> > > my scripts work just fine with a semi-free-form way that we currently
> > > have been doing this for the past 17+ years.  What are you attempting to
> > > do that requires such a fixed format?
> > 
> > Is there any problem having a fixed format? You are producing -stable
> > kernels, so you are not the one needing such functionality.
> 
> When I was doing extended LTS in the past, I used to restart from
> Greg's closest branch (e.g. 4.4.y for latest 3.10.y) and needed
> exactly that. It was pretty easy in the end, as you'll essentially
> find two formats (one form from net and the other for the rest of
> the patches):
> 
>   - commit XXXX upstream
>   - [ Upstream commit XXXX ]
> 
> I ended up writing this trivial script that did the job well for me
> and also supported the "git cherry-pick -x" format that I was using
> a lot. Feel free to reuse that as a starting point, here it comes, a
> bit covered in dust :-)

Please see previous discussion. Yes, I have my regexps, too, but there
are variations, and there were even false positives.. One of them is
in this email thread.

Greg suggests to simply ignore context and look for SHA1 sum; that
does not work, either.

So what I'm asking is for single, easy to parse format. I don't quite
care what it is, but

Upstream: (SHA)

would be best.

Best regards,
								Pavel


> Willy
> 
> #!/bin/bash
> 
> die() {
>         [ "$#" -eq 0 ] || echo "$*" >&2
>         exit 1
> }
> 
> [ -n "$1" ] || die "Usage: ${0##*/} <commit>|<file>"
> 
> upstream=( )
> if [ -s "$1" ]; then
>         upstream=( $(sed -n -e '/^$/,/^./s/^commit \([0-9a-f]*\) upstream\.$/\1/p' \
>                             -e 's/^\[ Upstream commit \([0-9a-f]*\) \]$/\1/p' \
>                             -e 's/^(cherry picked from commit \([0-9a-f]*\))/\1/p' "$1") )
> else
>         upstream=( $(git log -1 --pretty --format=%B "$1" | \
>                      sed -n -e '1,3s/^commit \([0-9a-f]*\) upstream\.$/\1/p' \
>                             -e 's/^\[ Upstream commit \([0-9a-f]*\) \]$/\1/p' \
>                             -e 's/^(cherry picked from commit \([0-9a-f]*\))/\1/p') )
> fi
> 
> [ "${#upstream[@]}" -gt 0 ] || die "No upstream commit ID found."
> 
> echo "${upstream[0]}"

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

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