linux-kernel - Re: [PATCH v2 1/2] dt-bindings: arm: qcom: Adding DT binding for zombie

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAD=FV=UBQjKhqYsfd2bGe0JVQ_SsxQ8aHVqSJnjLa2oJavP0QQ@mail.gmail.com>
Date:   Mon, 28 Nov 2022 10:51:46 -0800
From:   Doug Anderson <dianders@...omium.org>
To:     Matthias Kaehlcke <mka@...omium.org>
Cc:     楊宗翰 <ecs.taipeikernel@...il.com>,
        LKML <linux-kernel@...r.kernel.org>,
        Bob Moragues <moragues@...omium.org>,
        Harvey <hunge@...gle.com>, Stephen Boyd <swboyd@...omium.org>,
        Andy Gross <agross@...nel.org>,
        Bjorn Andersson <andersson@...nel.org>,
        Rob Herring <robh+dt@...nel.org>, devicetree@...r.kernel.org,
        linux-arm-msm@...r.kernel.org, Abner.Yen@....com.tw,
        Gavin.Lee@....com.tw, Vicy.Lee@....com.tw, Jason.Huang@....com.tw,
        Darren.Chen@....com.tw
Subject: Re: [PATCH v2 1/2] dt-bindings: arm: qcom: Adding DT binding for zombie

Hi,

On Mon, Nov 28, 2022 at 9:07 AM Matthias Kaehlcke <mka@...omium.org> wrote:
>
> On Mon, Nov 28, 2022 at 08:20:36AM -0800, Doug Anderson wrote:
> > Hi,
> >
> > On Wed, Nov 23, 2022 at 7:07 AM Matthias Kaehlcke <mka@...omium.org> wrote:
> > >
> > > > My checkout steps as below:
> > > > $ git remote add linux_qcomÂ git://git.kernel.org/pub/scm/linux/kernel/git/
> > > > qcom/linux.git
> > > > $ git fetch --no-tags linux_qcom
> > > > $ git checkout -b <MyLocalBranchName> linux_qcom/for-next
> > > >
> > > > Is myÂ code base branch still worng?Â  Am IÂ missing something?Â
> > >
> > > My understanding is that it is best to base you changes on a branch like
> > > 'arm64-for-6.2' as the 'for-next' branch is re-created every time changes
> > > land in one of the '${area}-for-${version}' branches.
> > >
> > > No big issue in this case, just use the corresponding '${area}-for-${version}'
> > > branch for future patches/versions :)
> >
> > FWIW, I usually just use Bjron's for-next branch for stuff like this.
> > While the merge commits in the the Qualcomm "for-next" branch are
> > re-created every time, because of the way "git" works the git hashes
> > of the actual patches are the same as the git hashes of the patches in
> > the separate branches. All the patches in "for-next" should be ones
> > that are fine to base your patches on.
>
> I had minor concerns that occasionally tools might get confused it they
> try to find the parent tree of a patch based on the unstable hash of
> the merge commit in "for-next". Not sure if it is much of an issue in
> practice.

It's a fair concern, but I don't _think_ it matters. I think git is
smart enough to handle this in nearly all the cases and I think the
cases where git can't handle it are cases where (perhaps) the for-next
was the correct thing to use anyway.

As a test:

atop for-next:
echo "foo" >> arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
git add -u
git commit -m "add foo"
git format-patch HEAD~

atop arm64-for-6.2:
echo "foo" >> arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
git add -u
git commit -m "add foo arm64"
git format-patch HEAD~

If you diff the two patches created, you can see that they both
contain "index" line. In my case:

index 65601bea0797..b5c9f39737f6 100644

That appears to basically just show a hash of the affected file both
before and after your patch. The merge commits and commits to other
files don't affect this. Specifically, you can see this before making
the change

$ git hash-object -w arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
65601bea07972e75cd1ac880bd43aa3dac62fb76

...and after making the change:

$ git hash-object -w arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
b5c9f39737f67e9ba0a115355ecf95df9a04dba7


So tl;dr is that as long as the files you're touching are identical in
"for-next" and in a specific branch (like arm64-for-6.2) that the
patch files created will actually be exactly the same because all they
contain are the object hashes. You could also imagine the files being
_not_ exactly the same. If two different branches touched the same
file and were merged into "for-next" then it could make a difference.
In that case, though, it would still at least be a plausible choice to
post it against the "for-next" branch because that should represent
the final state.

-Doug